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 (http://www.spinics.net/lists/netdev/) 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. Greets, Jeroen