Hi,
I just verified again.
The ! route problem seems to occur during startup of a host.
The two hosts are literally kept next to each other.
10.0.0.1 is the gateway to the internet.
Below is the routing table for host 10.0.0.3
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.0.0.0 * 255.255.255.0 U 0 0 0 wlan1
10.0.0.0 - 255.255.255.0 ! -1 - 0 -
10.0.0.1 - 255.255.255.255 !H -1 - 0 -
192.168.0.0 - 255.255.255.0 ! -1 - 0 -
192.168.0.7 - 255.255.255.255 !H -1 - 0 -
For this particular test, 10.0.0.3 was up and running first and then
after a few minutes I started 10.0.0.1
Both are configured as ad-hoc networks
I restarted the babeld service multiple times on 10.0.0.1 but the
routing table of 10.0.0.3 won't fix.
After I restart babeld service on 10.0.0.3, routes are fine.
-----------
Also I verified that
-C 'redistribute proto 3 allow'
works as intended, but only after I restart the babeld service on
10.0.0.3 after which all the routes were set correctly.
Thanks,
Regards,
On Wednesday 08 January 2014 04:43 PM, Harshal Vora wrote:
Hi Matthieu, Thanks for the reply.
My reply inline.
On Wednesday 08 January 2014 04:11 PM, Matthieu Boutier wrote:
But on few occasions, it inserts negative routes with Flag set to !H and metric
set to -1 for hosts which are in direct range of each other.
I don't know what is "!", perhaps "unreachable". This seems (for the moment)
quite normal : you're moving, so the metric changes (it will increase at some point), and at some
point, you will be out of feasible routes. Babel then must consider that the node has failed, and
set the route as unreachable to avoid some routing loops. It is well explained in the 2.8 paragraph
of the RFC :
http://www.ietf.org/rfc/rfc6126.txt
! is "Reject Route" as mentioned here.
http://unixhelp.ed.ac.uk/CGI/man-cgi?route+8
I agree with you that if the route is unreachable then babel
must consider that the node has failed.
But this happened even when the hosts were kept stationary
near to each other.
The RFC mentions
*the time for which such a route
must be maintained should be the worst-case propagation time of the
retraction of the route to C.*
Is there any value for this then I can try waiting for so long the
next time
These negative routes remain persistent until i restart babeld and sometimes
until i reboot the host.
Shouldn't it be auto-corrected?
It should. How many time before reboot ?
I waited for approximately 2-3 minutes before reboot. In the
mean time I was restarting babeld
Also I enabled level 3 logs for babeld. I could see requests
coming in from the hosts for which there were unreachable routes.
Is there any way to fix this?
What version (or commit) are you using ? Which OS ?
This happened in two different hosts (Both arm processors,
babeld v. 1.3.1-1 from apt-get)
1) Hackberry
kernel: linux-sunxi-v3.4.24-r1
OS: Ubuntu 12.10 --
|http://cdimage.ubuntu.com/ubuntu-core/releases/12.10/release/ubuntu-core-12.10-core-armhf.tar.gz|
2) Raspberry pi Model B
Kernel: rasppi_linux_rpi-3.6.y
OS: raspbian
Also, is it possible to redistribute routes added with proto kernel or boot?
Yes. Proto boot is avoided by default, so you must add a configuration line, as
:
redistribute proto 3 allow
I will give it a try. Thanks.
From the file /etc/iproute2/rt_protos
2 kernel
3 boot
4 static
Thus I assume 3 will enable routes enabled by boot protocol
Best regards,
Matthieu
Regards,
_______________________________________________
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
