Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Traffic shaping to softly redirect nodes away #90

Open
rubo77 opened this issue Feb 18, 2015 · 7 comments
Open

Traffic shaping to softly redirect nodes away #90

rubo77 opened this issue Feb 18, 2015 · 7 comments

Comments

@rubo77
Copy link
Contributor

rubo77 commented Feb 18, 2015

We should add traffic shaping with tc in the puppet script. So you can define after how many TeraByte the latency goes up.

This way we can redirect all Nodes from the gateway when the overall limit of your provider is nearly reached

https://wiki.debian.org/TrafficControl

@rubo77 rubo77 changed the title Traffic shaping Traffic shaping to softly redirect nodes away Feb 18, 2015
@ohrensessel
Copy link
Contributor

just use the maintenance mode, which leads to clients switching to another gateway. after some transitional period you can also disable fastd then

@BenBE
Copy link

BenBE commented Feb 18, 2015

As BATMAN ATM mostly uses the latency of nodes for the routing decision simple DHCP lease expiry might not be enough to redirect clients gracefully. The idea on the traffic shaping is to add incentives for BATMAN to switch to another gateway without limiting bandwidth for doing so (e.g. by increasing the latency to about 500-2000ms). While this makes client connection establishment a bit slower it doesn't slow traffic once a connection is upü and running.

The bandwidth limiting is best applied on the host system, but may be a separate option in the puppet scripts too.

@ohrensessel
Copy link
Contributor

with maintenance mode on, dhcp and radvd are disabled. in this case a client starts to use another gateway when its address has "expired" (lifetime for RAs, lease-time for dhcp). that way the gateway is switched and the fastd tunnel can be disabled after some time. at least this is my experience.

apart from that: I do not understand where you want to apply your increase-latency-by-tc stuff. does it really help for your case when client traffic is shaped?

@ohrensessel
Copy link
Contributor

sry clicked the wrong button :)

@sargon
Copy link
Contributor

sargon commented Feb 19, 2015

I think I know what is the real topic here. We have some gateways where the gateway provider uses the machine for other cases also and the gateway functionality is producing too much traffic for the situation.

Turning on the maintenance mode will not ultimately route away all the traffic. Since we have a mesh in the vpn, two connection per node. When both of the gateways go into maintenance it is hard to predict which one will forward the traffic to the destination.

@rubo77
Copy link
Contributor Author

rubo77 commented Feb 19, 2015

Setting up the latency with tc could also be an option for the maintenance mode. When the maintenance mode switches on, it increases the latency and resets back to minimum when maintenance is off

@sargon
Copy link
Contributor

sargon commented Feb 20, 2015

Introducing tc to the setup would force us to start mark the packets again.
Which we previously designed away, to remove a source of funny errors and inconsistent behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants