Dynamic ARP Inspection: Configuration and Failure Scenarios - 夜莺博客

Dynamic ARP Inspection: Configuration and Failure Scenarios

ARP has no authentication. Any host on a Layer 2 segment can claim any IP address in an ARP reply, and every other host on the segment will believe it. That is enough to become the default gateway, to blackhole a server, or to mount a man-in-the-middle attack. Dynamic ARP Inspection is the control that stops it, and it is also one of the most common causes of self-inflicted access-layer outages - usually because it was enabled without the prerequisites.

This article covers how DAI works, how to configure it correctly, the failures that happen in practice, and how to recover without turning it off permanently.

How DAI Works

DAI intercepts ARP packets on untrusted ports and validates them against a source of truth. There are two sources:

  • The DHCP snooping binding database. If DHCP snooping is enabled on the VLAN, the switch knows which MAC was leased which IP on which port. Every ARP reply is checked against it.
  • ARP ACLs. For hosts with statically configured addresses, a manual ARP access list provides the binding. This is required in non-DHCP environments and for any host you cannot move to DHCP.

ARP ACLs take precedence over the binding database. If an ARP ACL denies a packet, the packet is dropped even when a valid DHCP binding exists - which is a useful override, and a surprising one if someone else added the ACL.

DAI can validate four fields, and you should decide deliberately which ones to enable:

ip arp inspection validate src-mac dst-mac ip [vlan]
! src-mac  - ARP sender MAC must match the Ethernet source
! dst-mac  - ARP target MAC must match the Ethernet destination
! ip       - malformed IP addresses are dropped
! vlan     - drops ARP where the sender and target VLAN differ

Enabling all four is stronger and also more likely to drop something legitimate. src-mac and ip are the common baseline.

Configuration

! 1. DHCP snooping first - DAI depends on it
ip dhcp snooping
ip dhcp snooping vlan 20,30
no ip dhcp snooping information option          ! see the failure section
ip dhcp snooping database flash:dhcp-snooping.db
ip dhcp snooping database write-delay 60
! the uplink to the DHCP server is trusted
interface TenGigabitEthernet1/1/1
 ip dhcp snooping trust

! 2. Dynamic ARP inspection
ip arp inspection vlan 20,30
ip arp inspection validate src-mac ip
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 128 interval 10

! 3. trust the same ports you trust for snooping
interface TenGigabitEthernet1/1/1
 ip arp inspection trust

! 4. rate limit on host ports so a storm cannot exhaust the CPU
interface range GigabitEthernet1/0/1-24
 ip arp inspection limit rate 15 burst interval 1
 ! or, on some platforms:
 ! ip arp inspection limit rate 15

! 5. static hosts need an ARP ACL
arp access-list STATIC-HOSTS
 permit ip host 10.20.30.9 mac host 0050.56aa.0001
 permit ip host 10.20.30.10 mac host 0050.56aa.0002
ip arp inspection filter STATIC-HOSTS vlan 20 static

The static keyword means that hosts not covered by the ACL fall back to the DHCP snooping database; omit it and the ACL is applied exclusively.

Verify:

show ip arp inspection
show ip arp inspection vlan 20
show ip arp inspection interfaces
show ip arp inspection statistics
show ip dhcp snooping binding
show ip arp inspection log

On other platforms the feature exists under different names but the same model: ArubaOS-CX and Juniper both validate ARP against the DHCP snooping database and both need explicit trusted ports, and the equivalent baselines are shown in this ArubaOS-CX DHCP snooping guide and this Arista EOS DHCP snooping and IP Source Guard guide.

The Failure Scenarios That Actually Happen

Static-IP hosts stop working

The classic. Servers, printers, hypervisor management interfaces and building systems rarely use DHCP. Enable DAI without an ARP ACL and every one of them is blocked. Fix: inventory the static addresses first, then create the ARP ACL. Do not treat this as a reason to disable DAI.

Trunk and uplink ports left untrusted

An untrusted trunk means ARP from the other switch is validated against a binding database that does not contain it. The symptom is intermittent - it works for locally learned hosts and fails across the uplink. Mark every inter-switch and router-facing port trusted.

The DHCP option 82 mismatch

With ip dhcp snooping information option enabled, the switch inserts relay information into DHCP requests. If the DHCP server echoes it back, the reply can be dropped as coming from an untrusted source - and no binding is created, so ARP is blocked too. Either trust the server port properly or disable the option insertion where the server does not need it. This single setting accounts for a large share of "DHCP broke when we enabled snooping" reports.

Wireless and virtualisation paths

A wireless controller that tunnels client traffic, or a hypervisor vSwitch that proxies ARP for virtual machines, both break the assumption that one MAC uses one port. Either mark those ports trusted - accepting reduced protection - or verify that the binding database is populated for the MACs actually seen.

Rate limit drops during legitimate bursts

A host that has just booted, or a failover event where several hosts re-ARP at once, can exceed a low per-port ARP rate limit. The port then goes to err-disabled. Set the limit from measured traffic, not from a default, and enable err-disable recovery so a transient burst does not need a human:

errdisable recovery cause arp-inspection
errdisable recovery interval 300
show errdisable recovery

Mixed DAI and non-DAI switches in one VLAN

If some switches validate ARP and others do not, hosts behind the non-validating switch cannot be validated. Either deploy consistently across the VLAN or configure ARP ACLs that cover the hosts behind the other device. The half-deployed state is worse than either extreme, because it fails unpredictably.

Recovery Procedure

When DAI breaks a working network, resist the urge to disable it globally. Work the problem in order:

  1. Identify the affected hosts and check show ip arp inspection log. The log names the port and the reason for the drop.
  2. For DHCP hosts, check show ip dhcp snooping binding. A missing binding is a snooping problem, not a DAI problem.
  3. For static hosts, add the ARP ACL entry.
  4. For critical uplinks, confirm the trust state on both ends.
  5. Only if the network must be restored immediately, disable DAI for the specific VLAN rather than globally, and set a reminder to re-enable it - with an unenforced deadline, "temporarily disabled" becomes permanent.

DAI, IP Source Guard and Related Controls

These are usually deployed together but they do different things. DAI validates ARP. IP Source Guard validates the source IP of all data traffic against the binding table, which stops a host from spoofing a static address. Port security limits MAC addresses per port. Deploying all three from a single binding database is the coherent design; deploying one and expecting the protection of the others is a common misunderstanding. The complementary configuration for a Huawei VRP environment is in this Huawei DHCP snooping and IPSG guide, and the option 82 design considerations that affect the binding database are covered in this DHCP option 82 and IP Source Guard guide.

原文链接:https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-9/configuration_guide/sec/b_169_sec_9300_cg/configuring_dynamic_arp_inspection.pdf