systemd does not release DHCP IP during networkd restart #1546

Closed
vinaykul opened this Issue Oct 12, 2015 · 12 comments

Comments

Projects
None yet
8 participants
Contributor

vinaykul commented Oct 12, 2015

With version 224 and earlier, we found a cleanup issue during systemd-networkd restart. networkd requests a new DHCP IP without releasing the previously acquired DHCP IP. Please see the attached packet capture (filtered) from VMWare fusion host system, and a screen-shot of the resultant secondary IP address acquisition.

I scanned through the open and recently closed issues but didn't find a report of this issue. Please let me know if I missed a duplicate.

Thanks,
Vin

Unable to upload txt or pdf file, so below is a paste of packet capture data.

ipaddrshow

vmware@vlinux:~/Desktop/systemd224$ tcpdump -nvr pkt.cap icmp or udp port 67
reading from file pkt.cap, link-type EN10MB (Ethernet)
13:39:12.205358 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 313)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:c4:00:12, length 285, xid 0x6d817759, secs 1, Flags [none]
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255, 4e:3d:48💿00:02:00:00🆎11:40:4b:42:90:1a:7d:8f:27
Parameter-Request Option 55, length 8:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, NTP, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
Hostname Option 12, length 4: "p224"
13:39:12.205575 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.254 > 192.168.12.144: ICMP echo request, id 35034, seq 0, length 28
13:39:12.205660 IP (tos 0x0, ttl 128, id 41940, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.254 > 192.168.12.144: ICMP echo request, id 35034, seq 0, length 28
13:39:13.205938 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.12.254.67 > 192.168.12.144.68: BOOTP/DHCP, Reply, length 300, xid 0x6d817759, secs 1, Flags [none]
Your-IP 192.168.12.144
Server-IP 192.168.12.254
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.12.254
Lease-Time Option 51, length 4: 1800
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.12.2
Domain-Name Option 15, length 11: "localdomain"
Domain-Name-Server Option 6, length 4: 192.168.12.2
13:39:13.206354 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 325)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:c4:00:12, length 297, xid 0x6d817759, secs 1, Flags [none]
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255, 4e:3d:48💿00:02:00:00🆎11:40:4b:42:90:1a:7d:8f:27
Parameter-Request Option 55, length 8:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, NTP, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
Server-ID Option 54, length 4: 192.168.12.254
Requested-IP Option 50, length 4: 192.168.12.144
Hostname Option 12, length 4: "p224"
13:39:13.207361 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.12.254.67 > 192.168.12.144.68: BOOTP/DHCP, Reply, length 300, xid 0x6d817759, secs 1, Flags [none]
Your-IP 192.168.12.144
Server-IP 192.168.12.254
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.12.254
Lease-Time Option 51, length 4: 1800
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.12.2
Domain-Name Option 15, length 11: "localdomain"
Domain-Name-Server Option 6, length 4: 192.168.12.2

======>>>>>> NOTE: 'systemctl restart system-networkd' at this point.

