networkd: IPv6 rapid rotation of temporary addresses #20050
Comments
|
Looks like it's starting from an empty state with every cycle: |
|
Sounds like we need another #19980, but this time for IPv6. |
|
Please note that this is a regression in 249(rc2), this behaviour was not present in 248. |
|
Yeah, but there were 250 non-merge commits touching src/network in the period. If you could bisect this, that'd probably help. FWIW, I don't see this here. |
|
This seems to be the last unadressed issue for v249. I think we should leave it for later, unless @yuwata has some good idea how to fix this. |
|
|
+ SLAAC/privacy addressing based on prefix advertisements (ULA + global, with long lifetimes) from an OpenWRT router, no DHCPv6. |
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jun 30, 2021
Previously, NDisc configurations with `marked` flag are considered as old, and removed when all netlink messages are processed and at least one address becomes ready. However, when request queue was introduced, the logic was not updated. As all requests are once queued and processed later when each request is ready, the `marked` flag of each configuration is not removed within the same event. Thus, all previous configurations are removed before no address or route request is processed. This causes the issue systemd#20050. This introduces another request type to clear old NDisc configureations to make the cleanup is certainly processed after all address and route requests are processed. Fixes systemd#20050.
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jul 2, 2021
Previously, NDisc configurations with `marked` flag are considered as old, and removed when all netlink messages are processed and at least one address becomes ready. However, when request queue was introduced, the logic was not updated. As all requests are once queued and processed later when each request is ready, the `marked` flag of each configuration is not removed within the same event. Thus, all previous configurations are removed before no address or route request is processed. This causes the issue systemd#20050. This introduces another request type to clear old NDisc configureations to make the cleanup is certainly processed after all address and route requests are processed. Fixes systemd#20050.
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jul 2, 2021
Previously, `ndisc_remove_old_one()` checked `ndisc_{addresses,routes}_configured`
flags, but they are not unset when all addresses or routes are already
assigned.
After the request queue is implemented, the address or route requests
are not processed within the same event of ndisc handler is called, but
will processed later when they are ready. So, calling `ndisc_remove_old()`
in the event of ndisc handler will remove all addresses and routes
previously assigned even they are requested to be updated.
This makes `ndisc_remove_old()` do nothing when there exist some
requests to configure addresses and routes, thus previously assigned
addresses and routes are kept until all requests are processed.
Fixes systemd#20050.
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jul 2, 2021
…ured Fixes the issue similar to systemd#20050 but for DHCP6.
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jul 2, 2021
Previously, `ndisc_remove_old_one()` checked `ndisc_{addresses,routes}_configured`
flags, but they are not unset when all addresses or routes are already
assigned.
After the request queue is implemented, the address or route requests
are not processed within the same event of ndisc handler is called, but
will processed later when they are ready. So, calling `ndisc_remove_old()`
in the event of ndisc handler will remove all addresses and routes
previously assigned even they are requested to be updated.
This makes `ndisc_remove_old()` do nothing when there exist some
requests to configure addresses and routes, thus previously assigned
addresses and routes are kept until all requests are processed.
Fixes systemd#20050.
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jul 2, 2021
…ured Fixes the issue similar to systemd#20050 but for DHCP6.
|
Yes, #20108 works for me, thanks! Another difference between 248 and 249 (with or without your patch) is that the SLAAC addresses in the ULA prefix continously appear and disappear (both fixed mac-based in temporary privacy addresses), which is strange. This does not happen for the globally routable prefix though, does networkd distinguish between those? |
|
In fact, this causes the same issue for outgoing connections within ULA prefix (thus within my LAN). |
yuwata
added a commit
to yuwata/systemd
that referenced
this issue
Jul 2, 2021
Fixes another issue reported in systemd#20050. See systemd#20050 (comment).
|
Thank you for testing the PR so quickly! I added one more commit in the PR. I hope it fixes the ULA address issue. Please test gain. |
|
Yes, the ULA case is fixed as well now. Thanks! |
|
Thank you! Your help is much appreciated. |
|
Same here and PR#20108 fixed the issue (Archlinux, systemd-249rc3). |
jamacku
pushed a commit
to redhat-plumbers/systemd-rhel9
that referenced
this issue
Jul 20, 2021
Fixes another issue reported in #20050. See systemd/systemd#20050 (comment).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
Used distribution
Linux kernel version used (
uname -a)CPU architecture issue was seen on
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Additional program output to the terminal or log subsystem illustrating the issue
Below is a diff of
networkctl status 3with just a few minutes in a between.A new temporary privacy address has been added and the old one immediatly removed, breaking all existing connections with that old address. This happens every few minutes, despite the much longer valid_lifetime indicated by
ip addr list.Normally, old addresses are first put in "deprecated" state, so they are no longer used for new connections, and removed later. Plus rotation should be much less frequent, respecting valid_lifetime of the addresses (hours for global addresses, days for ULA).
I noticed this behaviour with systemd 249rc2, coming from 248 where it was stable.
ip -6 addr list
The text was updated successfully, but these errors were encountered: