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

[Benjamin Henrion]

On Mon, Jan 2, 2017 at 9:09 AM, Christof Schulze
 wrote:
> 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.

You could try to reduce the interval of the probes to a test every 2
minutes, or even more, which is enough for a highly static network.

There is no need to pollute the network with routing traffic if you
have a highly static network (not mobile).

I remember a comment of Juliusz saying he reverted back some change
for the defaults to a more frequent value because because some users
were complaining, don't remember what was the parameter in babel.conf
though.

Best,

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

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

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

[Christof Schulze]

Hi Juliusz,

Thank you very much for your response.


* I am aware that babel 1.8 is not stable yet.


It's stable -- I just need to take the time to do a release.
Great to hear! :) I have not seen any weird behavior in my tests with 
a small amount of nodes.


> As Babel 1.8 will be incompatible to 1.7 


Babeld 1.8 will be fully compatible with 1.7. It's babeld 1.9 which 
will change the source-specific routing extension, and that extension 
only.  If you're not using source-specific routing (SADR), you won't 
see any incompatibilities. 
This is also great to hear, I took this from the changelog that is 
mentioning incompatible changes. 

> So babel actually is placing a route in table 10 but not the default 
> route that bird has placed in table 12. How would I achieve that? 


I think there's a misunderstanding. Babeld will not copy routes from 
import-table into export-table. It will: 


- announce routes found in export-table over the Babel protocol; - 
install any routes learned over the Babel protocol into import-table. 


If there's an unfiltered default route in table 12 (your import-table), 
it will be announced to neighbouring nodes, and will prevent babeld 
from learning any default routes (since redistributed routes take 
priority over routes being learned). 


The solution to your problem is to use both tables when forwarding 
packets, something like: 



ip rule add prio 10 from all lookup 10
ip rule add prio 11 from all lookup 11
ip rule add prio 12 from all lookup 12


If you really need the routes to be copied between the tables, please 
let us know why, and we'll see if it's really a needed feature. 


Thank you, this solution works. At a later stage I would like to 
announce different default-routes at different places in the mesh 
network. 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?


Christof

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



signature.asc
Description: Digital signature
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

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

[Juliusz Chroboczek]

Hi Christof,

> * I am aware that babel 1.8 is not stable yet.

It's stable -- I just need to take the time to do a release.

> As Babel 1.8 will be incompatible to 1.7

Babeld 1.8 will be fully compatible with 1.7.  It's babeld 1.9 which will
change the source-specific routing extension, and that extension only.  If
you're not using source-specific routing (SADR), you won't see any
incompatibilities.

> So babel actually is placing a route in table 10 but not the default route
> that bird has placed in table 12. How would I achieve that?

I think there's a misunderstanding.  Babeld will not copy routes from
import-table into export-table.  It will:

  - announce routes found in export-table over the Babel protocol;
  - install any routes learned over the Babel protocol into import-table.

If there's an unfiltered default route in table 12 (your import-table), it
will be announced to neighbouring nodes, and will prevent babeld from
learning any default routes (since redistributed routes take priority over
routes being learned).

The solution to your problem is to use both tables when forwarding packets,
something like:

ip rule add prio 10 from all lookup 10
ip rule add prio 11 from all lookup 11
ip rule add prio 12 from all lookup 12

If you really need the routes to be copied between the tables, please let
us know why, and we'll see if it's really a needed feature.

-- Juliusz



___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users