DHCP Snooping & Dynamic ARP Inspection

Layer 2 networks trust every device on the segment by default. A host can advertise itself as the DHCP server and hand out fraudulent IP addresses, redirecting all traffic through an attacker-controlled machine. A separate host can broadcast forged ARP replies, poisoning the ARP cache of every neighbour and intercepting or dropping packets silently. Both attacks succeed because switches forward these frames without any validation. DHCP Snooping and Dynamic ARP Inspection (DAI) are two complementary Cisco Catalyst security features that close both gaps at the switch level — requiring no changes to end hosts or routers.

DHCP Snooping acts as a firewall between untrusted client ports and the legitimate DHCP server — only the uplink port toward the real server is trusted to send DHCP offers. DAI uses the binding table that DHCP Snooping builds to validate every ARP packet — if an ARP reply's IP-to-MAC mapping does not match a known lease, the frame is dropped. The two features are deeply interlinked: DAI depends on the DHCP Snooping binding table for its validation data. For a conceptual overview see DHCP Snooping and Dynamic ARP Inspection.

These are Layer 2 switch features — they are configured on Cisco Catalyst switches, not routers. Ensure VLANs are already configured before starting. Review VLAN Creation and Management and Assigning VLANs to Switch Ports if needed. For the DHCP server that DHCP Snooping will protect, see DHCP Server Configuration. For the inter-VLAN routing context these VLANs operate in, see Inter-VLAN Routing — Layer 3 Switch.

1. DHCP Snooping — Core Concepts

The Rogue DHCP Server Attack

