Hello Jeroen, 2013/7/2 Jeroen Massar <jer...@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