[Babel-users] two gateways using babeld on an adhoc network?
Harshal Vora
harshal at amideeptech.com
Fri Mar 28 15:25:18 UTC 2014
Hi,
All the systems are raspberry pi's running on kernel 3.6.11. We are
using babeld version 1.4.3
We have two edge systems
1) Wireless Adhoc: 10.0.0.1, Ethernet: 192.168.98.20
2) Wireless Adhoc: 10.0.0.11, Ethernet: 192.168.98.21
and five other wireless adhoc systems (10.0.0.2, 10.0.0.4,
10.0.0.6, 10.0.0.9, 10.0.0.11) in our network without any ethernet
connection.
Adhoc network IP's are statically assigned.
-------------------------------------------------
To start babeld
On edge-systems
/usr/local/bin/babeld -C redistribute metric 128 -C redistribute proto 3
metric 64 -d 3 -L /var/log/babeld.log -D -I /var/run/babeld.pid -r -g
33123 wlan1 eth0
On non-edge systems
/usr/local/bin/babeld -d 3 -L /var/log/babeld.log -D -I
/var/run/babeld.pid -r -g 33123 wlan0
We do not use any configuration file for babeld.
-------------------------------------------------
We have iptables rules for masquarading the traffic on the edge systems:
linaro at hackberry:~$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 14945 packets, 1818K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
7341 488K ACCEPT all -- wlan1 eth0 10.0.0.0/24
0.0.0.0/0 state NEW
8122 861K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 17224 packets, 8039K bytes)
pkts bytes target prot opt in out source destination
-------------------------------------------------
Below are the "ip route show" logs for two(10.0.0.1 and 10.0.0.11) are
edge ones , and one non-edge (10.0.0.2).
Other non-edge systems have similar logs.
Few things that we noticed:
1) DHCP does not add default route on ethernet interface of
10.0.0.11(edge node). Instead default route for 10.0.0.11 goes through
10.0.0.1.
2) Once 10.0.0.1 is down, there is no default route for the entire
babeld network until 10.0.0.1 comes up again.
3) After a few minutes all the routes disappear on 10.0.0.11 as well as
all the non-edge systems.
4) If we keep machine 10.0.0.1 down, and restart all other non-edge
systems then sometimes they get routes for each other, sometimes they dont.
5) If we restart 10.0.0.11(edge system) then it gets default route via
dhcp when 10.0.0.1 is down and then entire network has a default route.
-------------------------------------------------
LOGS:
#everthing is stable
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:34:01 UTC 2014
ip : 10.0.0.1 {edge}
default via 192.168.98.1 dev eth0
10.0.0.2 via 10.0.0.2 dev wlan1 proto 42 onlink
10.0.0.4 via 10.0.0.4 dev wlan1 proto 42 onlink
10.0.0.6 via 10.0.0.6 dev wlan1 proto 42 onlink
10.0.0.9 via 10.0.0.9 dev wlan1 proto 42 onlink
10.0.0.11 via 192.168.98.21 dev eth0 proto 42 onlink
10.0.0.12 via 10.0.0.12 dev wlan1 proto 42 onlink
192.168.98.0/24 dev eth0 proto kernel scope link src 192.168.98.20
192.168.98.21 via 192.168.98.21 dev eth0 proto 42 onlink
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:34:01 UTC 2014
ip : 10.0.0.11 {edge}
default via 10.0.0.1 dev wlan0 proto 42 onlink
10.0.0.1 via 192.168.98.20 dev eth0 proto 42 onlink
10.0.0.2 via 10.0.0.2 dev wlan1 proto 42 onlink
10.0.0.4 via 10.0.0.4 dev wlan1 proto 42 onlink
10.0.0.6 via 10.0.0.6 dev wlan1 proto 42 onlink
10.0.0.9 via 10.0.0.9 dev wlan1 proto 42 onlink
10.0.0.12 via 10.0.0.12 dev wlan1 proto 42 onlink
192.168.98.0/24 dev eth0 proto kernel scope link src 192.168.98.21
192.168.98.20 via 192.168.98.20 dev eth0 proto 42 onlink
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:34:01 UTC 2014
ip : 10.0.0.2 {non-edge}
default via 10.0.0.1 dev wlan0 proto 42 onlink
10.0.0.1 via 10.0.0.1 dev wlan0 proto 42 onlink
10.0.0.4 via 10.0.0.4 dev wlan0 proto 42 onlink
10.0.0.6 via 10.0.0.6 dev wlan1 proto 42 onlink
10.0.0.9 via 10.0.0.9 dev wlan1 proto 42 onlink
10.0.0.11 via 10.0.0.11 dev wlan0 proto 42 onlink
10.0.0.12 via 10.0.0.12 dev wlan1 proto 42 onlink
192.168.98.0/24 via 10.0.0.1 dev wlan0 proto 42 onlink
192.168.98.20 via 10.0.0.1 dev wlan0 proto 42 onlink
192.168.98.21 via 10.0.0.11 dev wlan0 proto 42 onlink
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
# now we shutdown machine 10.0.0.1 (which has boot level route installed
by dhcp)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:36:01 UTC 2014
ip : 10.0.0.11 {edge}
unreachable 10.0.0.2 proto 42 metric 4294967295 onlink
unreachable 10.0.0.4 proto 42 metric 4294967295 onlink
unreachable 10.0.0.6 proto 42 metric 4294967295 onlink
unreachable 10.0.0.9 proto 42 metric 4294967295 onlink
unreachable 10.0.0.12 proto 42 metric 4294967295 onlink
192.168.98.0/24 dev eth0 proto kernel scope link src 192.168.98.21
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:36:01 UTC 2014
ip : 10.0.0.2 {non-edge}
unreachable 10.0.0.4 proto 42 metric 4294967295 onlink
unreachable 10.0.0.6 proto 42 metric 4294967295 onlink
unreachable 10.0.0.9 proto 42 metric 4294967295 onlink
unreachable 10.0.0.11 proto 42 metric 4294967295 onlink
unreachable 10.0.0.12 proto 42 metric 4294967295 onlink
unreachable 192.168.98.0/24 proto 42 metric 4294967295 onlink
unreachable 192.168.98.21 proto 42 metric 4294967295 onlink
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#Final state. After this the routing table does not change until we
restart these machines.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:39:01 UTC 2014
ip : 10.0.0.11 {edge}
192.168.98.0/24 dev eth0 proto kernel scope link src 192.168.98.21
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
date is: Fri Mar 28 10:39:02 UTC 2014
ip : 10.0.0.2 {non-edge}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
On 03/27/2014 01:45 AM, Juliusz Chroboczek wrote:
>> Assume that for now we have two devices connected to ethernet, m1 and
>> m2 and s1..s6 are slaves.
> This terminology is not helpful. It's a mesh network, everything is
> peer-to-peer, none of this kinky master-slave stuff.
>
>> When we pull the ethernet plug for m1, we see that all the routes that
>> were present in s1..s3 do not correct themselves to use m2 as
>> gateway. Neither does m1 correct itself to use m2 as the gateway. [...]
>> Also, when we disable the wifi interface on m1, slaves s1..s3 get all
>> negative routes [...]
>> Is this the expected behaviour?
> No, something is wrong with your redistribution. How are the default
> routes installed, and how are they redistributed?
>
> Please show us the output of ``ip route show'' on the edge routers
> (your "masters") as well as the contents of /etc/babeld.conf.
>
> -- Juliusz
>
>
More information about the Babel-users
mailing list