DHCP acknowledges dhcprequest after client has been moved to another VLAN
isc-dhcp-server on Ubuntu 18.04.05, version 4.3.5-3ubuntu7.3
Server network configuration:
...
3: p2p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1b:21:53:81:ce brd ff:ff:ff:ff:ff:ff
inet 10.100.0.2/16 brd 10.100.255.255 scope global p2p1
valid_lft forever preferred_lft forever
inet6 fe80::21b:21ff:fe53:81ce/64 scope link
valid_lft forever preferred_lft forever
...
8: vlan5@p2p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:1b:21:53:81:ce brd ff:ff:ff:ff:ff:ff promiscuity 0
vlan protocol 802.1Q id 5 <REORDER_HDR> numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
inet 10.0.1.80/16 brd 10.0.255.255 scope global main
valid_lft forever preferred_lft forever
inet6 fe80::21b:21ff:fe53:81ce/64 scope link
valid_lft forever preferred_lft forever
i.e. interface with the main address and multiple vlans
dhcpd.conf excerpts:
shared-network Main {
subnet 10.100.0.0 netmask 255.255.0.0 {
range 10.100.2.0 10.100.5.255;
}
}
shared-network Vlan5 {
subnet 10.0.0.0 netmask 255.255.0.0 {
range 10.0.2.0 10.0.5.255;
}
}
Both client and server are connected to the same managed switch, which has all vlans configured. Initially, the client was on Main network and was assigned ip address 10.100.2.61. Then, on the switch, it was moved to vlan 5 network. Now it is sending DHCPREQUEST for 10.100.2.61 via vlan5 interface, and the server happily acknowledges the address, without paying attention that the request comes via the interface which is configured with a different subnet.
Aug 11 20:36:50 server dhcpd[19640]: DHCPREQUEST for 10.100.2.61 from bc:ee:7b:77:1d:2f (roma) via vlan5
Aug 11 20:36:50 server dhcpd[19640]: DHCPACK on 10.100.2.61 to bc:ee:7b:77:1d:2f (roma) via vlan5
Naturally, the client's host is not reachable anymore and there is no obvious way how to force it to drop the old address. Client, server and switch are all physically inaccessible.
Maybe related to #109