Magical ARP entry?

[ypakhomenko]

Hi All,

I noticed the following behaviour that I cannot understand,
I would very much appreciate if you could explain it to me || give me a tip where to look for it...

there is an ARP entry for the 192.168.1.1 address:

sh arp                 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1            12   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.3.2            19   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.3.1            19   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.4.1            19   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.4.2            19   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  172.16.100.10           -   c204.1fdd.0000  ARPA   FastEthernet0/0
Internet  172.16.100.1           19   c200.1fdd.0000  ARPA   FastEthernet0/0

I clear it:
clear ip arp 192.168.1.1

after a ~ second the entry is re-created:
(debug arp)

*Mar  1 05:16:25.454: IP ARP: sent req src 172.16.100.10 c204.1fdd.0000,
                 dst 192.168.1.1 c200.1fdd.0000 FastEthernet0/0
*Mar  1 05:16:25.470: IP ARP: rcvd rep src 192.168.1.1 c200.1fdd.0000, dst 172.16.100.10 FastEthernet0/0
*Mar  1 05:16:25.478: IP ARP: creating entry for IP address: 192.168.1.1, hw: c200.1fdd.0000


sh arp                 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.1.1             0   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.3.2            21   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.3.1            21   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.4.1            21   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  192.168.4.2            21   c200.1fdd.0000  ARPA   FastEthernet0/0
Internet  172.16.100.10           -   c204.1fdd.0000  ARPA   FastEthernet0/0
Internet  172.16.100.1           21   c200.1fdd.0000  ARPA   FastEthernet0/0



I cannot understand WHY the entry is re-created...

The tests are done in gns3 with:
sh ver
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(12), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Fri 17-Nov-06 14:48 by prod_rel_team

ROM: ROMMON Emulation Microcode
ROM: 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(12), RELEASE SOFTWARE (fc1)

PC1 uptime is 5 hours, 18 minutes
System returned to ROM by unknown reload cause - suspect boot_data[BOOT_COUNT] 0x0, BOOT_COUNT 0, BOOTDATA 19
System image file is "tftp://255.255.255.255/unknown"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 3725 (R7000) processor (revision 0.1) with 124928K/6144K bytes of memory.
Processor board ID FTX0945W0MY
R7000 CPU at 240MHz, Implementation 39, Rev 2.1, 256KB L2, 512KB L3 Cache
2 FastEthernet interfaces
DRAM configuration is 64 bits wide with parity enabled.
55K bytes of NVRAM.
16384K bytes of ATA System CompactFlash (Read/Write)

Configuration register is 0x2102


-------------------------------------------------

sh run
Building configuration...

Current configuration : 995 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PC1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
ip tcp synwait-time 5
!
no ip domain lookup

username spy privilege 15 secret 5 *********************

interface FastEthernet0/0
 description To R4
 ip address 172.16.100.10 255.255.255.0
 speed 100
 full-duplex
 no keepalive
!        
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!        
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
!        
!        
no ip http server
no ip http secure-server
!        
    
control-plane
!        

line con 0
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 login local
 escape-character 3
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 login local
line vty 0 4
 login local
 escape-character 3
!        
!        
end      
 

[ypakhomenko]

P.S.

only if I shut / no shut the f0/0 interface the ARP table is cleared as expected...

[Richard Burts · Accepted solution]

I believe that there are two parts for the complete answer to your question.

First part is that a basic behavior of IOS routers is that when you do a clear arp the router will clear entries from the table and will immediately attempt to replace them by sending an arp request and if it receives a reply then it put the entry back into the table. Your debug output is pretty clear in showing that the router did send a request and that it did receive a response and therefore put the entry back into the table.

Second part is why is the router doing arp for 192.168.1.1? The answer to this part is in the way that you configured your static default route. Your configuration says that any address (0.0.0.0 0.0.0.0) is available locally via interface FastEth0/0. When you configure a static route with just the outbound interface and that interface is Ethernet then the router will arp for EVERY destination address.

Bonus Question: why does the arp entry clear and not come back if you shut down the interface? It is because the router clears the entry (as I explained) and attempts to send the request (as I explained) but since the interface is down the request can not go out. So no response is learned and no entry is put back into the table.

HTH

Rick

[yurypakhomenko]

Dear Richard,

thank you very much for your perfect answer. I did look into the CISCO documentation but I missed the point that IOS attempts to replace the cleared ARP entries...

One more question if you have time:

Is this correct that a router will always answer a "who has" ARP request providing its own MAC address if it believes it has a route to the destination (Even a default route will do) ?

/* In fact I was testing what exactly is happening if one configures a default route to an interface (not to a next hop) and I observed this behavior */

Best regards,

Yury

[Richard Burts · Accepted solution]

Yury

I am glad that you found my answer helpful. Thank you for using the rating system to mark this question as answered.

I believe that your statement is correct that if a router receives an ARP request and if the router is going to respond to the request that it will always send its own MAC if it believes that it has a route to the destination, including the possibility of a default route.

HTH

Rick