[Babel-users] able to ping to neighbor but no entry in routing table
Harshal Vora
harshal at amideeptech.com
Fri Mar 28 15:29:44 UTC 2014
We are trying to make some sense from the logs to understand the
behaviour of babeld.
Maybe we are missing some basic configurations.
Thanks,
Regards,
On 03/27/2014 02:05 AM, Dave Taht wrote:
> On Wed, Mar 26, 2014 at 9:43 AM, Harshal Vora <harshal at amideeptech.com> wrote:
>> Hi Gabriel,
>>
>> If I understood correctly, we should use addresses with netmask
>> 255.255.255.255
>> But with this netmask, each device will think that it is the only IP in the
>> adhoc network and it will not be able to ping or ssh into any other device
>> that we expect to take part in the adhoc network (even if they have the same
>> SSID). Basically there will be no adhoc network.
> Let me give an example of a complex, existing babel managed network,
> and comment ip route's output:
>
> Topology is
>
> internet gw: 172.26.3.1
> | | |
> |
> wifi AP gw my gw 172.26.4.1
> a couple other gws
> |
> Wifi clients on 172.26.2.0/24
>
> default via 172.26.4.1 dev eth0 proto 42 onlink
>
> I get a default route via babel. In openwrt I disable getting the
> default route via dhcp.
>
> 10.53.0.1 via 172.26.4.1 dev eth0 proto 42 onlink
> 10.53.0.2 via 172.26.4.1 dev eth0 proto 42 onlink
> 10.53.0.3 via 172.26.4.1 dev eth0 proto 42 onlink
> 10.53.0.4 via 172.26.4.1 dev eth0 proto 42 onlink
> 10.53.0.5 via 172.26.4.1 dev eth0 proto 42 onlink
> 10.53.0.6 via 172.26.4.1 dev eth0 proto 42 onlink
> 10.53.0.7 via 172.26.4.1 dev eth0 proto 42 onlink
>
> These are all virtuals on a box elsewhere.
>
> 67.180.229.17 via 172.26.4.1 dev eth0 proto 42 onlink
>
> This is the default destination box
>
> 169.254.0.0/16 dev eth0 scope link metric 1000
>
> This ended up there due to booting before my router was booted.
>
> 172.26.0.64/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.65 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.96/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.97 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.128/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.129 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.160/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.161 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.0.224 via 172.26.4.1 dev eth0 proto 42 onlink
>
> I honestly forget what box this is! It's in the house somewhere.
>
> 172.26.1.3 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.2.0/24 via 172.26.4.1 dev eth0 proto 42 onlink
>
> This is the wifi AP that most of the house uses.
>
> 172.26.3.0/27 via 172.26.4.1 dev eth0 proto 42 onlink
>
> Default ethernet address range of /27 for all interfaces in cerowrt
>
> 172.26.3.1 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.9 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.13 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.18 via 172.26.4.1 dev eth0 proto 42 onlink
>
> These are babel running routers hanging off the main network.
>
> 172.26.3.64/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.65 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.96/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.97 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.128/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.129 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.160/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.3.161 via 172.26.4.1 dev eth0 proto 42 onlink
>
> Cerowrt has 6 interfaces by default, each with their own /27 subrange.
> They distribute addresses via dhcp for non-babel using clients
> and the babel using clients have things like default route fetching
> turned off for dhcp, and I used to use AHCP a lot before hncp came about.
>
> 172.26.3.224 via 172.26.4.1 dev eth0 proto 42 onlink
>
> This is the meshy adhoc interface on the cerowrt boxes, controlled by ahcp,
> with a 255.255.255.255 netmask. AHCP serves up a /27 worth of addresses
> in this range to ahcp using routers...
>
> And it's the same address on both the 2.4ghz and 5ghz radios
> basically distinguished internally as 172.26.3.224%gw01 and
> 172.26.3.224%gw11
>
> 172.26.4.0/27 dev eth0 proto kernel scope link src 172.26.4.20
> 172.26.4.1 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.4.64/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.4.65 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.4.128/27 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.4.129 via 172.26.4.1 dev eth0 proto 42 onlink
> 172.26.4.224 via 172.26.4.1 dev eth0 proto 42 onlink
>
> The cerowrt router I'm on now.
>
> 192.122.209.0/24 via 172.26.4.1 dev eth0 proto 42 onlink
> 192.122.209.39 via 172.26.4.1 dev eth0 proto 42 onlink
> 192.122.209.89 via 172.26.4.1 dev eth0 proto 42 onlink
> 192.122.209.135 via 172.26.4.1 dev eth0 proto 42 onlink
>
> The internal IP address range of armory.com where this is all located.
>
> There are three routers cross connecting it to the private ip space,
> thus avoiding nat internally. Getting the public ip space to work
> right along with the private has been a pita...
>
> The view from the main router is different of course:
>
> root at comcast-gw:~# ip route
> default via 67.180.228.1 dev ge00 proto static
>
> supplied by dhcp, this is the only default route you should have
> in the system.
>
> 10.53.0.1 via 172.26.3.9 dev se00 proto babel onlink
> 10.53.0.2 via 172.26.3.9 dev se00 proto babel onlink
> 10.53.0.3 via 172.26.3.9 dev se00 proto babel onlink
> 10.53.0.4 via 172.26.3.9 dev se00 proto babel onlink
> 10.53.0.5 via 172.26.3.9 dev se00 proto babel onlink
> 10.53.0.6 via 172.26.3.9 dev se00 proto babel onlink
> 10.53.0.7 via 172.26.3.9 dev se00 proto babel onlink
>
> The virtuals on a given box.
>
> 67.180.228.0/22 dev ge00 proto kernel scope link src 67.180.229.17
>
> My upstream from comcast subnet.
>
> 172.26.0.64/27 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.65 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.96/27 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.97 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.128/27 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.129 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.160/27 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.161 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.0.224 via 172.26.3.13 dev se00 proto babel onlink
>
> I still have no idea where this router is...
>
> 172.26.1.3 via 172.26.3.12 dev se00 proto babel onlink
> 172.26.2.0/24 via 172.26.3.12 dev se00 proto babel onlink
>
> The AP
>
> 172.26.3.0/27 dev se00 proto kernel scope link src 172.26.3.1
> 172.26.3.9 via 172.26.3.9 dev se00 proto babel onlink
> 172.26.3.13 via 172.26.3.13 dev se00 proto babel onlink
> 172.26.3.18 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.3.64/27 dev sw00 proto kernel scope link src 172.26.3.65
> 172.26.3.96/27 dev sw10 proto kernel scope link src 172.26.3.97
> 172.26.3.128/27 dev gw00 proto kernel scope link src 172.26.3.129
> 172.26.3.160/27 dev gw10 proto kernel scope link src 172.26.3.161
>
> The main router's network and interfaces.
>
> 172.26.4.0/27 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.4.1 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.4.20 via 172.26.3.18 dev se00 proto babel onlink
>
> one box on this network runs babel, the rest just fit in the /27s
>
> One bug I've encountered with many kernels is not falling
> back to the /27 match if there is not a /32 match.
>
> Another bug I've encountered in many devices (e.g. printers)
> is that they don't respond to an icmp redirect when there are p2p devices
> on the same wire. They only want to talk to the default gw.
>
> 172.26.4.64/27 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.4.65 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.4.128/27 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.4.129 via 172.26.3.18 dev se00 proto babel onlink
> 172.26.4.224 via 172.26.3.18 dev se00 proto babel onlink
>
> My box.
>
> 192.122.209.0/24 via 172.26.3.13 dev se00 proto babel onlink
> 192.122.209.39 via 172.26.3.9 dev se00 proto babel onlink
> 192.122.209.89 via 172.26.3.13 dev se00 proto babel onlink
> 192.122.209.135 via 172.26.3.9 dev se00 proto babel onlink
>
> Ahah. it's coming back to me now, the public subnet is
> broken into two halves, one part always goes out the dsl
> line, the other the natted comcast line.
>
> You can find the babeld configuration files for cerowrt in openwrt format here:
>
> https://github.com/dtaht/cerofiles-3.10/blob/cerowrt-3.10/files/etc/config/babeld
>
> Please note that I've never been happy about exporting all the /27
> routes by default, I'd rather
> roll them up into a single /24 per device... and will gladly take
> improvements to these....
>
>> How does babeld work in this case?
>>
>> ------------------------------
>> We use the following commands to start babeld
>>
>> Command to start babeld on master:
>>
>> start-stop-daemon --start --pidfile /var/run/babeld.pid --exec
>> /usr/local/bin/babeld -- -C 'redistribute metric 128' -C 'redistribute proto
>> 3 allow' -d 3 -L /var/log/babeld.log -D -I /var/run/babeld.pid -r -g 33123
>> wlan0
>>
>> 'redistribute proto 3 allow' is used to distribute routes generated for the
>> ethernet interface.
>>
>> Command to start babeld on slaves
>>
>>
>> start-stop-daemon --start --pidfile /var/run/babeld.pid --exec
>> /usr/local/bin/babeld -- -d 3 -L /var/log/babeld.log -D -I
>> /var/run/babeld.pid -r -g 33123 wlan0
>> ---------------------------
>>
>> Does this mean that any device that now wants to be a part of this network
>> will have to compulsorily run babeld?
>> Also since we are redistributing routes only on the master, other slaves
>> will get only routes distributed by the master?
>>
>> For ex.
>> If we have master A and slave B and C such that B is in proximity of A and C
>> is in proximity of B but not A
>> A --- B --- C
>> | |
>> -------x------
>>
>>
>> Will C get routes from A ?
>>
>> Regards,
>>
>>
>>
>> On 03/22/2014 10:54 PM, Gabriel Kerneis wrote:
>>> On Sat, Mar 22, 2014 at 08:18:14PM +0530, Harshal Vora wrote:
>>>> We checked that we are able to ping from the master to the slave
>>>> (because of the proximity and because they are on the same adhoc
>>>> network)
>>>> 10.0.0.0/24 metric 128 (exported)
>>>> 192.168.1.0/24 metric 128 (exported)
>>> I have no idea where your problem comes from, but it is common in mesh
>>> networks to set your addresses with a /32 prefix (or /128 for IPv6). The
>>> reason is precisely to avoid those hard-to-debug behaviours where you do
>>> not know whether you can reach another host thanks to a correctly
>>> installed route, or thanks to the default route for your prefix and
>>> random proximity.
>>>
>>> Best,
>>
>>
>> _______________________________________________
>> Babel-users mailing list
>> Babel-users at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
>
More information about the Babel-users
mailing list