0

I made this topology in GNS3 :

enter image description here

I cleared the switches MAC tables. In this way, when PC1 sends an ARP request to know who has the IP 192.168.1.20 (PC2 IP), the request is broadcast through all ports of switch1 and also switch2. I used wireshark to verify this and I saw the ARP request reaching PC3.

enter image description here

However, the ARP table of PC3 is empty. Why doesn't it add a new entry for PC1 in his table ?

enter image description here

Is this an expected behavior?

Improve this question

3 Answers 3

Reset to default
6

Yes, this is expected behaviour.

Even though PC3 sees the ARP request from PC1, it does not populate it's ARP cache with the IP-to-MAC mapping of PC1.

While this may not seem to be the most efficient method of distributing address to host information, you need to remember that the ARP protocol was developed in 1982[1] and even back then the author made the following very relevant point:

The workstations aren't generally going to be talking to each other (and therefore have 100 useless entries in a table); they will be mainly talking to a mainframe, file server or bridge, but only to a small number of other workstations (for interactive conversations, for example). The protocol described in this paper distributes information as it is needed, and only once (probably) per boot of a machine.

It would be a trivial usage of resource on today's PCs to populate the entire ARP table for the local subnet(s) the machine resides on, but perhaps not so for a networked machine back in 1982.

[1] RFC826 - An Ethernet Address Resolution Protocol - https://www.rfc-editor.org/rfc/rfc826

Improve this answer
2

ARP replies are unicast, so the switch doesn't forward it to PC 3.

Gratuitous ARPs are broadcast so all nodes can hear it.

Improve this answer
7
  • PC3 don't see the reply (because the switch MAC tables contains PC1) but it is able to see the request as shown in the screenshot I added.
    – SwissFr
    Commented Dec 8, 2016 at 15:35
  • What you mean is that an ARP entry is only added by the hosts associated to the ARP exchange ? In this case only PC1 and PC2, except for Gratuitous ARP that are destined to all hosts.
    – SwissFr
    Commented Dec 8, 2016 at 15:39
  • This is really a function of how switches forward frames, not of the ARP protocol itself. When PC2 replies, the switch looks at the destination MAC (PC1) and only forwards the frame out the port attached to PC1. The reply never gets forwarded to SW2 or PC3. The ARP request is a broadcast, so switches flood them out all ports.
    – Ron Trunk
    Commented Dec 8, 2016 at 15:44
  • Alright, I see. Thank you for explanation. But why doesn't the PC3 benefit from this request and add a new ARP entry for a future use ?
    – SwissFr
    Commented Dec 8, 2016 at 16:01
  • I don't think you understand. PC3 can't make an entry in its ARP table because switch 1 never forwards the reply to switch 2, so PC 3 never hears it.
    – Ron Trunk
    Commented Dec 8, 2016 at 16:03
0

Gratuitous ARPs are in fact ARP Requests and not ARP Replies as I had stated previously. This is explained in RFC5227.

The term "gratuitous reply" would seem to apply perfectly to an ARP
Announcement: an answer to an implied question that in fact no one
asked.

However reasonable this may seem in principle, in practice there are two reasons that swing the argument in favor of using ARP Request packets. One is historical precedent, and the other is pragmatism.

The historical precedent is that (as described above in Section 4) Gratuitous ARP is documented in Stevens Networking [Ste94] as using
ARP Request packets. BSD Unix, Microsoft Windows, Mac OS 9, Mac OS
X, etc., all use ARP Request packets as described in Stevens. At
this stage, trying to mandate that they all switch to using ARP Reply packets would be futile.

The practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations, some of which
may not implement RFC 826 entirely correctly. The Packet Reception
rules in RFC 826 state that the opcode is the last thing to check in
packet processing, so it really shouldn't matter, but there may be
"creative" implementations that have different packet processing
depending on the 'ar$op' field, and there are several reasons why
these are more likely to accept gratuitous ARP Requests than
gratuitous ARP Replies:

  • An incorrect ARP implementation may expect that ARP Replies are only sent via unicast. RFC 826 does not say this, but an incorrect implementation may assume it; the "principle of least surprise" dictates that where there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one likely to have the fewest interoperability problems with existing implementations. An ARP Announcement needs to broadcast information to all hosts on the link. Since ARP Request packets are always broadcast, and ARP Reply packets are not, receiving an ARP Request packet via broadcast is less surprising than receiving an ARP Reply packet via broadcast.

  • An incorrect ARP implementation may expect that ARP Replies are only received in response to ARP Requests that have been issued recently by that implementation. Unexpected unsolicited Replies may be ignored.

  • An incorrect ARP implementation may ignore ARP Replies where 'ar$tha' doesn't match its hardware address.

  • An incorrect ARP implementation may ignore ARP Replies where 'ar$tpa' doesn't match its IP address.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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