Linux 3.9 routing oddity

Jeroen Massar jeroen at
Tue Jul 2 22:09:00 CEST 2013

On 2013-07-02 21:27, Pierre Emeriaud wrote:
> $ ip -6 nei show
> fe80::f6ca:e5ff:fe43:d114 dev eth0 lladdr f4:ca:e5:43:d1:14 router REACHABLE

The neighbor tables are caches, thus indeed, until they are used they
won't appear there.

> $ 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. Are you sure
that the route entry for your 2000::/3 route is fully active and that
forwarding etc is enabled on that interface?

Your metrics seem to be '0' which is quite odd.

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.

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 ;)

Sounds rather something to raise on the netdev list

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.


More information about the ipv6-ops mailing list