commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Understand-your-batman-adv-network (7494e895)
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 7494e895d748a00dc0c594200a63f0a7001fade1 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sat Mar 26 17:45:12 2011 +0000 doc: batman-adv/Understand-your-batman-adv-network >--------------------------------------------------------------- 7494e895d748a00dc0c594200a63f0a7001fade1 .../Understand-your-batman-adv-network.textile | 86 ++++++++++++---------- 1 file changed, 47 insertions(+), 39 deletions(-) diff --git a/batman-adv/Understand-your-batman-adv-network.textile b/batman-adv/Understand-your-batman-adv-network.textile index 3c56c347..26bf42f5 100644 --- a/batman-adv/Understand-your-batman-adv-network.textile +++ b/batman-adv/Understand-your-batman-adv-network.textile @@ -1,107 +1,115 @@ -= Understand your B.A.T.M.A.N. Advanced network = +h1. Understand your B.A.T.M.A.N. Advanced network -{{{ -#!div style="width: 46em; text-align: justify" +This document assumes you have created a batman-adv network and are interested in finding out how batman routes the traffic from node to node, getting an access to the whole network topology and/or wish understand why batman is doing what it is doing. Batman provides a set of debug tools and debug tables which aim to facilitate this task. Explaining the routing decisions / various routing optimizations are not in the scope of this document. Links to complementary documents will be provided if available. -This document assumes you have created a batman-adv network and are interested in finding out how batman routes the traffic from node to node, getting an access to the whole network topology and/or wish understand why batman is doing what it is doing. Batman provides a set of debug tools and debug tables which aim to facilitate this task. Explaining the routing decisions / various routing optimizations are not in the scope of this document. Links to complementary documents will be provided if available.[[BR]] -__Note__: Although this document focusses on the "raw" debugfs interface you always can use batctl for a more convenient access to the data. This document assumes debugfs was mounted at /sys/kernel/debug/. Please adjust the given examples if your system mounts the filesystem somewhere else. The batctl tool will automatically mount debugfs whenever you try to access functionality that require it. This document also assumes that you created a mesh cloud "bat0". [wiki:tweaking-batman-adv This page] provides background information on how to handle mesh clouds. ++Note+: Although this document focusses on the "raw" debugfs interface you always can use batctl for a more convenient access to the data. This document assumes debugfs was mounted at /sys/kernel/debug/. Please adjust the given examples if your system mounts the filesystem somewhere else. The batctl tool will automatically mount debugfs whenever you try to access functionality that require it. This document also assumes that you created a mesh cloud "bat0". [[tweaking-batman-adv|This page]] provides background information on how to handle mesh clouds. -=== Tables === -'''originator table''' +h2. Tables + + +h3. originator table Each batman node maintains a list of all other nodes in the network and remembers in which direction to send the packets if data should be transmitted. The direction manifests itself in the form of the "best next neighbor" which basically is the next step towards the destination. You can retrieve batman's internal originator table by reading the originators file. The printed table begins with a header line with some more or less useful status data, followed by the data. Each line contains information regarding a specific originator: -{{{ +<pre> <originator> <last-seen> <TQ (transmit quality) value towards the originator> <next best hop> <outgoing iface> <alternative best next hops> -}}} +</pre> Sample output: -{{{ +<pre> cat /sys/kernel/debug/batman_adv/bat0/originators -Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.3.0-alpha, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0)] +Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... [B.A.T.M.A.N. adv 0.3.0-alpha, [[MainIF]]/MAC: eth0/fe:fe:00:00:01:01 (bat0)] fe:fe:00:00:02:01 0.360s (133) fe:fe:00:00:02:01 [ eth0]: fe:fe:00:00:02:01 (133) -}}} +</pre> -'''translation tables''' +h3. translation tables To let non-batman nodes use the mesh infrastructure easily, batman-adv introduced mac translation tables: When a batman-adv node detects that a client wishes to communicate over the mesh it will store the client's mac address in the local translation table and flood the network with the information that this mac address / client is attached to this batman-adv node. As soon as other nodes wish to send data to the client, they will search the client's mac in the mesh-wide (global) translation table, to find the corresponding batman-adv node. Then the data gets transmitted to the batman node first which then relays it to the client. The local translation table (mac addresses announced by this host) can be found in the transtable_local file: -{{{ +<pre> cat /sys/kernel/debug/batman_adv/bat0/transtable_local Locally retrieved addresses (from bat0) announced via HNA: - * fe:fe:00:00:01:01 -}}} +* fe:fe:00:00:01:01 +</pre> + +Every batman node announces at least one mac address - the mac of the batX interface. -Every batman node announces at least one mac address - the mac of the batX interface. [[BR]] The global translation table (mac addresses announced by other hosts) can be found in the transtable_global file: -{{{ +<pre> cat /sys/kernel/debug/batman_adv/bat0/transtable_global Globally announced HNAs received via the mesh bat0: - * fe:fe:00:00:01:01 via fe:fe:00:00:02:01 -}}} +* fe:fe:00:00:01:01 via fe:fe:00:00:02:01 +</pre> Each line contains the announced mac address and the mac of the batman node announcing it. -'''Gateway table''' +h3. Gateway table -The gateway table lists all available batman-adv gateways in this network (see the [wiki:batman-adv-gateways gateway documentation] to learn how to use this feature). Each line contains information about a specific gateway: +The gateway table lists all available batman-adv gateways in this network (see the [[batman-adv-gateways|gateway documentation]] to learn how to use this feature). Each line contains information about a specific gateway: -{{{ +<pre> <selection symbol> <gateway> <TQ (transmit quality) value towards the gateway> <next best hop> <outgoing iface> <gateway class - announced throughput> -}}} +</pre> For example: -{{{ - Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv devel 1886, MainIF/MAC: eth0/fe:fe:00:00:03:01 (bat0)] + +<pre> + Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv devel 1886, [[MainIF]]/MAC: eth0/fe:fe:00:00:03:01 (bat0)] fe:fe:00:00:01:01 (233) fe:fe:00:00:01:01 [ eth0]: 41 - 2048KBit/512KBit => fe:fe:00:00:02:01 (243) fe:fe:00:00:02:01 [ eth0]: 41 - 2048KBit/512KBit -}}} +</pre> -'''Softinterface neighbor table''' +h3. Softinterface neighbor table -This table is part of the [wiki:bridge-loop-avoidance bridge loop avoidance] code and contains all nodes that have been detected as being part of the same bridge. The currently selected 'gateway to the LAN' is marked with the '=>' symbol. +This table is part of the [[bridge-loop-avoidance|bridge loop avoidance]] code and contains all nodes that have been detected as being part of the same bridge. The currently selected 'gateway to the LAN' is marked with the '=>' symbol. -{{{ +<pre> cat /sys/kernel/debug/batman_adv/bat0/softif_neigh Softif neighbor list (bat0) => fe:fe:00:00:02:01 (vid: 1) -}}} +</code></pre> + + +h2. ICMP -=== ICMP === Traditional network debugging tools based on the ICMP protocol such as ping or traceroute won't be able to perform their duties as expected. All traffic in the mesh will be transported to the destination transparently, so that higher protocols do not notice the number of hops or the route. This is one of the main reasons why you can roam around without breaking your connection. To provide the same type of diagnosis tools, batman-adv has an own simplified version of ICMP integrated in the protocol. Via debugfs it is possible to inject IMCP packets which behave very similar to their layer3 counterpart. The icmp socket file /sys/kernel/debug/batman_adv/bat0/icmp_socket can't be used with cat/echo directly, since it expects binary data. The batctl tool offers a ping / traceroute like interface that make use of this icmp socket interface. Please read the batctl manpage or the README file to learn how to use it or to see examples. -=== Logging === -Batman-adv offers extended logging to understand & debug the routing protocol internals. After you activated debugging at compile time (instructions can be found in [http://www.open-mesh.org/browser/trunk/batman-adv/README the README file]) and the appropriate log level has been set (read about the log levels [wiki:tweaking-batman-adv here]) you can retrieve the logs by simply reading the 'log' file: +h2. Logging -{{{ + +Batman-adv offers extended logging to understand & debug the routing protocol internals. After you activated debugging at compile time (instructions can be found in "the README file":http://www.open-mesh.org/browser/trunk/batman-adv/README) and the appropriate log level has been set (read about the log levels [[tweaking-batman-adv|here]]) you can retrieve the logs by simply reading the 'log' file: + +<pre> cat /sys/kernel/debug/batman_adv/bat0/log [ 418] Sending own packet (originator fe:fe:00:00:02:01, seqno 643, TQ 255, TTL 50, IDF off) on interface eth0 [fe:fe:00:00:02:01] [ 418] Received BATMAN packet via NB: fe:fe:00:00:01:01, IF: eth0 [fe:fe:00:00:02:01] (from OG: fe:fe:00:00:02:01, via prev OG: fe:fe:00:00:02:01, seqno 643, tq 245, TTL 49, V 12, IDF 1) [ 418] Drop packet: originator packet from myself (via neighbor) [..] -}}} +</code></pre> The log is a circular ring buffer and will continue writing messages as soon as they become available. -=== Visualization === -Despite its decentral nature batman-adv offers an easy way to access topology information that can be visualized. The [wiki:VisAdv visualization document] covers the necessary steps in detail. -}}} +h2. Visualization + + +Despite its decentral nature batman-adv offers an easy way to access topology information that can be visualized. The [[VisAdv|visualization document]] covers the necessary steps in detail. +

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/UsingBatmanGit (0114cb16)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batmand/DebugOutput (332a3d43)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multi-link-optimizations-technical (afffedaa)
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 (d3aea372)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multi-link-optimizations-technical (31887b79)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Troubleshooting (8c05c58f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batmand/InternetTuning (7aa38930)
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 7aa389305a5d4b3b8e9a10d585151e1fe5d282ed Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sat Mar 26 17:22:07 2011 +0000 doc: batmand/InternetTuning >--------------------------------------------------------------- 7aa389305a5d4b3b8e9a10d585151e1fe5d282ed batmand/InternetTuning.textile | 71 +++++++++++++++++++++++++++++------------- 1 file changed, 50 insertions(+), 21 deletions(-) diff --git a/batmand/InternetTuning.textile b/batmand/InternetTuning.textile index 446851fa..da3b9256 100644 --- a/batmand/InternetTuning.textile +++ b/batmand/InternetTuning.textile @@ -1,20 +1,28 @@ -== Internet tuning == +h2. Internet tuning -'''Gateway''' + +*Gateway* Batman offers to announce the avaibility of an internet connection. You can use the gateway class option (-g down/up) to tell batman how much bandwidth is available. You can specify the download and upload speed - batman will choose the nearest gateway class to represent your speed and propagate it in the network. The following examples should illustrate the usage: +<pre> batmand -g 5000 [interface] - +</pre> +<pre> batmand -g 5000kbit [interface] - +</pre> +<pre> batmand -g 5mbit [interface] - +</pre> +<pre> batmand -g 5mbit/1024 [interface] - +</pre> +<pre> batmand -g 5mbit/1024kbit [interface] - +</pre> +<pre> batmand -g 5mbit/1mbit [interface] +</pre> The syntax is very flexible and allows all these values to become gateway class 49. @@ -27,71 +35,92 @@ That behaviour allows the gateway maintainer to distinguish between traffic insi Additionally, you have to make sure that the gateway allows forwarding and that the firewall masquerades all traffic coming through gate0. -'''!GatewayClient''' +*!GatewayClient* You can tell batman to watch out for announced gateways and connect to them via the routing class option (-r). This option allows you to influence which gateway will be chosen. Currently, there are 3 modes available: -batmand -r 1 [interface]: +<pre> +batmand -r 1 [interface] +</pre> This mode is called "fast internet connection" because it considers the link quality and the advertised gateway class before choosing the gateway. Once a gateway is chosen and the tunnel is established batman will try to keep the tunnel open as long as possible to not break your stateful connections. -batmand -r 2 [interface]: +<pre> +batmand -r 2 [interface] +</pre> This mode only considers the link quality towards the gateway while choosing it. Therefore it is named "stable internet connection". It also will keep the tunnel open as long as possible. -batmand -r 3 [interface]: +<pre> +batmand -r 3 [interface] +</pre> This mode also considers the link quality only but it will destroy the established tunnel as soon as another gateway with a better link quality is found (fast-switching). -batmand -r (number between 3 and 256) [interface]: +<pre> +batmand -r (number between 3 and 256) [interface] +</pre> This mode also considers the link quality only but switches to another gateway as soon as this gateway has a TQ value which is $number better than the currently selected gateway (late-switching). After a gateway is chosen batman will create a gate0 interface and tries to get an IP from the gateway. The tunnel architecture allows batman to observe the internet connection because all traffic is going through the tunnel. If batman notices that the currently selected gateway does not forward the traffic into the internet it will disconnect from that gateway and choose another gateway. -batman 0.3.1 and before: +*batman 0.3.1 and before:* If you plan to attach non-batman clients to your batman internet client you have to masquerade all outgoing packets on interface gate0 (e.g. iptables). -batman 0.3.2 and later: -The batman daemon will try to locate the iptables binary to setup the masquerading automatically. This behaviour can be disabled using the "--disable-client-nat" option. If the outgoing packets are not masqueraded (the iptables binary wasn't found / the automatism disabled) batman will switch to the "half tunnel" mode which operates without masquerading. Beware: This mode __requires__ the gateway to have a routing entry for each client that accesses the internet (e.g. non-batman clients may be announced via HNA). Also, batman won't be able to automatically detect whether the chosen gateway is connected to the internet or not as only outgoing packets go through gate0. +*batman 0.3.2 and later:* +The batman daemon will try to locate the iptables binary to setup the masquerading automatically. This behaviour can be disabled using the "--disable-client-nat" option. If the outgoing packets are not masqueraded (the iptables binary wasn't found / the automatism disabled) batman will switch to the "half tunnel" mode which operates without masquerading. Beware: This mode +requires+ the gateway to have a routing entry for each client that accesses the internet (e.g. non-batman clients may be announced via HNA). Also, batman won't be able to automatically detect whether the chosen gateway is connected to the internet or not as only outgoing packets go through gate0. -'''Tuning''' +h3. Tuning To be more flexible and better integrate into different setups and environments batman has a runtime interface which you can connect to. You can change batmans behaviour on the fly and adapt to changing requirements. For example you announce internet but you discover that your internet connection is down, so you can tell batman to stop announcing the gateway class: +<pre> batmand -c -g 0 +</pre> You could even say: I try to get my internet over that mesh as well: +<pre> batmand -c -r 1 +</pre> Later you deactivate it again and reactivate your gateway announcement: +<pre> batmand -c -r 0 && batmand -c -g 5000 +</pre> -Or in one step: batmand -c -g 5000 +Or in one step: +<pre> +batmand -c -g 5000 +</pre> If you know that you want to use a particular gateway you can use the preferred gateway option (-p) to specify it. If batman finds the given gateway it will use it otherwise it will choose a gateway according to the routing class (routing class 1 is default if none is given). -For example: batmand -c -p 1.2.3.4 +For example: +<pre> +batmand -c -p 1.2.3.4 +</pre> The preferred gateway option can also be given at startup time. If you have many users connected to your gateway you will experience a higher CPU load on the gateway because it has to maintain tunnel connections to numerous gateway clients at the same time. To reduce the load you can use the batgat kernel module which will do the tunneling from within the kernel space. You can load it like any other kernel module. Have a look in your kernel logs to see its boot up messages: +<pre> batgat: [init_module:96] batgat loaded rv959 - batgat: [init_module:97] I was assigned major number 252. To talk to - batgat: [init_module:98] the driver, create a dev file with 'mknod /dev/batgat c 252 0'. - batgat: [init_module:99] Remove the device file and module when done. +</pre> Now the module is loaded but inactive. When you start batmand the daemon will automatically look for a file '/dev/batgat' to communicate with the kernel module in order to activate it. This file should be generated by the kernel if you have devfs (on linux 2.4) or udev (on linux 2.6) running. You can create the file by yourself as mentionned in the logs if it was not generated. When batmand finds this file the kernel module will be used. Attention: Do not hardcode the major number in your scripts. This number is assigned by the kernel and may differ from system to system, even from boot to boot. You can retrieve the current number from the proc filesystem: +<pre> cat /proc/devices | grep batgat +</pre> \ No newline at end of file

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017