Projecte

General

Perfil

Wiki » Historial » Versió 64

Axel Neumann, 18-08-2013 14:13

1 54 Pau Escrich
!bmx6.png!
2 1 Pau Escrich
3
Bmx6 is a routing protocol for Linux based operating systems.
4 6 Axel Neumann
The following intro provides kind of tutorial to get started.
5
6 56 Pau Escrich
{{>toc}}
7 1 Pau Escrich
8 8 Axel Neumann
h2. Installation
9 6 Axel Neumann
10 8 Axel Neumann
h3. Requirements
11 7 Axel Neumann
12 6 Axel Neumann
The following tools are needed to obtain, compile, and install bmx6
13
* git (debian package: git-core)
14
* gcc
15
* make
16
17
18 8 Axel Neumann
h3. Downloading
19 6 Axel Neumann
20
Latest development sources are available from bmx6 git repository
21
<pre>
22
git clone git://qmp.cat/bmx6.git
23
cd bmx6
24
</pre>
25
26 8 Axel Neumann
h3. Compile and Install
27 6 Axel Neumann
28 7 Axel Neumann
To only compile the main bmx6 daemon (no bmx6 plugins)
29 6 Axel Neumann
<pre>
30
make
31
sudo make install
32
</pre>
33
34
35 57 Pau Escrich
h2. Installing in OpenWRT 
36
37
Bmx6 is currently in the official routing feed of OpenWRT, so to install it from a existing system you can use opkg
38
39
    opkg install bmx6 bmx6-uci-config
40
41
h3. Compile it by adding a feed
42
43
If you are compiling your own OpenWRT, you can add the routing feed (already enabled by default) which can be found here
44
45
     https://github.com/openwrt-routing/packages
