[Babel-users] Fwd: Why we switched to Babel

[max b]

Marc will probably chime in here as we had plenty of sit downs trying to
figure out how to incorporate BATMAN into our topology, but I (hope) I can
help articulate the issue:

Our topology was the following (very simplified). It mirrored (and was
inspired by) the wlan slovenijia project.

Cloud (or colocation) hosted exit server running batman
 l2tp interface
  |
 V
l2tp interface
OpenWRT wifi router running batman
open0 interface
 |
V
heterogenous set of hosts connected wirelessly over an open network.

The routers create l2tp tunnels to the exit server when they have an direct
internet connection (ie. someone is sharing their bandwidth).
The open0 and l2tp interfaces were added to batman, along with an adhoc
interface which would connect to other routers over wifi. The l2tp
interfaces had to have a non-standard MTU, they were an l2tp interface
carrying batman-adv "frames".

The problem is that the hosts connecting to the open network would
generally not respect dhcp options setting an MTU. A significant number of
hosts - including I believe all windows machines and at least IOS devices -
would just set the MTU of their wireless interface to 1500. Under normal
circumstances, this wouldn't be an issue because "When a packet arrives at
a node from a client with too large an mtu, what SHOULD happen in a normal
forwarding situation (per RFC 1191) is that the node issue a ICMP
'Destination Unreachable' packet with a "Fragmentation required" code. The
client then uses this information to reset its mtu." (I'm quoting an email
exchange from our mailing list:
https://sudoroom.org/pipermail/mesh-dev/2014-October/000019.html)

However, in our situation, we were essentially stuck bridging two
interfaces that had different MTUs because they were both added to this
batman-adv layer 2 forwarding daemon. Because there was no layer 3 routing
going on, the ICMP message would never be sent. We were just seeing dropped
frames in wireshark analyses - client devices wouldn't adjust their mtu and
they wouldn't fragment because they wouldn't know to.

We tried a couple workarounds, including an iptables MSS clamping rule, but
that only works for TCP traffic. We were eventually stuck with what we came
to realize was an unworkable stack+topology.

The email exchange
https://sudoroom.org/pipermail/mesh-dev/2014-October/000019.html could help
out with any additional confusion.

I still think that a heterogenous mesh with babel on top of batman-adv
could be an excellent combination of dynamic routing with layer 2 mesh
roaming, something like this diagram:
https://libre-mesh.org/projects/libre-mesh/wiki/Network_Architecture?version=13

The libre-mesh folks mentioned that they've been experimenting with that
sort of architecture, but I don't think we're really going to need it any
time soon (and we weren't exactly in love with bmx6, but that's probably
outside of the scope here).


Hope that was reasonably helpful.


Max


On Sat, Aug 8, 2015 at 6:10 PM, Juliusz Chroboczek <
jch at pps.univ-paris-diderot.fr> wrote:

> > Are you sure about 2.?
>
> I frankly have no idea -- it's merely my reading of Marc's e-mail.  Marc,
> could you either confirm or infirm?
>
> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20150809/128d64cc/attachment.html>