I85PREP
⌘ K
JNCIS-ENT study materials
JNCIS-ENT study resources

DHCP Snooping and DAI Break a Working Access Layer

JNCIS-ENT · Put your knowledge to work in context.

All case studies

DHCP Snooping and DAI Break a Working Access Layer

An EX4300 access stack serves 200 users in VLAN 300 (10.30.0.0/23). The DHCP server is in the data center, several hops away, reachable across the trunk uplink ae0. A security hardening change window enabled DHCP snooping and dynamic ARP inspection for VLAN 300 on the stack, and enabled IP source guard on all user ports. Afterwards every user falls back to 169.254.x.x and show dhcp snooping binding is empty. Two network printers with statically assigned addresses 10.30.1.20 and 10.30.1.21 also stopped working, although they can still be pinged from the core. The uplink is a standard trunk with no security configuration applied to it, and VLAN 300 is present on both sides.

1. Why is the snooping binding table empty and why did every client lose its address?

Read the worked answer

DHCP snooping classifies every port as untrusted by default. On an untrusted port, server-to-client DHCP messages (OFFER, ACK, NAK) are dropped.

The DHCP server is not on this stack; its replies arrive over the trunk uplink ae0. Because ae0 was never marked trusted, every OFFER and ACK is discarded at ingress. Clients send DISCOVER, get nothing, retry, and eventually self-assign 169.254/16.

With no ACK ever accepted, no binding is created, so show dhcp snooping binding is empty - which is the diagnostic that separates this from a server problem or a VLAN/trunk problem. If the server were unreachable, the trunk counters would show no inbound DHCP; here the replies arrive and are dropped.

The fix is to mark the uplink trusted (in ELS, a dhcp-security group with the trusted override applied to the ae0 unit for VLAN 300), and only that uplink. Trusting the access ports would defeat the entire feature, since the attack it defends against is a rogue server plugged into a wall port.

2. Why did the two static-IP printers break, and what are the options to bring them back?

Read the worked answer

Dynamic ARP inspection validates every ARP packet against the DHCP snooping binding table. A host with a static address never did DHCP, so it has no binding. Its gratuitous ARP and its ARP replies are dropped as spoofed, which is why it can still be pinged from the core (the core's ARP entry may already exist and the request path differs) but cannot resolve anything itself.

Options, in order of preference:

  1. Create static snooping entries (static-ip mappings of IP to MAC to interface under the VLAN's dhcp-security configuration) for 10.30.1.20 and 10.30.1.21. This preserves DAI on those ports and is the least invasive.
  2. Move statically addressed devices into their own VLAN where DAI is not enabled. Clean separation, but adds a subnet.
  3. Disable DAI on the printer ports. Works, but silently punches a hole and tends to spread as more exceptions are added.

A plain static ARP entry on the router is not sufficient - the enforcement point is the access switch, and it consults its own snooping table, not the router's ARP cache.

3. You now have to roll the same hardening out to a second building. What ordering and verification would you insist on?

Read the worked answer

Order matters because DAI and IP source guard both read the snooping binding table; enabling them before the table is populated drops legitimate traffic wholesale.

Sequence:

  1. DHCP snooping only, on all access VLANs, with the uplink(s) trusted. Verify bindings appear for a sample of real clients before proceeding.
  2. Inventory what will never have a binding: printers, cameras, UPS management cards, hypervisor management IPs, any static host. Build static entries for them now, while DAI is still off and no one is impacted.
  3. Enable DAI, followed by IP source guard, port by port or floor by floor rather than building-wide.
  4. Verify with show dhcp snooping binding counts against expected lease counts, and check that ARP works from a static host and from a DHCP host.

Also confirm the snooping database survives a stack member reboot: on a Virtual Chassis the bindings should persist across member failover, or every client re-DHCPs during a switch reboot - a scheduled maintenance event that turns into an outage.