Modify

Opened 10 years ago

Closed 7 years ago

Last modified 6 years ago

#3706 closed defect (worksforme)

IPv6 default "unreachable" route

Reported by: romain.riviere@… Owned by: florian
Priority: normal Milestone:
Component: base system Version:
Keywords: Cc:

Description

There seems to be a very persistent IPv6 route in OpenWRT :

unreachable default dev lo  proto none  metric -1  error -128

For reasons unknown to me, this route does not get replaced by a legitimate route when one is added. For example, this is my current routing table from a WRT54GL running 7.09 and having received a RA from its neighbour router :

default dev eth0.0  proto kernel  metric 256  mtu 1500 advmss 1440
default via fe80::200:ff:fe00:0 dev br-lan  proto kernel  metric 1024  expires 1671sec mtu 1500 advmss 1440
unreachable default dev lo  proto none  metric -1  error -128

Similar hebaviour can be observed on another WRT54GL running 7.09 on which I have an ip-up.d script that reads

#!/bin/sh
route -A inet6 add default dev $1

After a normal boot, I get BOTH the default route via ppp0 AND the dreaded unreachable route via lo.

Something goes wrong somewhere but I can't put my finger on it.

Attachments (0)

Change History (23)

comment:1 Changed 10 years ago by romain.riviere@…

I've managed to narrow it down a bit. I disabled (commented) the wan interface in /etc/config/network and booted OpenWRT. THEN, I uncommented the wan inferface and manually issued a

 ifup wan

Voila, one default route for IPv6.

I've also tried using the ipv6-up and -down files from the latest trunk revision but as I suspected, they offer no improvement.

So there seems to be some kind of race condition during boot that causes both default routes to coexist, until wan is restarted and one, rightful route remains.

comment:2 Changed 9 years ago by francois@…

It might be related to the kernel version, I experienced the same problem with 2.4.34. Anyone can test with 2.6 ?

A workaround is to add a route to 2000::/3 instead of 0::/0.

http://www.sixxs.net/forum/?msg=setup-658563
http://marc.info/?l=linux-net&m=104067759607753&w=2

comment:3 Changed 9 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to assigned

comment:4 Changed 8 years ago by florian

  • Resolution set to fixed
  • Status changed from accepted to closed

This probably got fixed now.

comment:5 Changed 8 years ago by Laurent Bigonville <l.bigonville@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

I've recompiled svn trunk (rev 20980) with brcm2.4 and I also get that "unreachable default" route.

I'm using aiccu and radvd

comment:6 Changed 8 years ago by alex@…

In short, this is not a bug and should be closed.

Why do you care about the 'unreachable', it's at a lower precedence than your uplink default route so does not have any effect. That 'unreachable' message is meant to be there otherwise the routing table inside Linux behaves, look in net/ipv6/route.c:ip6_route_net_init().

When your WAN link is down and you try to contact something not on your subnet you get an 'unreachable' ICMPv6 message because of this route. As well as this route (hardcoded by the kernel), it is actually a good idea to follow rfc5735/rfc5156 also to block other special-use subnets too (along with 'rp_filter=1' for IPv4 traffic).

busybox# ip -6 route
unreachable ::/96 dev lo  metric 1024  error -128
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -128
unreachable 2001:2::/48 dev lo  metric 1024  error -128
unreachable 2001:10::/28 dev lo  metric 1024  error -128
unreachable 2001:db8::/32 dev lo  metric 1024  error -128
unreachable MINE dev lo  metric 256  error -128
ALSO:MINE::/64 dev eth0  metric 256 
unreachable 2a01:348:45::/48 dev lo  metric 1024  error -128
MINE:TOO::/64 dev ppp0  metric 256  expires 2500722sec
unreachable fc00::/7 dev lo  metric 1024  error -128
unreachable fe80::/64 dev lo  metric 256  error -128
fe80::/64 dev eth0  metric 256 
fe80::/64 dev ppp0  metric 256 
fe80::/10 dev ppp0  metric 1 
fe80::/10 dev ppp0  metric 256 
unreachable ff00::/8 dev lo  metric 256  error -128
ff00::/8 dev eth0  metric 256 
ff00::/8 dev ppp0  metric 256 
default dev ppp0  metric 1024 
unreachable default dev lo  metric -1  error -128

