[Babel-users] able to ping to neighbor but no entry in routing table

Wed Mar 26 20:35:59 UTC 2014

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

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html