[Babel-users] SOLVED - routes appearing later than hoped-for

[Christof Schulze]

Juliuszm

>Christof, I'm very much interested in your experiments, which are likely
>to improve the quality of the Babel implementations.
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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20180308/0d1a1431/attachment.sig>