ARP sending an ARP request on changing port IP address

Question

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

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?

Answer 1

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.