Most organizations treat their access switches as “safe”: we’re inside the perimeter, the user is one of ours… In production, though, a meaningful chunk of the most expensive small problems start at L2: the wrong DHCP handing out leases, ARP spoofing siphoning traffic, static IP impersonation, and devices ending up in the wrong VLAN. In this post I’ll walk through the three guardrails I find most effective in the field, applied together:
- DHCP Snooping (verify where DHCP comes from + build a binding table)
- Dynamic ARP Inspection (DAI) (validate ARP packets against the binding table)
- IP Source Guard (bind source IP/MAC to a port so spoofing gets curtailed)
The threat model (real production scenarios)
Together, this trio significantly reduces the following problem classes:
- Rogue DHCP: a user spins up a “DHCP server” on their laptop and the devices around them grab the wrong gateway/DNS.
- ARP spoofing / MITM: a device on the same VLAN claims “I’m the gateway” and pulls traffic through itself.
- IP impersonation: someone uses another host’s IP via a static configuration (very common for printers, cameras, IoT).
These controls are not a substitute for NAC/802.1X. But in environments where NAC isn’t in place, or is being rolled out in stages, they shrink the blast radius at very low cost.
Design principles: secure default first, exceptions second
Three of the most important calls in practice:
- Trusted ports should only be the uplinks/relay paths going to the DHCP server (access ports never get marked trusted).
- Phased rollout: start with one building / one access stack; build an inventory of anomalies and exceptions.
- Evidence + runbook: keep a log/command set that lets you answer “who broke?” within ten minutes.
1) Turn on DHCP Snooping: build the binding table
DHCP Snooping does two things:
- It watches DHCP messages and verifies where server-side replies (OFFER/ACK) are coming from.
- It records the IP/MAC/port/VLAN tuple it learns from DHCP into a binding table.
Where to enable it?
- Per VLAN: only on the VLANs that actually use DHCP.
- Access layer: the switches end-user devices are connected to.
- Uplink: the port(s) toward the DHCP server/relay marked “trusted.”
Operational pre-checks
Before you turn it on, get clear answers to these three:
- Where do the DHCP servers live? (in-VLAN or centralized?)
- Is there a DHCP relay involved? (IP helper / relay agent)
- Do you have a list of devices using static IPs? (printers, cameras, PLCs, firewall management, etc.)
2) DAI: validate ARP packets against the binding
DAI’s superpower is this: ARP is a protocol that just declares “I am this IP,” and that openness makes it intrinsically spoofable. DAI cross-checks ARP packets against the DHCP Snooping binding table and drops anything that doesn’t line up.
Which VLANs?
- User VLANs and IoT VLANs: yes
- Server VLANs: it depends (most environments have less L2 there, with higher risk/complexity)
- Management VLAN: usually more controlled; still apply based on risk vs. operational tradeoff
Turning DAI on “strictly”
The safest activation order in the field:
- DHCP Snooping → let the binding table populate
- DAI → start in monitoring mode / low-impact thresholds
- Static-IP exceptions → ARP ACL or static binding
- Then tighten up
3) IP Source Guard: lock the IP/MAC leaving a port
IP Source Guard ties the source IP/MAC of traffic leaving a port to the binding. That severely restricts the “static IP impersonation” class of attack.
The two wins I see most in practice:
- IP collisions / impersonation in the same VLAN surface much faster
- ARP poisoning attempts become much less successful (paired with DAI)
Troubleshooting: ‘a device can’t get out to the internet’ — what do you check?
A simple flow for fast triage when something breaks in production:
- Did the device get DHCP, or is it static?
- Does the binding table show the IP/MAC/port?
- Are DAI drop counters going up?
- Which port is dropping traffic? (usually an access port)
Rollout plan: waves plus a rollback path
The rollout model I keep coming back to in the field:
- Canary: 1 access stack / 1 floor / 1 small building
- Exception inventory: static IPs, legacy devices, special DHCP requirements
- Waves: 2–3 stacks per wave (small enough that the team can roll back the same day if needed)
- Alarms: DAI drop rate, DHCP snooping violations, IP Source Guard violations
- Rollback: a quick disable procedure scoped to a VLAN/port
Closing: L2 protection isn’t “small” — it cuts incidents
DHCP Snooping + DAI + IP Source Guard together don’t solve every security problem at the org level. But when they’re rolled out properly, they bring two things at once: predictability and evidence. They make it harder for small mistakes inside the network to balloon into large outages, and they help you answer the “what happened?” question much faster during an incident.