Linux 3.9 routing oddity
Pierre Emeriaud
petrus.lt at gmail.com
Tue Jul 2 23:03:00 CEST 2013
Hello Jeroen,
2013/7/2 Jeroen Massar <jeroen at massar.ch>:
>> $ ip -6 route get 2001:db8:400c:c03::be
>> 2001:db8:400c:c03::be from :: via fe80::f6ca:e5ff:fe43:d114 dev eth0
>> src 2001:db8:ee8c:180:216:d3ff:feb6:d908 metric 0
>
> That is quite wrong indeed. A specific route should always be used, even
> if it cannot be used because the next-hop is not available.
Great. At least I was not wrong on this.
>Are you sure
> that the route entry for your 2000::/3 route is fully active and that
> forwarding etc is enabled on that interface?
Well, the route looks fine. I don't know how to check forwarding on
the interface, but it works fine.
Is there another way to look at linux' "fib", if one could call it
that way? I see the route in /proc/net/ipv6_routes even if it's not
used.
> You might want to check with 'ip -6 ro show table all' to reveal some
> more routing alternatives and check if you are not accidentally using
> multiple routing tables.
No pbr/source routing/multiple routing tables, and no usable routes
other than thoses shown before.
> You might also want to try this out with something that is not a tun/tap
> interface, thus a default ethernet interface, as tun/tap might have all
> kinds of odd behavior, eg no or hacked neighbor discovery depending on
> the tool being used by the tun device. (and in case you use openvpn,
> kick Gert ;)
That was my next step before reporting this on netdev. I just wanted
to be sure that this behavior was indeed incorrect.
> FTR: From my testing with 3.9.x and 3.10-rc7 I have not noticed that
> kind of behavior on boxes with normal ethernet interfaces.
Thanks for the feedback,
Pierre
More information about the ipv6-ops
mailing list