Repository : ssh://git@open-mesh.org/doc

On branches: backup-redmine/2017-07-13,master

commit 6c96bafec971b96a4562c0d7b59e63606f6ee19c Author: Marek Lindner mareklindner@neomailbox.ch Date: Sun Sep 26 22:14:14 2010 +0000

doc: batman-adv/Bridge-loop-avoidance

6c96bafec971b96a4562c0d7b59e63606f6ee19c batman-adv/Bridge-loop-avoidance.textile | 57 ++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+)

diff --git a/batman-adv/Bridge-loop-avoidance.textile b/batman-adv/Bridge-loop-avoidance.textile new file mode 100644 index 00000000..99291bfc --- /dev/null +++ b/batman-adv/Bridge-loop-avoidance.textile @@ -0,0 +1,57 @@ += Batman-adv LAN loop avoidance = + +{{{ +#!div style="width: 46em; text-align: justify" + +This document explains how batman-adv is able to detect & avoid loops that are created by bridging multiple batX interfaces on different hosts into the same ethernet LAN. If you don't intend to connect multiple batman-adv hosts to the same LAN or don't use bridging you can safely skip this page. + + +=== Where does the loop come from ? === + +To better understand what creates the loop it is helpful to focus on a sample topology. The simplest case involves only 2 nodes that are connected via with wifi and ethernet at the same time. + +Here, the wifi interfaces (W1 & W2) have a decent link quality and the LAN interfaces (L1 & L2) are bridged with the batX interface. Let's assume a broadcast packet from the LAN arrives at node1 which then floods the mesh with that new packet. Node2 receives the packet via the mesh and forwards it to the LAN where node1 receives it ... + + + +If there wasn't the LAN connection this would not happen because batman-adv provides a flood/loop protection inside the batman header but as soon as the packet gets bridged this information is stripped from the packet. Every batman node connected to the LAN will think: Hey, it is a new packet! + + +=== How to avoid the loop ? === + +A common solution to avoid bridge loops is to deploy protocols like STP or one of its derivatives. STP would detect the loop and close ports to avoid it. Running STP over the mesh is not really what we want as STP has no clue about the link qualities and who wants to run a spanning tree over lossy links ? + +Batman-adv needs its own mechanism to detect other batman nodes connected to the same LAN and then close the appropriate ports. By simply re-using the existing OGM packets we don't need to invent a whole new packet type or protocol. OGMs that come in via the batX interface (as this interface is bridged to the LAN) are interpreted as "port announcements" and allow batman-adv to learn about all the "batX neighbors". Internally, it keeps a list of these neighbors and selects the one of them as 'gateway' to the LAN. All traffic from and to the LAN will have to go through this one special gateway, thereby avoiding the loop. + +In practice this means the following: + * If a node is the gateway to the LAN it does not need to do anything special. Forwarding traffic between the LAN and the mesh as usual. + * All other batman-adv nodes connected to the LAN drop traffic coming from the LAN (the gateway takes care of that) and forward all traffic destined for the LAN to the gateway node. + +To keep things simple the node with the smallest mac address becomes the gateway to the LAN. + + +=== How to activate the lan loop avoidance ? === + +The LAN loop avoidance feature is built-in and does not need to be activated in a special way. Batman-adv will automatically detect and deal with the loop provided that each node sends OGMs on the LAN interface. + +Simple steps to see it in action: + * add your wifi interface +{{{ +batctl if add wlan0 +}}} + + * create a bridge for bat0 and your lan +{{{ +brctl addbr br-lan +brctl addif br-lan eth0 +brctl addif br-lan bat0 +}}} + + * activate batman on the lan +{{{ +batctl if add br-lan +}}} + +Batman-adv can also deal with vlans on top of batX and offers a list of LAN neighbors via debugfs (batctl support is available). + +}}}