Hi all, has anyone had experience using the batman-adv protocol and can comment on its use instead of ospf?
The recommended "drop in" replacement for quagga/ospf based routing with the frr/ospf package has proven to be a less than stellar replacement in my case (not really frr's fault, but it is not identical to quagga and my requirements are complex) so I am looking to jump ship to batman. I am currently building kernels and vm's to test but I would appreciate comments from someone who has done this already.
My networks include ~10-15 vlans that extend across (open)vpn tunnels and multiple wifi SSID's and have a number of potential looping scenarios that ospf manages. I use zeroconf (for homeassistant) and have lxc based instances using veth interfaces for services (asterisk, web, dns, ...). There is a moosefs data store on its own switch and two dedicated vlans. I have in excess of 30 devices on the network and ESP IoT devices are multiplying like rabbits (!) All non-esp or android phone systems use gentoo on arm32/arm64/intel, run shorewall, have multiple vlans via trunking or multiple interfaces in different vlans or in some cases up to 4 interfaces bonded for throughput. I am using d-link managed switches and a homebrew AP using hostapd in the 2.4 and 5g bands.
Using quagga/ospf was mostly stable and just worked. While I could try tuning frr to work more reliably (worst problems are not staying converged, convergence time (which sometimes kills vm's via the moosefs data store disappearing off the network for minutes at a time), fighting frr's interference in ip forwarding across multiple interfaces and excessive overhead as it never seems to settle for long). I am thinking the effort might be better spent on batman - I am attracted to the supposedly fast convergence, minimal overhead and the potential of meshes (IoT) using the flat routing overlay it implements.
Questions I have are: 1. easily works with shorewall
2. it actually does have fast and glitch free convergence
3. internetworking across a VPN based WAN with batman at either end
4. mesh hot spot control
5. any other gotchas?
BillK
The recommended "drop in" replacement for quagga/ospf based routing with the frr/ospf package has proven to be a less than stellar replacement in my case (not really frr's fault, but it is not identical to quagga and my requirements are complex) so I am looking to jump ship to batman. I am currently building kernels and vm's to test but I would appreciate comments from someone who has done this already.
My networks include ~10-15 vlans that extend across (open)vpn tunnels and multiple wifi SSID's and have a number of potential looping scenarios that ospf manages. I use zeroconf (for homeassistant) and have lxc based instances using veth interfaces for services (asterisk, web, dns, ...). There is a moosefs data store on its own switch and two dedicated vlans. I have in excess of 30 devices on the network and ESP IoT devices are multiplying like rabbits (!) All non-esp or android phone systems use gentoo on arm32/arm64/intel, run shorewall, have multiple vlans via trunking or multiple interfaces in different vlans or in some cases up to 4 interfaces bonded for throughput. I am using d-link managed switches and a homebrew AP using hostapd in the 2.4 and 5g bands.
Using quagga/ospf was mostly stable and just worked. While I could try tuning frr to work more reliably (worst problems are not staying converged, convergence time (which sometimes kills vm's via the moosefs data store disappearing off the network for minutes at a time), fighting frr's interference in ip forwarding across multiple interfaces and excessive overhead as it never seems to settle for long). I am thinking the effort might be better spent on batman - I am attracted to the supposedly fast convergence, minimal overhead and the potential of meshes (IoT) using the flat routing overlay it implements.
Questions I have are: 1. easily works with shorewall
2. it actually does have fast and glitch free convergence
3. internetworking across a VPN based WAN with batman at either end
4. mesh hot spot control
5. any other gotchas?
BillK