network: fold ipv4ll fallback modes into normal ipv4ll addressing by yuwata · Pull Request #17692 · systemd/systemd

yuwata · 2020-11-23T04:58:22Z

Replaces #17290.
Fixes #13316.

yuwata · 2020-11-23T22:02:48Z

Yey, now all CentOS CIs are green.

keszybz

Thanks for picking this up.

src/network/networkd-dhcp4.c

The code was changed in 715cedf to allow more than six attempts and the old description stopped making sense.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

So far we only reported major state transitions like failure to acquire the message. Let's report the initial failure after a few timeouts in a new event type. The number of timeouts is hardcoded as 3, since Windows seems to be using that. I don't think we need to make this configurable out of the box. A reasonable default may be enough.

Fixes systemd#13316.

This makes an IPv4LL address optional when multiple dynamic addressing protocols are enabled.

Follow-up for 1d370b2.

yuwata · 2020-11-30T03:44:08Z

@keszybz Thank you for the comment. Now, the IPv4LL address is dropped after the DHCPv4 address becomes ready. PTAL.

keszybz · 2020-12-01T13:07:00Z

So... what is expected behaviour after we finally acquire the lease? I get the following:

$ while ip a show dev host0; do sleep 1; done
2: host0@if40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link 
       valid_lft forever preferred_lft forever
...
2: host0@if40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet 192.168.102.53/28 brd 192.168.102.63 scope global dynamic host0
       valid_lft 3600sec preferred_lft 3600sec
    inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link 
       valid_lft forever preferred_lft forever
...
2: host0@if40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet 192.168.102.53/28 brd 192.168.102.63 scope global dynamic host0
       valid_lft 3582sec preferred_lft 3582sec
    inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link 
       valid_lft forever preferred_lft forever

I.e. the LL address will remain forever. Shouldn't we mark it non-preferred and drop after a minute or so?

keszybz · 2020-12-01T20:59:26Z

Anyway, let's merge this. We can improve on the lifetime later.

Shouldn't we mark it non-preferred and drop after a minute or so?

If the kernel allow that, I'd like to go from

inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever

to

inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
       valid_lft 180 preferred_lft 0

when the DHCPv4 address is acquired.

yuwata · 2020-12-01T23:35:42Z

The IPv4LL address must be removed. I will prepare a follow-up PR.

BillPlunkett · 2020-12-04T17:58:02Z

I've been following this discussion for a while, but not 100% sure I understand where things stand.

The desired behavior (for me) is:

network configured in DHCP client mode
DHCP server not present or unresponsive, so ipv4ll address assigned
DHCP server (re)appears, so ipv4ll address removed and DHCP address assigned
From above, it seems like this behavior has been implemented in v247 with the exception that the ipv4ll address will remain after a DHCP address is assigned in step 3. Assuming that is true, what are the ramifications?

keszybz · 2020-12-07T08:17:28Z

The expected behaviour is how you describe it. #17798 even included a test that the ipv4ll address is dropped. Sans bugs, we should be good.

ratagupt · 2021-05-27T08:40:11Z

@yuwata : Can you explian the behaviour here? Do we still have the fall back option or it has been deprecated.

yuwata · 2021-05-27T09:33:21Z

@ratagupt The fall back option is now deprecated. IPv4LL is assigned only when DHCP client is disabled or the client does not receive any response from servers.

ratagupt · 2021-05-27T14:36:36Z

@yuwata : I tried it on systemd v247 and it didn't work with linklocaladdressing=yes, I can see that LL address was always there even after getting the DHCP address.

yuwata · 2021-05-27T16:31:17Z

Could you open a new issue page with debugging logs? Otherwise, we can easily forget your comment in this already merged and closed page.

BillPlunkett · 2021-08-13T18:35:07Z

I was thinking the ipv4 dhcp/linklocal fallback feature made it into systemd v247, but it seems not. I grabbed yocto-hardknott (latest yocto release), which uses systemd v247.6 and it's pretty clear the changes are not there. From https://layers.openembedded.org/layerindex/recipe/5979/ it looks as if v247 is the most recent version available in any yocto release. I am tempted to patch the 247.6 networkd-dhcp4.c to get this feature. Any advice or suggestions?

nikhilsunilkumar · 2023-08-18T10:19:57Z

I was thinking the ipv4 dhcp/linklocal fallback feature made it into systemd v247, but it seems not. I grabbed yocto-hardknott (latest yocto release), which uses systemd v247.6 and it's pretty clear the changes are not there. From https://layers.openembedded.org/layerindex/recipe/5979/ it looks as if v247 is the most recent version available in any yocto release. I am tempted to patch the 247.6 networkd-dhcp4.c to get this feature. Any advice or suggestions?

Any updates on this ?

yuwata added network dhcp labels Nov 23, 2020

yuwata mentioned this pull request Nov 23, 2020

Fold ipv4ll fallback modes into normal ipv4ll addressing #17290

Closed

yuwata force-pushed the ipv4ll branch 2 times, most recently from 6657a89 to 1a4cefe Compare November 23, 2020 13:35

yuwata mentioned this pull request Nov 23, 2020

networkd: don't enable dhcpv6 on l3 devices #17608

Merged

yuwata force-pushed the ipv4ll branch from 1a4cefe to 47f78c9 Compare November 23, 2020 17:30

yuwata force-pushed the ipv4ll branch from 47f78c9 to b856366 Compare November 27, 2020 05:34

keszybz reviewed Nov 27, 2020

View reviewed changes

src/network/networkd-dhcp4.c Outdated Show resolved Hide resolved

keszybz and others added 10 commits November 30, 2020 12:37

man: adjust description of MaxAttempts

573b02f

The code was changed in 715cedf to allow more than six attempts and the old description stopped making sense.

sd-dhcp-client: minor simplification

e4dc084

networkd: start ipv4ll when dhcp has trouble getting a lease

0107b76

Fixes systemd#13316.

network: stop IPv4LL engine when DHCPv4 address is successfully acquired

8ccae2d

network: shorten link_check_ready() a bit

d19b993

network: simplify the condition about ipv4ll is enabled or not

0b4b66c

network: treat IPv4LL is one of dynamic addressing protocol

0d0799d

This makes an IPv4LL address optional when multiple dynamic addressing protocols are enabled.

network: use IN_SET() macro

53ec5dd

Follow-up for 1d370b2.

yuwata force-pushed the ipv4ll branch from b856366 to 53ec5dd Compare November 30, 2020 03:42

keszybz merged commit 0a67dd8 into systemd:master Dec 1, 2020

yuwata deleted the ipv4ll branch December 1, 2020 23:34

yuwata mentioned this pull request Dec 2, 2020

network: improve debug logs and add tests for IPv4LL #17798

Merged

Uh oh!

Conversation

yuwata commented Nov 23, 2020

Uh oh!

yuwata commented Nov 23, 2020

Uh oh!

keszybz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

yuwata commented Nov 30, 2020

Uh oh!

keszybz commented Dec 1, 2020

Uh oh!

keszybz commented Dec 1, 2020

Uh oh!

yuwata commented Dec 1, 2020

Uh oh!

BillPlunkett commented Dec 4, 2020

Uh oh!

keszybz commented Dec 7, 2020

Uh oh!

ratagupt commented May 27, 2021

Uh oh!

yuwata commented May 27, 2021

Uh oh!

ratagupt commented May 27, 2021

Uh oh!

yuwata commented May 27, 2021

Uh oh!

BillPlunkett commented Aug 13, 2021

Uh oh!

nikhilsunilkumar commented Aug 18, 2023

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants