Phones on a new hotel VLAN come up with 169.254 addresses. Phones on the older VLANs still receive leases from the same DHCP server, the new scope still has free addresses, and the new router interface has no DHCP helper. Which fault is this?
Select an answer to reveal the explanation.
Short Explanation
A DHCP broadcast does not cross a router unless someone carries it. You are missing the DHCP relay on the new hotel VLAN, so those phones fall back to 169.254 while every older VLAN still gets a lease. An empty pool, a helper aimed at the wrong server, or snooping that would have broken the working VLANs does not fit.
Full Explanation
Clients send DHCP discovery as a broadcast. A router does not forward it unless a helper is configured on the interface that hears it. The new interface has no helper, so the phones never reach the server and assign themselves addresses in 169.254.0.0/16. Older VLANs still lease from that server, so the server is fine. Pool exhaustion needs a scope with no free addresses. This scope still has room, and the phones never reach it. A helper aimed at the wrong server is the tempting twin because the symptom looks the same. The stem says the new interface has no helper at all, so there is no address to correct until the relay exists. Snooping that dropped offers on every VLAN would have stopped the older phones too. Exam caveat: once the relay exists it must point at the right server, and that server needs a scope for the new subnet. Operational check: add the relay on the new interface, renew a phone, and confirm it receives an address from the new scope while an older VLAN still renews. Point the new helper at the same server the older VLANs already use, then confirm the new scope is the one that answers.