DHCP snooping, Dynamic ARP Inspection and IP Source Guard answer three different access-layer security questions: which DHCP replies should be accepted, which ARP mappings are valid, and which source IP addresses a host may use.[2][3][1]
Short answer:
- DHCP snooping filters DHCP messages and builds a binding database.[2]
- Dynamic ARP Inspection (DAI) validates incoming ARP claims on untrusted ports.[3]
- IP Source Guard (IPSG) restricts incoming IP traffic using permitted source bindings.[1]
DHCP snooping vs DAI vs IP Source Guard
| Feature | Main question | Information used | Example of rejected traffic |
|---|---|---|---|
| DHCP snooping | Is this DHCP message allowed from this interface? | Interface trust, DHCP message checks and learned bindings | DHCP server reply entering an untrusted client port.[2] |
| Dynamic ARP Inspection | Is this ARP sender mapping valid? | DHCP snooping bindings or configured ARP ACLs | ARP claiming an IP-to-MAC mapping not permitted by the validation policy.[3] |
| IP Source Guard | Is this source IP allowed on this port? | Dynamic or static IP source bindings; optional MAC filtering | IPv4 packet using an address not permitted on the ingress port.[1] |
Think of these as complementary checks, not three names for one feature: checking DHCP does not itself validate every later ARP or data packet.[2][3][1]
This article focuses on the conventional IPv4 access-switch design; the command references are Catalyst 9300 IOS XE documentation, not a promise that every switch supports identical syntax or behavior.
The binding table is the connection between them
A DHCP snooping binding records the client MAC address, assigned IP address, lease information, VLAN and local untrusted interface.[2] It is not simply the switch MAC address table, and a DHCP server's lease database is a separate database from the switch's snooping bindings.[2]
Consider this fictional binding, not captured switch output:
Client MAC IPv4 address VLAN Client-facing interface
02:00:00:00:00:10 192.0.2.10 20 Gi1/0/10
In this example, the intended identity is a host using that address on that access port in VLAN 20. DAI can use the learned IP-to-MAC mapping when checking ARP, while IPSG applies source-address filtering to traffic arriving on the protected interface.[3][1]
An important consequence is that a host having an address does not prove the local switch has the necessary binding: the switch might have reloaded without restoring its snooping database.[2] Check the binding before blaming routing.
Packet flow: lease, ARP, then data
The following is a conceptual walkthrough, not an executed lab:
- Client requests a lease. DHCP messages enter through the client-facing untrusted port and undergo snooping checks.[2]
- The legitimate server replies through the approved path. DHCP snooping distinguishes trusted server-facing ingress from untrusted client ingress and builds the client binding as the lease exchange completes.[2]
- The client sends ARP. On a DAI-untrusted interface, the switch validates the ARP mapping before forwarding; invalid claims are dropped.[3]
- The client sends IPv4 data. IPSG permits source addresses allowed by its binding-based filter and rejects other source addresses on that interface.[1]
Now separate three hypothetical failures:
- A rogue DHCP server connected to a client port sends an Offer: DHCP snooping is the relevant check.[2]
- A host sends ARP with an unauthorized sender IP-to-MAC mapping: DAI is the relevant check.[3]
- A host leaves ARP alone but changes the source IPv4 address of its data packets: IPSG is the relevant check.[1]
Passing one check does not establish that the other checks will pass. Troubleshoot the packet type that is actually failing.
Trusted ports: two settings, two meanings
DHCP snooping trust allows the legitimate server-side DHCP path; DAI trust bypasses ARP validation for packets entering that interface.[2][3]
These are separate interface settings, not a universal declaration that a port is secure.[2][3]
Do not trust a port merely because it is a trunk. Cisco documents that trusting a connection toward an unprotected switch can allow forged ARP through, while leaving a link untrusted without the required bindings can break legitimate connectivity.[3]
My rollout recommendation is to document the enforcement boundary first: where are hosts checked, where do legitimate DHCP replies enter, and which device knows the bindings? Only then choose the trust settings.
A staged configuration and verification example
Assume an isolated lab with an existing VLAN 20, a DHCP client on Gi1/0/10, and Gi1/0/48 leading toward a controlled gateway/DHCP path. Verify the platform release, VLAN configuration and Option 82 handling before applying anything. The snippets below are illustrative; they have not been executed on a switch.
First establish DHCP snooping and the intended server-facing trust setting; snooping requires global and VLAN enablement.[2]
configure terminal
ip dhcp snooping
ip dhcp snooping vlan 20
interface GigabitEthernet1/0/48
ip dhcp snooping trust
exit
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
no ip dhcp snooping trust
end
Renew the lab client's lease and inspect the learned state using the documented verification commands.[2]
show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping statistics
show ip dhcp snooping database
Stop if the binding is missing or wrong. Do not enable the remaining checks merely to complete the template.
After confirming the binding, configure DAI trust only for the controlled upstream path in this lab, then enable DAI on the VLAN and source-IP filtering on the client port.[3][1]
configure terminal
interface GigabitEthernet1/0/48
ip arp inspection trust
exit
ip arp inspection vlan 20
interface GigabitEthernet1/0/10
no ip arp inspection trust
ip verify source
end
Here, ip verify source selects source-IP filtering; the optional MAC-check mode is a separate choice with platform-specific considerations.[1] The upstream DAI trust line is an explicit assumption about this lab's boundary, not a recommendation to trust every uplink.
Inspect the operational state and counters rather than relying only on the running configuration.[3][1][2]
show ip arp inspection vlan 20
show ip arp inspection interfaces
show ip arp inspection statistics vlan 20
show ip arp inspection log
show ip verify source
show ip source binding
Static addresses and switch reloads
Static-address hosts need an explicit plan. Cisco documents ARP ACLs for DAI in non-DHCP environments and static IP source bindings for IPSG.[3][1] A manually configured host address does not automatically create a dynamic DHCP snooping entry.[2]
Do not assume that configuring an IPSG static binding also supplies every DAI exception you need: verify each feature's actual validation policy. For an ARP ACL applied to a mixed DHCP/static VLAN, the optional static keyword is significant: it prevents fallback to DHCP bindings for packets unmatched by the ACL.[3]
Plan persistence before a maintenance reload. Cisco's DHCP snooping database agent stores bindings for restoration after reload; losing dynamic bindings can disrupt connectivity when DAI or IPSG relies on them.[2] Include a controlled reload/recovery test in acceptance, not just a successful first DHCP lease.
Troubleshooting checklist
| Symptom | Check first | Why |
|---|---|---|
| Client cannot obtain a lease | Snooping VLAN, server-facing trust, DHCP drop counters and Option 82 policy | Snooping or relay-information checks can discard legitimate DHCP traffic when the design is inconsistent.[2] |
| Lease exists, but ARP fails | DAI drop log, sender IP/MAC, local bindings and ARP ACLs | DAI validates ARP independently of address assignment.[3] |
| ARP succeeds, but IPv4 traffic fails | IPSG state and source binding for the exact interface/VLAN | Source-IP filtering can reject traffic even when ARP succeeds.[1] |
| Static printer fails after rollout | DAI exception and IPSG static-host policy | DHCP-only learning does not cover every static-host case.[3][1] |
| Problems start after reload | Binding database restoration and lease state | Dynamic bindings need a persistence/recovery strategy.[2] |
| Interface becomes error-disabled | ARP rate-limit events, not just binding mismatches | Exceeding the DAI ARP rate limit can error-disable the interface.[3] |
A useful distinction: dropping a rogue DHCP reply is not the same event as error-disabling a port. Diagnose the actual violation and configured rate limits rather than assuming every invalid packet shuts down the link.[2][3]
Option 82 is another common pitfall: insertion, relay handling and acceptance of Option 82 on untrusted inputs are separate behaviors.[2] Check the end-to-end server/relay design instead of blindly disabling the option or allowing it on every untrusted port.
A concise interview answer
“DHCP snooping filters DHCP messages and learns bindings that associate a client address and MAC with a VLAN and port.[2] DAI uses trusted binding information or ARP ACLs to reject invalid ARP mappings on untrusted ports.[3] IP Source Guard filters source IP addresses on protected interfaces, optionally also checking MAC addresses.[1] I would verify the legitimate DHCP path, static-host exceptions and binding recovery before deploying enforcement.”
Related reading
- Access Port vs Trunk Port vs Native VLAN Explained
- ACL Basics: Standard vs Extended and Implicit Deny
Summary
DHCP snooping establishes and protects DHCP-derived identity information, DAI checks ARP claims, and IPSG checks permitted source IP usage.[2][3][1] My practical rule is: establish the bindings, verify the trust boundary, then test each enforcement feature separately.
Preparing for a network engineering interview? Practice explaining one legitimate packet and one rejected packet for each feature, then explain how you would keep a static printer working after a switch reload.
Post a Comment