DHCP4 weirdness when container is rebooted

Incus
1

incus/noble,now 1:6.5-ubuntu24.04-202409070227 amd64 [installed]

Since my kea dhcp server is scripted to register dhcp assignments into DNS, I’ve been noticing some unusual behaviour with dhcp4 and incus (dhcp6 doesn’t seem to be affected)
The containers are bridged onto the container-host network.

Each time I reboot a container, there is a dhcp request from the container, but which contains the hostname of the container-host.
Immediately followed by a dhcp request from the container with the correct container hostname.
eg:
dhcp request hostname:container-host.example.com (from container) <-incorrect
dhcp request hostname:container.example.com (from container)

This leaves DNS with an invalid IP for container-host.example.com

Has anyone come across this? Any suggestions on how to fix?

2

Welcome!

Whatever appears as a request from a container, depends on the container image.
It’s quite weird that the container would know the hostname of the host and then request it.

Which container image do you use?
Also, it’s important to setup a testing environment so that others can replicate. Here’s mine.

First, I create the container and take note of the MAC address so that I can filter later the traffic.

$ incus launch images:ubuntu/24.04 mycontainer
Launching mycontainer
$ incus shell mycontainer
root@mycontainer:~# ip address show dev eth0
73: eth0@if74: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:a0:11:8b brd ff:ff:ff:ff:ff:ff link-netnsid 0
...
root@mycontainer:~#

The MAC address is 00:16:3e:a0:11:8b.

Second, I start a new terminal window and keep running the following.
Then, on the Incus terminal I run

incus restart mycontainer

If you want an overview of the capture, do this. These are 7 DHCP packets.

$ sudo tshark -i incusbr0  "(port 67 or port 68) and ether host 00:16:3e:a0:11:8b"
...
    1 0.000000000 10.10.10.163 → 10.10.10.1   DHCP 295 DHCP Release  - Transaction ID 0xe7fd46c1
    2 0.146357855      0.0.0.0 → 255.255.255.255 DHCP 332 DHCP Discover - Transaction ID 0x323cde54
    3 0.146640277   10.10.10.1 → 10.10.10.163 DHCP 342 DHCP Offer    - Transaction ID 0x323cde54
    4 0.146681905      0.0.0.0 → 255.255.255.255 DHCP 344 DHCP Request  - Transaction ID 0x323cde54
    5 0.152216212   10.10.10.1 → 10.10.10.163 DHCP 354 DHCP ACK      - Transaction ID 0x323cde54
    6 1.490812310      0.0.0.0 → 255.255.255.255 DHCP 328 DHCP Discover - Transaction ID 0x85a9e528
    7 1.492935984   10.10.10.1 → 10.10.10.163 DHCP 356 DHCP ACK      - Transaction ID 0x85a9e528

If you want to view just the hostname in the packet, do the following. Again, it’s the seven packets from before. The DHCP Request has the host myhost.

sudo tshark -T fields -e dhcp.option.hostname -i incusbr0  "(port 67 or port 68) and ether host 00:16:3e:a0:11:8b"

1 - 
2 - myhost
3 - 
4 - myhost
5 - mycontainer
6 - mycontainer
7 - mycontainer

This means that it looks that I can verify what you get.

What I need now from you is to verify that you perform the exact same steps and get the respective results. Is that the case?

3

It happens with either a Debian or Rocky 9 container.
In the screenshot below during a container reboot, packets # 1-5 are the mac address of the container requesting a dhcp lease with the hostname of the container-host (anguille), followed by packets # 6-9 of the container requesting a dhcp lease with the correct hostname of the container.
The container-host has a static ipv4 address configured so can’t be doing this “by mistake”

image
image1693×1080 297 KB

And this is the DHCP4 traffic when just shutting down a container. The mac address is for the container being shut down, but the hostname belongs to the container-host.

22:13:13.058027 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 314)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:3e:7f:7e:5d, length 286, xid 0x5dafd88c, secs 1, Flags [none]
          Client-Ethernet-Address 00:16:3e:7f:7e:5d
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            Client-ID (61), length 7: ether 00:16:3e:7f:7e:5d
            Parameter-Request (55), length 17: 
              Subnet-Mask (1), Time-Zone (2), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), MTU (26), BR (28), Classless-Static-Route (121)
              Default-Gateway (3), Static-Route (33), YD (40), YS (41)
              NTP (42), Unknown (119), Classless-Static-Route-Microsoft (249), Unknown (252)
              RP (17)
            MSZ (57), length 2: 576
            Hostname (12), length 8: "anguille"
22:13:13.073436 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 356)
    192.168.22.1.67 > 192.168.22.116.68: BOOTP/DHCP, Reply, length 328, xid 0x5dafd88c, Flags [none]
          Your-IP 192.168.22.116
          Client-Ethernet-Address 00:16:3e:7f:7e:5d
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Offer
            Subnet-Mask (1), length 4: 255.255.255.0
            Default-Gateway (3), length 4: 192.168.22.1
            Domain-Name-Server (6), length 8: 192.168.22.17,192.168.22.36
            Hostname (12), length 8: "anguille"
            Domain-Name (15), length 14: "dom.example.com"
            NTP (42), length 4: 192.168.22.1
            Lease-Time (51), length 4: 7200
            Server-ID (54), length 4: 192.168.22.1
            Unknown (119), length 16: 74280811,1627743849,1953724675,1668246784
22:13:13.074837 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 326)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:3e:7f:7e:5d, length 298, xid 0x5dafd88c, secs 1, Flags [none]
          Client-Ethernet-Address 00:16:3e:7f:7e:5d
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            Client-ID (61), length 7: ether 00:16:3e:7f:7e:5d
            Parameter-Request (55), length 17: 
              Subnet-Mask (1), Time-Zone (2), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), MTU (26), BR (28), Classless-Static-Route (121)
              Default-Gateway (3), Static-Route (33), YD (40), YS (41)
              NTP (42), Unknown (119), Classless-Static-Route-Microsoft (249), Unknown (252)
              RP (17)
            MSZ (57), length 2: 576
            Requested-IP (50), length 4: 192.168.22.116
            Server-ID (54), length 4: 192.168.22.1
            Hostname (12), length 8: "anguille"
22:13:13.103346 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 356)
    192.168.22.1.67 > 192.168.22.116.68: BOOTP/DHCP, Reply, length 328, xid 0x5dafd88c, Flags [none]
          Your-IP 192.168.22.116
          Client-Ethernet-Address 00:16:3e:7f:7e:5d
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: ACK
            Subnet-Mask (1), length 4: 255.255.255.0
            Default-Gateway (3), length 4: 192.168.22.1
            Domain-Name-Server (6), length 8: 192.168.22.17,192.168.22.36
            Hostname (12), length 8: "anguille"
            Domain-Name (15), length 14: "dom.example.com"
            NTP (42), length 4: 192.168.22.1
            Lease-Time (51), length 4: 7200
            Server-ID (54), length 4: 192.168.22.1
            Unknown (119), length 16: 74280811,1627743849,1953724675,166824678
4

Turns out it was NetworkManager on the container-host fiddling with interface connections when bridge members are added/removed from the bridge

Adding the config below fixed it.

root@anguille:/etc/NetworkManager/conf.d# cat ignore-veth.conf 
[main]
plugins=keyfile

[keyfile]
unmanaged-devices=interface-name:veth*
1 Like