Reading my Directed ARP and ICMP Redirects blog post you might have wondered “how did Directed ARP ever get into ***redacted***?”

I searched for “directed ARP cisco” and found this gem, which really talks about unicast ARP behavior, an ancient mechanism documented in RFC 1122 (it’s not my Google-Fu, I got the reference to RFC 1122 in this blog post).

Unicast ARP is used in Windows and Linux to verify remote system reachability (see also this blog post), but I never heard of Cisco IOS using it to refresh its ARP cache. Time for another test.

Getting my Hands Dirty

I used the same VIRL setup as in the previous blog post. After the initial communication was established, the IOS router had ARP entries for its interfaces and the two Linux servers:

GW#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.1                -   fa16.3e63.f348  ARPA   GigabitEthernet0/1
Internet  10.0.0.5               27   fa16.3e99.a0ac  ARPA   GigabitEthernet0/1
Internet  10.0.1.1                -   fa16.3e63.f348  ARPA   GigabitEthernet0/1
Internet  10.0.1.5                0   fa16.3e9f.d087  ARPA   GigabitEthernet0/1

I turned on ARP debugging and cleared the ARP cache:

GW#debug arp
ARP packet debugging is on
GW#clear arp
GW#
ARP: flushing ARP entries for all interfaces
IP ARP: sent rep src 10.255.0.62 fa16.3e0d.892c,
                 dst 10.255.0.62 ffff.ffff.ffff GigabitEthernet0/0
IP ARP: sent rep src 10.0.0.1 fa16.3e63.f348,
                 dst 10.0.0.1 ffff.ffff.ffff GigabitEthernet0/1
IP ARP: sent rep src 10.0.1.1 fa16.3e63.f348,
                 dst 10.0.1.1 ffff.ffff.ffff GigabitEthernet0/1
IP ARP: sent req src 10.0.0.1 fa16.3e63.f348,
                 dst 10.0.0.5 fa16.3e99.a0ac GigabitEthernet0/1
IP ARP: sent req src 10.0.0.1 fa16.3e63.f348,
                 dst 10.0.1.5 fa16.3e9f.d087 GigabitEthernet0/1
IP ARP: rcvd rep src 10.0.0.5 fa16.3e99.a0ac, dst 10.0.0.1 GigabitEthernet0/1
IP ARP: rcvd rep src 10.0.1.5 fa16.3e9f.d087, dst 10.0.0.1 GigabitEthernet0/1

The first three packets were gratuitous ARPs for router’s own IP addresses. The next two packets were ARP requests for entries already in the ARP cache (although I told the router to clear it) and they were sent as unicasts to known MAC addresses.

Periodic ARP refreshes

I also knew that Cisco IOS refreshes ARP entries instead of deleting them (here’s why), so I modified the ARP timeout on the Ethernet interface and waited…

interface GigabitEthernet0/1
 description to L2
 ip address 10.0.1.1 255.255.0.0 secondary
 ip address 10.0.0.1 255.255.0.0
 arp timeout 20

Not surprisingly, this is what I got:

IP ARP: sent req src 10.0.0.1 fa16.3e63.f348,
                 dst 10.0.1.5 fa16.3e9f.d087 GigabitEthernet0/1
IP ARP: rcvd rep src 10.0.1.5 fa16.3e9f.d087, dst 10.0.0.1 GigabitEthernet0/1
IP ARP: creating entry for IP address: 10.0.1.5, hw: fa16.3e9f.d087
IP ARP: sent req src 10.0.0.1 fa16.3e63.f348,
                 dst 10.0.0.5 fa16.3e99.a0ac GigabitEthernet0/1
IP ARP: rcvd rep src 10.0.0.5 fa16.3e99.a0ac, dst 10.0.0.1 GigabitEthernet0/1
IP ARP: creating entry for IP address: 10.0.0.5, hw: fa16.3e99.a0ac

Lesson learned: Cisco IOS uses unicast ARP to refresh expired ARP entries.

Interestingly, I got the same result in 2007 but never realized what’s really going on. Sometimes it does pay to watch carefully while getting your hands dirty ;)