Linux 3.9 routing oddity

Pierre Emeriaud at
Tue Jul 2 23:03:00 CEST 2013

Hello Jeroen,

2013/7/2 Jeroen Massar <jeroen at>:
>> $ 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

> 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,


More information about the ipv6-ops mailing list