So you might be asking yourself why you see this, well busybox's 'ip route' command does not behave exactly the same way as iproute2's version; however if you type 'route -6n' on any other IPv6 enabled box you will see the unreachable route (example from a Debian 'lenny' sparc64 box):

debian:# route -6n | tail -n1
::/0                           ::                         !n   -1  111160983 lo

As for the 2000::/3 suggestion, that came from the obsolete days of 6bone and related administrator advice, so do *not* do it, everyone is now expected to use ::/0. However, in doing so you must remember than with default routes (applies for IPv4 too) you need to null route your own address space as follows, so not to not cause routing loops:

ip route add unreachable <your-public-allocation>

This will have the lowest presedence, even if you have a matching sized routing rule.

comment:7 Changed 8 years ago by Laurent Bigonville <bigon@…>

Thanks for the explanations.

But the problem for me (maybe should I open a new bug) is that my tunnel is not working from my subnet when booting my wrt device (no route to host). But it's working from the device it self.

I need to reboot aiccu. The only thing that change is that "unreachable" route which disappears..

comment:8 Changed 8 years ago by alex@…

Romain's issue is that they have two default routes (looks like they might have an RA daemon running on a host lurking off br-lan; probably a Windows box with ICS enabled)...you might have the same issue?

Can you show the output of 'ip -6 route' and 'ip addr'.

Cheers

comment:9 Changed 8 years ago by romain.riviere@…

Just to clarify: there is no RA daemon running other than the WRT itself, and there is definitely no Windows box, let alone running ICS, on the LAN either. Besides, this unreachable route did not appear to have a lower precedence than the proper, default route (as opposed to what alex said initially), as it totally prevented me from reaching the v6 world.

However that ticket was opened on 7.09 and I have yet to upgrade to 10.03 to check how it behaves exactly.

comment:10 Changed 8 years ago by alex@…

*Something* installed the following route:

default via fe80::200:ff:fe00:0 dev br-lan  proto kernel  metric 1024  expires 1671sec mtu 1500 advmss 1440

The 'kernel proto' and 'expires' bit means it comes from an advertised route. It's possible that it is radvd on the box it's-self has installed the route, although unlikely as the link-local address looks a bit weird.

comment:11 Changed 8 years ago by romain.riviere@…

It is also my suspicion, and the weird LL address is indeed something I had noticed before and that still happens on stock 10.03. Meaning that two devices can and will actually have that exact LL address for br-lan and be happy to use it.

As discussed last night on IRC, I believe that the eth0.0 and wl0 should be stripped from their LL addresses (just like they don't normally have IPv4 addresses anyway) so that the bridge can use the MAC to get a proper, unique LL address and work from that. I think that a lot of weirdness may come from the fact that, with the default software and IPv6 enabled, all interfaces get a LL address, even when they're part of the bridge.

comment:12 Changed 8 years ago by alex@…

You can have identical LL addresses, all the VLAN's at $ORK I have configured have ff80:: as the LL gateway; although TBH I am not too sure what should happen in the case of a bridge, like yourself I would expect eth0.0/wlan0 to not have any L3 presence (only the bridge interface should) as they should be L2 only devices.

Can you slap here the spiel from 'ip addr', 'ip link' and 'ip -6 route'?

comment:13 Changed 8 years ago by romain.riviere@…

AFAIK, you canNOT have identical LL addresses for two devices on the same link. But this is exactly what happens if you put two IPv6-enabled OpenWRT devices on the same link, and this should cause Duplicate Address Detection some trouble, but somehow it doesn't. But we agree that the bridge sub-interfaces should not have L3 presence indeed.

Do you want the whole output? There's quite a bit. Maybe as an attachment?

comment:14 Changed 8 years ago by alex@…

you can't, I was talking about the same LL address on different interfaces on the same device.

As for the output, how big is your routing table ;) I personally would put it inline...

comment:15 Changed 8 years ago by romain.riviere@…

Well you can't, but OpenWRT can, and does. I have proof right before my eyes, and before yours now:

root@mara:~# ifconfig br-lan
br-lan    Link encap:Ethernet  HWaddr 00:1D:7E:4B:75:62  
          inet addr:192.168.41.253  Bcast:192.168.41.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link

root@wrt-dev:~# ifconfig br-lan
br-lan    Link encap:Ethernet  HWaddr 00:18:F8:CC:CC:20  
          inet addr:192.168.41.251  Bcast:192.168.41.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link

