Re: [Babel-users] Route-dete:wq

[Christof Schulze]

Hello,

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?

Regards

Christof




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
>>down.

>>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:

>>   https://github.com/Vivena/babelweb2

>>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
>
>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/20180306/5dbd036e/attachment.sig>