Without DHCP Snooping, any host on the VLAN can run a DHCP server. When a client broadcasts a DHCP Discover, whichever server responds first wins. An attacker runs a rogue DHCP server that responds faster than the legitimate server, assigning itself as the default gateway — all client traffic is then routed through the attacker's machine (man-in-the-middle):

  Without DHCP Snooping:
  Client: DHCP Discover (broadcast) ──► ALL ports
                                         ├──► Legitimate DHCP Server
                                         └──► Rogue DHCP Server (attacker)
  Both respond with DHCP Offer — client accepts the first one
  Rogue server assigns: gateway = 192.168.10.99 (attacker's IP)
  All client traffic now routes through attacker

  With DHCP Snooping:
  Client: DHCP Discover (broadcast) ──► Switch (DHCP Snooping active)
                                         ├──► TRUSTED port (uplink to real server) ──► DHCP Offer FORWARDED
                                         └──► UNTRUSTED port (rogue server)        ──► DHCP Offer DROPPED
  Only legitimate server's offer reaches the client

Trusted vs Untrusted Ports

Port Type	DHCP Packets Allowed	Typical Assignment	Default?
Trusted	All DHCP messages — Discover, Offer, Request, Ack, NAK, Release	Uplinks to legitimate DHCP servers, uplinks to other switches, router ports	No — must be explicitly configured
Untrusted	Only client messages — Discover and Request (sent by clients)	All access ports facing end hosts — PCs, printers, phones, IoT	Yes — all ports are untrusted by default

All ports are untrusted by default when DHCP Snooping is enabled. This includes uplinks to legitimate DHCP servers and inter-switch links. If you enable DHCP Snooping globally without marking uplinks as trusted, legitimate DHCP Offers from the server are dropped — clients stop receiving IP addresses. Always mark uplink ports as trusted immediately after enabling DHCP Snooping.

The DHCP Snooping Binding Table

As clients receive DHCP leases through trusted paths, DHCP Snooping records each binding in a table. This table is the foundation for DAI and other Layer 2 security features:

Field	Stored Value	Used By
MAC address	Client's MAC as seen in DHCP request	DAI — validates ARP replies; Port Security — optional correlation
IP address	Assigned IP from legitimate DHCP Ack	DAI — confirms the IP-to-MAC mapping is legitimate
VLAN	VLAN the client is on	Scopes the binding to the correct VLAN — prevents cross-VLAN spoofing
Port	Switch port the client is connected to	DAI and IP Source Guard — validates that traffic from an IP arrives on the correct port. See also Port Security
Lease time	Remaining lease duration	Automatically removes expired entries — binding table stays current

2. Dynamic ARP Inspection — Core Concepts

The ARP Spoofing Attack

ARP has no authentication — any host can broadcast an ARP reply claiming any IP-to-MAC mapping, even without receiving an ARP request. This gratuitous ARP overwrites the ARP caches of all hosts on the segment, redirecting traffic:

  Without DAI:
  Attacker broadcasts: "192.168.10.1 (gateway) is at MAC aa:bb:cc:dd:ee:ff (attacker's MAC)"
  All hosts update their ARP cache: gateway = aa:bb:cc:dd:ee:ff
  All traffic to the gateway is now sent to the attacker (man-in-the-middle)
  Attacker forwards to real gateway — victim never notices

  With DAI:
  Attacker sends ARP reply: "192.168.10.1 is at aa:bb:cc:dd:ee:ff"
  DAI checks DHCP Snooping binding table:
    192.168.10.1 is a STATIC address (not in binding table) — use ARP ACL
    OR
    Binding shows: 192.168.10.50 assigned to MAC 00:1a:2b:3c:4d:5e on Fa0/3
    ARP reply claims 192.168.10.50 is at aa:bb:cc:dd:ee:ff — MISMATCH
  DAI drops the forged ARP reply — ARP cache is never poisoned

DAI Validation Checks

Validation Type	Command	What It Checks	Drops If...
Binding table check	Enabled by default with DAI	ARP packet's sender IP and MAC match a DHCP Snooping binding entry	IP-MAC pair not in binding table (for untrusted ports)
Source MAC	`ip arp inspection validate src-mac`	Ethernet frame source MAC matches ARP sender MAC field	Frame MAC differs from ARP sender MAC — forged inner header
Destination MAC	`ip arp inspection validate dst-mac`	For ARP replies: Ethernet destination MAC matches ARP target MAC	Destination MAC mismatch in ARP reply
IP address	`ip arp inspection validate ip`	ARP sender/target IP is valid — not 0.0.0.0, 255.255.255.255, or multicast	Invalid IP in ARP payload

DAI Trusted vs Untrusted Ports

Like DHCP Snooping, DAI has trusted and untrusted ports. Trusted ports bypass DAI validation — untrusted ports have all ARP packets checked:

Port Type	ARP Validation	Assign To
Trusted (DAI)	ARP packets forwarded without validation	Uplinks between switches (trunk ports), router ports — devices that hold static IPs not in the binding table
Untrusted (DAI)	Every ARP packet validated against binding table or ARP ACL	All access ports facing end hosts — default for all ports

3. Lab Topology & Scenario

NetsTuts_SW1 is a Cisco Catalyst access layer switch. The legitimate DHCP server is on a dedicated server port (Fa0/1). The uplink to the distribution switch (Gi0/1) connects to NetsTuts_SW2. All client ports (Fa0/2–Fa0/24) face end hosts and are untrusted by default. An attacker host on Fa0/10 will attempt both a rogue DHCP attack and ARP spoofing — both blocked by the completed configuration:

                        [DHCP Server: 192.168.10.200]
                              |
                           Fa0/1 (TRUSTED — DHCP + DAI)
                 ┌────────────────────────────────────┐
                 │           NetsTuts_SW1              │
                 │   VLAN 10: 192.168.10.0/24          │
                 │   ip dhcp snooping vlan 10          │
                 │   ip arp inspection vlan 10         │
                 └────────────────────────────────────┘
          Fa0/2  |      Fa0/5  |   Fa0/10  |      Gi0/1 |
         [PC1]  [PC2]  [PC3]  [Attacker]       [SW2 uplink]
       .10.10  .10.11  .10.12   .10.99         TRUSTED port

  Trust assignments:
  Fa0/1  (DHCP Server) — TRUSTED for DHCP Snooping + DAI
  Gi0/1  (Uplink SW2)  — TRUSTED for DHCP Snooping + DAI
  Fa0/2–Fa0/24         — UNTRUSTED (default) for both features

Port	Connected To	DHCP Snooping Trust	DAI Trust	Reason
Fa0/1	DHCP Server (192.168.10.200)	Trusted	Trusted	Legitimate DHCP server must send Offers and Acks — needs trust for both
Gi0/1	Uplink to SW2	Trusted	Trusted	Inter-switch links forward all DHCP and ARP from many VLANs — must be trusted
Fa0/2–Fa0/24	End hosts / clients	Untrusted (default)	Untrusted (default)	No client should send DHCP Offers or forged ARP replies

4. Step 1 — Configure DHCP Snooping

NetsTuts_SW1>en
NetsTuts_SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Step 1a: Enable DHCP Snooping globally ───────────────
NetsTuts_SW1(config)#ip dhcp snooping

! ── Step 1b: Enable for VLAN 10 ──────────────────────────
! ── (DHCP Snooping must be enabled per-VLAN) ─────────────
NetsTuts_SW1(config)#ip dhcp snooping vlan 10

! ── Step 1c: Disable Option 82 insertion ─────────────────
! ── Option 82 adds relay info — causes server to reject ──
! ── packets if server is not configured to accept it ──────
NetsTuts_SW1(config)#no ip dhcp snooping information option

! ── Step 1d: Mark uplink/server ports as trusted ─────────
NetsTuts_SW1(config)#interface FastEthernet0/1
NetsTuts_SW1(config-if)#ip dhcp snooping trust
NetsTuts_SW1(config-if)#exit

NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#ip dhcp snooping trust
NetsTuts_SW1(config-if)#exit

Four commands enable full DHCP Snooping. ip dhcp snooping activates the feature globally but does not yet filter any VLAN. ip dhcp snooping vlan 10 activates filtering on VLAN 10 specifically — DHCP Snooping can be enabled on multiple VLANs simultaneously: ip dhcp snooping vlan 10,20,30 or ip dhcp snooping vlan 10-30.

no ip dhcp snooping
    information option

disables Option 82 insertion — without this, the switch adds relay agent information to DHCP packets, which many DHCP servers reject unless specifically configured to accept it. See DHCP Relay Agent for how Option 82 is used in legitimate relay scenarios. Trust assignments must be made immediately after — before any clients attempt to get DHCP leases.

DHCP Snooping Rate Limiting

! ── Rate-limit DHCP packets on untrusted ports ───────────
! ── Prevents DHCP starvation attacks (filling lease pool) ─
NetsTuts_SW1(config)#interface range FastEthernet0/2 - 24
NetsTuts_SW1(config-if-range)#ip dhcp snooping limit rate 15
NetsTuts_SW1(config-if-range)#exit

Rate limiting caps the number of DHCP packets per second allowed from each untrusted port. A DHCP starvation attack sends thousands of DISCOVER messages with spoofed source MACs to exhaust the DHCP server's address pool, leaving no addresses for legitimate clients. 15 packets/second is a reasonable limit — a legitimate host sends one DISCOVER, waits for an Offer, then sends one Request — well below 15/second. If the limit is exceeded, the port is placed in the errdisable state.

5. Step 2 — Configure Dynamic ARP Inspection (DAI)

! ── Step 2a: Enable DAI on VLAN 10 ──────────────────────
NetsTuts_SW1(config)#ip arp inspection vlan 10

! ── Step 2b: Mark uplink/server ports trusted for DAI ────
! ── (Trust is per-feature — set for both DHCP and DAI) ───
NetsTuts_SW1(config)#interface FastEthernet0/1
NetsTuts_SW1(config-if)#ip arp inspection trust
NetsTuts_SW1(config-if)#exit

NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#ip arp inspection trust
NetsTuts_SW1(config-if)#exit

! ── Step 2c: Enable additional DAI validation checks ─────
NetsTuts_SW1(config)#ip arp inspection validate src-mac dst-mac ip

NetsTuts_SW1(config)#end
NetsTuts_SW1#wr
Building configuration...
[OK]

DAI is enabled per-VLAN with ip arp inspection vlan 10. Trust must be set independently for both DHCP Snooping and DAI — the ip dhcp snooping trust command on a port does not automatically make it trusted for DAI, and vice versa. The three additional validation options (src-mac dst-mac ip) can be combined on a single line. The order in the command does not matter — IOS validates all specified criteria simultaneously.

ARP ACL for Static IP Hosts (DAI for Non-DHCP Devices)

! ── Hosts with static IPs are not in DHCP Snooping table ─
! ── DAI would drop their ARP packets without an ARP ACL ──
NetsTuts_SW1(config)#arp access-list STATIC-HOSTS
NetsTuts_SW1(config-arp-nacl)#permit ip host 192.168.10.200 mac host 0050.56a1.b2c3
NetsTuts_SW1(config-arp-nacl)#permit ip host 192.168.10.1 mac host 0050.56a1.0001
NetsTuts_SW1(config-arp-nacl)#exit

! ── Apply ARP ACL to VLAN 10 — checked before binding table
NetsTuts_SW1(config)#ip arp inspection filter STATIC-HOSTS vlan 10

This is a critical consideration for real deployments. The DHCP Snooping binding table only contains entries for hosts that received their IP via DHCP. Devices with static IPs — servers, printers, the default gateway on the router — have no entry in the binding table. Without an ARP ACL for these devices, DAI drops all their ARP replies as "no matching entry." The arp access-list defines explicit IP-to-MAC mappings for static hosts. When

ip arp inspection
    filter STATIC-HOSTS vlan 10

is applied, ARP packets are checked against this ACL first — if a match is found, the packet is forwarded or dropped per the ACL action without consulting the binding table.

6. Step 3 — DAI Rate Limiting

An attacker can flood the switch with forged ARP packets to overwhelm the DAI validation engine. DAI rate limiting on untrusted ports caps the ARP packet rate — if the limit is exceeded, the port is placed in the errdisable state:

! ── Rate-limit ARP packets on untrusted ports ────────────
NetsTuts_SW1(config)#interface range FastEthernet0/2 - 24
NetsTuts_SW1(config-if-range)#ip arp inspection limit rate 100
NetsTuts_SW1(config-if-range)#exit

! ── Rate-limit on trusted ports (lower risk but best practice)
NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#ip arp inspection limit rate 1000 burst interval 1
NetsTuts_SW1(config-if)#exit

The default DAI rate limit is 100 ARP packets/second on untrusted ports. The burst interval parameter (default: 1 second) defines the measurement window. rate 1000 burst interval 1 on the uplink allows up to 1000 ARP packets per second — appropriate for a trunk carrying many VLANs. If the rate is exceeded, errdisable activates on the port. Configure errdisable recovery cause arp-inspection for automatic recovery.

Errdisable Recovery for DAI

! ── Auto-recover ports errdisabled by DAI rate-limit ─────
NetsTuts_SW1(config)#errdisable recovery cause arp-inspection
NetsTuts_SW1(config)#errdisable recovery cause dhcp-rate-limit
NetsTuts_SW1(config)#errdisable recovery interval 30

Without errdisable recovery, a port placed into errdisable state by ARP or DHCP rate limiting requires manual intervention: shutdown then no shutdown on the interface. With recovery configured, the switch automatically brings the port back up after 30 seconds — useful for client ports where a legitimate host may have briefly exceeded the rate (e.g., booting after power cut and replaying cached ARPs). See also PortFast & BPDU Guard for another errdisable cause on access ports.

7. Verification

show ip dhcp snooping

NetsTuts_SW1#show ip dhcp snooping
Switch DHCP snooping is enabled
Switch DHCP snooping is configured on following VLANs:
10
Switch DHCP snooping is operational on following VLANs:
10
Switch DHCP snooping is NOT configured on following VLANs:
20,30

DHCP snooping is configured on 1 interface:
  Interface     Trusted   Allow option   Rate limit (pps)
  ---------     -------   ------------   ----------------
  Fa0/1         yes       yes            unlimited
  Gi0/1         yes       yes            unlimited

"Switch DHCP snooping is enabled" confirms global activation. "Operational on VLANs: 10" confirms VLAN 10 is actively snooping. Fa0/1 and Gi0/1 show "Trusted: yes" — these are the only ports where DHCP Offers and Acks are forwarded. All other ports not listed here are untrusted by default. If a port that should be trusted does not appear here, add ip dhcp snooping trust to that interface.

show ip dhcp snooping binding

NetsTuts_SW1#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:1A:2B:3C:4D:5E   192.168.10.10    85921       dhcp-snooping  10    FastEthernet0/2
00:2C:3D:4E:5F:6A   192.168.10.11    85900       dhcp-snooping  10    FastEthernet0/5
00:3E:4F:50:61:7B   192.168.10.12    85888       dhcp-snooping  10    FastEthernet0/3
Total number of bindings: 3

The binding table is the central database for Layer 2 security. Each entry records: the client's MAC address, the IP address assigned by the legitimate DHCP server, the remaining lease time in seconds, the VLAN, and the physical port the client is connected to. Type "dhcp-snooping" means the entry was dynamically created by watching a DHCP exchange. Entries expire when the lease expires. DAI uses exactly this table — if an ARP reply claims 192.168.10.10 is at a different MAC than 00:1A:2B:3C:4D:5E, DAI drops it.

show ip arp inspection

NetsTuts_SW1#show ip arp inspection
 Source Mac Validation      : Enabled
 Destination Mac Validation : Enabled
 IP Address Validation      : Enabled

 Vlan    Configuration    Operation   ACL Match          Static ACL
 ----    -------------    ---------   ---------          ----------
   10    Enabled          Active      STATIC-HOSTS       No

 Vlan    ACL Logging      DHCP Logging      Probe Logging
 ----    -----------      ------------      -------------
   10    Deny             Deny              Off

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
   10           1847              8              0              8

"Enabled / Active" on VLAN 10 confirms DAI is operational. The validation lines at the top confirm all three additional checks (src-mac, dst-mac, ip) are active. The statistics at the bottom are the most valuable diagnostic data: 1847 forwarded (legitimate ARP packets allowed) vs 8 dropped (forged ARP packets caught and discarded). "ACL Drops: 8" means 8 packets were dropped because they matched a deny in the ARP ACL (or had no match in the binding table). "DHCP Drops: 0" means no packets were dropped specifically due to DHCP lease violations.

show ip arp inspection statistics vlan 10

NetsTuts_SW1#show ip arp inspection statistics vlan 10
 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
   10           1847              8              0              8

 Vlan      ACL Permits      DHCP Permits    Source Mac Failures
 ----      -----------      ------------    -------------------
   10              4              1843                        3

 Vlan      Dest Mac Failures    IP Val Failures    Req Forwarded    Res Forwarded
 ----      -----------------    ---------------    -------------    -------------
   10                      2                  3             1124              723

The extended statistics reveal which specific validation check failed. "Source Mac Failures: 3" — 3 ARP packets where the Ethernet frame source MAC differed from the ARP sender MAC field (forged inner header). "Dest Mac Failures: 2" — 2 ARP replies where the destination MAC was inconsistent. "IP Val Failures: 3" — 3 packets with invalid IP addresses (broadcast, multicast, or 0.0.0.0) in the ARP payload. These detailed counters identify which attack method the attacker is using.

show ip arp inspection interfaces

NetsTuts_SW1#show ip arp inspection interfaces
 Interface        Trust State     Rate (pps)    Burst Interval
 ---------------  -----------     ----------    --------------
 Fa0/1            Trusted              None         N/A
 Fa0/2            Untrusted             100           1
 Fa0/3            Untrusted             100           1
 Fa0/5            Untrusted             100           1
 Fa0/10           Untrusted             100           1
 Gi0/1            Trusted              1000           1

Verification Command Summary

Command	What It Shows	Primary Use
`show ip dhcp snooping`	Global status, active VLANs, trusted port list, rate limits	Confirm DHCP Snooping is active on the correct VLANs and trusted ports are correct
`show ip dhcp snooping binding`	Full binding table — MAC, IP, VLAN, port, lease time per client	Verify clients are getting leases and entries are being recorded — DAI depends on this table
`show ip arp inspection`	DAI status per VLAN, validation checks active, forwarded/dropped packet counts	Confirm DAI is active and check cumulative drop counts for evidence of attack activity
`show ip arp inspection statistics vlan [n]`	Detailed per-VLAN drop breakdown — which validation check failed and how many times	Post-incident analysis — identify which specific ARP attack type is occurring
`show ip arp inspection interfaces`	Per-interface trust state and rate limit configuration	Verify trust assignments — confirm no untrusted port is accidentally trusted
`show errdisable recovery`	Errdisable recovery settings — which causes are enabled and recovery interval	Confirm auto-recovery is configured for arp-inspection and dhcp-rate-limit causes

8. Troubleshooting DHCP Snooping & DAI Issues

Problem	Symptom	Cause	Fix
Clients not getting DHCP addresses after enabling snooping	DHCP requests from clients time out — no IP assigned. `show ip dhcp snooping binding` shows no entries	Uplink to DHCP server or inter-switch uplink is not marked trusted — DHCP Offers and Acks from the server are being dropped by the switch	Mark the server-facing port and uplink trusted: `interface Fa0/1` then `ip dhcp snooping trust`. Verify with `show ip dhcp snooping` — confirm the port appears in the trusted list.
DHCP server rejects packets after snooping enabled	Clients send DHCP Discover but server logs show malformed packets or Option 82 errors	Option 82 (DHCP relay information) is being inserted by the switch. The DHCP server is not configured to accept or ignore relay information from the switch	Disable Option 82 insertion: `no ip dhcp snooping information option`. Alternatively configure the DHCP server to accept Option 82 packets. This is a very common issue in labs where the server is on the same VLAN as clients.
DAI drops legitimate ARP from static-IP host	Static-IP server or router cannot be reached — `show ip arp inspection statistics` shows its ARP packets as dropped	The host uses a static IP not assigned by DHCP — no entry in the DHCP Snooping binding table. DAI finds no matching binding and drops the ARP	Create an ARP ACL for the static host: `arp access-list STATIC-HOSTS` then `permit ip host [IP] mac host [MAC]`. Apply to the VLAN: `ip arp inspection filter STATIC-HOSTS vlan 10`. Alternatively trust the port facing the static device (less secure).
Port errdisabled due to DHCP rate limit	A client port is errdisabled — `show interfaces Fa0/x` shows "err-disabled"	The port exceeded the configured DHCP rate limit — a legitimate host sending excessive DHCP packets (booting after power cut, DHCP client bug) or an actual DHCP starvation attack	Investigate cause: check if it is a legitimate host (`show ip dhcp snooping binding`). If legitimate, increase the rate limit or enable recovery: `errdisable recovery cause dhcp-rate-limit`. Re-enable the port: `shutdown` then `no shutdown`.
DAI drops ARP from a DHCP client that recently renewed	Intermittent connectivity loss for DHCP clients — DAI drops their ARP even though they have a valid lease	DHCP lease was renewed and the IP address changed, but the old binding table entry has not been cleared yet. A race condition where the new IP is not yet in the binding table when an ARP is sent	Check `show ip dhcp snooping binding` — verify the client's current IP matches the binding. If the binding is stale, clear it: `clear ip dhcp snooping binding`. Ensure the DHCP server sends ACKs through the trusted port so bindings update correctly.
DHCP Snooping binding table not persisting across reload	After switch reload, all clients must re-DHCP — the binding table is empty and DAI drops all ARP until leases are renewed	The binding table is stored in RAM by default — it is lost on reload. Clients retain their leased IPs but the switch has no record of the assignments	Configure binding table persistence to flash: `ip dhcp snooping database flash:snooping.db`. This writes the table to flash storage periodically so it survives reloads. Set the write interval: `ip dhcp snooping database write-delay 300`.

Key Points & Exam Tips

DHCP Snooping prevents rogue DHCP servers by classifying switch ports as trusted (forwards all DHCP messages) or untrusted (drops DHCP Offers and Acks — only permits client-originated Discover and Request). All ports are untrusted by default.
DHCP Snooping must be enabled in two places: ip dhcp snooping (globally) AND ip dhcp snooping vlan [n] (per VLAN). The global command alone does not activate filtering on any VLAN.
no ip dhcp snooping information option disables Option 82 insertion — required when the DHCP server is on the same VLAN as clients and not configured to accept relay agent information.
The DHCP Snooping binding table (show ip dhcp snooping binding) records MAC, IP, VLAN, port, and lease time for every client that received a DHCP lease through a trusted path. DAI uses this table as its validation source. This is distinct from the switch's CAM/MAC address table, which maps MACs to ports for forwarding decisions.
Dynamic ARP Inspection validates every ARP packet on untrusted ports against the DHCP Snooping binding table. If the IP-to-MAC mapping does not match a binding entry, the ARP is dropped — preventing ARP spoofing and man-in-the-middle attacks.
DAI trusted/untrusted ports are independent of DHCP Snooping trusted/untrusted ports. Both must be set separately — ip dhcp snooping trust and ip arp inspection trust are different commands on the same interface.
Static-IP hosts (servers, gateways, printers) have no DHCP binding entry — DAI drops their ARP without an ARP ACL. Use arp access-list to define static IP-to-MAC mappings and apply with ip arp inspection filter [ACL] vlan [n].
DAI additional validation (ip arp inspection validate src-mac dst-mac ip) checks Ethernet frame MAC consistency and rejects ARP packets with invalid IPs (broadcast, multicast, 0.0.0.0). All three can be combined in one command.
Both features support rate limiting to prevent flooding attacks: ip dhcp snooping limit rate [pps] and ip arp inspection limit rate [pps]. Exceeding the limit puts the port in errdisable state — configure errdisable recovery for automatic recovery.
On the CCNA exam: know the trusted/untrusted port distinction, what DHCP message types untrusted ports block (Offer and Ack), what the binding table contains, how DAI uses it, and what the no ip dhcp snooping information option command does. Also review 802.1X Port Authentication as another Layer 2 access security mechanism, and Spanning Tree which interacts with the same physical port infrastructure.

Next Steps: With DHCP Snooping and DAI protecting Layer 2, extend security to the port level with Port Security and Sticky MAC to limit which MAC addresses can connect to each access port. For monitoring suspicious traffic caught by DAI, configure SPAN/RSPAN port mirroring to capture and analyse dropped frames. For VLAN configuration that DHCP Snooping operates on, revisit VLAN Creation and Management. For the DHCP server being protected by snooping, see DHCP Server Configuration.

TEST WHAT YOU LEARNED

1. After enabling `ip dhcp snooping` and `ip dhcp snooping vlan 10`, clients on VLAN 10 immediately stop receiving IP addresses. The DHCP server is connected to Fa0/1. What is the most likely cause?

A. DHCP Snooping requires a reboot to take effect — clients will get addresses after the switch is reloaded B. The DHCP server's port (Fa0/1) is in the wrong VLAN — move it to VLAN 10 C. Fa0/1 (DHCP server port) is untrusted by default — the switch is dropping DHCP Offers and Acks from the legitimate server. Fix: interface Fa0/1 then ip dhcp snooping trust D. DHCP Snooping blocks all DHCP traffic including client Discover messages until a static binding is manually entered

Correct answer is C. This is the most common DHCP Snooping deployment mistake. All ports are untrusted by default when DHCP Snooping is enabled — including the port facing the legitimate DHCP server. Untrusted ports drop DHCP Offer and Ack messages (server-originated traffic). The server's Offers are silently dropped before reaching clients, so clients never receive IP address assignments. The client's Discover and Request messages are still forwarded (these are client-originated, which untrusted ports allow). The fix is immediate: mark the DHCP server port trusted. In a real deployment, you should pre-configure trust assignments before enabling DHCP Snooping to avoid any service interruption.

2. Why does DAI drop ARP packets from a server with a static IP address even though DHCP Snooping and DAI are both correctly configured?

A. The server was assigned its IP statically — it never went through a DHCP exchange, so DHCP Snooping never created a binding table entry for it. DAI validates ARP packets against the binding table. With no entry for the server's IP-MAC pair, DAI has no validation data and drops the ARP. Fix: create an ARP ACL with the server's static IP-to-MAC mapping and apply it to the VLAN B. Static IP hosts must renew their address via DHCP to get a binding entry — configure the server for DHCP instead C. DAI requires all ARP packets to originate from trusted ports — servers should have their ports marked trusted D. ARP packets from servers are always dropped by DAI — servers should use proxy ARP through the router instead

Correct answer is A. The DHCP Snooping binding table is populated only by watching DHCP exchanges — specifically by recording the IP address from the DHCP Ack and the MAC from the DHCP Request/Discover. A device with a static IP never participates in a DHCP exchange, so it never gets a binding table entry. When that device sends an ARP reply, DAI looks up the IP-MAC pair in the binding table, finds no entry, and drops the packet. The solution is an ARP ACL that explicitly permits the known static IP-to-MAC mapping. Alternatively, marking the server's port as trusted for DAI bypasses validation entirely on that port — less secure since any device on that port is trusted.

3. What is the purpose of `no ip dhcp snooping information option` and when is it required?

A. It disables the DHCP Snooping binding table — use it when DAI is not needed B. It prevents DHCP Snooping from logging to syslog — reduces log volume C. It disables trusted port verification — allows DHCP Offers from any port D. It prevents the switch from inserting DHCP Option 82 (relay agent information) into DHCP packets. When a switch enables DHCP Snooping, it adds Option 82 by default. Many DHCP servers reject packets containing relay information if not configured to accept it — clients time out. This command is required when the DHCP server is on the same segment and not configured for relay agent support

Correct answer is D. DHCP Option 82 (Relay Agent Information) is a field that DHCP relay agents insert to identify the circuit (port) and agent (switch) that forwarded the request. Cisco switches with DHCP Snooping enabled insert Option 82 into DHCP packets by default, even when acting as a switch (not a relay agent). Many DHCP server implementations — particularly Windows DHCP Server and simple ISC DHCP configurations — reject DHCP Discover packets containing Option 82 unless explicitly configured to accept them. The result: clients send Discovers, the switch inserts Option 82, the server drops the packets, clients get no response. The fix is no ip dhcp snooping information option to disable insertion. In environments with a proper DHCP relay (ip helper-address) on the router, Option 82 handling is managed by the relay configuration instead.

4. An administrator configures `ip dhcp snooping trust` on Fa0/1. Does this also make Fa0/1 trusted for DAI?

A. Yes — DHCP Snooping trust and DAI trust share the same configuration. One command sets both B. No — DHCP Snooping trust and DAI trust are independent. ip dhcp snooping trust only affects DHCP packet handling. A separate ip arp inspection trust command on the same interface is required for DAI to trust that port C. Yes — all trusted ports for one Layer 2 security feature are automatically trusted for all others D. No — but DAI automatically trusts all ports facing DHCP servers, regardless of configuration

Correct answer is B. DHCP Snooping and DAI are independent features with independent trust configurations. ip dhcp snooping trust tells the switch to forward DHCP Offer and Ack messages received on that port. ip arp inspection trust tells the switch to bypass ARP validation for packets received on that port. They share the same concept (trusted/untrusted) but are configured separately and serve different purposes. In practice, the same physical ports often need to be trusted for both features — the uplink to the distribution switch and the DHCP server port. But both commands must be explicitly entered on each interface. Forgetting to set DAI trust on the uplink while correctly setting DHCP Snooping trust causes ARP from inter-switch traffic to be dropped by DAI.

5. `show ip arp inspection statistics vlan 10` shows "Source Mac Failures: 15". What does this indicate?

A. 15 ARP packets were dropped because the sending host's MAC was not in the DHCP Snooping binding table B. 15 ARP requests had invalid source IP addresses — the IP validation check failed C. 15 ARP packets arrived on trusted ports with unexpected source MACs D. 15 ARP packets were dropped because the source MAC in the Ethernet frame header did not match the sender MAC field in the ARP payload itself — indicating a forged inner header. This is a specific attack technique where the outer Ethernet source MAC is spoofed differently from the ARP sender MAC. Requires ip arp inspection validate src-mac to catch

Correct answer is D. The "Source Mac Failures" counter specifically tracks the src-mac validation check — comparing the Ethernet frame's source MAC address field against the ARP sender MAC address field inside the ARP payload. In a legitimate ARP packet, these two MAC addresses should be identical. An attacker crafting forged ARP packets may set the outer Ethernet source MAC to one value (perhaps a legitimate MAC to avoid basic filtering) while the ARP sender MAC inside the payload is different (the spoofed value for poisoning caches). The ip arp inspection validate src-mac check catches this inconsistency and drops the packet, incrementing this counter. This is distinct from a binding table miss, which increments "DHCP Drops" or "ACL Drops."

6. A new switch (SW3) is added to the network and connected to SW1's Gi0/2 port. Clients on SW3 suddenly stop receiving DHCP addresses. What must be done on SW1?

A. Mark SW1's Gi0/2 (uplink to SW3) as trusted for DHCP Snooping: interface Gi0/2 then ip dhcp snooping trust. DHCP Discover messages from SW3's clients traverse the inter-switch link — if Gi0/2 is untrusted, SW1 would not drop Discovers (client messages are allowed), but DHCP Offers and Acks from the server traveling back toward SW3 through Gi0/2 outbound would not be affected by snooping on ingress. Actually the critical issue is DHCP Offers coming from the server back out toward SW3 via Gi0/2 — if SW3 is forwarding DHCP packets through this link, the uplink must be trusted B. Disable DHCP Snooping on SW1 — it does not support multi-switch environments C. Configure SW3 as a DHCP relay agent pointing to SW1 D. SW3 clients must be on a different VLAN — DHCP Snooping cannot span multiple switches on the same VLAN

Correct answer is A. When DHCP Snooping is active and a new inter-switch link is added, the new uplink port on SW1 must be marked trusted. In this scenario, SW3's clients send DHCP Discovers that traverse Gi0/2 into SW1. SW1 forwards the Discovers toward the trusted DHCP server (Fa0/1). The server responds with a DHCP Offer directed back through SW1 toward SW3. When the Offer arrives at SW1's trusted port (Fa0/1) and is forwarded toward Gi0/2 — the outbound direction on Gi0/2 is not an issue. However, if SW3 itself also has a DHCP Snooping-like function or if the Offer arrives at Gi0/2 inbound for any reason, Gi0/2 must be trusted. Most commonly, the Offers come from the server through Fa0/1 (trusted) and are forwarded normally. The issue is usually that SW3 may be inserting Option 82 or SW1 needs to trust the inter-switch link for DAI as well.

7. What happens to a host's connectivity when a DHCP Snooping rate limit is exceeded on its access port?

A. Only DHCP packets are dropped — all other traffic (data, ARP) continues normally B. The switch rate-limits DHCP to the configured maximum — excess packets are queued until the rate drops C. The entire port is placed into errdisable state — ALL traffic stops on that port, not just DHCP. The host loses complete connectivity. Manual recovery requires shutdown then no shutdown on the interface, or automatic recovery if errdisable recovery cause dhcp-rate-limit is configured D. Only the offending MAC address is blocked — other hosts on the same port (through a downstream hub) continue normally

Correct answer is C. DHCP Snooping rate limiting uses the errdisable mechanism — when the configured packets-per-second threshold is exceeded on an untrusted port, the switch shuts down the entire port interface and sets it to errdisable state. This is not a selective DHCP-only block — all traffic ceases on that port. The reasoning is that a port generating more than the configured DHCP rate is likely under attack (DHCP starvation), and the appropriate response is to quarantine the port entirely rather than just dropping excess DHCP while continuing to pass attack traffic. Recovery requires either manual port cycling (shutdown/no shutdown) or automatic recovery via errdisable recovery cause dhcp-rate-limit with a configured recovery interval.

8. How does DAI protect against ARP spoofing, and what is the source of truth it uses for validation?

A. DAI checks ARP packets against the MAC address table — if the source MAC is not in the CAM table the ARP is dropped B. DAI intercepts every ARP packet on untrusted ports and compares the sender's IP-to-MAC mapping against the DHCP Snooping binding table. If the claimed mapping (e.g., "192.168.10.10 is at aa:bb:cc") does not match the binding table entry for that IP (which shows the legitimate MAC), DAI drops the packet before it can poison any host's ARP cache. The binding table — populated by legitimate DHCP exchanges — is the source of truth C. DAI uses the routing table to verify ARP packets — only IPs in the routing table are permitted in ARP replies D. DAI compares ARP packets against the STP topology — ports not in forwarding state have their ARP dropped

Correct answer is B. DAI's validation logic is straightforward: when an ARP packet arrives on an untrusted port, DAI extracts the sender IP and sender MAC from the ARP payload. It then looks up the sender IP in the DHCP Snooping binding table. If the binding table shows that IP was legitimately assigned to a different MAC address, DAI drops the ARP packet — the claimed mapping is false. If no binding entry exists for that IP at all, DAI also drops it (unless an ARP ACL provides a permit entry). This makes the DHCP Snooping binding table the foundational dependency — DAI cannot operate correctly without accurate binding data. This is why both features must be configured together and why static-IP hosts need explicit ARP ACL entries.

9. After a switch reload, the DHCP Snooping binding table is empty even though all clients still have their DHCP leases. What is the consequence and how is it prevented?

A. No consequence — DAI rebuilds the binding table by scanning the ARP cache on reload B. Clients lose their DHCP leases — the switch cancels all leases it cannot find in the binding table C. DHCP Snooping stops filtering — it requires a full binding table to operate and enters a bypass mode when empty D. DAI drops all ARP packets from clients until they renew their DHCP leases — because the binding table is empty, no ARP passes DAI validation. Clients experience connectivity loss until their DHCP client renews and repopulates the binding table. Prevention: configure binding persistence to flash storage with ip dhcp snooping database flash:snooping.db

Correct answer is D. The DHCP Snooping binding table is stored in RAM by default — it is lost on every reload. After a reload, the switch has no binding entries. The clients still have their IP addresses (leased from the DHCP server, stored on the client) and are sending ARP traffic normally. But DAI finds no binding table entries to validate against and drops every ARP packet from every client. All hosts appear unreachable to each other. The network recovers only as each client's DHCP lease renewal is processed by the switch, rebuilding the binding table entry by entry — this can take minutes in large networks. The prevention is ip dhcp snooping database flash:snooping.db which periodically writes the binding table to flash storage, so it is restored automatically on reload.

10. An ARP ACL is configured with `permit ip host 192.168.10.1 mac host 0050.56a1.0001` and applied to VLAN 10 with `ip arp inspection filter STATIC-HOSTS vlan 10`. An ARP packet arrives claiming 192.168.10.1 is at 0050.56a1.0001. What does DAI do, and in what order does it evaluate the ACL vs the binding table?

A. DAI checks the binding table first — since 192.168.10.1 has no DHCP binding, it drops the packet regardless of the ACL B. DAI checks the binding table and ACL simultaneously — both must permit the packet for it to be forwarded C. DAI checks the ARP ACL first — the packet matches the permit entry for 192.168.10.1 at 0050.56a1.0001. Because the ACL returns a permit match, DAI forwards the ARP without consulting the binding table. The ACL is evaluated before the binding table, and a match in the ACL is final D. DAI ignores the ACL for permit entries — only deny entries in the ARP ACL are enforced

Correct answer is C. When an ARP ACL is applied to a VLAN with ip arp inspection filter, DAI evaluates the ARP ACL before the DHCP Snooping binding table. The processing order is: (1) Check ARP ACL — if the IP-MAC pair matches a permit entry, forward immediately without checking the binding table. If it matches a deny entry, drop immediately. (2) If no ACL match (implicit deny or no ACL applied), check the DHCP Snooping binding table. This ordering allows the ARP ACL to serve as an authoritative override for static hosts that have no binding table entries. In this scenario, 192.168.10.1 at 0050.56a1.0001 matches the permit entry in STATIC-HOSTS — the ARP is forwarded immediately, solving the static-IP host problem without needing to trust the entire port.

Back to Home