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

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

commit 17ef867820bb0cc82d6d6262accca503d133a151 Author: Marek Lindner mareklindner@neomailbox.ch Date: Mon Nov 8 01:47:29 2010 +0000

doc: batman-adv/Bridge-loop-avoidance

17ef867820bb0cc82d6d6262accca503d133a151 batman-adv/Bridge-loop-avoidance.textile | 48 +++++++++++++++++++------------- 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/batman-adv/Bridge-loop-avoidance.textile b/batman-adv/Bridge-loop-avoidance.textile index 4dd8e25f..da8b367f 100644 --- a/batman-adv/Bridge-loop-avoidance.textile +++ b/batman-adv/Bridge-loop-avoidance.textile @@ -1,15 +1,19 @@ -= Batman-adv bridge loop avoidance =

-{{{ -#!div style="width: 46em; text-align: justify" +h1. Batman-adv bridge loop avoidance + + +<pre> +<code class="div">

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 segment (e.g. LAN) that are outside of batman's realm. If you don't intend to connect multiple batman-adv hosts to the same ethernet segment or don't use bridging you can safely skip this page.

-__Note__: It is the normal traffic which loops around, not the protocol traffic generated by batman-adv. Unsurprisingly, bridge loops are not unique to batman-adv mesh networks but have been around for quite a while. While this document discusses bridge loops in conjunction with batman-adv in great detail it might be helpful to have some background knowledge regarding bridge loops. ++Note+: It is the normal traffic which loops around, not the protocol traffic generated by batman-adv. Unsurprisingly, bridge loops are not unique to batman-adv mesh networks but have been around for quite a while. While this document discusses bridge loops in conjunction with batman-adv in great detail it might be helpful to have some background knowledge regarding bridge loops. + + +h3. Where does the loop come from ?

-=== 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 an ethernet LAN at the same time. +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 wifi and (Ethernet) LAN at the same time.

[[Image(wiki:bridge-loop-avoidance:lanloop1.png)]]

@@ -20,43 +24,47 @@ Here, the wifi interfaces (W1 & W2) have a decent link quality and the LAN inter If there wasn't the LAN connection this would not happen because batman-adv provides a flood/loop protection inside the batman header for every payload packet traveling through the mesh but as soon as the packet gets bridged this information is stripped from the packet. Every batman-adv node connected to the LAN will think: Hey, it is a new packet!

-=== How to avoid the loop ? === + +h3. 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. +* 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.

[[Image(wiki:bridge-loop-avoidance:lanloop3.png)]]

-=== How to activate the bridge loop avoidance ? === + +h3. How to activate the bridge loop avoidance ? +

The bridge 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 bridge interface.

Simple steps to see it in action: - * add your wifi interface -{{{ +* add your wifi interface +<pre> batctl if add wlan0 -}}} +</code></pre>

- * create a bridge for bat0 and your lan -{{{ +* create a bridge for bat0 and your lan +<pre> brctl addbr br-lan brctl addif br-lan eth0 brctl addif br-lan bat0 -}}} +</code></pre>

- * activate batman on the bridge -{{{ +* activate batman on the bridge +<pre> batctl if add br-lan -}}} +</code></pre>

Batman-adv can also deal with vlans on top of batX and offers a list of batX neighbors via debugfs (batctl support is available).

-}}} +</code></pre>