Here comes the big part:

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host 
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21d:7eff:fe4b:7562/64 scope link 
3: eth0.0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue 
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21d:7eff:fe4b:7562/64 scope link 
4: eth0.1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.253/24 brd 192.168.1.255 scope global eth0.1
    inet6 fe80::21d:7eff:fe4b:7562/64 scope link 
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
6: br-lan: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.41.253/24 brd 192.168.41.255 scope global br-lan
    inet6 fe80::200:ff:fe00:0/64 scope link 
    inet6 2001:7a8:b285::1/64 scope global 
7: wl0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:7e:4b:75:64 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21d:7eff:fe4b:7564/64 scope link 
9: gre0@NONE: <NOARP> mtu 1476 qdisc noop 
    link/gre 0.0.0.0 brd 0.0.0.0
721: wds0.1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:7e:4b:75:64 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21d:7eff:fe4b:7564/64 scope link 
730: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 3
    link/ppp 
    inet 213.41.242.133 peer 62.4.16.250/32 scope global ppp0
    inet6 fe80::f106:59e2:5f2d:e59b/10 scope link 

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
3: eth0.0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue 
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
4: eth0.1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
6: br-lan: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 00:1d:7e:4b:75:62 brd ff:ff:ff:ff:ff:ff
7: wl0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:7e:4b:75:64 brd ff:ff:ff:ff:ff:ff
9: gre0@NONE: <NOARP> mtu 1476 qdisc noop 
    link/gre 0.0.0.0 brd 0.0.0.0
721: wds0.1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:1d:7e:4b:75:64 brd ff:ff:ff:ff:ff:ff
730: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 3
    link/ppp 

2001:7a8:b285::/64 dev br-lan  metric 256  mtu 1500 advmss 1440
fe80::/64 dev eth0  metric 256  mtu 1500 advmss 1440
fe80::/64 dev eth0.1  metric 256  mtu 1500 advmss 1440
fe80::/64 dev br-lan  metric 256  mtu 1500 advmss 1440
fe80::/64 dev eth0.0  metric 256  mtu 1500 advmss 1440
fe80::/64 dev wl0  metric 256  mtu 1500 advmss 1440
fe80::/64 dev wds0.1  metric 256  mtu 1500 advmss 1440
fe80::/64 dev ppp0  metric 256  mtu 1500 advmss 1440
fe80::/10 dev ppp0  metric 1  mtu 1500 advmss 1440
fe80::/10 dev ppp0  metric 256  mtu 1500 advmss 1440
ff00::/8 dev eth0  metric 256  mtu 1500 advmss 1440
ff00::/8 dev eth0.1  metric 256  mtu 1500 advmss 1440
ff00::/8 dev br-lan  metric 256  mtu 1500 advmss 1440
ff00::/8 dev eth0.0  metric 256  mtu 1500 advmss 1440
ff00::/8 dev wl0  metric 256  mtu 1500 advmss 1440
ff00::/8 dev wds0.1  metric 256  mtu 1500 advmss 1440
ff00::/8 dev ppp0  metric 256  mtu 1500 advmss 1440
default via fe80::f106:59e2:5f2d:e59b dev ppp0  metric 1  mtu 1500 advmss 1440

Obviously this is after I manually remove the unreachable route (this is my "production" router so I want it to work ...).

comment:16 Changed 8 years ago by alex@…

Just *before* you create your bridge run the following (as 'pre-up or something'):

echo 1 > /proc/sys/net/ipv6/conf/eth0.0/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/wl0/disable_ipv6

Hopefully when these interfaces can merged to create br-lan, IPv6 should be enabled on that. This will not fix your problem, but it will do what I think is the Right Thing[tm] to do (although I cannot see much in the way of grumblings on the Internet).

Also, for your default route, can you drop the 'metric 1' when you create it, let it default to 1024. I think doing this might fix things, I think for some reason 'metric 1' is being processed *after* the unreachable 'metric -1' that is there by default.

comment:17 Changed 8 years ago by alex@…

...although 'metric -1' could be signed int 2x-1. :-/

comment:18 Changed 8 years ago by romain.riviere@…

No can do. My units are running 2.4-brcm, so that sysctl is simply not available (although I admit it would be a handy solution) without a patch to the 2.4 kernel.

I don't set the default route myself, pppd does that on its own (defaultroute in my /etc/ppp/options.pptp).