13:40:15.608265 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 313)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:c4:00:12, length 285, xid 0xac26bb3a, secs 1, Flags [none]
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255, 4e:3d:48💿00:02:00:00🆎11:40:4b:42:90:1a:7d:8f:27
Parameter-Request Option 55, length 8:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, NTP, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
Hostname Option 12, length 4: "p224"
13:40:15.608378 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.254 > 192.168.12.144: ICMP echo request, id 35034, seq 0, length 28
13:40:15.608411 IP (tos 0x0, ttl 128, id 41945, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.254 > 192.168.12.144: ICMP echo request, id 35034, seq 0, length 28
13:40:15.608588 IP (tos 0x10, ttl 64, id 14924, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.144 > 192.168.12.254: ICMP echo reply, id 35034, seq 0, length 28
13:40:15.608604 IP (tos 0x0, ttl 64, id 14925, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.144 > 192.168.12.254: ICMP echo reply, id 35034, seq 0, length 28
13:40:17.714302 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 313)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:c4:00:12, length 285, xid 0xac26bb3a, secs 2, Flags [none]
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255, 4e:3d:48💿00:02:00:00🆎11:40:4b:42:90:1a:7d:8f:27
Parameter-Request Option 55, length 8:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, NTP, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
Hostname Option 12, length 4: "p224"
13:40:17.714553 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.254 > 192.168.12.145: ICMP echo request, id 30938, seq 0, length 28
13:40:18.715873 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.12.254.67 > 192.168.12.145.68: BOOTP/DHCP, Reply, length 300, xid 0xac26bb3a, secs 2, Flags [none]
Your-IP 192.168.12.145
Server-IP 192.168.12.254
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.12.254
Lease-Time Option 51, length 4: 1800
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.12.2
Domain-Name Option 15, length 11: "localdomain"
Domain-Name-Server Option 6, length 4: 192.168.12.2
13:40:18.716098 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 325)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:c4:00:12, length 297, xid 0xac26bb3a, secs 3, Flags [none]
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255, 4e:3d:48💿00:02:00:00🆎11:40:4b:42:90:1a:7d:8f:27
Parameter-Request Option 55, length 8:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, NTP, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
Server-ID Option 54, length 4: 192.168.12.254
Requested-IP Option 50, length 4: 192.168.12.145
Hostname Option 12, length 4: "p224"
13:40:18.717257 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.12.254.67 > 192.168.12.145.68: BOOTP/DHCP, Reply, length 300, xid 0xac26bb3a, secs 3, Flags [none]
Your-IP 192.168.12.145
Server-IP 192.168.12.254
Client-Ethernet-Address 00:0c:29:c4:00:12
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.12.254
Lease-Time Option 51, length 4: 1800
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.12.2
Domain-Name Option 15, length 11: "localdomain"
Domain-Name-Server Option 6, length 4: 192.168.12.2
13:40:19.718946 IP (tos 0x0, ttl 128, id 41946, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.254 > 192.168.12.145: ICMP echo request, id 30938, seq 0, length 28
13:40:19.719065 IP (tos 0x0, ttl 64, id 51499, offset 0, flags [none], proto ICMP (1), length 48)
192.168.12.145 > 192.168.12.254: ICMP echo reply, id 30938, seq 0, length 28
vmware@vlinux:~/Desktop/systemd224$

@poettering poettering added the network label Oct 13, 2015

Owner

poettering commented Oct 13, 2015

@teg, any idea?

Contributor

vinaykul commented Oct 13, 2015

Thanks for the quick response and looking into this.

On a related note, I'm wondering if it is also possible to enhance networkd to persist a DHCP acquired IP address across system reboot and networkd restart. The following is a DHCP DISCOVER packet captured when Ubuntu 14.04 (does not use systemd) VM was rebooted - please note the "Requested-IP Option" vs. the systemd discover packet above.

Thanks,
Vinay

vmware@vlinux:~/Desktop/tmp$ sudo tcpdump -envr dhcp_1404.cap udp port 68
reading from file dhcp_1404.cap, link-type EN10MB (Ethernet)
10:28:49.299457 00:0c:29:07:39:15 > 00:50:56:eb:97:91, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 13074, offset 0, flags [DF], proto UDP (17), length 328)
192.168.12.162.68 > 192.168.12.254.67: BOOTP/DHCP, Request from 00:0c:29:07:39:15, length 300, xid 0xf106107e, Flags [none]
Client-IP 192.168.12.162
Client-Ethernet-Address 00:0c:29:07:39:15
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Release
Server-ID Option 54, length 4: 192.168.12.254
Hostname Option 12, length 22: "vmware-virtual-machine"
10:29:09.952004 00:0c:29:07:39:15 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:07:39:15, length 300, xid 0xa62c4333, Flags [none]
Client-Ethernet-Address 00:0c:29:07:39:15
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Requested-IP Option 50, length 4: 192.168.12.162
Hostname Option 12, length 22: "vmware-virtual-machine"
Parameter-Request Option 55, length 13:
Subnet-Mask, BR, Time-Zone, Default-Gateway
Domain-Name, Domain-Name-Server, Option 119, Hostname
Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
NTP
10:29:10.953530 00:50:56:eb:97:91 > 00:0c:29:07:39:15, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328)
192.168.12.254.67 > 192.168.12.162.68: BOOTP/DHCP, Reply, length 300, xid 0xa62c4333, Flags [none]
Your-IP 192.168.12.162
Server-IP 192.168.12.254
Client-Ethernet-Address 00:0c:29:07:39:15
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.12.254

