How does a DHCP snooping switch build and remove its binding-table entries, and why does losing the table in a reboot cut hosts off?

## What an entry holds **DHCP snooping**, a vendor feature with no RFC, learns a **binding** each time it forwards a `DHCPACK` from a trusted port toward a client on an untrusted port. Typical fields: | Field | Where the switch reads it | |---|---| | Client MAC | `chaddr` in the exchange, already checked against the client's frame | | IP address | `yiaddr`, the address the server assigned | | Lease time | Option 51 in the `DHCPACK` | | VLAN | The VLAN the exchange ran on | | Port | The untrusted port where the client's request arrived | **SAVI-DHCP** (RFC 7513, Standards Track), the IETF's specification of the same idea for DHCPv4 and DHCPv6, calls this the **Binding State Table** and gives each entry six fields: binding anchor, address, state (such as `INIT_BIND` or `BOUND`), lifetime, transaction ID and a timeout count. Its **binding anchor** is the attachment — usually a switch port, plus a MAC address where an unmanaged device shares the port — and RFC 7513 says a SAVI device "MUST use a non-spoofable and exclusive binding anchor". A plain MAC address does not qualify, because any host can forge one. ## Building, refreshing and removing entries 1. A client on an untrusted port sends its `DHCPREQUEST`. RFC 7513 creates a provisional `INIT_BIND` entry at this point, keyed by the transaction ID, with a short lifetime. 2. The server's `DHCPACK` arrives on a trusted port; the switch matches it to the pending entry and the entry becomes `BOUND`, its lifetime set to the lease time plus a short response allowance. 3. Each renewal the switch sees refreshes the lifetime from the new `DHCPACK`. 4. A `DHCPRELEASE` or `DHCPDECLINE` removes the entry — but only from the port that holds the binding. RFC 7513 calls this the binding anchor check. 5. Expiry removes the entry when the lifetime runs out with no renewal. ## Who reads the table - **ARP inspection** (vendor feature, no RFC) drops ARP packets on untrusted ports whose sender MAC and IP do not match a binding. - **IP source guard** (vendor feature, no RFC) drops IP packets whose source address, and optionally source MAC, is not bound to the arrival port. - **Per-port binding limits** count entries to cap how many addresses one attachment may hold. RFC 7513 section 8 folds these into one rule set: a data packet from a validating attachment whose source has no `BOUND` entry "MUST be discarded", and ARP and Neighbor Discovery packets are checked against the same table. ## What never lands in it 1. **Statically addressed hosts** — no DHCP exchange, no entry. Implementations let operators add static bindings. 2. **Hosts whose exchange the switch did not see.** RFC 7513 names multiple paths (the DHCP exchange went around this switch) and dynamic paths (a topology change, or a host moving ports without reconfirming). 3. **Addresses DHCP never assigned** — link-local addresses and SLAAC addresses. RFC 7513 points to FCFS SAVI (RFC 6620) for those. ## When the switch reboots The table normally lives in memory. A switch reload does not touch the hosts' leases, but the switch has forgotten all of them, and every feature that reads the table now drops their traffic. A host that senses its link go down and up and re-verifies its lease — an INIT-REBOOT `DHCPREQUEST` sent from `0.0.0.0` — gets its binding back at once; RFC 7513 lets that message through and binds on the server's reply. A host that does not re-verify — one behind an unmanaged switch, whose own link never dropped — stays unknown, and how long depends on what still passes: - If DHCP itself is let through, an entry returns when the switch sees that host's next renewal, at T1 — by default half the lease, so hours with day-long leases. - Under RFC 7513's control-packet rule, a DHCPv4 client message whose source is "neither all zeros nor bound" MUST be discarded. The unicast renewal and the broadcast rebind both carry the host's own address, so both are dropped, and the host waits for its lease to expire and starts again from `0.0.0.0`. RFC 7513 section 9.2 therefore recommends saving entries to non-volatile storage when they reach `BOUND`, restoring them immediately after reboot, and removing those that would have expired meanwhile. Its optional **Data Snooping Process** (section 7) is the fallback: an unbound data packet can trigger a duplicate check by ARP or DAD and then a leasequery — `DHCPLEASEQUERY` from RFC 4388 for DHCPv4 — asking the server whether the address is really leased. RFC 7513 warns that data snooping puts "a considerable burden" on the switch's processor, which is why it is optional and triggered only probabilistically.