-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
just use the maintenance mode, which leads to clients switching to another gateway. after some transitional period you can also disable fastd then |
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. |
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? |
sry clicked the wrong button :) |
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. |
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 |
Introducing tc to the setup would force us to start mark the packets again. |
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
The text was updated successfully, but these errors were encountered: