Dynamic ARP Inspection, usually shortened to DAI, checks whether an ARP packet's claimed IPv4 address and MAC address agree with an approved binding. A switch can discard an invalid claim before forwarding it to other devices. That helps keep a device from convincing its neighbors that it owns another device's IPv4 address.

The approval record depends on how the device obtained its address. For DHCP clients, that record normally comes from DHCP snooping. A manually addressed printer or server needs a supported static approval method. The port receiving the packet also matters: traffic arriving through a trusted interface can bypass inspection.

The Address Claim That ARP Spoofing Changes

The Address Resolution Protocol (ARP) lets devices on an Ethernet local area network (LAN) find the MAC address associated with an IPv4 address. Its packets contain sender and target addresses. Both requests and replies carry information about the sender, so a packet asking a question can also teach a recipient an address mapping.

Consider a hypothetical office where the gateway uses 192.168.40.1 and MAC address 02:00:00:00:40:01. A workstation needs that gateway's MAC address to send an Ethernet frame toward destinations outside its subnet. A false ARP claim could associate 192.168.40.1 with a different device's MAC address.

The IP destination of the workstation's application traffic does not have to change for this to cause trouble. Its next Ethernet frame can go to the wrong local recipient. If that recipient forwards the traffic onward, the connection may continue while the local path has been diverted. If it does not, the workstation may simply lose connectivity.

DAI lets the switch reject that false pairing. The check happens when the ARP packet enters an interface where DAI is active, before the claim reaches another endpoint. Tracing that packet's path shows which switch can inspect it.

How DAI Checks IP-to-MAC Bindings

DHCP snooping learns client lease information by observing DHCP traffic. Its binding database associates client addresses with their MAC addresses and includes network context such as the virtual local area network (VLAN) and interface. DAI uses approved IP-to-MAC bindings when checking ARP packets from untrusted interfaces in an inspected VLAN.

In another hypothetical example, a workstation receives 192.168.40.86 and uses MAC address 02:00:00:00:40:86. The inspecting switch has the corresponding lease binding for VLAN 40. An ARP packet claiming that sender pairing has the expected address information. A packet claiming 192.168.40.86 with 02:00:00:00:40:99 would present a different pairing.

That comparison explains why a plausible address is insufficient. Both MAC addresses in this example are syntactically usable, and the claimed IP address belongs to the office subnet. The failure is that the packet's claim disagrees with the approved record.

Missing bindings can also cause legitimate ARP packets to be rejected. If the switch has no approved binding for the workstation, it cannot make the same successful comparison. The absence might reflect a device that bypassed DHCP or a lease the switch has not observed. Neither possibility establishes that the workstation is malicious.

Static Hosts Need an Explicit Approval Method

A manually configured IPv4 address does not produce a DHCP lease exchange. Enabling DHCP snooping therefore does not automatically supply an approval record for every fixed-address device. Inventory those devices before enforcing a policy that depends on learned bindings.

Suppose a hypothetical printer uses 192.168.40.25 and MAC address 02:00:00:00:40:25. Its address was entered directly into the printer. The workstation at 192.168.40.86 can have a learned DHCP binding while the printer has none. Putting both devices in the same VLAN does not make their records equivalent.

ARP ACLs and Static Bindings

On Catalyst 9300 switches running IOS XE 17.18.x, an ARP access control list (ACL) can permit a specified sender IP–MAC pair and must be applied to the relevant VLAN. Explicit ACL denials override DHCP bindings. With the filter's static option, unmatched packets are dropped without DHCP fallback; without it, unmatched packets can proceed to the binding check when no explicit denial applies.

For the example printer, the intended exception identifies 192.168.40.25 together with 02:00:00:00:40:25. Its purpose is to approve that device's particular claim. If a replacement printer retains the old IP address but has a new MAC address, the old pairing no longer describes it. Update the exception to match the replacement printer's authorized IP and MAC addresses.

Other platforms can use static IP bindings, and support differs by product and release. HPE Aruba AOS-CX 10.13.1000, for example, enforces DAI using DHCP snooping bindings and static IP bindings. Check that your switch's DAI implementation uses the binding or ACL you configure.

A DHCP reservation is a different case. When the reserved client still obtains its address through DHCP, the switch can observe that exchange. A device with the same numerical address entered manually does not become a DHCP client merely because a reservation exists on the server.

Trusted Interfaces Move the Inspection Boundary

A trusted interface permits incoming ARP traffic to bypass DAI checks. The switch then relies on whatever protection exists elsewhere along that traffic's path. A port label such as uplink does not establish that every device reachable through it has been inspected.

Imagine two switches, A and B, serving the same office VLAN. A workstation attached to A sends an ARP packet toward a workstation attached to B. If B trusts its incoming link from A, the receiving switch relies on the protection provided before that packet arrives. An unchecked client behind A can undermine that reliance.

Keeping the link untrusted requires B to have an applicable approved record for the incoming claim. Do not assume each switch has learned identical lease information: where the DHCP exchange traveled affects what each one observed. Each inspecting switch needs the binding or ACL required to validate the ARP traffic it receives.

DHCP snooping trust and ARP inspection trust also deserve separate attention. On Juniper EX and QFX switches running Junos OS, an interface trusted for DHCP is also trusted for ARP. Product defaults and the relationship between these controls vary. Examine the actual ARP trust state instead of inferring it from another feature's configuration.

Two clients behind a small unmanaged switch may exchange ARP packets without those packets reaching the managed switch upstream. DAI on the upstream switch cannot inspect traffic that stays between those clients. Account for these local paths when deciding where to enforce inspection.

Prepare the Records before Enforcing the Policy

An existing DHCP client may already hold a valid lease when snooping is enabled. The switch still needs to observe an exchange that supplies its binding. Before enabling DAI, verify that the binding table contains the expected client entries. A valid lease on a client does not prove that the switch has learned the binding.

In the office example, check the workstation's learned binding and the printer's static approval record. Then trace how the gateway's ARP traffic enters the protected VLAN to determine whether the receiving interface inspects that traffic or trusts it.

VLAN selection matters as well. Inspection enabled for VLAN 40 does not automatically cover a separate VLAN 50. A successful connection from a device in VLAN 50 says little about how VLAN 40's ARP policy behaves. Diagnose the VLAN carrying the disputed packet.

Diagnosing Dropped ARP Packets

Forwarded and dropped ARP counters show whether inspection is handling traffic. They become more useful when related to the affected VLAN and the time of a reported failure. A historical total cannot identify which newly installed device caused a recent increase.

For a blocked printer, compare the logged sender address and MAC address with the authorized printer inventory and the switch's applicable approval record. Also identify the receiving interface. The printer may be using authorized addresses while the switch's record is missing, belongs to another VLAN, or still contains the previous printer's MAC address.

Read the reason for rejection before changing trust. A DHCP-based mismatch and an explicit ACL denial call for different corrections. Trusting the port may make the symptom disappear by skipping the check, but that result does not explain why the original claim was rejected.

Keep the original rejection details with the change record when an authorized exception is corrected. That preserves which IP–MAC pair actually failed, so a later recurrence can be compared with the first incident instead of reconstructed from memory.