commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-Testcases (f935d76d)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit f935d76d29d5710e22270b89701d8d9870097845 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Thu Oct 27 17:54:36 2011 +0000 doc: batman-adv/Bridge-loop-avoidance-Testcases >--------------------------------------------------------------- f935d76d29d5710e22270b89701d8d9870097845 batman-adv/Bridge-loop-avoidance-Testcases.textile | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/batman-adv/Bridge-loop-avoidance-Testcases.textile b/batman-adv/Bridge-loop-avoidance-Testcases.textile new file mode 100644 index 00000000..3f93d61c --- /dev/null +++ b/batman-adv/Bridge-loop-avoidance-Testcases.textile @@ -0,0 +1,59 @@ +h1. Bridge-loop-avoidance-Testcases + +This page describes test cases for the bridge loop avoidance. For more technical information and reference, please +have a look at [[Bridge-loop-avoidance-II]]. + +h2. Test Cases + +h3. Roaming from backbone to mesh + +!Test_roaming_LAN_mesh.dia.png! + +The client is connected to the backbone first and then roams to a mesh node which is not connected to the backbone. + +Ping the internet gateway or a mesh node continuously and see if the connection is recovered. + +h3. Roaming from mesh to backbone + +!Test_roaming_mesh_LAN.dia.png! + +The client is connected to a mesh node first and then roams the backbone. + +Ping the internet gateway or a mesh node continuously and see if the connection is recovered. + +h3. A client switches its gateway (due to loss of link/better TQ) + +!Test_gateway_selection.dia.png! + +Continuously ping the internet gateway from the client, and change the quality of the currently selected node (e.g. adding packet loss). + +h3. Limited Horizon tests + +!Test_limited_horizon.dia.png! + +In this test, the first node A can't reach the last one C due to a limited horizon (the OGMs of A don't reach the OGMs of C and vice versa). + + * Test 1: Client 1 and Client 2 should be able to ping the internet gateway. There are are no bridge loops. + * Test 2: Client 1 and Client 2 should be able to ping each other. + ++note+: Test 2 can only be performed when the batman interface (or one of its VLANs) is used as a batman hard interface. The support for this requires are separate patch. + +h3. VLAN support + +The clients are connected to local VLANs which are used on top of BATMAN. All claim frames should then have a VLAN tag. + +h3. Two LANs connected by one mesh + +!Test_2xLAN.dia.png! + +Two LANs are connected by one mesh. The backbone gateways of each LAN should find each other and claim only packets from each LAN. +Every node should be able to reach every other node. + +h3. Two meshes connected by one LAN + +!Test_2xmesh.dia.png! + +Two meshes are connected to one LAN. The backbone gateways of each mesh should find themselves and share their claims, but should disregard claims for backbone gateways they are not part of (only possible with the backbone gateway grouping optimization) +Every node should be able to reach every other node. + ++note:+ this patch requires the group forming patch to be included.

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/Test_limited_horizon.dia (b5cd83f2)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit b5cd83f2b34e373353be23a802d335b7d4d22723 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Thu Oct 27 17:56:29 2011 +0000 doc: attachments/Test_limited_horizon.dia >--------------------------------------------------------------- b5cd83f2b34e373353be23a802d335b7d4d22723 attachments/Test_limited_horizon.dia | Bin 0 -> 2067 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/attachments/Test_limited_horizon.dia b/attachments/Test_limited_horizon.dia new file mode 100644 index 00000000..c6bb4506 Binary files /dev/null and b/attachments/Test_limited_horizon.dia differ

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (5f7a6e0c)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (6c3219b7)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (0d110ed2)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 0d110ed2760963cd6e4716b2031d007b1e98d822 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Mon Oct 24 21:32:54 2011 +0000 doc: batman-adv/Bridge-loop-avoidance-II >--------------------------------------------------------------- 0d110ed2760963cd6e4716b2031d007b1e98d822 batman-adv/Bridge-loop-avoidance-II.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/batman-adv/Bridge-loop-avoidance-II.textile b/batman-adv/Bridge-loop-avoidance-II.textile index a93741d7..2d8786b3 100644 --- a/batman-adv/Bridge-loop-avoidance-II.textile +++ b/batman-adv/Bridge-loop-avoidance-II.textile @@ -93,13 +93,13 @@ Although a broadcast frame is sent into the mesh, it won't loop back into the LA h3. LAN->mesh Roaming: -(TODO: illustration) +!Test_roaming_LAN_mesh.dia.png! This is the easy case: Sooner or later, a claim will be added for the roamed client. h3. mesh->LAN Roaming: -(TODO: illustration) +!Test_roaming_mesh_LAN.dia.png! We assume that the client was already claimed by a backbone gateway before, otherwise there is nothing to consider. @@ -210,7 +210,7 @@ h2. Test Cases h3. Roaming from backbone to mesh -!test_roaming_LAN_mesh.dia.png! +!Test_roaming_LAN_mesh.dia.png! The client is connected to the backbone first and then roams to a mesh node which is not connected to the backbone. @@ -218,7 +218,7 @@ Ping the internet gateway or a mesh node continuously and see if the connection h3. Roaming from mesh to backbone -!test_roaming_mesh_LAN.dia.png! +!Test_roaming_mesh_LAN.dia.png! The client is connected to a meshnode first and then roams the backbone.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (5714bbf9)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (1e7bba1e)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (278ce718)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 278ce718cf9002de76e54476fb8873d7187da6f2 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Mon Oct 24 21:35:14 2011 +0000 doc: batman-adv/Bridge-loop-avoidance-II >--------------------------------------------------------------- 278ce718cf9002de76e54476fb8873d7187da6f2 batman-adv/Bridge-loop-avoidance-II.textile | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/batman-adv/Bridge-loop-avoidance-II.textile b/batman-adv/Bridge-loop-avoidance-II.textile index 2d8786b3..41bfbf42 100644 --- a/batman-adv/Bridge-loop-avoidance-II.textile +++ b/batman-adv/Bridge-loop-avoidance-II.textile @@ -261,6 +261,13 @@ Every node should be able to reach every other node. +note:+ this patch requires the group forming patch to be included. +h2. Open Implementation issues + + * update README and sysfs description + * add support for soft interface OGM propagation + * test all test cases (so far, only basic tests and 2x mesh, 2x LAN) + * send to ml, add review points + h2. Further ideas h3. from discussion on 2011-06-08:

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (f86a6526)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit f86a65261bf881e1b588723f4bae0f5b810dd072 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Tue Oct 25 19:40:29 2011 +0000 doc: batman-adv/Bridge-loop-avoidance-II >--------------------------------------------------------------- f86a65261bf881e1b588723f4bae0f5b810dd072 batman-adv/Bridge-loop-avoidance-II.textile | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/batman-adv/Bridge-loop-avoidance-II.textile b/batman-adv/Bridge-loop-avoidance-II.textile index e7d2e49b..9ac7ae91 100644 --- a/batman-adv/Bridge-loop-avoidance-II.textile +++ b/batman-adv/Bridge-loop-avoidance-II.textile @@ -11,7 +11,7 @@ This is the example we will use to discuss the concept: multiple mesh nodes (cal h2. Definitions: - * backbone gateway: A mesh node which is conncted to both - a mesh network and a LAN. + * backbone gateway: A mesh node which is connected to both - a mesh network and a LAN. * client: A non-mesh network participant which is sending data via the mesh. The client is always identified by the source MAC address of the payload Ethernet header. h2. Goals: @@ -40,7 +40,7 @@ The concept will be explained by discussing the different cases: unicast and bro h3. Broadcast, mesh->LAN: -!mesh_LAN.dia.png!:http://www.open-mesh.org/attachments/98/mesh_LAN.dia.png +!mesh_LAN.dia.png! If the originator of the broadcast is not known (not in the originator table), drop it. If the originator of the broadcast is another backbone gateway from the same LAN, drop it. @@ -70,7 +70,7 @@ If the client is not claimed, all backbone gateways will send the broadcast into h3. Unicast, LAN->mesh: -!LAN_mesh_unicast .dia.png! +!LAN_mesh_unicast.dia.png! Nothing fancy should happen here, as a switch should do the right thing. If the client is not claimed, the frame is simply sent into the mesh. @@ -110,23 +110,23 @@ h3. Gateway selection: All gateways announce the clients within their LAN and ignore roaming messages from other gateways on the same LAN. -Other non-gateway meshnodes may select their best gateway to the LAN based on the TQ value. +Other non-gateway mesh nodes may select their best gateway to the LAN based on the TQ value. h3. Claim frames !claimtypes.dia.png! -All claim operations are sent using "special" gratious ARP frames. 4 types are used which are illustrated above: +All claim operations are sent using "special" gratuitous ARP frames. 4 types are used which are illustrated above: * CLAIM frames are used to tell others that a backbone gateway feels responsible for a client now * UNCLAIM frames are sent when a backbone gateway does not feel responsible anymore * ANNOUNCE frames are sent regularly to find other backbone gateways and provides the CRC of its local table - * REQUEST frames are used to ask for a full table update when the information is out of sync (i.e. the announced crc does not match with the local crc) + * REQUEST frames are used to ask for a full table update when the information is out of sync (i.e. the announced CRC does not match with the local CRC) -the claim type is announced within the 4th byte of the Target HW address. Each claim frame is discussed in detail further. +The claim type is announced within the 4th byte of the Target HW address. +Note:+ Although this is a misuse of ARP packets, the "normal" ARP process should not be disturbed as the IP addresses -(0.0.0.0) should not be in any sane ARP table. As far as I understand, a gratious ARP should only be considered if the +(0.0.0.0) should not be in any sane ARP table. As far as I understand, a gratuitous ARP should only be considered if the IP address is already in an ARP table [2]. [1] http://tools.ietf.org/html/rfc826 @@ -150,7 +150,7 @@ The periodic ANNOUNCE frames (default: every 10 seconds) by the backbone gateway * backbone gateways learn about the existence of other backbone gateways (this is important for new gateways) * when no ANNOUNCE frames are received anymore, we can assume that this backbone gateway is no longer serving the LAN and can remove its claims - * it contains a checksum (the last 2 bytes YY:YY within the Sender HW address) which other backbone gateways can use to check their table consistency. If a table is not consistent, a backbone gateway can ask for the full claim table via the REQUEST frame. + * It contains a checksum (the last 2 bytes YY:YY within the Sender HW address) which other backbone gateways can use to check their table consistency. If a table is not consistent, a backbone gateway can ask for the full claim table via the REQUEST frame. Note: the SRC HW address is a "locally administered address" group address which should not be used by any NIC or protocol, but is not registered with the IEEE @@ -162,10 +162,10 @@ It then sends a REQUEST frame to the backbone gateway it just received the ANNOU The asked backbone gateway will send all of its local CLAIM frames again, and send another ANNOUNCE frame afterwards. -The requesting backbone gateway will add all claims it receives through the CLAIM frames, and can check the CRC another time once it receives the final ANNOUNCE frame. +The requesting backbone gateway will add all claims it receives through the CLAIM frames, and can check the CRC once more as soon as it receives the final ANNOUNCE frame. (If the CRC is still wrong, the process will start again) -While a request is in flight, the requesting backbone gateway will close down its soft interface for broadcast to avoid loops in this period. +While a request is in flight, the requesting backbone gateway will close down its soft-interface for broadcast to avoid loops in this period. +group forming+ @@ -180,7 +180,7 @@ h2. Discussion: h3. Features: * no single "super" gateway => should scale better - * the only additional BATMAN LAN packets are claim packets, which are only sent for new claims + * the only additional BATMAN LAN packets are claim packets, which are only sent for new claims and regular announcements * no BATMAN packets on the LAN * broadcasts are sent from all the gateways into the mesh * nodes can select gateways, and change among them (gateways will automatically re-claiming) @@ -219,7 +219,7 @@ h3. Roaming from mesh to backbone !Test_roaming_mesh_LAN.dia.png! -The client is connected to a meshnode first and then roams the backbone. +The client is connected to a mesh node first and then roams the backbone. Ping the internet gateway or a mesh node continuously and see if the connection is recovered.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Bridge-loop-avoidance-II (df59c253)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017