1

Using the c7200 images on GNS3. I configured two routers as so: GNS3 topology

With arp debugging on, after assigning an ip address I see that each router sends a gratuitous ARP response packet (only debug output of R1 shown here):

 ARP: flush cache for interface FastEthernet0/0, by 60093304
*Jun 18 23:05:41.419: ARP: flushing ARP entries for interface FastEthernet0/0
*Jun 18 23:05:41.427: IP ARP: sent rep src 192.168.1.1 ca01.2f98.0000,
                 dst 192.168.1.1 ffff.ffff.ffff FastEthernet0/0

A look at the show arp output reveals that neither router has learnt of of each others IP-to-ARP mapping at this point. I understand that the gratuitous ARP response packet is sent in order to check for ip address conflicts. However, why were the routers not able to insert an entry into their arp tables using the gratuitous arp packets?

Next after pinging R2 from R1 (and consequentially both routers had each other's ip-to-mac entry), I changed R1's ip address to 192.168.1.3, R1's debug output showed (timestamp removed, each line is a new output message:

ARP: flush cache for interface FastEthernet0/0, by 60093304
IP ARP: sent req src 192.168.1.3 ca01.2f98.0000, dst 192.168.1.2 ca02.4314.0000 FastEthernet0/0
ARP: flushing ARP entries for interface FastEthernet0/0
IP ARP: sent rep src 192.168.1.3 ca01.2f98.0000, dst 192.168.1.3 ffff.ffff.ffff FastEthernet0/0
IP ARP: rcvd rep src 192.168.1.2 ca02.4314.0000, dst 192.168.1.3 FastEthernet0/0
IP ARP: creating entry for IP address: 192.168.1.2, hw: ca02.4314.0000

A subsequent examination of R2's arp table showed that R2 had a new ARP entry for the newly configured address, which in the above output we can see it received as a response in line 5 to the request in line 2. Why was the ARP request in the second line sent?

2

However, why were the routers not able to insert an entry into their arp tables using the gratuitous arp packets?

Because a device should only update an existing ARP table entry, not create a new one for that unless the device is the target. This is explained in the pseudocode included in RFC 826, An Ethernet Address Resolution Protocol:

 ?Do I have the hardware type in ar$hrd? Yes: (almost definitely)  
 [optionally check the hardware length ar$hln]   ?Do I speak the
 protocol in ar$pro?   Yes:
     [optionally check the protocol length ar$pln]
     Merge_flag := false
     If the pair <protocol type, sender protocol address> is
         already in my translation table, update the sender
         hardware address field of the entry with the new
         information in the packet and set Merge_flag to true.
     ?Am I the target protocol address?
     Yes:
       If Merge_flag is false, add the triplet <protocol type,
           sender protocol address, sender hardware address> to
           the translation table.
       ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
       Yes:
         Swap hardware and protocol fields, putting the local
             hardware and protocol addresses in the sender fields.
         Set the ar$op field to ares_op$REPLY
         Send the packet to the (new) target hardware address on
             the same hardware on which the request was received.

Notice the part that says, "Am I the target protocol address?" A "No" means to drop it.

Why was the ARP request in the second line sent?

The router was updating its ARP table after changing its address, and this will update both router's ARP tables for those interfaces.

2
  • On a slightly different (but related to the question) note: drawing upon your experience and your hindsight, in your opinion, is delving into details such as this (whatever the level-of-detail this question is in relation to the practical day-to-day workings of an entry network engineer) a good idea for a beginner in networking with no on-the-job experience? In other words, would it be recommendable for a beginner to learn these details now, or to leave them to for later to be learned when an issue raises a question such as this on-the-job?
    – Zeeshan
    Jun 18 at 20:38
  • 2
    You want to understand how stuff works, but do not try to drink from a firehose. If you do learn it now, it may stick with you, but this is not really anything you will often run across in a network engineering career. What is really important is learning how to find stuff. The RFCs are important, and you can search for rfc arp. That is a small, easy-to-understand RFC. Some, like TCP are complex and can scare you off, but keep at it.
    – Ron Maupin
    Jun 18 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.