Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 6fa824766ff4188572b1688c6f3fa6c28209f5db Author: Marek Lindner mareklindner@neomailbox.ch Date: Sun Sep 26 22:21:50 2010 +0000
doc: batman-adv/Bridge-loop-avoidance
6fa824766ff4188572b1688c6f3fa6c28209f5db batman-adv/Bridge-loop-avoidance.textile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/batman-adv/Bridge-loop-avoidance.textile b/batman-adv/Bridge-loop-avoidance.textile index 99291bfc..e91bb6cf 100644 --- a/batman-adv/Bridge-loop-avoidance.textile +++ b/batman-adv/Bridge-loop-avoidance.textile @@ -10,9 +10,11 @@ This document explains how batman-adv is able to detect & avoid loops that are c
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 ... +[[Image(wiki:lan-loop-avoidance:lanloop1.png)]]
+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 simple ARP broadcast 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 ...
+[[Image(wiki:lan-loop-avoidance:lanloop2.png)]]
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!