Wiki » Historial » Revisió 33
Revisió 32 (Axel Neumann, 28-08-2012 13:50) → Revisió 33/68 (Axel Neumann, 28-08-2012 14:08)
{{toc}}
h1. BMX6
Bmx6 is a routing protocol for Linux based operating systems.
The following intro provides kind of tutorial to get started.
h2. Installation
h3. Requirements
The following tools are needed to obtain, compile, and install bmx6
* git (debian package: git-core)
* gcc
* make
h3. Downloading
Latest development sources are available from bmx6 git repository
<pre>
git clone git://qmp.cat/bmx6.git
cd bmx6
</pre>
h3. Compile and Install
To only compile the main bmx6 daemon (no bmx6 plugins)
<pre>
make
sudo make install
</pre>
h2. Usage (hello mesh)
h3. Starting
In its most simple configuration, the only required parameter are the interfaces names that should be used for meshing.
The following example starts bmx6 on interface wlan0:
<pre>
root@mlc1001:~# bmx6 dev=eth1
</pre>
However, to let this simple command work as expected also check the following basic requirements:
* bmx6 must be executed in root context (with super user permissions). If you are not already root, prepend all commands with sudo (eg: @ sudo bmx6 dev=eth1 @ ).
* NO IP address needs to be configured. By default bmx6 assumes IPv6 and autoconfigures an ULA based IPv6 address for each interface based on the MAC address of the device. Just, the interfaces must be UP. The linux ip command can do this for you (eg: @ ip link set wlan0 up @). Also, if you are using a wireless interface, the wireless interface settings must be set correctly so that link-layer connectivity is given with bmx6 daemons running on other nodes (computers). The good old iwconfig command may help to achieve that. For example @ iwconfig wlan0 mode ad-hoc ap 02:ca:ff:ee:ba:be channel 11 essid my-mesh-network @ is a typical configuration for a wireless mesh setup.
* Bmx6 (by default) works in daemon mode, thus sends itself to background and gives back a prompt. To let it run in foreground specify a debug level with the startup command like: @ bmx6 debug=0 dev=eth1 @ . Of course you may need to kill a previously started bmx6 daemon beforehand (@ killall bmx6 @)
If everything went fine bmx6 is running now, searching for neighboring bmx6 daemons via the configured interface (link), and coordinates with them to learn about existence-of and routes-to all other bmx6 nodes in the network.
h3. Accessing Protocol Events, Status, and Network Information
To access debug and status information of the bmx6 daemon which has just been started, a second bmx6 process can be launched in client mode (with the --connect or -c parameter) to connect to the main bmx6 daemon and retrieve the desired information.
In the following, a few example will be discussed
Continuous debug levels with different verbosity and scope are accessible with the --debug or -d parameter.
* Debug level 0 only reports critical events
* Debug level 3 reports relevant changes and
* Debug level 4 reports everything.
* Debug level 12 dump in and outgoing protocol traffic
Eg.: @ bmx6 -cd3 @ connects a bmx6 client process to debug-level 3 of the main daemon and logs the output stdout until terminated with ctrl-c
Status, network, and statistic information are accessible with dedicated parameters:
* status
* interfaces
* links
* originators
* descriptions, plus optional sub-parameters for filtering
* tunnels
* traffic=DEV where DEV:= all or eth1, ....
<pre>
root@mlc1001:~# bmx6 -c status
version compatibility codeVersion globalId primaryIp myLocalId uptime cpu nodes
BMX6-0.1-alpha 16 9 mlc1001.7A7422752001EC4AC4C8 fd66:66:66:0:a2cd:efff:fe10:101 24100101 0:00:40:37 0.1 4
</pre>
So apart from version, compatibility number, and code, the status reveals the daemon's global (see: [[Wiki#Global-ID]] ) and local ID, its primary (self-configured) IPv6 address, the time since when it is running (40 minutes), its current cpu consumption (0.1%) and the total number of 4 learned nodes in the network (including itself).
These desired types can be combined. Also the above given example shows kind of shortcut. The long argument would be
@ bmx6 connect show=status @. A more informative case using the long form would be:
<pre>
root@mlc1001:~# bmx6 connect show=status show=interfaces show=links show=originators show=tunnels
status:
version compatibility codeVersion globalId primaryIp myLocalId uptime cpu nodes
BMX6-0.1-alpha 16 9 mlc1001.7A7422752001EC4AC4C8 fd66:66:66:0:a2cd:efff:fe10:101 06100101 0:00:53:19 0.3 4
interfaces:
devName state type rateMin rateMax llocalIp globalIp multicastIp primary
eth1 UP ethernet 1000M 1000M fe80::a2cd:efff:fe10:101/64 fd66:66:66:0:a2cd:efff:fe10:101/64 ff02::2 1
links:
globalId llocalIp viaDev rxRate txRate bestTxLink routes wantsOgms nbLocalId
mlc1000.0AE58311046412F248CD fe80::a2cd:efff:fe10:1 eth1 100 100 1 1 1 9B100001
mlc1002.91DCF042934B5913BB00 fe80::a2cd:efff:fe10:201 eth1 100 100 1 2 1 BB100201
originators:
globalId blocked primaryIp routes viaIp viaDev metric lastDesc lastRef
mlc1000.0AE58311046412F248CD 0 fd66:66:66:0:a2cd:efff:fe10:1 1 fe80::a2cd:efff:fe10:1 eth1 999M 3193 3
mlc1001.7A7422752001EC4AC4C8 0 fd66:66:66:0:a2cd:efff:fe10:101 0 :: --- 128G 3197 0
mlc1002.91DCF042934B5913BB00 0 fd66:66:66:0:a2cd:efff:fe10:201 1 fe80::a2cd:efff:fe10:201 eth1 999M 3196 3
mlc1003.09E796BC491D386248C3 0 fd66:66:66:0:a2cd:efff:fe10:301 1 fe80::a2cd:efff:fe10:201 eth1 576M 22 3
</pre>
Only if relevant information for a requested type is available it will be shown.
In this example no tunnels are configured nor offered by other nodes and therefore no tunnel information is shown.
The loop argument can be prepended to the connect argument to continuously show the requested information.
Many of the long arguments are usable via a short notation, like l for loop, c for connect, s for show, d for debug.
And there is another shortcut summarizing my current favorite information types via debug level 8
The following commands do the same as above: @ bmx6 -lc status interfaces links originators tunnels @ or just @ bmx6 -lcd8 @.
Description of the provided info:
* interfaces: Followed by one line per configured interface
** dev: Interface name
** state and type: Whether the interface is UP or DOWN and its assumed link-layer type.
** rateMin and rateMax: Min- and maximum transmit rates assumed for this interface.
** llocalIp: IPv6 link-local address (used as source address for all outgoing protocol data).
** globalIp: Autoconfigured address used for sending network traffic via this interface and which is propagated to other nodes.
** multicastIp: Multicast IP (used as destination address for all bmx6 protocol traffic send via this interface).
** primary: Indicates whether the global ip of this interface is used as primary ip for this daemon.
* links: Followed by one line per detected neighboring bmx6 node.
** globalId: GlobalId of that neighbor (see: [[Wiki#Global-ID]] ).
** llocalIp: Link-local IP of the neighbor's interface building the other side of the link.
** viaDev: Interface of this node for the link.
** rxRate: Measured receive rate in percent for the link.
** txRate: Measured transmit rate in percent for the link.
** bestTxLink: Indicates whether this link is the best link to a neighboring nodes.
** routes: Indicates for how much routes to other nodes this link is used.
** wantsOgms: Indicates whether the neighboring node has requested (this node) to propagate originator messsages (OGMs) via this link.
** nbLocalId: Neighbors local ID.
* originators: Followed by one line per aware originator in the network (including itself).
** globalId: Global Id of that node (see: [[Wiki#Global-ID]] ).
** blocked: Indicates whether this node is currently blocked (see: [[Wiki#Blocked-Nodes]] ).
** primaryIp: The primary IP of that node.
** routes: Number of potential routes towards this node.
** viaIp: Next hops link-local IP of the best route towards this node.
** viaDev: Outgoing interface of the best route towards this node.
** metric: The end to end path metric to this node
** lastDesc: Seconds since the last description update was received (see: [[Widi#Description]] )
** lastRef: Seconds since this node was referenced by any neighboring node (like last sign of life)
Quick summary of provided info:
* Node mlc1001 uses one wired interface (eth1) which is up and actively used for meshing.
* Node mlc1001 got aware of 2 neighbors and 4 nodes (originators) including itself.
* The link qualities (rx and tx rate) to its neighbors are perfect (100%) and actively used (bestTxLink)
* Routes to nodes mlc1000 and mlc1002 are via interface eth1 and directly to the neighbor's link-local address with a metric of 999M (nearly maximum tx/rx rate of the configured interface)
* Route to node mlc1003 is setup via interface eth1 and via the link-local address of neighbor mlc1002 (at least two hops to the destination node).
The following links of the total network topology can be guessed from this information (further links may exist):
@ mlc1000 --- mlc1001 --- mlc1002 - - - mlc1003 @
h3. Simple Ping Test
This could be verified using traceroute6 towards the primary IP of the other nodes.
To mlc1000's primary IP fd66:66:66:0:a2cd:efff:fe10:1 shows one hop:
<pre>
root@mlc1001:~# traceroute6 -n -q 1 fd66:66:66:0:a2cd:efff:fe10:1
traceroute to fd66:66:66:0:a2cd:efff:fe10:1 (fd66:66:66:0:a2cd:efff:fe10:1), 30 hops max, 80 byte packets
1 fd66:66:66:0:a2cd:efff:fe10:1 0.324 ms
</pre>
To mlc1002's primary IP fd66:66:66:0:a2cd:efff:fe10:201 shows one hop:
<pre>
root@mlc1001:~# traceroute6 -n -q 1 fd66:66:66:0:a2cd:efff:fe10:201
traceroute to fd66:66:66:0:a2cd:efff:fe10:201 (fd66:66:66:0:a2cd:efff:fe10:201), 30 hops max, 80 byte packets
1 fd66:66:66:0:a2cd:efff:fe10:201 0.302 ms
</pre>
To mlc1003's primary IP fd66:66:66:0:a2cd:efff:fe10:301 shows two hops:
<pre>
root@mlc1001:~# traceroute6 -n -q 1 fd66:66:66:0:a2cd:efff:fe10:301
traceroute to fd66:66:66:0:a2cd:efff:fe10:301 (fd66:66:66:0:a2cd:efff:fe10:301), 30 hops max, 80 byte packets
1 fd66:66:66:0:a2cd:efff:fe10:201 0.313 ms
2 fd66:66:66:0:a2cd:efff:fe10:301 0.429 ms
</pre>
h3. Dynamic Reconfiguration
Most bmx6 parameters can be applied not only at startup, but also dynamically to an already running main daemon, using the --connect command.
For example interfaces can be added, removed, or specified with more details:
The following example removes interface eth1 and adds eth2 with a max rate of 100 Mbits (overwriting the default assumption of 1000Mbits for ethernet interfaces).
<pre>
bmx6 -c dev=-eth1 dev=eth2 /rateMax=100000
bmx6 -cd8
</pre>
Checking new status of interfaces, links, and originator:
<pre>
root@mlc1001:~# bmx6 -cd8
status:
version compatibility codeVersion globalId primaryIp myLocalId uptime cpu nodes
BMX6-0.1-alpha 16 9 mlc1001.7A7422752001EC4AC4C8 fd66:66:66:0:a2cd:efff:fe10:102 06100101 0:02:26:00 0.1 4
interfaces:
devName state type rateMin rateMax llocalIp globalIp multicastIp primary
eth2 UP ethernet 100M 100M fe80::a2cd:efff:fe10:102/64 fd66:66:66:0:a2cd:efff:fe10:102/64 ff02::2 1
links:
globalId llocalIp viaDev rxRate txRate bestTxLink routes wantsOgms nbLocalId
mlc1000.0AE58311046412F248CD fe80::a2cd:efff:fe10:2 eth2 89 88 1 3 1 9B100001
originators:
globalId blocked primaryIp routes viaIp viaDev metric lastDesc lastRef
mlc1000.0AE58311046412F248CD 0 fd66:66:66:0:a2cd:efff:fe10:1 1 fe80::a2cd:efff:fe10:2 eth2 81757K 18 0
mlc1001.7A7422752001EC4AC4C8 0 fd66:66:66:0:a2cd:efff:fe10:102 0 :: --- 128G 80 0
mlc1002.91DCF042934B5913BB00 0 fd66:66:66:0:a2cd:efff:fe10:201 1 fe80::a2cd:efff:fe10:2 eth2 83620K 14 4
mlc1003.09E796BC491D386248C3 0 fd66:66:66:0:a2cd:efff:fe10:301 1 fe80::a2cd:efff:fe10:2 eth2 81488K 9 0
</pre>
It can be seen that:
* Interface eth1 has been replaced by eth2 with a lower rate.
* The primary IP of the node has changed (using the autoconfigured IP from eth2.
* The old links (via eth1) are removed and a single new link via eth2 to mlc1000 has been detected
* All routes are now going via eth2 and mlc1000's link-local IP fe80::a2cd:efff:fe10:2
h2. Concepts
h3. Global ID
Each bmx6 node creates during its initialization (booting) a global ID for itself.
This ID is created as a concatenation of the node's hostname and a random value.
In the above given example with node hostname: "mlc1001" the globalID is: mlc1001.7A7422752001EC4AC4C8
When the bmx6 daemon restarts the hostname will remain. But the rand part will change.
As a consequence, the restarted node will appear as a new node to other nodes in the mesh while the old Global ID is still present in their node table.
Since both node IDs are announcing the same resources (eg the same primary IP), the ID that appears later will be blocked until the state maintained for the first ID expires.
h3. Descriptions
Instead of propagating individual routing updates for each announced network and interface address, each bmx6 daemon summarizes this and other node specific attributes into a single node-specific description. A specific description is propagated only once to all other nodes. Subsequent routing updates are referencing to the corresponding description with it's hash.
If a node is reconfigured, for example because its interfaces change or a new network shall be announced, than also the node's description changes.
Other nodes are becoming aware of the changed attributes of a reconfigured node by receiving a corresponding description update.
Subsequent references to this node will use the hash of the new description.
Because the description is designed very generic it can be easily used to piggyback other non-routing specific data. For example the bmx6-sms plugin is taking advantage of this option by adding arbitrary short messages data to the node's description.
Currently there is a limit for the total size of a description of 1400 bytes. While this is more than sufficient for quite a number of interfaces and announced networks per node, it is critical few when considering a gateway node with BGP route exchange that is announcing 100eds of networks.
h3. Blocked Nodes
Nodes may be blocked by other nodes.
When a node is blocked no routing updates (OGMs) of the blocked node are propagated by the blocking node.
The decision for blocking another node is done locally based on the detection of more than one node announcing the same unique resource.
This happens if two nodes are declaring themselves as the owner of a unique resource. Then one of those two nodes (usually the latter) is blocked to avoid the propagation of conflicting state. Duplicate address usage is the most common reason for such events which happens if two nodes are using (and announcing) the same primary IPs. Another typical scenario leading to such events is the rebooting of a node. Once a bmx6 daemon restarts it appears as a new node (with a new global ID) to the network but announcing the same address as the previous process. Since the resources allocated by the previous resources are still in the database of other nodes in the mesh they will block the new process until this information expires (by default after 100 seconds).
h2. Unicast Host Network Announcements (UHNA)
A Host Network Announcements (HNA) describes the advertisement of IP addresses and networks by a node to other nodes in the mesh.
Typically (but not with BMX6), several nodes can announce the same or overlapping HNAs at the same time.
Announced networks do overlap if they are equal or one being a subset of another (eg. 10.1.1.0/24 is a subset and overlapped by 10.1.0.0/16).
Packets with a destination address matching an announced networks will be routed toward any node that originated a corresponding HNA.
Therefore these HNA types may also be called anycast HNA.
In bmx6, HNAs have an unicast nature (UHNAs) because each network can only be announced once and announced networks MUST NOT overlap (See also [[Wiki#Blocked-Nodes]]).
This way it can be ensured that the destination of an UHNA routed packet is exactly known.
In a sense the origination and propagation (by intermediate nodes) of UHNA announcements can be thought of a promise that guarantees:
1. All packets with a destination address matching an announced UHNA network will be routed exactly to the node (with the global ID) that originated the UHNA and
2. each node on the forwarding path towards the originator of the UHNA is supporting this promise.
By default, Bmx6 only announces primary and non-primary interface addresses via UHNAs.
The auto address configuration ensures that interface addresses are unique.
Using UHNAs for the announcements of networks requires a strict coordination to ensure that no network is announced twice.
Technically, multiple UHNAs, each wrapped into a single message, are aggregated into a UHNA frame and attached to the description of a node.
If Bmx6 is configured in IPv6 mode only IPv6 UHNAs can be announced and in IPv4 mode only IPv4 UHNAs
h3. UHNA Configuration
The announcement of UHNAs can be configured with the --unicastHna or -u parameter followed by a network specification in ip/prefixlen notation.
By default all interface addresses are announced via UHNAs. However, this can be disabled by setting the --dev subparameter /announce or /a to 0.
The following example reconfigures an already running bmx6 daemon (in IPv6 mode) to UHNA announce the network fd00:ffff:ffff:ffff::/64 and fd01:ffff:ffff::/48.
By omitting the --connect / -c parameter, the same could be configured as startup parameter for bmx6.
<pre>
bmx6 -c u=fd00:ffff:ffff:ffff::/64 u=fd01:ffff:ffff::/48
</pre>
An already active announcement can be removed by preceeding the network with the '-' char:
<pre>
bmx6 -c u=-fd00:ffff:ffff:ffff::/64
</pre>
Before bmx6 accepts a dynamically configured UHNA announcement it checks if this UHNA is not overlapping with an already existing UHNA announcement form another node.
If this is the case the configuration will fail.
To check if a chain of dynamic commands would be accepted by a bmx6 daemon without actually applying it, the --test command may follow the --connect /-c command.
h2. Tunnel Announcements
Tunnel announcements offer an alternative mechanism to propagate routes.
Tunnel announcements are currently only implemented for Bmx6-IPv6 mode. However, in IPv6 mode IPv6 and IPv4 networks can be announced.
In contrast to UHNAs, using tunnel announcements, the same or overlapping networks can be announced from different nodes.
Tunnel announcements are an offer from the originating node to other nodes. Other nodes can take the offer or not.
For example several nodes in a network may offer to share their DSL connection by doing a default-route (0.0.0.0/0 or ::/0) tunnel announcement.
Other nodes looking for a route to the internet (a default route) can choose between the multiple offers by establishing a tunnel to one specific of the offering nodes.
Therefore an unidirectional (onw-way) tunnel is established from the searching to the offering node.
At the searching node, the remote tunnel address is configured with an UHNA address (usually the primary address) of the offering node.
and the networks advertised with the tunnel announcements are configured as routes via the unidirectional tunnel.
This way, each node can make an individual choice between networks offered via tunnel announcements.
The automatic selection can be specified via a policy description that considers parameters such as advertised bandwidth, path metric, trust in specific GW nodes, hysteresis, ... .
Since an UHNA address is used as the outer (remote) tunnel address, the client end of the tunnel can be sure that all packets routed into the tunnel will indeed end up at the intended GW node (see [[Wiki#Unicast-Host-Network-Announcements-UHNA]]).
Using tunnel announcements for offering GW services to networks requires NO coordination with other nodes since its up to the client node to select an appropriate GW.
Technically, multiple tunnel announcements, each wrapped into a single tun6in6-net message, are aggregated into a tun4in6 or tun6in6-net frame and attached to the description of a node.
Tunnel announcements are also used for redistributing routes from other routing protocols (see [[Wiki#Quagga-Plugin]]) into a bmx6 zone.
Therefore, each announcements message is decorated with a route-type field indicating the routing protocol that exported the route for being redistributed.
h3. Tunnel Configuration and Debugging
In the following, following the tunnel configuration is described from two perspectives:
* Gateway (GW) nodes or just GWs are offering GW services to networks via the advertizement of tunnel announcements and the provisioning of tunnel-end-points.
* GW-client nodes (or just GW-clients) that are searching for GWs with tunnel endpoints and routing services to networks.
h4. Gateway Nodes
Similar to the configuration of UHNAs the advertisement of a tunnel endpoint to a network can be configured with the --tunInNet --tunIn parameter + network argument and a bandwidth specification (given as bits per second) using the /bandwidth or /b sub parameter.
Announcement can be removed by preceeding the network argument with a '-' char.
The configuration can be done during daemon startup or dynamically (using --connect / -c parameter).
The following command dynamically configures the advertisement of the following routes:
* An an IPv4 default route 0.0.0.0/0 with a bandwidth of 32 Mbps.
* A a more specific route to 10.10.0.0/16 with a bandwidth of 10 Mbps.
* An an IPv6 route to the [RFC 4291] designated 2000::/3 global unicast address space with a bandwidth of 16 Mbps.
* A a more specific route to the 2012:1234::/32 IPv6 space at 10 Mbps.
<pre>
bmx6 -c tunInNet=0.0.0.0/0 tunIn=0.0.0.0/0 /b=32000000 tunInNet=10.10.0.0/16 tunIn=10.10.0.0/16 /b=10000000 tunInNet=2000::/3 tunIn=2000::/3 /b=16000000 tunInNet=2012:1234::/32 tunIn=2012:1234::/32 /b=10000000
</pre>
h4. Gateway-Client Nodes
The configuration of GW clients can simple but also, depending on the preferences of a desired GW-selection policy, very complex.
A general requirement for GW clients is the configuration of source addresses for all outgoing tunnels.
At least one network address must be configured for IPv6 and/or IPv4 tunnels using the the --tun4Address and/or --tun6Address parameters.
The specified addresses will automatically be advertized as tunnel announcements, allowing the GW client to be reachable via the given addresses.
Therefore, each GW client node is also a GW node to its own (usually small) tunnel address space.
Starting with the simple case,
h4. Tunnel Status Information
h2. Bmx6 Plugins
h3. Config Plugin
h4. Requirements
uci libs are needed for the bmx6-config plugin.
To install it do:
<pre>
wget http://downloads.openwrt.org/sources/uci-0.7.5.tar.gz
tar xzvf uci-0.7.5.tar.gz
cd uci-0.7.5
make
sudo make install
</pre>
Depending on your system there happens to be an error during compilation.
Then edit cli.c and change line 465 to: @ char *argv[MAX_ARGS+2]; @
h4. Compile and Install
To compile the bmx6 daemon and bmx6 plugins
<pre>
make build_all
sudo make install_all
</pre>
h4. Usage
h3. Json Plugin
h4. Requirements
* json-c for bmx6_json plugin (debian package: libjson0 libjson0-dev)
json-c developer libs are needed!
For further reading check: http://json.org/ or https://github.com/jehiah/json-c
Note for debian sid:
The debian package libjson0-dev 0.10-1 seems to miss the file /usr/include/json/json_object_iterator.h
Manually copying it from the below mentioned json-c_0.10.orig.tar.gz archive helps.
To install manually (only if NOT installed via debian or other package management system):
<pre>
wget http://ftp.de.debian.org/debian/pool/main/j/json-c/json-c_0.10.orig.tar.gz
tar xzvf json-c_0.10.orig.tar.gz
cd json-c..
./configure ; make ; make install; ldconfig
</pre>
h4. Compile and Install
To compile the bmx6 daemon and bmx6 plugins
<pre>
make build_all
sudo make install_all
</pre>
h4. Usage
h3. SMS Plugin
h3. Quagga Plugin
*Misc*
[[Tunnel]]