Why wait a full DHCP lease period before ARP validation drops, while a gateway claim still succeeds?

## The table is a record of what the switch happened to see Dynamic ARP inspection does not know anything about your addressing plan. On an untrusted port it takes the sender MAC and sender IP out of an ARP frame and looks for a binding that matches; no binding, no pass. The bindings come from one place only — DHCP exchanges the switch itself forwarded after snooping was enabled. That single fact drives the whole rollout order. When you enable snooping on a live segment, the table is empty. Hosts do not re-request an address because a switch feature was turned on; they keep using the lease they already hold. A client normally contacts the server again at **T1**, half the lease, and falls back to broadcasting at **T2**, seven eighths of it. So the table fills gradually over roughly half a lease period for a well-behaved population, and never at all for the hosts that do not use DHCP. ## What happens if you skip the wait Enable dropping in the same window and every host whose lease predates snooping loses the ability to resolve its default gateway. The failure has three properties that make it expensive: - It is **partial and confusing**: existing conversations continue until an ARP entry ages out, so the rack degrades over minutes rather than failing at once. - It is **invisible from the host**: the interface is up, the address is valid, the lease is fine. The packets simply stop being forwarded. - It is **wide**: one command on a top-of-rack switch reaches every port on it. A storage controller or an out-of-band management interface with a static address never had a binding and never will, so for that population the wait changes nothing — they need static bindings entered from the inventory. ## What the log window actually buys Running validation in log-only mode does two jobs at once. 1. **It fills the table.** Every renewal observed during the window becomes a binding. 2. **It produces the exception list.** Each logged mismatch is an address that would have been dropped. Sorted and de-duplicated, that list is the set of hosts you must resolve before flipping — by letting them renew, by adding a static binding, or by deciding the port is exempt. The list shrinks quickly at first, as leases renew, then flattens. The flat residue is the interesting part: those are the hosts that will never appear on their own. ## What a log entry proves, and what it does not A validation log entry proves exactly one thing: a frame on an untrusted port carried a sender pair with no matching binding. That is the signature of a host claiming an address it was not given — and it is also precisely what a legitimate statically addressed appliance produces, every few seconds, forever. The record proves a mismatch, not intent. Treating the log as an attack feed during a rollout wastes the window; treating it as a coverage worklist is what it is for. ## Shortening the wait, and what each shortcut costs | Move | Effect | Cost | | --- | --- | --- | | Shorten the lease before the window | clients renew sooner, table fills faster | more server load and more churn while it lasts | | Bounce access ports rack by rack | forces immediate re-lease | a brief, scheduled outage per port group | | Import bindings from the server's active leases and the asset inventory | covers hosts before they renew | the import is only as good as the source, and it goes stale | ## The half nobody says out loud Every day spent logging is a day the control is not enforcing. The host you deployed this against — the one answering for the gateway from an access port — is unaffected by a log entry. That is the trade the change record should state plainly: a bounded window of continued exposure, chosen deliberately, in exchange for not blackholing a rack full of hosts you had not yet learned. Stating it that way is also what gets the shorter window approved, because it makes the wait a cost rather than a formality.