Arista EOS DHCP Snooping and IP Source Guard

Two attack patterns dominate access-layer incidents: someone plugs in a consumer router and starts handing out addresses, and someone statically configures an address that belongs to a server or gateway. DHCP snooping and IP source guard close both holes on Arista EOS with a small amount of configuration - provided you get the trusted/untrusted boundary right, because getting it wrong takes the whole VLAN off the air. This guide covers the configuration and, more importantly, the verification steps.

How the two features fit together

DHCP snooping builds a binding table of MAC, IP, VLAN, lease and port from observed DHCP transactions, and drops server replies arriving on untrusted ports. IP source guard then uses that table (or static bindings) to drop traffic from an access port whose source IP - and optionally MAC - does not match a binding. Enable snooping first; without it, IPSG has an empty table and blocks everything.

1. Enable DHCP snooping globally and per VLAN

switch(config)# ip dhcp snooping
switch(config)# ip dhcp snooping vlan 20,30
switch(config)# ip dhcp snooping information option

The information option inserts option 82 into client requests so the server can tell which port a request arrived on - required if your DHCP server logs or filters by relay information, and effectively required for IPSG with MAC filtering.

2. Mark the trusted boundary

! uplinks towards the real DHCP server or relay
switch(config)# interface Ethernet49/1
switch(config-if-Et49/1)# ip dhcp snooping trust

! access ports stay untrusted (the default)
switch(config)# interface Ethernet3
switch(config-if-Et3)# switchport access vlan 20
switch(config-if-Et3)# no shutdown

Only ports facing a legitimate DHCP server, relay, or upstream distribution switch are trusted. Trusting a port range "to make it work" is exactly how a rogue server stays undetected; if clients stop getting addresses after enabling snooping, the fix is finding the real server path, not trusting more ports.

3. Add IP source guard on access ports

switch(config-if-Et3)# ip verify source
! or verify both address and hardware address
switch(config-if-Et3)# ip verify source mac-check

# static hosts that never use DHCP (printers, cameras, controllers)
switch(config)# ip source binding 00:11:22:33:44:55 vlan 20 10.20.0.60 interface Ethernet3

When IPSG is enabled with no bindings and no DHCP traffic, the port stops forwarding ordinary IP traffic. That is by design, and it is why static hosts need explicit bindings and why you enable this on a pilot port before rolling it out.

4. Logging the events you care about

show logging | grep -i "dhcp snooping"
show ip dhcp snooping counters
show ip dhcp snooping binding

Rogue-server drops and rate-limit violations both appear in the log. Rate limiting client requests (ip dhcp snooping rate-limit) protects the CPU from a spoofing storm; set it well above normal boot-up behaviour, because a lab port with a switch behind it will legitimately generate a burst.

5. Verification checklist

1. show ip dhcp snooping - is snooping enabled, and for the right VLANs?
2. show ip dhcp snooping binding - bindings should appear within one lease cycle for every access port. An empty table means the trusted port is wrong or clients are using static addresses.
3. show ip verify source - per-port state should be active with a non-zero entry count.
4. Test from a spare port: attach a rogue DHCP server on an untrusted port and confirm its offers are dropped; then attempt a static IP that is not in the binding table and confirm traffic is blocked.
5. Check the ARP side too, since DHCP snooping on other vendors often pairs with dynamic ARP inspection; the configuration used for Arista EOS DHCP Relay: ip helper-address Configuration Guide is a useful comparison for organisations running mixed access layers.

Pitfalls

• Enabling snooping before defining the trusted uplink - clients silently lose addressing.
• Trunk ports carrying client VLANs - set per-VLAN trust explicitly; snooping state differs per VLAN on the same physical port.
• Virtualised hosts doing DHCP for guest VMs - the hypervisor's vSwitch may relay DHCP differently; give the host's uplink a considered trust decision rather than an automatic one.
• Relay and snooping interaction - if the switch is also the relay agent, revisit 华为交换机 DHCP Snooping 与 IPSG 配置：防私接与仿冒 to keep option 82 and the helper address consistent with the snooping configuration.

原文链接：https://www.arista.com/en/um-eos/eos-configuring-dhcp