thx1111 commented Oct 15, 2015

networkd does not reconfigure, remove, or "flush" already configured addresses - Issue 1352 and Issue 780. I requested a feature, some kind of "FlushAddresses=yes" option, to have networkd remove "old" addresses when invoking "sysemctl restart " or "systemctl reload-or-restart" on systemd-networkd. Not flushing old addresses might be desirable with "systemctl start ...", perhaps to continue an established network connection.

Lennart refused to discuss the issue here. You are not the only one to have been "bitten" by this behavior. Keep trying. You might have better luck, getting a fix.

For now, the workaround is to modify the systemd-networkd.service file, to flush the existing interface addresses before configuring any static or dynamic addresses, using a line like "ExecStartPre=/usr/bin/ip addr flush dev eth0" in the [Service] section.

Owner

poettering commented Oct 15, 2015

@thx1111 I refused what?

I already agreed that networkd should flush all addresses, always. And @teg is working on it. It's him anyway who's in charge on networkd, not me...

lht commented Nov 20, 2015

May be a duplicates of #780

is it flushing now? if so which version got the fix?

ssahani added a commit to ssahani/systemd that referenced this issue May 6, 2016

Contributor

teg commented May 20, 2016

Just a quick comment on the behavior observed here: the DHCP server handing out a new address when it already has handed out a valid lease to the same ClientID is broken behavior. It should give the same address again. We may of course choose to flush the old address when we get a new one, but on the other hand the lease will be valid, so we could also chose to keep both as we currently do. The same problem would occur if we provided the old address but the server ignored it and gave us a new one.

Contributor

vinaykul commented May 20, 2016

The packet traces I analyzed showed new address being handed out was because the client holding on to the old address responding to the ARP from DHCP server after initiating a DISCOVER. Flushing it works because DHCP server determines the address is not in use and hands out the leased address back. This is probably designed to handle the case where client suffers a catastrophic outage and reboots.

The correct way would perhaps be for the client to send a DHCPRELEASE but that will likely end the lease and might open doors for a different address on networkd restart. So the current solution is perhaps the better solution.

@vinaykul vinaykul closed this May 20, 2016

Contributor

teg commented May 22, 2016

@vinaykul thanks for the follow-up. That explains it. The server should probably be a bit more clever and realize the owner of the IP is the same as the one requesting the lease, but not much we can do about that... shrug

SpComb commented Jul 6, 2016

I'm running into the same issue where every systemctl restart systemd-networkd leads to a new lease on the interface.

This is problematic because the ISP has a per-circuit limit on the number of available leases, and after a couple networkd restarts the ISP refuses to hand out any more new leases. If you now reboot, then you will be unable to get a new DHCP lease until the existing ones expire.

This doesn't happen with the old dhclient, presumeably because it does a DHCPREQUEST to renew its existing lease before falling back to a DHCPDISCOVER?

tcpdump below, with the DHCPDISCOVER and resulting ICMP ping to the previous 82.181.208.58 lease from the ISP, followed by a new lease for 62.78.183.59. Followed by an ARP probe from the initial DHCP lease (62.78.183.68).

13:16:35.018852 ea:c9:5e:c0:64:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from ea:c9:5e:c0:64:38, length 287, xid 0x69b2dc01, secs 1, Flags [none] (0x0000)
          Client-Ethernet-Address ea:c9:5e:c0:64:38
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 19: hardware-type 255, d5:6b:6a:1a:00:02:00:00:ab:11:11:27:16:e3:8d:35:f2:61
            Parameter-Request Option 55, length 9: 
              Subnet-Mask, Default-Gateway, Hostname, Domain-Name
              Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
              MDHCP
            MSZ Option 57, length 2: 576
            Hostname Option 12, length 5: "yzzrt"
13:16:35.034736 00:17:10:90:c9:27 > ea:c9:5e:c0:64:38, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto ICMP (1), length 48)
    81.175.171.117 > 82.181.208.58: ICMP echo request, id 57191, seq 0, length 28
