Dynamic ARP inspection
As we already know, ARP is the protocol used to learn the MACs of devices in the LAN and it usually comes down to just 2 message types: request and reply.
The request messages are sent by the inquiring device to the broadcast address ff:ff:ff:ff:ff:ff so that all interfaces connected to the LAN receive it. Only the interface with the given IP should reply revealing its MAC.
Besides the usual request/reply messages, we often see Gratuitous ARP messages. This kind of message is sent when a device wants to proactively inform the rest of interfaces in the LAN about an IP or MAC addition or change (e.g. interface with new IP is brought up).
Dynamic ARP inspection or DAI is a useful security mechanism to prevent ARP spoofing (or poisoning) and illegitimate broadcast storms. When enabled, DAI filters ARP messages (only ARP) on untrusted ports. As with DHCP snooping, with DAI all ports are untrusted by default. Generally speaking, we should only set to trusted the ports connected to other network devices.
Why should we enable DAI and leave ports connected to end devices set to untrusted?
• To stop attackers sending gratuitous messages with fake IPs to impersonate other devices.
• To stop attackers replying request messages to impersonate other devices.
The mechanism of both attacks is fairly simple: we take another device’s MAC/IP and pretend to own it in order to get traffic destined for its righteous owner.
How does DAI exactly work? DAI inspects the sender’s MAC and IP fields in the ARP messages received on untrusted ports, and looks for a matching record in the DHCP snooping binding table we saw in the previous section:
SW1# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
—————— ————– ———- ———— —- ——————–
0C:29:2F:18:79:00 192.168.100.10 86467 dhcp-snooping 1 GigabitEthernet0/1
0C:29:2F:18:79:01 192.168.100.11 86443 dhcp-snooping 1 GigabitEthernet0/2
0C:29:2F:18:79:02 192.168.100.12 86412 dhcp-snooping 1 GigabitEthernet0/3
Total number of bindings: 3
If it sees that the combination of MAC+IP cannot be found, it discards the message.
As we can imagine, DAI piggybacks the functionality of DHCP snooping so usually we would enable both. However, if we must disable DHCP snooping for some reason or our LAN uses static IPs, then we can use ARP ACLs as a workaround (we shall briefly cover them at the end of this page).
Enabling DAI is fairly straightforward:
SW2(config)# ip arp inspection vlan 1
SW2(config)# interface range g0/0 – 1
SW2(config-if-range)# ip arp inspection trust
We enable it for the chosen VLANs and then we switch a subset of ports to trusted. Now we can view the un/trusted ports…
S2# show ip arp inspection interfaces
Interface Trust State Rate (pps) Burst Interval
————– ———- ———- —————
Gi0/0 Trusted None N/A
Gi1/1 Untrusted 15 1
Gi1/2 Untrusted 15 1
Gi3/1 Untrusted 15 1
Gi3/2 Untrusted 15 1
We see in the output above the two fields “Rate” and “Burst interval” which gets us into rate limiting. Rate limiting is obviously disabled on trusted ports and enforced on untrusted ones. The default rate limiting kicks in at 15 packets per second per port but we can customise it:
SW1(config)# interface g0/1
SW1(config-if)# ip arp inspection limit rate 25
SW1(config-if)# interface g0/2
SW1(config-if)# ip arp inspection limit rate 30 burst interval 2
And we can view the customisation …
SW1# show ip arp inspection interfaces
Interface Trust State Rate (pps) Burst Interval
————– ———– ———- ————–
Gi0/0 Trusted None N/A
Gi0/1 Untrusted 25 1
Gi0/2 Untrusted 30 2
When the rate limit is exceeded, the interface is disabled and its state is set to err-disable. As with DHCP snooping we saw in the previous section, we can re-enable the interface with the customary shutdown + no shutdown or with the command:
SW1(config)# errdisable recovery cause arp-inspection
SW1(config)# do show errdisable recovery
ErrDisable Reason Timer Status
—————– ————
[…]
arp-inspection Enabled
[…]
ARP inspection offers 3 additional checks we can enforce:
SW1(config)# ip arp inspection validate ?
dst-mac Validate destination MAC address
ip Validate IP addresses
src-mac Validate source MAC address
• dst-mac: compares destination MAC address in the Ethernet header against the target MAC address in the ARP body and drops packets if there is a mismatch
• ip: checks for invalid of unexpected IP addresses (e.g. 0.0.0.0 or 255.255.255.255) and multicast addresses (e.g. 224.0.0.9), and drops the packet if it sees anything invalid
• src-mac: compares source MAC address in the Ethernet header against the source MAC address in the ARP body and drops packets if there is a mismatch
We can enable one or two or all if we want by listing them:
SW1(config)# ip arp inspection validate ip src-mac
SW1(config)# do show running-config | include validate
ip arp inspection validate ip src-mac
We briefly mentioned before the use of ARP ACLs so let’s have a quick overview of what purpose they serve and how to use them. Let’s assume that our DHCP snooping binding table looks like this:
SW1# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
—————— ————– ———- ———— —- ——————–
0C:29:2F:18:79:00 192.168.100.10 86467 dhcp-snooping 1 GigabitEthernet0/1
0C:29:2F:18:79:01 192.168.100.11 86443 dhcp-snooping 1 GigabitEthernet0/2
0C:29:2F:18:79:02 192.168.100.12 86412 dhcp-snooping 1 GigabitEthernet0/3
Total number of bindings: 3
We have DAI enabled and have another client with a static IP of 192.168.100.100. If this client sends an ARP packet the switch will drop it and we’ll see a message along these lines:
!CLI2 has a static IP address of 192.168.100.1002, so it does not have an entry in SW1’s DHCP snooping binding table.
*Jan 19 13:13:14.439: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi0/2, vlan 1.
To walk around this scenario we can use ARP ACLs:
SW1(config)# arp access-list ARP-ACL-1
SW1(config-arp-nacl)# permit ip host 192.168.100.100 mac host 0c25.2e41.5546
SW1(config-arp-nacl)# end
SW1(config)# ip arp inspection filter ARP-ACL-1 vlan 1
These ACLs are checked just after the snooping table and they would prevent CLI2’s ARP packets from being dropped.