comment:19 Changed 8 years ago by alex@…

pppd does not set IPv6 default routes, that's up to RA's on the line[1][2]...which then get ignored as 'forwarding' gets enabled... :-/

My /etc/ppp/ipv6-up file is simple:

#!/bin/sh

grep -q defaultroute /etc/ppp/options
if [ $? -eq 0 ]; then
        ip -6 route add default via $LLREMOTE dev $IFNAME
fi

I see openwrt have added a whole bunch of 'fun' to theirs (probably as they use the evil 'route' command still). Can you comment out everything and try my one liner, you should see something like:

$ ip -6 route
::/96 via :: dev tun6to4  metric 256 
unreachable ::/96 dev lo  metric 1024  error -128
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -128
unreachable 2001:2::/48 dev lo  metric 1024  error -128
unreachable 2001:10::/28 dev lo  metric 1024  error -128
unreachable 2001:db8::/32 dev lo  metric 1024  error -128
2002::/16 dev tun6to4  metric 1024 
unreachable <ahem>:0:311e:7a15:88ab:1f59 dev lo  metric 256  error -128
<ahem>:1000::/64 dev eth0  metric 256 
unreachable <ahem>::/48 dev lo  metric 1024  error -128
unreachable fc00::/7 dev lo  metric 1024  error -128
unreachable fe80::/64 dev lo  metric 256  error -128
fe80::/64 dev eth0  metric 256 
fe80::/64 dev ppp0  metric 256 
fe80::/10 dev ppp0  metric 1 
fe80::/10 dev ppp0  metric 256 
unreachable ff00::/8 dev lo  metric 256  error -128
ff00::/8 dev eth0  metric 256 
ff00::/8 dev ppp0  metric 256 
default via fe80::21b:53ff:feda:6e60 dev ppp0  metric 1024 
unreachable default dev lo  metric -1  error -128

Cheers

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477245

[2] /ticket/2372.html

comment:20 Changed 8 years ago by Romain Riviere <romain.riviere@…>

My ipv6-up script is very similar in effect, it's actually the default script provided by kamikaze. I don't see any of the "fun" you're referring to, so I am not sure exactly what you would like me to remove from it ...
Hopefully I can try 10.03 soon enough and try to reproduce this bug. Maybe it's been fixed already.

comment:21 Changed 7 years ago by jeremy@…

After all these years, I am still suffering from the bug on almost every reboot of my OpenWrt.

Despite the "unreachable default" route having a lower metric (-1) than my actual default route (1024), this bug by its very definition is that the router is simply ignoring the metric and/or the proper default route.

The only workaround for me is to delete and re-add the routes:

# ip route del default
# ip route add default dev pppoe-wan

I have not found a way to delete just the "unreachable default" line by itself. If I type ip route del unreachable default, the proper default route gets deleted instead, and then the unreachable default gets deleted automatically as soon as the proper one is manually re-added.

comment:22 Changed 7 years ago by jow

  • Resolution set to worksforme
  • Status changed from reopened to closed

And I see the same on my Ubuntu:

jow@wws-7 $ ip -6 r
[...]
default via fe80::b468:4bff:fe40:def4 dev tap0  proto kernel  metric 1024  expires 79sec mtu 1500 advmss 1440 hoplimit 64
jow@wws-7 $ route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
[...]
::/0                           fe80::b468:4bff:fe40:def4  UGDAe 1024 1    11 tap0
::/0                           ::                         !n   -1  1 14156 lo
[...]
::/0                           ::                         !n   -1  1 14156 lo

... and Debian machines:

jow@ff0:~$ ip -6 r
[...]
default via 2a01:198:200:19c::1 dev sixxs  metric 1024  mtu 1280 advmss 1220 hoplimit 4294967295
jow@ff0:~$ route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
[...]
::/0                           2a01:198:200:19c::1        UG   1024 1594239 sixxs
::/0                           ::                         !n   -1  11829854 lo
[...]
::/0                           ::                         !n   -1  11829854 lo

I think the conclusion reached here ("stale route prevents proper default rules from being added") is wrong and the actual cause for the supposedly realted issues are sysctl settings (accept_ra / send_rs in relation to v6 forwarding / non forwarding mode).

comment:23 Changed 6 years ago by jeremy@…

@jow, please explain your justification for closing the ticket when what is being described here is clearly a problem, and still unfixed.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.