[Babel-users] babel export routes from bird to routing table?

[Christof Schulze]

Hello Juliusz,

>> At a later stage I would like to announce different default-routes at
>> different places in the mesh network.
>Why?
I am working on integrating babel into gluon, which is a framework for 
building freifunk-firmwares.
Freifunk is a project where large, mostly wifi, mesh networks are built to 
enable open wifi access throughout a city. In Frankfurt the Freifunk 
Network consists of roughly 500 concurrent cheap wifi routers. Besides 
wifi about 2/3 of these routers are running vpn connections to one of a 
few servers to get parts of the network connected that do not have a 
direct wifi connection.

At the moment batman is used as mesh protocol for this network. Batman 
works but has the drawback that we are reaching the limits of what the 
protocol can handle due to saturation effects on relatively small VPN 
Uplinks on DSL. Mostly little packets saturate the links without even 
using a lot of bandwidth. There is not much room for scaling to more 
network nodes. The current network can be seen here: Http://map.ffm.freifunk.net

I, among others who are also working on this, am very interested in 
trying a layer 3 mesh network in the hope that the resulting network 
will scale significantly better.

The architecture of the network currently mandates that all traffic that 
is directed towards the internet is passed through the VPN-links to the 
central servers and then routed either directly or through a VPN link 
into the internet. Again, this is a solution that works but it is not 
ideal. We are hoping to build a de-central mesh network yet for the 
moment we have to rely on central dhcp-servers and central routing 
towards the internet.

Running an l3-mesh might provide other solutions like locally announcing 
public ipv6 prefixes and routing traffic directly. For that a smart 
RA-filter must be implemented that allows for the best (whatever that 
means) RAs to reach clients. Those would then use local connections for 
their internet routing needs and central infrastructure would not be 
necessary any more.

A short status of the project (sorry it is german only) is collected 
here: https://wiki.ffm.freifunk.net/firmware:babel
In Short: the network is actually working in a lab environment (babel, 
mmfd, l3roamd) we yet have to put work into monitoring and fixing 
mtu-issues. The network is IPv6-only at the moment though there is work 
on getting a distributed dhcp server integrated, which is already 
working in a lab environment as well. For now I am hoping that building 
an IPv6-only network will suffice, knowing that some kind of translation 
is necessary at some point in the network to reach IPv4-only parts of 
the internet (pretty much everything besides google).

The basic principles of the network are covered here: 
Https://www.nilsschneider.net/2016/04/10/babel-in-gluon.html

This is a quick run-through on what I am hoping to achieve. In the end 
there will likely still be gateways but they will be one of many 
different exit points towards the internet and the wifi network will 
work without a connection to a gateway. 

      VPN/GRE
         |
      Gateway
         |
         |
Uplink -Node1 --- Node 2 --- Client

In a scenario where Internet Access is provided through the Prefix 
shared by the Gateway (let's call that G) and through a locally shared 
prefix (lets call that P) on Node1 the Ras from Node1 should pass the 
wifi-mesh-only Node2 and reach the client by means of a custom software 
that will be called prefixd. At the moment source based routing is used 
on gateways only.
At the moment Clients use IP-Addresses within G. In the future, clients 
should use IP-Addresses within G and P, using P as means of reaching the 
Internet. There may be a couple more locally shared public prefixes 
available to the client too, which it may or may not use.
It seems to be that Source Based Routing may not be necessary on Node1 
even though that would lead to asymmetric traffic flows. Fortunately 
IPv6 should be able to handle this correctly.

>> It seems to me like I might be better off not using table 12 as an
>> import-route so any static default routes on the gateway-side will not
>> interfere with whatever babeld is announcing. What do you think?
>
>That you should tell us what you're trying to achieve, so we can think
>together how best to meet your requirements.  I suspect you need
>source-specific routing, but since I don't know what you're trying to do,
>it's difficult to say.
Having considered all of the above it seems that I only need to add 
another default-route on Node1. In an ideal world the client would also 
pick prefix P for traffic directed towards the internet and Node2 would 
help the client to do that.
A solution with Source Based Routing seems possible too, which would 
prevent connections with unexpected IP prefixes to show up in the Uplink 
of Node1. This would probably require me to set up a different routing 
table for each Prefix dynamically. This mechanism would have to consider 
G, P and all other locally shared global prefixes (P1-Pn) that are 
announced in proximity of Node 1. So it seems a lot more complicated.

Sorry for this lengthy reply to your short question. This may not even 
be a babel question any more because it is more about routing, but maybe 
babel can assist to make the right routing decisions.


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: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20170102/6b152298/attachment.sig>