Juliuszm
I like to share what I do. Will you be in Berlin for the BattleMesh this year? In either case, there is already some documentation for it and I think there will be more now that we broaden the testing.Christof, I'm very much interested in your experiments, which are likely to improve the quality of the Babel implementations.
For the moment I have mostly done work on the l3roamd and gluon/openwrt-integration and not so much on babel itself. Initial testing shows that this l3roamd/gluon part is now usable in our testbed. There is still quite a bit to be done but the most important issue now is (used to be) the latency incurred by route-distribution when depending on intervals expiring.
Using babel master indeed resolves the issue.A proof-of-concept for this type of network was made with babel 1.7 where changed routes seems to have been interchanged much more frequently. A roaming client and it's corresponding routes were updated instantaneous (milliseconds).
> We have update-interval set to 5 minutes to reduce the load on the > network because we are hoping to run this topology on 500+ Aps with > 1000+ Clients.
The protocol is very flexible, but the reference implementation is not designed to work with such large update intervals. The amount of data in an update is pretty small, so I would recommend reducing the update interval -- it should be fine with thousands of routes in your network.Based on this, I think I will go with the default of 16s again.
The right way to reduce the amount of routing traffic in Babel is not to increase the update interval (which can at best yield a linear reduction), but to use aggregation and filtering (which can yield an exponential decrease in a well designed network). Dave Taht has been successful with this approach, perhaps he'll want to chime in.I would very much like to learn about this. The network however is a little special since we are using host-routes only instead of one /64 prefix for each AP.
Note that babeld currently sends updates as a single burst when the upate interval expires (the same is true of Toke's implementation of Babel, as far as I'm aware). For very large networks, it would be good to split updates into one-packet pieces that are sent throughout the update interval. I'd be glad to accept a patch that does that.I also think sending a routing update whenever a packet is full to be beneficial. However the bursty behavior you describe is actually not a problem yet because our test network is still very small with only few routes changing at a time.
Adding just one to three routes to the network would very likely not lead to packets for updates being full. Also the new routes must be known on every AP along the whole path up to the gateway. Triggering an update on just one babeld instance in the network is not enough to resolve the situation.
> * making babel trigger updates on newly appeared routes I've gone through different approaches for scheduling updtes, and the current master is more aggressive with scheduling updates. I'd need to check to make sure, but I believe it already does what you suggest. If you have time, could you please check if current master improves things; if it doesn't, we need to work together to improve the implementation (no protocol changes will be needed).
You could also try Toke's implementation, which is very well written.
> * communicating the appearance of a route across the network outside > babel and inserting that at the gateway
I'm not sure what you mean.
This is solved with babel-master. What I meant is the following:The situation is that on one instance of l3roamd in the network a search was triggered. At another location a different instance of l3roamd has already learnt the new IP-address and added an appropriate route into the local kernels routing table. Communication is still not possible because babel has not distributed the new route.
I could in theory send a unicast packet from the local l3roamd that knows the IP towards the l3roamd that triggered a seek containing necessary information to insert a temporary route for the client-IP pointing to the AP having the client connected. This would handle the situation outside the scope of babel and the fast-connection and roaming-features would not rely on babel. This also means that on a large network the babel-situation could be tuned to low-packet-count instead of low-latency. Low packet count in this type of large network is very important, especially since we are using VPN in user-space at the moment (fastd). This would however be a layering violation because then the daemon meant to search IP-addresses/routes (l3roamd) would be doing route distribution wich really is babels domain.
I am hesitant to implement this because that would require l3roamd to identify all the AP on the path and then sending them routing updates. This is way more complicated than a solution in babel. I am glad, master does it already.
> What do you think about those approaches?
Please try current master. If not, we'll need to think together about redesigning our approach to sending triggered updates.I tried the current master and it seems that this issue indeed is resolved. I almost immediately see an update and I also see quick route distribution. Thank you very much for the hint!
Now all we need is some more testing. :)I wasn't aware of Toke's implementation of babel so far. Why are there two?
Christof -- () ascii ribbon campaign - against html e-mail /\ against proprietary attachments
signature.asc
Description: PGP signature
_______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