13:16:35.034762 ea:c9:5e:c0:64:38 > 00:17:10:90:c9:27, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 24772, offset 0, flags [none], proto ICMP (1), length 48)
    82.181.208.58 > 81.175.171.117: ICMP echo reply, id 57191, seq 0, length 28
13:16:37.937148 ea:c9:5e:c0:64:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from ea:c9:5e:c0:64:38, length 287, xid 0x69b2dc01, secs 2, Flags [none] (0x0000)
          Client-Ethernet-Address ea:c9:5e:c0:64:38
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 19: hardware-type 255, d5:6b:6a:1a:00:02:00:00:ab:11:11:27:16:e3:8d:35:f2:61
            Parameter-Request Option 55, length 9: 
              Subnet-Mask, Default-Gateway, Hostname, Domain-Name
              Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
              MDHCP
            MSZ Option 57, length 2: 576
            Hostname Option 12, length 5: "yzzrt"
13:16:38.949915 00:17:10:90:c9:27 > ea:c9:5e:c0:64:38, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    81.175.171.116.67 > 62.78.183.59.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x69b2dc01, secs 2, Flags [none] (0x0000)
          Your-IP 62.78.183.59
          Server-IP 81.175.171.116
          Gateway-IP 89.27.8.1
          Client-Ethernet-Address ea:c9:5e:c0:64:38
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 81.175.171.116
            Lease-Time Option 51, length 4: 18000
            Subnet-Mask Option 1, length 4: 255.255.248.0
            Default-Gateway Option 3, length 4: 62.78.176.1
            Domain-Name Option 15, length 9: "pp.htv.fi"
            Domain-Name-Server Option 6, length 8: 62.241.198.246,62.241.198.245
13:16:38.949952 ea:c9:5e:c0:64:38 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 62.78.183.59 tell 62.78.183.68, le
13:16:38.950041 ea:c9:5e:c0:64:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 341: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 327)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from ea:c9:5e:c0:64:38, length 299, xid 0x69b2dc01, secs 3, Flags [none] (0x0000)
          Client-Ethernet-Address ea:c9:5e:c0:64:38
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 19: hardware-type 255, d5:6b:6a:1a:00:02:00:00:ab:11:11:27:16:e3:8d:35:f2:61
            Parameter-Request Option 55, length 9: 
              Subnet-Mask, Default-Gateway, Hostname, Domain-Name
              Domain-Name-Server, Static-Route, Classless-Static-Route, NTP
              MDHCP
            MSZ Option 57, length 2: 576
            Server-ID Option 54, length 4: 81.175.171.116
            Requested-IP Option 50, length 4: 62.78.183.59
            Hostname Option 12, length 5: "yzzrt"
13:16:38.967508 00:17:10:90:c9:27 > ea:c9:5e:c0:64:38, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    81.175.171.116.67 > 62.78.183.59.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x69b2dc01, secs 3, Flags [none] (0x0000)
          Your-IP 62.78.183.59
          Server-IP 81.175.171.116
          Gateway-IP 89.27.8.1
          Client-Ethernet-Address ea:c9:5e:c0:64:38
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 81.175.171.116
            Lease-Time Option 51, length 4: 18000
            Subnet-Mask Option 1, length 4: 255.255.248.0
            Default-Gateway Option 3, length 4: 62.78.176.1
            Domain-Name Option 15, length 9: "pp.htv.fi"
            Domain-Name-Server Option 6, length 8: 62.241.198.246,62.241.198.245

r7vme commented Jul 16, 2017

I'm also affected by this issue (looks the same).

systemd version 231 (both in host and vm)

I have Container Linux VM connected via bridge (dhcp server). Problem is that vm tries to get ip address two times: 1) While initramfs phase 2) when switched to real root. I have very small dhcp network /30 for only one dhcp client. That's why VM ends up without any IP.

In networkd logs i see that first try was successful, but second one is not. Continuous DHCPDISCOVER packages.

