Hi Team,

Please see the attached files for the findings regarding the DHCP Migration issue from VyOS 1.4 to 1.5.

Note: I attached screenshots of the VyOS outputs and Wireshark output in the Word file so that it would be easier to check.

1.4 DHCP Configuration
vyos@R1:~$ show configuration commands | match dhcp-server
set service dhcp-server listen-address '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 name-server '8.8.8.8'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range rangr start '192.168.1.10'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range rangr stop '192.168.1.250'
vyos@R1:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description

eth0 10.10.10.1/24 0c:46:47:5b:00:00 default 1500 u/u

192.168.1.1/24

eth1 - 0c:46:47:5b:00:01 default 1500 u/D
eth2 - 0c:46:47:5b:00:02 default 1500 u/D
eth3 - 0c:46:47:5b:00:03 default 1500 u/D
eth4 - 0c:46:47:5b:00:04 default 1500 u/D
eth5 - 0c:46:47:5b:00:05 default 1500 u/D
eth6 - 0c:46:47:5b:00:06 default 1500 u/D
eth7 - 0c:46:47:5b:00:07 default 1500 u/D
eth8 - 0c:46:47:5b:00:08 default 1500 u/D
eth9 10.217.32.150/24 0c:46:47:5b:00:09 default 1500 u/u
lo 127.0.0.1/8 00:00:00:00:00:00 default 65536 u/u

1.5 DHCP Configuration : After Upgrade from 1.4 to 1.5

vyos@R1:~$ show configuration commands | match dhcp-server
set service dhcp-server listen-address '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server '8.8.8.8'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range rangr start '192.168.1.10'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range rangr stop '192.168.1.250'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 subnet-id '1'
vyos@R1:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description

eth0 10.10.10.1/24 0c:46:47:5b:00:00 default 1500 u/u

192.168.1.1/24

eth1 - 0c:46:47:5b:00:01 default 1500 u/D
eth2 - 0c:46:47:5b:00:02 default 1500 u/D
eth3 - 0c:46:47:5b:00:03 default 1500 u/D
eth4 - 0c:46:47:5b:00:04 default 1500 u/D
eth5 - 0c:46:47:5b:00:05 default 1500 u/D
eth6 - 0c:46:47:5b:00:06 default 1500 u/D
eth7 - 0c:46:47:5b:00:07 default 1500 u/D
eth8 - 0c:46:47:5b:00:08 default 1500 u/D
eth9 10.217.32.132/24 0c:46:47:5b:00:09 default 1500 u/u
lo 127.0.0.1/8 00:00:00:00:00:00 default 65536 u/u

::1/128

vyos@R1:~$

Summary:

After upgrading from VyOS 1.4 to 1.5, DHCP stops working for directly connected clients if the service dhcp-server listen-address is configured. VyOS 1.4 uses ISC DHCP, which handles listen-address with a raw socket, so LAN clients are still served. VyOS 1.5 uses Kea, which switches to UDP-only sockets when listen-address is set ("dhcp-socket-type": "udp"). UDP sockets can’t receive broadcasts from directly connected clients, so only relayed traffic works. The migration script doesn’t handle this: it has no migration from listen-address to listen-interface, so the option is carried over unchanged and breaks DHCP.

A second report of this, with the cause confirmed.

Case. A router upgraded from 1.4 to 1.5 with service dhcp-server listen-address '192.168.14.1' set, serving a directly connected subnet (range and static mappings on eth1). After the upgrade no client got an offer. A capture on the interface showed the DHCPDISCOVER broadcasts (0.0.0.0.68 > 255.255.255.255.67) arriving and no OFFER leaving. kea-dhcp4 was running and had loaded the configuration. The log said DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type udp and listening on address 192.168.14.1, on interface eth1, and netstat showed only 192.168.14.1:67 for it.

Cause. With listen-address the template renders "dhcp-socket-type": "udp" and the address as the interface (kea-dhcp4.conf.j2). The Kea manual says: "Using UDP sockets automatically disables the reception of broadcast packets from directly connected clients." A client without an address cannot reach that socket. This matches the summary of this task.

Fix on the router. delete service dhcp-server listen-address and set service dhcp-server listen-interface eth1 (or no listen setting at all). The log then shows the raw socket, and the clients get their offers. The reporter confirmed that this solved it.

Why it surprises after an upgrade. In 1.4 (ISC dhcpd) listen-address only added an empty subnet { } statement to dhcpd.conf so that the server accepts relayed traffic (T2562), it did not change the receive path for broadcasts. The migration to Kea (dhcp-server 7-to-8) does not touch listen-address, and verify() only checks that the address is assigned to the system. The configuration is kept as it was, but its meaning changed, silently.

Not a deletion of configuration rows. The comparisons in this task show the renames (default-router and name-server to option ...) and the added subnet-id, no rows removed.

Suggestion. A migration cannot know whether listen-address was meant for relays, so I would not rewrite it. A warning at commit would help: when the subnet of a listen-address is also a configured subnet with a range or static mapping on a local interface, say that the server will not receive broadcasts from directly connected clients and point to listen-interface. The documentation of listen-address already says it is only useful for relayed clients, a sentence on the broadcast limitation and a pointer to listen-interface would help as well. I can prepare both if that is wanted.