From: | William Kenworthy <billk@×××××××××.au> |
---|---|
To: | "gentoo-user@l.g.o" <gentoo-user@l.g.o> |
Subject: | [gentoo-user] OT: BATMAN vs frr/ospf |
Date: | Thu, 02 Dec 2021 02:06:48 |
Message-Id: | eb4d9fc3-325a-e6a9-f047-23e0a91efb91@iinet.net.au |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | Hi all, has anyone had experience using the batman-adv protocol |
8 | and can comment on its use instead of ospf? |
9 | The recommended "drop in" replacement for quagga/ospf based |
10 | routing with the frr/ospf package has proven to be a less than |
11 | stellar replacement in my case (not really frr's fault, but it is |
12 | not identical to quagga and my requirements are complex) so I am |
13 | looking to jump ship to batman.�� I am currently building kernels |
14 | and vm's to test but I would appreciate comments from someone who |
15 | has done this already. |
16 | My networks include ~10-15 vlans that extend across (open)vpn |
17 | tunnels and multiple wifi SSID's and have a number of potential |
18 | looping scenarios that ospf manages.�� I use zeroconf (for |
19 | homeassistant) and have lxc based instances using veth interfaces |
20 | for services (asterisk, web, dns, ...).�� There is a moosefs data |
21 | store on its own switch and two dedicated vlans.�� I have in excess |
22 | of 30 devices on the network and ESP IoT devices are multiplying |
23 | like rabbits (!) All non-esp or android phone systems use gentoo |
24 | on arm32/arm64/intel, run shorewall, have multiple vlans via |
25 | trunking or multiple interfaces in different vlans or in some |
26 | cases up to 4 interfaces bonded for throughput.�� I am using d-link |
27 | managed switches and a homebrew AP using hostapd in the 2.4 and 5g |
28 | bands. |
29 | |
30 | Using quagga/ospf was mostly stable and just worked.�� While I |
31 | could try tuning frr to work more reliably (worst problems are not |
32 | staying converged, convergence time (which sometimes kills vm's |
33 | via the moosefs data store disappearing off the network for |
34 | minutes at a time), fighting frr's interference in ip forwarding |
35 | across multiple interfaces and excessive overhead as it never |
36 | seems to settle for long).�� I am thinking the effort might be |
37 | better spent on batman - I am attracted to the supposedly fast |
38 | convergence, minimal overhead and the potential of meshes (IoT) |
39 | using the flat routing overlay it implements. |
40 | Questions I have are: |
41 | 1. easily works with shorewall |
42 | 2. it actually does have fast and glitch free convergence |
43 | 3. internetworking across a VPN based�� WAN with batman at either end |
44 | 4. mesh hot spot control |
45 | 5. any other gotchas? |
46 | BillK |
47 | |
48 | |
49 | |
50 | |
51 | |
52 |