Tariq,
To be totally honest, it appears that this command does nothing. Either a bug - or I did not get the point.
I have originally thought that this command activates a certain form of sanity check on arriving gratuitous ARP messages. As you know, ARP messages carry IP addresses in their bodies - the IP address of the station that sends the ARP message, and the IP address of the "target", which is either the IP address that is being looked for (in ARP Requests), or the IP address of the station that needs the response (in ARP Replies). In the case of gratuitous ARP messages, the source and target IP address are the same. It would make sense to verify whether this IP address in the received gratuitous ARP message is from the same IP network as the interface through which the gratuitous ARP message arrived, or at least, whether it arrived through an interface that would be used as an outgoing interface to reach that IP address according to the routing table.
Assume the following setup:
- A router has its Fa0/0 in 10.0.0.0/24 network.
- A router has also a static route defined:
ip route 172.16.1.0 255.255.255.0 FastEthernet0/0
obviously relying on ProxyARP to reach the 172.16.1.0/24 network
Further assume that the router receives two gratuitous ARP messages over Fa0/0, one saying about 10.0.0.10, the other about 172.16.1.10.
Now, I have assumed the following:
- If no ip arp gratuitous is configured (the default), the router should process both of them. The ARP about 10.0.0.10 should be accepted because the 10.0.0.10 is right in the directly connected network on Fa0/0. The ARP about 172.16.1.10 should also be accepted because it arrived through an interface toward the whole 172.16.1.0/24.
- If ip arp gratuitous local is configured, the router should only accept the ARP about 10.0.0.10 (from a local, directly connected network) but it should ignore the ARP about 172.16.1.10 because that is no longer a local, directly connected network.
- If ip arp gratuitous none is configured, the router should ignore both gratuitous ARPs.
What a nice theory... but when I did debugs, I was disappointed to see that no matter what I configure, the gratuitous ARPs continue to be accepted. While the debug claims that some of ARPs have been ignored, the ARP table was nonetheless updated for both addresses above, no matter how I used the ip arp gratuitous command.
The fact that the debug output changes based on different setting of this command suggests that my original idea about this command is not entirely wrong, but to be honest, as I said in the beginning, I failed to actually show what the command does.
I've tested 12.4T and 15.3XB IOSes, the same behavior. I'd like you to test it if you can and come back with any results you might have. One thing: You first need to have the ARP entries for the IP addresses in the ARP table before the gratuitous ARPs start being processed at all. This is logical: If your router has not communicated with those IP addresses before, it will not create an ARP entry for them just because it has received a gratuitous ARP message. It will only use a received gratuitous ARP message to update already existing entries in its ARP table - therefore if you want to experiment with this feature, you must first ping the IP addresses for which you are going to generate gratuitous ARP messages.
Sorry to post this long article just to say "I do not know what this command does" but perhaps someone will be able to uncover what's going on based on the info gathered so far.
Best regards,
Peter
