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

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

Reply via email to