2

I have a small LAN with three hosts A,B,C connected through a switch. If A pings B, then the arp tables of A and B get populated, as expected. But C's arp table remains empty, even though it receives the arp broadcast. Is this expected behaviour?

I thought an arp broadcast always caused each host to update their arp.

Suppose that host C would want to ping host A. Because C doesn't know A's mac adress, it must send an arp broadcast. This seems a bit unnecessary. If it had learned A's mac-adress the first time, it wouldn't need to broadcast.

Can anyone please explain? (and I'd be even more happy if you could point to an official document that verifies this)

Thanks :-)

Improve this question

1 Answer 1

Reset to default
3

If it is following the process laid out in RFC 826, then this is expected behavior. Host C should only update an existing entry if present. It should only add an entry if it is the target of the ARP request.

From RFC 826, here is the processing flow:

Packet Reception:
-----------------

When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
*which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.

?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.
Improve this answer
3
  • Good answer! But why it is a bad idea for a host who is not the target of the arp request to add the mac address? Is there a risk of the stored macs becoming obsolete? or is it a matter of the arp table growing too big if the network is large?
    – rigor
    Commented Sep 13, 2015 at 15:28
  • To answer myself, I think I found a valid explanation: "If a host is not the target and does not already have an entry for the source in its ARP table, then it does not add an entry for the source. This is because there is no reason to believe that this host will ever need the source's link-level address; there is no need to clutter its ARP table with this information." (From "Computer Networks ISE: A Systems Approach" by Harry L Peterson and Bruce S Davie p.256) books.google.co.uk/…
    – rigor
    Commented Sep 13, 2015 at 17:40
  • Exactly. Remember, RFC 826 was published in 1982. Back then devices had relatively trivial amounts of processing and memory resources compared to today's devices. So it was written this way so that devices that didn't communicate with each other didn't have to keep track of each other to reduce the use of those resources. Even today, if you are connected to a network with hundreds or thousands of devices it would be wasteful for one system to keep track of all of them if it is only communicating with only a few (and maybe only the gateway).
    – YLearn
    Commented Sep 13, 2015 at 20:41

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.