When using babeld in a Freifunk network, I am seeing an issue with network convergence on newly appearing routes in this topology:

Client ==== AP1 ==== AP2 === Gateway === (INTERNET) ===remote host
Each client has a /128 address and /128 route inside the same /64 net-wide prefix. Client roaming is handled by detecting where clients are connected and having babel work out which routes need to be set. 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.

Currently the following happens when a Client connects to AP1:

1 A client connects to a local access point. It will grab one or more ipv6 IP-addresses based on RA sent by uradvd running locally on this AP and start using this IPv6 address. 2 the client will initiate a connection to somewhere else, let's say to the internet and send a packet towards some remote host.
3 Using routing, the request will be delivered to the remote host.
4 The remote host will reply, the reply is delivered to the first gateway inside the Freifunk network which is acting as border router for the network. At this point no route towards the client's IP, the destination of the response, is known to this gateway. Therefore a seek-operation (implemented by l3roamd) is triggered. 5 l3roamd will check locally on all client interfaces using NDP whether a client having this IP is connected and it will query the l3roamd processes on neighbouring nodes to do the same.
6 AP2 checks locally and asks AP1 to do the same
7 AP1 checks locally, detects that a client using this new IP-address is connected locally and inserts a host-route into its local routing table 8 The user of the client is experiencing a no-connection-situation be cause no route from the gateway to the client is known until... 9 After the update-interval is expired (possibly minutes) babeld triggers an update, the routes are then known to AP2, and successively to the Gateway where babeld will insert routes towards the next-hops for this new IP to AP1/AP2 respectively upon which point the gateway can route it's packets towards the correct destination. 10 the l3roamd running on the gateway flushes its internal packet buffer and now the client has connectivity What can I sensibly do to shorten the time where the client does not appear to have internet connectivity in step 8/9?

possible solutions that come to my mind are:
* making babel trigger updates on newly appeared routes
* communicating the appearance of a route across the network outside babel and inserting that at the gateway

What do you think about those approaches?



On Fri, Feb 09, 2018 at 09:12:11PM +0100, Christof Schulze wrote:

You're probably just seeing fallback routes.  (We'd need to see your dump
to be sure.)

Babel keeps a redundant routing table -- it keeps routes to every
destination through every single neighbour.  This way, it can switch to
a different route immediately when it detects that its current next-hop is

If you have 10 neighbours and there are 60 routes in the network, you'll
see 600 routes in your routing table.  Don't worry, though -- a fallback
route is just a 60-byte data structure, so 600 routes take less than 40kB
of memory.  (Fallback routes are not visible to the kernel, and are not
announced over the network.)

You can distinguish between redundant routes and the routes actually used
by the "installed" flag -- a route that is marked as "installed" is
currently used for traffic, a route that is marked as "feasible" is
a fallback route that can be used straight away if necessary, a route that
is not marked is an "unfeasible" route, one that cannot be used without
doing a quick packet exchange to make sure that it is loop-free.

My advice would be:

- don't panic, in large, friendly letters;
- only start worrying if babeld starts having a large RSS or uses more
  than a fraction of CPU;
- use BabelWeb in order to better understand better what's going on in
  your network:


Please don't hesitate to send me a route dump (through the list or, if
you're concerned about your users' privacy, by private mail), I'd be
curious to see what's going on.

Thanks for the input,
I have sent a reply off-list containing routes and dump from babel. Unfortunately in my tiny network a 3 digit number of routes is actually installed.

viele Grüße

()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments

Attachment: signature.asc
Description: PGP signature

Babel-users mailing list

Reply via email to