Jul 16 10:09:57 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: DISCOVER (0x3fe977e0)
Jul 16 10:09:57 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: OFFER (0x3fe977e0)
Jul 16 10:09:57 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: REQUEST (selecting) (0x3fe977e0)
Jul 16 10:09:57 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: ACK (0x3fe977e0)
Jul 16 10:10:11 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: DISCOVER (0xebdaaf3a)
Jul 16 10:10:13 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: DISCOVER (0xebdaaf3a)
Jul 16 10:10:16 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: DISCOVER (0xebdaaf3a)
Jul 16 10:10:20 000014f351a80f9d systemd-networkd[16955]: DHCP SERVER: DISCOVER (0xebdaaf3a)

Interesting fact, that VM ip is not presented in ARP table on the host and is not reachable by ICMP.

Host bridge configuration:

r7vme@000014f351a80f9d ~ $ cat /etc/systemd/network/10-br-ns2uw.netdev 
[NetDev]
Name=br-ns2uw
Kind=bridge
r7vme@000014f351a80f9d ~ $ cat /etc/systemd/network/10-br-ns2uw.network 
[Match]
Name=br-ns2uw

[Network]
Address=172.23.1.89/30
DHCPServer=yes
IPMasquerade=no

[DHCPServer]
DNS=8.8.8.8

r7vme commented Jul 16, 2017

Here is the tcpdump

[root@000014f351a80f9d ~]# tcpdump -i br-ns2uw 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-ns2uw, link-type EN10MB (Ethernet), capture size 262144 bytes
11:01:59.095053 IP6 000014f351a80f9d > ff02::2: ICMP6, router solicitation, length 16
11:02:03.118924 IP6 000014f351a80f9d > ff02::2: ICMP6, router solicitation, length 16
11:02:07.369115 IP6 000014f351a80f9d > ff02::2: ICMP6, router solicitation, length 16
11:02:31.274404 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from de:ad:be:7b:70:d4 (oui Unknown), length 281
11:02:31.274572 IP 000014f351a80f9d.bootps > 172.23.1.90.bootpc: BOOTP/DHCP, Reply, length 268
11:02:31.276029 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:31.276444 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from de:ad:be:7b:70:d4 (oui Unknown), length 293
11:02:31.276572 IP 000014f351a80f9d.bootps > 172.23.1.90.bootpc: BOOTP/DHCP, Reply, length 279
11:02:32.258596 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:32.337934 IP6 :: > ff02::1:ff7b:70d4: ICMP6, neighbor solicitation, who has fe80::dcad:beff:fe7b:70d4, length 24
11:02:33.426903 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:33.430480 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::2: ICMP6, router solicitation, length 16
11:02:33.431287 IP6 fe80::dcad:beff:fe7b:70d4.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req
11:02:34.111674 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:34.463498 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:34.509571 IP6 fe80::dcad:beff:fe7b:70d4.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req
11:02:45.565441 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:45.682757 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from de:ad:be:7b:70:d4 (oui Unknown), length 281
11:02:46.201491 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:46.491467 IP6 :: > ff02::1:ff7b:70d4: ICMP6, neighbor solicitation, who has fe80::dcad:beff:fe7b:70d4, length 24
11:02:47.240967 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from de:ad:be:7b:70:d4 (oui Unknown), length 281
11:02:47.493593 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:47.510115 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::2: ICMP6, router solicitation, length 16
11:02:47.511059 IP6 fe80::dcad:beff:fe7b:70d4.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req
11:02:48.128986 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
11:02:48.591461 IP6 fe80::dcad:beff:fe7b:70d4.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req
11:02:49.870500 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from de:ad:be:7b:70:d4 (oui Unknown), length 281
11:02:50.602423 IP6 fe80::dcad:beff:fe7b:70d4.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req
11:02:51.694909 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::2: ICMP6, router solicitation, length 16
11:02:54.532100 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from de:ad:be:7b:70:d4 (oui Unknown), length 281
11:02:54.840015 IP6 fe80::dcad:beff:fe7b:70d4.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 inf-req
11:02:55.944877 IP6 fe80::dcad:beff:fe7b:70d4 > ff02::2: ICMP6, router solicitation, length 16

restart of systemd-networkd immediately fixes the problem :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment