Brief notes on Batman-adv
Batman-adv is a distance-vector mesh routing protocol which acts completely on L2 (or 2.5 as it is said often).
- “Batman-advanced operates on ISO/OSI Layer 2 only and uses and routes (or better: bridges) Ethernet Frames. It emulates a virtual network switch of all nodes participating. Therefore all nodes appear to be link local, thus all higher operating protocols won’t be affected by any changes within the network.” 
I guess that the topology info for the vis-server is propagated using the protocol so does not add significant overhead
- “In dense node areas with low packet loss B.A.T.M.A.N. III generates quite some packets which increases the probability of collisions, wastes air time and causes more CPU load. Each OGM being 20 Bytes small, B.A.T.M.A.N. IV introduces a packet aggregation that combines several distinct OGMs into one packet.” 
But still the problem exists in dense node areas no matter the aggregation since it is inherent of dealing with the environment.
- “A virtual interface is provided (bat0), which can be considered as a usual ethernet device (probably with a little more packet loss 😉 )” 
- “From a couple of years B.A.T.M.A.N. has moved from a layer 3 implementation to a layer 2 one (2.5 would be more correct as it resides between the data-link and the network layer running in kernel and not on NICOS but using MAC addresses) without changing the routing algorithm. B.A.T.M.A.N. now represents a new level in the network stack, with its own encapsulation header and its own services. It became totally transparent to the IP protocol since it now works like an extended LAN with standard ethernet socket exposed to the IP layer.” 
- “at the IP layer, every packet sending operation is seen as a one-hop communication” 
Would we need a L3 protocol then, in case there is no communication with the external world (other networks)?
Technical Facts (that were usefull to me)
- The batman-adv module on the debian wheezy repo uses the built 2011.4.0 which runs the Batman-IV routing algorithm.
- Batman-adv module cannot be loaded separately inside LXC for each container because cannot insert modules so it can be simply associated to a namespace. Therefore, the virtual interface should be created in the host and be used somehow by all the containers. Specific integration with from the part of batman-adv module does not exist.
- Upto the version 2013.2.0 (current) vis functionality was part of the kernel module. This was changed as mentioned here: “This is replaced by a userspace program, we don’t need this
functionality to bloat the kernel.”
In 2010 it had problems with node-failure, while 802.11s dealt very good.
“We can note that batman-adv is generally more stable.”(than 802.11s in terms of links)
“networks performance decreases sharply after two hops for both voice and Ethernet sized packets.” 
“BATMAN was proven to work as well in an environment with signiﬁcant interference and longer distances between nodes as in a friendlier setting. In contrast, AODV often failed to provide stable routes in cases where multi-hop communication was necessary”
Since it’s third version (v.2011.3.0) batman-adv has much improved performance. (after the evaluation papers were written )
Batman can be used for any kind of interface.
: Experimental evaluation of two open source solutions for wireless mesh routing at layer two, Paper(batman-adv vs open80211s)
Finally, I want to share with you a interesting article, presenting a different motivation beside mesh-netorking: Mesh networking with batman-adv