46
47
Then run "make menuconfig" and select the bmx6 package in _Networking -> Routing and redirection_
48
49
It is recommended to select also, at least, the uci plugin (bmx6-uci-config)
50
51
You can select "luci-app-bmx6" to have a nice web interface for manage and monitorize the routing daemon.
52
53
Finally type "make" to build the image.
54
55
56 8 Axel Neumann
h2. Usage (hello mesh)
57 6 Axel Neumann
58 19 Axel Neumann
h3. Starting
59 3 Axel Neumann
60
In its most simple configuration, the only required parameter are the interfaces names that should be used for meshing.
61
The following example starts bmx6 on interface wlan0:
62
<pre>
63 15 Axel Neumann
root@mlc1001:~# bmx6 dev=eth1
64 3 Axel Neumann
</pre>
65
66
However, to let this simple command work as expected also check the following basic requirements:
67
68 15 Axel Neumann
* 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 @ ).
69 3 Axel Neumann
70 9 Axel Neumann
* 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.
71 3 Axel Neumann
72 15 Axel Neumann
* 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 @)
73 1 Pau Escrich
74 19 Axel Neumann
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.
75 1 Pau Escrich
76 19 Axel Neumann
77
78
79
80
h3. Accessing Protocol Events, Status, and Network Information
81
82
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.
83
84
In the following, a few example will be discussed
85
86
Continuous debug levels with different verbosity and scope are accessible with the --debug or -d parameter.
87
* Debug level 0 only reports critical events
88
* Debug level 3 reports relevant changes and 
89
* Debug level 4 reports everything.
90
* Debug level 12 dump in and outgoing protocol traffic
91 50 Pau Escrich
92
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
93 19 Axel Neumann
94
95
96
Status, network, and statistic information are accessible with dedicated parameters:
97
* status
98
* interfaces
99
* links
100
* originators
101 21 Axel Neumann
* descriptions, plus optional sub-parameters for filtering
102 19 Axel Neumann
* tunnels
103
* traffic=DEV where DEV:= all or eth1, ....
104
105
106 18 Axel Neumann
<pre>
107 1 Pau Escrich
root@mlc1001:~# bmx6 -c status
108
version        compatibility codeVersion globalId                     primaryIp                       myLocalId uptime     cpu nodes 
109
BMX6-0.1-alpha 16            9           mlc1001.7A7422752001EC4AC4C8 fd66:66:66:0:a2cd:efff:fe10:101 24100101  0:00:40:37 0.1 4
110
</pre>
111 18 Axel Neumann
112 5 Axel Neumann
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).
113 9 Axel Neumann
114 19 Axel Neumann
These desired types can be combined. Also the above given example shows kind of shortcut. The long argument would be
115
@ bmx6 connect show=status @. A more informative case using the long form would be:
116 1 Pau Escrich
<pre>
117 9 Axel Neumann
root@mlc1001:~# bmx6 connect show=status show=interfaces show=links show=originators show=tunnels
118 1 Pau Escrich
status:
119 18 Axel Neumann
version        compatibility codeVersion globalId                     primaryIp                       myLocalId uptime     cpu nodes
120
BMX6-0.1-alpha 16            9           mlc1001.7A7422752001EC4AC4C8 fd66:66:66:0:a2cd:efff:fe10:101 06100101  0:00:53:19 0.3 4
121 15 Axel Neumann
interfaces:
122 18 Axel Neumann
devName state type     rateMin rateMax llocalIp                    globalIp                           multicastIp primary
123
eth1    UP    ethernet 1000M   1000M   fe80::a2cd:efff:fe10:101/64 fd66:66:66:0:a2cd:efff:fe10:101/64 ff02::2     1
124 15 Axel Neumann
links:
125 18 Axel Neumann
globalId                     llocalIp                 viaDev rxRate txRate bestTxLink routes wantsOgms nbLocalId
126
mlc1000.0AE58311046412F248CD fe80::a2cd:efff:fe10:1   eth1   100    100    1          1      1         9B100001
127
mlc1002.91DCF042934B5913BB00 fe80::a2cd:efff:fe10:201 eth1   100    100    1          2      1         BB100201
128 15 Axel Neumann
originators:
129 18 Axel Neumann
globalId                     blocked primaryIp                       routes viaIp                    viaDev metric lastDesc lastRef
130
mlc1000.0AE58311046412F248CD 0       fd66:66:66:0:a2cd:efff:fe10:1   1      fe80::a2cd:efff:fe10:1   eth1   999M   3193     3 
131
mlc1001.7A7422752001EC4AC4C8 0       fd66:66:66:0:a2cd:efff:fe10:101 0      ::                       ---    128G   3197     0
132
mlc1002.91DCF042934B5913BB00 0       fd66:66:66:0:a2cd:efff:fe10:201 1      fe80::a2cd:efff:fe10:201 eth1   999M   3196     3 
133
mlc1003.09E796BC491D386248C3 0       fd66:66:66:0:a2cd:efff:fe10:301 1      fe80::a2cd:efff:fe10:201 eth1   576M   22       3 
134 1 Pau Escrich
</pre>
135
136 9 Axel Neumann
Only if relevant information for a requested type is available it will be shown.
137
In this example no tunnels are configured nor offered by other nodes and therefore no tunnel information is shown.
138 1 Pau Escrich
139 9 Axel Neumann
The loop argument can be prepended to the connect argument to continuously show the requested information.
140
Many of the long arguments are usable via a short notation, like l for loop, c for connect, s for show, d for debug.
141
And there is another shortcut summarizing my current favorite information types via debug level 8
142
The following commands do the same as above: @ bmx6 -lc status interfaces links originators tunnels @ or just @ bmx6 -lcd8 @.
143 1 Pau Escrich
144 18 Axel Neumann
Description of the provided info:
145 14 Axel Neumann
* interfaces: Followed by one line per configured interface
146
** dev: Interface name
147
** state and type: Whether the interface is UP or DOWN and its assumed link-layer type.
148
** rateMin and rateMax: Min- and maximum transmit rates assumed for this interface.
149
** llocalIp: IPv6 link-local address (used as source address for all outgoing protocol data).
150
** globalIp: Autoconfigured address used for sending network traffic via this interface and which is propagated to other nodes.
151
** multicastIp: Multicast IP (used as destination address for all bmx6 protocol traffic send via this interface).
152
** primary: Indicates whether the global ip of this interface is used as primary ip for this daemon.
153
* links: Followed by one line per detected neighboring bmx6 node.
154 16 Axel Neumann
** globalId: GlobalId of that neighbor (see: [[Wiki#Global-ID]] ).
155 14 Axel Neumann
** llocalIp: Link-local IP of the neighbor's interface building the other side of the link.
156
** viaDev: Interface of this node for the link.
157
** rxRate: Measured receive rate in percent for the link.
158
** txRate: Measured transmit rate in percent for the link.
159
** bestTxLink: Indicates whether this link is the best link to a neighboring nodes.
160 1 Pau Escrich
** routes: Indicates for how much routes to other nodes this link is used.
161
** wantsOgms: Indicates whether the neighboring node has requested (this node) to propagate originator messsages (OGMs) via this link.
162
** nbLocalId: Neighbors local ID.
163
* originators: Followed by one line per aware originator in the network (including itself).
164
** globalId: Global Id of that node (see: [[Wiki#Global-ID]] ).
165 30 Axel Neumann
** blocked: Indicates whether this node is currently blocked (see: [[Wiki#Blocked-Nodes]] ).
166 1 Pau Escrich
** primaryIp: The primary IP of that node. 
167
** routes: Number of potential routes towards this node.
168
** viaIp: Next hops link-local IP of the best route towards this node.
169
** viaDev: Outgoing interface of the best route towards this node.
170
** metric: The end to end path metric to this node
171
** lastDesc: Seconds since the last description update was received (see: [[Widi#Description]] )
172 18 Axel Neumann
** lastRef: Seconds since this node was referenced by any neighboring node (like last sign of life)
173
174
175
Quick summary of provided info:
176
* Node mlc1001 uses one wired interface (eth1) which is up and actively used for meshing.
177
* Node mlc1001 got aware of 2 neighbors and 4 nodes (originators) including itself.
178
* The link qualities (rx and tx rate) to its neighbors are perfect (100%) and actively used (bestTxLink)
179 1 Pau Escrich
* 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)
180
* 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).
181
182 21 Axel Neumann
The following links of the total network topology can be guessed from this information (further links may exist):
183 1 Pau Escrich
@ mlc1000 --- mlc1001 --- mlc1002 - - - mlc1003 @
184
185 21 Axel Neumann
186
187
188 19 Axel Neumann
h3. Simple Ping Test
189
190 1 Pau Escrich
This could be verified using traceroute6 towards the primary IP of the other nodes.
191 18 Axel Neumann
192 19 Axel Neumann
To mlc1000's primary IP fd66:66:66:0:a2cd:efff:fe10:1 shows one hop:
193 18 Axel Neumann
<pre>
194
root@mlc1001:~# traceroute6 -n -q 1 fd66:66:66:0:a2cd:efff:fe10:1
195
traceroute to fd66:66:66:0:a2cd:efff:fe10:1 (fd66:66:66:0:a2cd:efff:fe10:1), 30 hops max, 80 byte packets
196 1 Pau Escrich
 1  fd66:66:66:0:a2cd:efff:fe10:1  0.324 ms
197 18 Axel Neumann
</pre>
198
199 19 Axel Neumann
To mlc1002's primary IP fd66:66:66:0:a2cd:efff:fe10:201 shows one hop:
200 18 Axel Neumann
<pre>
201
root@mlc1001:~# traceroute6 -n -q 1 fd66:66:66:0:a2cd:efff:fe10:201
202
traceroute to fd66:66:66:0:a2cd:efff:fe10:201 (fd66:66:66:0:a2cd:efff:fe10:201), 30 hops max, 80 byte packets
203
 1  fd66:66:66:0:a2cd:efff:fe10:201  0.302 ms
204 1 Pau Escrich
</pre>
205
206 19 Axel Neumann
To mlc1003's primary IP fd66:66:66:0:a2cd:efff:fe10:301 shows two hops:
207 1 Pau Escrich
<pre>
208
root@mlc1001:~# traceroute6 -n -q 1 fd66:66:66:0:a2cd:efff:fe10:301
209 18 Axel Neumann
traceroute to fd66:66:66:0:a2cd:efff:fe10:301 (fd66:66:66:0:a2cd:efff:fe10:301), 30 hops max, 80 byte packets
210
 1  fd66:66:66:0:a2cd:efff:fe10:201  0.313 ms
211
 2  fd66:66:66:0:a2cd:efff:fe10:301  0.429 ms
212
</pre>
213 19 Axel Neumann
214 1 Pau Escrich
215
h3. Dynamic Reconfiguration
216
217
Most bmx6 parameters can be applied not only at startup, but also dynamically to an already running main daemon, using the --connect command.
218 21 Axel Neumann
For example interfaces can be added, removed, or specified with more details:
219
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).
220
<pre>
221
bmx6 -c dev=-eth1 dev=eth2 /rateMax=100000
222
bmx6 -cd8
223
</pre>
224 1 Pau Escrich
225 21 Axel Neumann
Checking new status of interfaces, links, and originator:
226
<pre>
227
root@mlc1001:~# bmx6 -cd8
228
status:
229
version        compatibility codeVersion globalId                     primaryIp                       myLocalId uptime     cpu nodes 
230
BMX6-0.1-alpha 16            9           mlc1001.7A7422752001EC4AC4C8 fd66:66:66:0:a2cd:efff:fe10:102 06100101  0:02:26:00 0.1 4 
231
interfaces:
232
devName state type     rateMin rateMax llocalIp                    globalIp                           multicastIp primary 
233
eth2    UP    ethernet 100M    100M    fe80::a2cd:efff:fe10:102/64 fd66:66:66:0:a2cd:efff:fe10:102/64 ff02::2     1       
234
links:
235
globalId                     llocalIp               viaDev rxRate txRate bestTxLink routes wantsOgms nbLocalId 
236
mlc1000.0AE58311046412F248CD fe80::a2cd:efff:fe10:2 eth2   89     88     1          3      1         9B100001  
237
originators:
238
globalId                     blocked primaryIp                       routes viaIp                  viaDev metric lastDesc lastRef 
239
mlc1000.0AE58311046412F248CD 0       fd66:66:66:0:a2cd:efff:fe10:1   1      fe80::a2cd:efff:fe10:2 eth2   81757K 18       0      
240
mlc1001.7A7422752001EC4AC4C8 0       fd66:66:66:0:a2cd:efff:fe10:102 0      ::                     ---    128G   80       0      
241
mlc1002.91DCF042934B5913BB00 0       fd66:66:66:0:a2cd:efff:fe10:201 1      fe80::a2cd:efff:fe10:2 eth2   83620K 14       4      
242
mlc1003.09E796BC491D386248C3 0       fd66:66:66:0:a2cd:efff:fe10:301 1      fe80::a2cd:efff:fe10:2 eth2   81488K 9        0
243
</pre>
244 1 Pau Escrich
245 21 Axel Neumann
It can be seen that:
246
* Interface eth1 has been replaced by eth2 with a lower rate.
247
* The primary IP of the node has changed (using the autoconfigured IP from eth2.
248
* The old links (via eth1) are removed and a single new link via eth2 to mlc1000 has been detected
249
* All routes are now going via eth2 and mlc1000's link-local IP fe80::a2cd:efff:fe10:2
250 1 Pau Escrich
251 21 Axel Neumann
252
253
254
255 1 Pau Escrich
h2. Concepts
256 17 Axel Neumann
257
h3. Global ID
258
259
Each bmx6 node creates during its initialization (booting) a global ID for itself. 
260
This ID is created as a concatenation of the node's hostname and a random value.
261
In the above given example with node hostname: "mlc1001" the globalID is: mlc1001.7A7422752001EC4AC4C8
262 1 Pau Escrich
When the bmx6 daemon restarts the hostname will remain. But the rand part will change.
263
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.
264
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.
265
266 26 Axel Neumann
267
268 21 Axel Neumann
h3. Descriptions
269
270 22 Axel Neumann
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.
271 23 Axel Neumann
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.
272
Other nodes are becoming aware of the changed attributes of a reconfigured node by receiving a corresponding description update.
273
Subsequent references to this node will use the hash of the new description.
274
275
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.
276
277 25 Axel Neumann
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.
278 23 Axel Neumann
279 30 Axel Neumann
h3. Blocked Nodes
280 26 Axel Neumann
281 29 Axel Neumann
Nodes may be blocked by other nodes.
282
When a node is blocked no routing updates (OGMs) of the blocked node are propagated by the blocking node.
283
The decision for blocking another node is done locally based on the detection of more than one node announcing the same unique resource.
284 59 Axel Neumann
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 allocations (and ambiguous forwarding 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 causing such case temporary is the rebooting of a node. Once a bmx6 daemon restarts it appears as a new node (with a new random part of it's global ID) to the network but (due to a typically persistant configuration) 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).
285 26 Axel Neumann
286 1 Pau Escrich
287 29 Axel Neumann
288
289
h2. Unicast Host Network Announcements (UHNA)
290
291 26 Axel Neumann
A Host Network Announcements (HNA) describes the advertisement of IP addresses and networks by a node to other nodes in the mesh.
292 29 Axel Neumann
Typically (but not with BMX6), several nodes can announce the same or overlapping HNAs at the same time.
293
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).
294 26 Axel Neumann
Packets with a destination address matching an announced networks will be routed toward any node that originated a corresponding HNA.
295
Therefore these HNA types may also be called anycast HNA.
296
297 30 Axel Neumann
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]]).
298 26 Axel Neumann
This way it can be ensured that the destination of an UHNA routed packet is exactly known.
299
300
In a sense the origination and propagation (by intermediate nodes) of UHNA announcements can be thought of a promise that guarantees:
301
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
302
2. each node on the forwarding path towards the originator of the UHNA is supporting this promise.
303
304
By default, Bmx6 only announces primary and non-primary interface addresses via UHNAs.
305 1 Pau Escrich
The auto address configuration ensures that interface addresses are unique.
306 26 Axel Neumann
307 1 Pau Escrich
Using UHNAs for the announcements of networks requires a strict coordination to ensure that no network is announced twice.
308
309
Technically, multiple UHNAs, each wrapped into a single message, are aggregated into a UHNA frame and attached to the description of a node.
310
311 32 Axel Neumann
If Bmx6 is configured in IPv6 mode only IPv6 UHNAs can be announced and in IPv4 mode only IPv4 UHNAs
312
313
314 31 Axel Neumann
h3. UHNA Configuration
315 30 Axel Neumann
316
The announcement of UHNAs can be configured with the --unicastHna or -u parameter followed by a network specification in ip/prefixlen notation.
317
By default all interface addresses are announced via UHNAs. However, this can be disabled by setting the --dev subparameter /announce or /a to 0.
318
319
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.
320
By omitting the --connect / -c parameter, the same could be configured as startup parameter for bmx6.
321
<pre>
322
bmx6 -c u=fd00:ffff:ffff:ffff::/64 u=fd01:ffff:ffff::/48
323
</pre>
324
325
An already active announcement can be removed by preceeding the network with the '-' char:
326
<pre>
327
bmx6 -c u=-fd00:ffff:ffff:ffff::/64
328
</pre>
329
330
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.
331
If this is the case the configuration will fail.
332
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.
333
334
335 26 Axel Neumann
336 29 Axel Neumann
h2. Tunnel Announcements
337 26 Axel Neumann
338 27 Axel Neumann
339 32 Axel Neumann
Tunnel announcements offer an alternative mechanism to propagate routes. 
340 59 Axel Neumann
Tunnel announcements are currently only implemented for Bmx6-IPv6 mode. 
341
However, in IPv6 mode IPv6 and IPv4 networks can be announced.
342
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.
343 1 Pau Escrich
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.
344
Therefore an unidirectional (onw-way) tunnel is established from the searching to the offering node.
345 46 Axel Neumann
At the searching node, the remote (outer) tunnel address is configured with an UHNA address (usually the primary address) of the offering node.
346
The networks advertised with the tunnel announcements are configured at the client side as routes via (into) the unidirectional tunnel.
347 1 Pau Escrich
348
This way, each node can make an individual choice between networks offered via tunnel announcements.
349
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, ... .
350 26 Axel Neumann
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]]).
351 29 Axel Neumann
352 59 Axel Neumann
Technically, multiple tunnel announcements, each wrapped into a single tun4/6in6-net message, are aggregated into a tun4/6in6-net frame and attached to the description of a node.
353 1 Pau Escrich
354 32 Axel Neumann
Tunnel announcements are also used for redistributing routes from other routing protocols (see [[Wiki#Quagga-Plugin]]) into a bmx6 zone. 
355 1 Pau Escrich
Therefore, each announcements message is decorated with a route-type field indicating the routing protocol that exported the route for being redistributed.
356 31 Axel Neumann
357 1 Pau Escrich
358 60 Axel Neumann
h3. Tunnel Configuration and Debugging 
359 33 Axel Neumann
360 34 Axel Neumann
In general, a specific tunnel configuration is described from two perspectives:
361 32 Axel Neumann
* 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.
362 1 Pau Escrich
* GW-client nodes (or just GW-clients) that are searching for GWs with tunnel endpoints and routing services to networks.
363
364
A node can (and usually is) operating in both modes (as GW and as GW-client). 
365 59 Axel Neumann
But regarding a specific network each node is operating either in GW mode (thus, offering GW-services to that network) or in GW-client mode (thus, searching and using GW-services to that network)!
366 1 Pau Escrich
367
368 61 Axel Neumann
A quick and simple tunnel configuration example is given here.
369
Further details and options are described in the next Sections.
370 63 Axel Neumann
The full set of available options for configuring tunnels is given via the build-in --help and --verboseHelp commands
371 61 Axel Neumann
372
* First make your own tunnel addresses known and reachable for other nodes, eg:
373 60 Axel Neumann
<pre>
374
bmx6 -c tunDev=Default /tun4Address=10.254.10.123/32 /tun6Address=2012:1234:5678:123::1/64
375 1 Pau Escrich
</pre>
376 60 Axel Neumann
377 61 Axel Neumann
* Second, configure the automatic establishment of outgoing tunnels to other nodes by searching and selecting any kind of announcement:
378 60 Axel Neumann
<pre>
379
bmx6 -c tunOut=v4Default /network=0.0.0.0/0 tunOut=v6Default /network=::/0
380 1 Pau Escrich
</pre>
381 59 Axel Neumann
382 62 Axel Neumann
* Optionally, check the currently offered tunnel announcements of other GW nodes and the selected tunnel routes by this node with:
383
<pre>
384
bmx6 -c show=tunnels
385
</pre>
386 61 Axel Neumann
387 62 Axel Neumann
388 59 Axel Neumann
Remark: Since master commit f2fd75072f7dc4738069be6c69625419b9cc7767 the syntax for configuring tunnels has changed.
389 1 Pau Escrich
In the following the new syntax is explained. 
390 60 Axel Neumann
For the old syntax please use the build-in --help and --verboseHelp of the binary you are using
391 1 Pau Escrich
392 60 Axel Neumann
393 1 Pau Escrich
h4. Tunnel Device Configuration
394
395
Operation in GW and/or GW-client mode implies the configuration of a bmx6 tunnel device and the IPv4 and/or IPv6 addresses that shall be used for tunnel traffic.
396 60 Axel Neumann
397
The selection of these addresses should be coordinated with:
398
* the mesh community because conflicting tunnel address usage will cause problems for the conflicting nodes
399
* GW administrators because (depending on the GW connection to other networks) only specific addresses may be routable and considered to be originated from the bmx6 cloud. 
400
401 1 Pau Escrich
The command
402 60 Axel Neumann
<pre>
403 1 Pau Escrich
bmx6 -c tunDev=Default /tun4Address=10.254.10.123/32 /tun6Address=2012:1234:5678:123::1/64
404 60 Axel Neumann
</pre>
405 1 Pau Escrich
dynamically
406 62 Axel Neumann
* configures a linux ip4/6in6 tunnel device called bmx6Default (check it with command: ip link show).
407 60 Axel Neumann
* assignes the address 10.254.10.123 and 2012:1234:5678:123::1 to the tunnel interface and uses them for outgoing tunnel traffic.
408
* enables GW-mode for the specified networks: Makes a tunnel announcement so that other nodes can select it for tunneling packets to this node.
409 1 Pau Escrich
410 60 Axel Neumann
Now other nodes can send tunneled packets to this node via the unidirectional tunnel end point offered by this node.
411 1 Pau Escrich
412
413 60 Axel Neumann
But for bidirectional tunnel communication with any another node also a backwards tunnel is needed (an unidirectional tunnel from this node to the other node).
414
415
The automatic selection and establishemt of tunnels to other nodes is achieved with the GW-client mode as described in more derail in the next Section.
416
417
418
h4. Gateway-Client Nodes
419
420
The configuration of GW clients can be simple but also, depending on the preferences for a GW-selection policy, very complex.
421
Through the configuration of the mandatory tunDev and it's addresses (see above), each GW client node is also a GW node to its own (usually small) tunnel address space.
422
423
In the following simple example a GW-client node is searching for any other kind of offered IPv4 and v6 tunnels:
424
425
<pre>
426
bmx6 -c tunOut=v4Default /network=0.0.0.0/0 tunOut=v6Default /network=::/0
427
</pre>
428
429
430
With the above configured tunnel selection policy, tunnels are selected in the following order:
431
1) prefix-length of announced tunnels (networks that are more specific than others).
432
2) the resulting tunnelMetric (combination of the advertised bandwidth, path metric in the bmx6 cloud, and locally specified prefereces like hysteresis or bonus)
433 1 Pau Escrich
434 63 Axel Neumann
The disadvantage of this simple config is that other nodes can easily redirect your tunnel selections to specific networks by announcing more precise tunnel networks (larger prefix length). To prevent this, selection policy can be split into several and more precise search directives.
435 60 Axel Neumann
436 1 Pau Escrich
Imagine the following address assignment policy for IPv4 tunnel addresses in a mesh cloud (the general idea can be straight translated to IPv6).
437 62 Axel Neumann
438 60 Axel Neumann
* Nodes in the mesh cloud announce their private and local address ranges with a prefix length of 24 and somewhere in the range of 10.254.0.0/16. 
439 1 Pau Escrich
Announcements of this type should always be preferred, even if any of the following announced types has a better end-to-end metric or more precise announcement.
440
<pre>
441 63 Axel Neumann
bmx6 -c tunOut=v4Nodes /network=10.254.0.0/16 /minPrefixLen=24 /maxPrefixLen=24 /ipmetric=2001
442 62 Axel Neumann
</pre>
443 1 Pau Escrich
444 62 Axel Neumann
* Some BGP GW nodes are connected to other mesh clouds/areas of the same overall community network. These clouds are operating in a different IPv4 range (than 10.254.0.0/16) but always somewhere in the range of 10.0.0.0/8. Route announcements of this type should be preferred over the announcement of a default route.
445 60 Axel Neumann
<pre>
446
bmx6 -c tunOut=v4Clouds /network=10.0.0.0/8 /maxPrefixLen=16 /bgp=1
447 62 Axel Neumann
</pre>
448 1 Pau Escrich
449 60 Axel Neumann
* Some DSL GW nodes are offering to share their DSL line and are announcing a default route (0.0.0.0/0). 
450
Further, to mitigate the effects of GW switching between GWs having a similar end-to-end metric a GW switch should only happen if the other GW is at least 30% better.
451
<pre>
452
bmx6 -c tunOut=v4Default /network=0.0.0.0/0 /maxPrefixLen=0 /hysteresis=30 # refine the above configured v4 tunnel search
453 62 Axel Neumann
</pre>
454 60 Axel Neumann
455
* In case my node is directly connected to a DSL gateway and gets a automatically (dhcp) configured default route in the main routing table (use: ip route show table main ). then this route should be preferred and should NOT clash with default tunnel routes configured by bmx6. 
456
Therefore move all bmx6 tunnel routes to 0.0.0.0/0 into a separate routing table with lower lookup prioriy (check with: ip rule show; ip route show table 150)
457
<pre>
458
bmx6 -c tunOut=v4Default /network=0.0.0.0/0 /maxPrefixLen=0 /hysteresis=30 /tableRule=50000/150 # again refine the above default search
459 62 Axel Neumann
</pre>
460 60 Axel Neumann
461
462
* The default route announcements from two well known GWs (with hostname pepe and paula) should be strictly preferred over unknown GWs. 
463
So, if available, move them to new table (with lower priority than main and higher priority than used for the backup tunnel rule configured above)
464
<pre>
465
bmx6 -c tunOut=v4DefaultPepe  /network=0.0.0.0/0 /maxPrefixLen=0 /name=pepe  /hysteresis=30 /tableRule=40000/140
466
bmx6 -c tunOut=v4DefaultPaula /network=0.0.0.0/0 /maxPrefixLen=0 /name=paula /hysteresis=30 /tableRule=40000/140
467
</pre>
468
469
* Finally, GW Paula turned out to be more stable. Therefore I want to prefer GW Paula over Pepe:
470
<pre>
471
bmx6 -c tunOut=v4DefaultPaula /network=0.0.0.0/0 /maxPrefixLen=0 /name=paula /hysteresis=30 /bonus=100
472
</pre>
473
474
475
476 1 Pau Escrich
h4. Gateway Nodes
477
478
The advertisement of a tunnel endpoint to a network can be configured with the --tunIn=<arbitrary name>  and /network=<network> argument and an optional bandwidth specification (given as bits per second) using the /bandwidth or /b sub parameter.
479
Announcement can be removed by preceeding the name argument with a '-' char. 
480 46 Axel Neumann
481
The following command dynamically configures the advertisement of the following routes:
482
* An IPv4 default route 0.0.0.0/0 with a bandwidth of 32 Mbps.
483 63 Axel Neumann
* A more specific route to 10.10.0.0/16 with a bandwidth of 10 Mbps (eg: a local v4 Network).
484 46 Axel Neumann
* An IPv6 route to the [RFC 4291] designated 2000::/3 global unicast address space with a bandwidth of 16 Mbps.
485 63 Axel Neumann
* A more specific route to the 2012:1234::/32 IPv6 space at 10 Mbps (eg: a local v6 Network).
486 46 Axel Neumann
487
<pre>
488
bmx6 -c tunIn=def4Offer /n=0.0.0.0/0 /b=32000000  tunIn=local4 /n=10.10.0.0/16 /b=10000000  tunIn=def6Offer /n=2000::/3 /b=16000000  tunIn=local6 /n=2012:1234::/32 /b=10000000
489 1 Pau Escrich
</pre>
490 33 Axel Neumann
491
492
h4. Tunnel Status Information
493 36 Axel Neumann
494 63 Axel Neumann
Tunnel status information can be accessed with the --tunnels or --show=tunnels parameters.
495 10 Axel Neumann
496 1 Pau Escrich
497
498
499
h2. Bmx6 Plugins
500 36 Axel Neumann
501 1 Pau Escrich
h3. Compile and Install
502 36 Axel Neumann
503
To compile and install bmx6 daemon and all bmx6 plugins simply do:
504
<pre>
505
make build_all
506
sudo make install_all
507 1 Pau Escrich
</pre>
508 36 Axel Neumann
509
However. specific requirements may need to be fulfilled for some plugins in order to compile correctly.
510 32 Axel Neumann
These requirements are described in the corresponding plugin section.
511
512 1 Pau Escrich
513 36 Axel Neumann
514 1 Pau Escrich
h2. Config Plugin
515 8 Axel Neumann
516 36 Axel Neumann
517 1 Pau Escrich
h3. Requirements
518 8 Axel Neumann
519
uci libs are needed for the bmx6-config plugin.
520 1 Pau Escrich
To install it do:
521 8 Axel Neumann
<pre>
522
wget http://downloads.openwrt.org/sources/uci-0.7.5.tar.gz
523
tar xzvf uci-0.7.5.tar.gz
524 1 Pau Escrich
cd uci-0.7.5
525 8 Axel Neumann
make
526
sudo make install
527 1 Pau Escrich
</pre>
528 8 Axel Neumann
529
Depending on your system there happens to be an error during compilation.
530
Then edit cli.c and change line 465 to: @ char *argv[MAX_ARGS+2]; @
531 36 Axel Neumann
532 8 Axel Neumann
h3. Compile and Install
533
534 36 Axel Neumann
<pre>
535
make -C lib/bmx6_uci_config/ 
536 8 Axel Neumann
sudo make -C lib/bmx6_uci_config/ install
537
</pre>
538
539 36 Axel Neumann
540 8 Axel Neumann
h3. Usage
541
542
543 36 Axel Neumann
544 64 Axel Neumann
545
546 8 Axel Neumann
h2. Json Plugin
547
548 36 Axel Neumann
549 1 Pau Escrich
h3. Requirements
550 8 Axel Neumann
551 1 Pau Escrich
* json-c for bmx6_json plugin (debian package: libjson0 libjson0-dev)
552 8 Axel Neumann
553 1 Pau Escrich
554 8 Axel Neumann
json-c developer libs are needed!
555
For further reading check: http://json.org/ or https://github.com/jehiah/json-c
556
557
Note for debian sid:
558
The debian package libjson0-dev 0.10-1 seems to miss the file /usr/include/json/json_object_iterator.h
559
Manually copying it from the below mentioned json-c_0.10.orig.tar.gz archive helps.
560
561
562
To install manually (only if NOT installed via debian or other package management system):
563
<pre>
564
wget http://ftp.de.debian.org/debian/pool/main/j/json-c/json-c_0.10.orig.tar.gz
565 1 Pau Escrich
tar xzvf json-c_0.10.orig.tar.gz
566 8 Axel Neumann
cd json-c..
567
./configure ; make ; make install; ldconfig
568
</pre>
569
570 36 Axel Neumann
571 8 Axel Neumann
h3. Compile and Install
572 36 Axel Neumann
573 1 Pau Escrich
To compile and install only the  bmx6 json plugins:
574 36 Axel Neumann
<pre>
575
make -C lib/bmx6_json/ 
576 8 Axel Neumann
sudo make -C lib/bmx6_json/ install
577
</pre>
578
579 36 Axel Neumann
580 3 Axel Neumann
h3. Usage
581 35 Axel Neumann
582
583 36 Axel Neumann
584 64 Axel Neumann
585
586 35 Axel Neumann
h2. SMS Plugin
587 47 Pau Escrich
588
This plug-in uses routing packets to transmit any information from one node to the
589
whole network. The good point is that propagation works even if there is no continuous data-
590
path. Even though the WiFi network is under bad conditions (because the Wireless noise,
591 48 Simó Albert i Beltran
distance between nodes, etc...), the data will be propagated. However in the current implemen-
592 47 Pau Escrich
tation, there exist a maximum size limit of 240 Bytes for each file.
593
594
The API of the sms plug-in is very simple. It simply clones the content of one or more files
595 48 Simó Albert i Beltran
given by one node to all other nodes. All other nodes can do the same. Once started, each
596
node will have two directories:/var/run/bmx6/sms/rcvdSms and /var/run/bmx6/sms/sendSms. Files
597 47 Pau Escrich
put into the sendSms folder will be cloned to all other nodes inside rcvdSms folder.
598
QMP is using this feature for several things. The positioning Map information is transmitted
599
using it. There is a chat in web interface which uses it too. And in the future we are planning
600 35 Axel Neumann
to use it for more purposes like statistics, captive portal, MAC filter rules, etc...
601
602 36 Axel Neumann
603 64 Axel Neumann
604
605
h2. Table plugin
606
607
This plug-in can be used to automatically announce routes from specific routing tables.
608
For example to dynamically announce routes from another routing protocol.
609
610
h3. Usage
611
612
To use the bmx6 table plugin it must be loaded during bmx6 daemon startup with the @ plugin=bmx6_table.so @ argument. 
613
Alternatively a plugin section can be defined in the bmx6 config file like this:
614
<pre>
615
config 'plugin'
616
        option 'plugin' 'bmx6_table.so'
617
</pre>
618
619
Once the plugin is successfully loaded, the new parameters for redistributing routes from specific tables are enabled.
620
621
A full documentation of the table-related parameters is available via the @ --help @ and @ --verboseHelp /r=1 @ option.
622
623
624
h3. Configuring route redistribution
625
626
Redistribution of routes is configurable with the @ --redistributeTable @ parameter.
627
Similar to the @ --tunOut @ parameter,  @ --redistributeTable @ must be given with an arbitrary name for referencing to a specific redistribution directive and further sub-criterias.
628
629
Mandatary sub-criterias are @ /table @ and at least one route of the available types ( @ /kernel, /boot, /static @ )
630
631
The following example automatically and dynamically announces (and removes announcements of) routes as they appear/disappear in routing table 100 and that match the criterias of:
632
* being a sub network of 192.168.0.0/16
633
* have a prefix length >= 24
634
* are configured as type kernel or boot (manually configured routes will appear by default as type boot)
635
636
If routes matching these criterias exist then:
637
* They are announced with a bandwidth of 1Mbit
638
* Subsequent routes are aggregated down to a minimum prefix length of 24
639
640
<pre>
641
 bmx6 -c \
642
 redistTable            otherProtocol        \
643
    /network            192.168.0.0/16       \
644
    /table              100                  \
645
    /aggregatePrefixLen 24                   \
646
    /minPrefixLen       24                   \
647
    /kernel             1                    \
648
    /boot               1                    \
649
    /bandwidth          1000000
650
</pre>
651
652
653
654
655
656
657
658 35 Axel Neumann
h2. Quagga Plugin
659
660
The bmx6 quagga plugin can be used to exchange routes with a quagga/zebra daemon.
661
Both, export and redistribution of routes is supported.
662 36 Axel Neumann
663 35 Axel Neumann
664 41 Axel Neumann
h3. Requirements, Compile, and Install
665 1 Pau Escrich
666 41 Axel Neumann
h4. Quagga
667
668
Quagga version 0.99.21 must be patched for bmx6 support.
669
670
The bmx6 directory lib/bmx6_quagga/patches/ contains patches to enable quagga for bmx6 support.
671
The following example provides instructions for obtaining, patching, compiling, and installing quagga:
672
673
<pre>
674
wget http://download.savannah.gnu.org/releases/quagga/quagga-0.99.21.tar.gz
675
tar xzvf quagga-0.99.21.tar.gz
676
cd quagga-0.99.21
677
patch -p1 < ../bmx6/lib/bmx6_quagga/patches/quagga-0.99.21.tar.diff
678
./configure
679
make
680
sudo make install
681 1 Pau Escrich
</pre>
682
683 41 Axel Neumann
For further instructions to obtain, patch, compile, and install quagga please have a look at:
684
the file lib/bmx6_quagga/patches/README in the bmx6 sources.
685 35 Axel Neumann
686
h4. Bmx6
687 36 Axel Neumann
688
To compile and install the bmx6 part of the quagga plugin simply do:
689 2 Pau Escrich
<pre>
690 1 Pau Escrich
make -C lib/bmx6_quagga/ 
691 36 Axel Neumann
sudo make -C lib/bmx6_quagga/ install
692 37 Axel Neumann
</pre>
693 38 Axel Neumann
694
695
h3. Usage
696
697
To use the bmx6 quagga plugin it must be loaded during bmx6 daemon startup with the @ plugin=bmx6_quagga.so @ argument. 
698
Alternatively a plugin section can be defined in the bmx6 config file like this:
699
<pre>
700
config 'plugin'
701
        option 'plugin' 'bmx6_quagga.so'
702
</pre>
703
704
Once the plugin is successfully loaded, the bmx6 daemon will try to connect with the zebra process (via the ZAPI socket) 
705
and new parameters for exchanging routes with quagga/zebra daemon are enabled.
706 1 Pau Escrich
707
A quick documentation of the quagga-related parameters is available via the --help and --verboseHelp option.
708 39 Axel Neumann
If the quagga-enabled daemon is already running @ bmc6 -c verboseHelp /r=1 @ will print all currently supported parameters.
709
710 41 Axel Neumann
711 39 Axel Neumann
712
713 38 Axel Neumann
h3. Redistributing routes (from quagga/zebra to bmx6)
714
715 1 Pau Escrich
Redistribution of routes is configurable with the --redistribute parameter.
716 64 Axel Neumann
Similar to the --tunOut parameter,  --redistribute must be given with an arbitrary name for referencing to a specific redistribution directive and further sub-criterias.
717 38 Axel Neumann
718
Further mandatory sub-parameters are /bandwidth and at least one (to-be redistributed route type).
719
The following route types exist:
720
<pre>
721
  /system <VAL>                          def: 0       range: [ 0 , 1 ]
722
  /kernel <VAL>                          def: 0       range: [ 0 , 1 ]
723
  /connect <VAL>                         def: 0       range: [ 0 , 1 ]
724
  /rip <VAL>                             def: 0       range: [ 0 , 1 ]
725
  /ripng <VAL>                           def: 0       range: [ 0 , 1 ]
726
  /ospf <VAL>                            def: 0       range: [ 0 , 1 ]
727
  /ospf6 <VAL>                           def: 0       range: [ 0 , 1 ]
728
  /isis <VAL>                            def: 0       range: [ 0 , 1 ]
729
  /bgp <VAL>                             def: 0       range: [ 0 , 1 ]
730
  /babel <VAL>                           def: 0       range: [ 0 , 1 ]
731
  /hsls <VAL>                            def: 0       range: [ 0 , 1 ]
732
  /olsr <VAL>                            def: 0       range: [ 0 , 1 ]
733
  /batman <VAL>                          def: 0       range: [ 0 , 1 ]
734 1 Pau Escrich
</pre>
735 38 Axel Neumann
736 1 Pau Escrich
Only quagga/zebra routes types that are explicitly specified will be redistributed to the bmx6 network.
737 38 Axel Neumann
In addition, one usually wants to filter out networks from being redistributed based on their prefix.
738 64 Axel Neumann
Therefore the sub parameters /network, /minPrefixLen, and /maxPrefixLen can be used in the same way as for the --tunOut parameter.
739 41 Axel Neumann
740 40 Axel Neumann
h4. Route Aggregation
741 1 Pau Escrich
742 40 Axel Neumann
By default, maximum aggregation of to-be redistributed routes is enabled.
743
This means that to-be redistributed neighboring and overlapping networks with the same route type and bandwidth are aggregated if possible.
744
The extend of aggregation can be controlled with the /aggregatePrefixLen sub-parameter.
745
The given value limits the aggregation to a minimum prefix length.
746
The default of 0 defines maximum aggregation whenever possible which may not be wanted.
747 45 Axel Neumann
748 40 Axel Neumann
For example the GW node may be configured to redistribute the following routes:
749 45 Axel Neumann
750
* 10.254.20.1/32
751
* 10.254.20.0/24
752
* 10.254.21.0/24
753 40 Axel Neumann
* 10.254.22.0/24
754
* 0.0.0.0/0
755
756
The following bmx6 configuration would aggregate all 5 routes into a single 0.0.0.0/0 tunnel announcement since 0.0.0.0/0 is overlapping any other more-specific route:
757
<pre>
758
redistribute=ipv4 /bandwidth=10000000 /kernel=1 /aggregatePrefixLen=0
759
</pre>
760
761
This aggregation may be too generic since GW-client nodes are usually looking for more specific routes to specific destination.
762
The following configuration would aggregate only routes with a prefix-len larger than 16:
763
764
<pre>
765
redistribute=ipv4 /bandwidth=10000000 /kernel=1 /aggregatePrefixLen=16
766
</pre>
767
768 45 Axel Neumann
Resulting in the following aggregations:
769
* 10.254.20.1/32: Aggregated (sub-network of 10.254.20.0/24)! NOT announced!
770
* 10.254.20.0/24: Aggregated with 10.254.21.0/24! Announced as 10.254.20.0/23 
771
* 10.254.21.0/24: Aggregated with 10.254.20.0/24! Announced as 10.254.20.0/23 
772 40 Axel Neumann
* 10.254.22.0/24: Not aggregatable into larger network! Announced as is!
773
* 0.0.0.0/0:      Not aggregated (prefix-len smaller than /aggregatePrefixLen=16)! Announced as is!
774 38 Axel Neumann
775
776 41 Axel Neumann
777 42 Axel Neumann
h3. Exporting routes (from bmx6 to quagga/zebra)
778
779
780
For exporting routes received as bmx6 tunnel announcements, the /exportDistance can be used as a subparameter of the --tunOut parameter.
781
The default value of /exportDistance is 256 which is considered as infinit or disabled.
782
Any lower configured value will export the corresponding outgoing tunnel (once it becomes active) with the given distance to quagga/zebra.
783
784
A GW node usually only wants to export bmx6 routes that were announced by other (non-GW) bmx6 nodes in the mesh.
785 43 Axel Neumann
786 1 Pau Escrich
In the following example there are 3 other bmx6 nodes, each tunnel announcing a private /32 network.
787 43 Axel Neumann
788
The given parametrization configures a GW node to search, establish related tunnels, and export all tunnel announcements for other bmx6 daemons that have a prefix-length smaller that /27 and fall into the network range of 10.254.0.0/16:
789 1 Pau Escrich
790 43 Axel Neumann
<pre>
791
plugin=bmx6_quagga.so tunOut=privV4Nets /network=10.254.0.0/16 /minPrefixLen=27 /exportDistance=0
792
</pre>
793
794
Checking the export from the quagga perspective show the following:
795
<pre>
796
root@mlc1001:~# telnet localhost zebra
797
Trying ::1...
798
Trying 127.0.0.1...
799
Connected to localhost.
800
Escape character is '^]'.
801
802
Hello, this is Quagga (version 0.99.21).
803
Copyright 1996-2005 Kunihiro Ishiguro, et al.
804
805
User Access Verification
806
Password:
807
808
Router> show ip route
809
Codes: K - kernel route, C - connected, S - static, R - RIP,
810
       O - OSPF, I - IS-IS, B - BGP, H - HSLS, o - OLSR,
811
       b - BATMAN, x - BMX6, A - Babel,
812
       > - selected route, * - FIB route
813
814
K>* 0.0.0.0/0 via 10.0.0.1, eth0
815
C>* 10.0.0.0/11 is directly connected, eth0
816
x>* 10.254.10.0/32 [0/1024] is directly connected, bmx6_out0000, 00:03:24
817
C * 10.254.10.1/32 is directly connected, bmx6_out0003
818
C * 10.254.10.1/32 is directly connected, bmx6_out0002
819
C * 10.254.10.1/32 is directly connected, bmx6_out0001
820
C * 10.254.10.1/32 is directly connected, bmx6_out0000
821
C>* 10.254.10.1/32 is directly connected, bmx6_in0000
822
x>* 10.254.10.2/32 [0/1024] is directly connected, bmx6_out0001, 00:03:24
823
x>* 10.254.10.3/32 [0/1024] is directly connected, bmx6_out0002, 00:03:24
824
x>* 10.254.10.4/32 [0/1024] is directly connected, bmx6_out0003, 00:03:24
825 42 Axel Neumann
C>* 127.0.0.0/8 is directly connected, lo
826 1 Pau Escrich
</pre>