After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 721392 - Active IPv6 routes get stuck when default (RA) router changes
Active IPv6 routes get stuck when default (RA) router changes
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
0.9.x
Other Linux
: Normal major
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-01-03 13:21 UTC by Anders Blomdell
Modified: 2020-11-12 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Anders Blomdell 2014-01-03 13:21:39 UTC
With 2 routers prepared (1 active and 1 spare), i.e. only one is sending out RA's.

On a Fedora-20 client with NetworkManager-0.9.9.0-22.git20131003.fc20.x86_64,  

1. Start router1 (fe80::13:10ff:fe07:1158)
2. client now has the following relevant routing entry:
     default via fe80::13:10ff:fe07:1158 dev eth0  proto static  metric 1024 
3. Start a 'ping6 www.google.com' (arn06s01-in-x13.1e100.net,
   2a00:1450:400f:800::1013)
4. Routing entries is still the same as #2
5. Kill router1
6. Client routing entries now become:
     2a00:1450:400f:800::1013 via fe80::13:10ff:fe07:1158 dev eth0  metric 0 
       cache 
     default via fe80::13:10ff:fe07:1158 dev eth0  proto static  metric 1024 
7. Start router2 (fe80::13:12ff:fe10:1311)
8. Routing entries now are
     2a00:1450:400f:800::1013 via fe80::13:10ff:fe07:1158 dev eth0  proto static  metric 1 
     default via fe80::13:12ff:fe10:1311 dev eth0  proto static  metric 1024 
9. And from now on the route to 2a00:1450:400f:800::1013 seems to be stuck
   to fe80::13:10ff:fe07:1158
Comment 1 Pavel Simerda 2014-01-03 18:53:16 UTC
a) Note the 'cache' keyword at the end of the route. It means it's a kernel routing cache record (I'm curious whether that cache helps anything at all).

b) I'm curious why you don't see the cache entries after step #3. Killing the router may result in sending a router advertisement (you can check with tcpdump -vv or radvdump). But that one should only result in *normal* route *removal*, not *cache* route *addition*.

c) The cached route (with metric 0) is transformed to a static route with metric 1. That looks like something (NetworkManager) read the cached route from the kernel which shouldn't happen and then wrote it back to the kernel (with metric 1, which suggest another bug in the code, as NM normally translates zero metric to 1024 unless the code changed since I wrote it).

My best guess is that we need to fix NM to filter out cached routes upon read (ignore them entirely).

Thanks for the report. Adding Thomas to Cc and will follow further development of the bug.
Comment 2 André Klapper 2020-11-12 14:33:52 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).