ARP question

Unanswered Question
Jun 7th, 2012


I'm studying towards the CCNA exam and am currently reading the ICND2 book.

In chapter 3 (p 147), we're given an example under predicting normal operation of the LAN switching data plane.  Specifically, the example covers a PC broadcasting in a VLAN through three routers (configured in a 'triangular connection') to a router which is located the other side two of the routers.

The text says:

"The first working data plane example examines the path of a broadcast sent by PC1.  PC1 might not have R1's MAC address in PC1's ARP cache, so in that case, PC1 sends an ARP broadcast with an IP destination of and an Ethernet destination address of FFFF.FFFF.FFFF.  This section examines what the various switches do to forward the broadcast..."

What I'm having difficulty understanding is why, if PC1 is trying to find the MAC address of the router, the ARP destination IP address is set as the broadcast IP and not the IP address of the router?

My understanding is that normally an ARP will be sent to a specific IP address, with a destination Ethernet address of FFFF.FFFF.FFFF.  I also thought that a gratuitous ARP request has the both the source and destination IP addresses set to that of the sender.  Neither of these cases cover an ARP with a destination IP address of the network broadcast address.

As I currently understand it, broadcast ARPs do not get responded to, is this right?

Having worked through the example, it does not state or otherwise imply that on receipt of the ARP by R1 that R1 will respond (and I would hope that it wouldn't, as long as my understanding is correct).

Is there something about ARPs sent to a broadcast address that I haven't picked up on?  Do routers automatically respond to a broadcast ARP with their own IP and MAC address to the sender?


I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (4 ratings)
nathanaelminesso Thu, 06/07/2012 - 11:09

Hi Tim,

If the host does not have already the MAC to Layer3 mapping in the arp cache (on pc arp -a) and it wants to send something it, sends out a broadcast no matter where the destination is (Lan or Wan). The broadcast is askig for someone who can tell what MAC address the known destination IP belongs to.

In case the destination is on the LAN, the host directly responds with an unicast reply. In case it is on the Wan the default gateway will respond with the Lan interface of itself allowing the host to finally reach something else than the own Lan (Internet).

You can install wireshark (free), clear the arp cache and start pinging around to see this happen.

This link is also very good and tells you everything in simple words :-)

I hope that helps :-)



TimOnCisco Fri, 06/08/2012 - 03:44


many thanks for taking the time to reply.

My understanding of the ARP request protocol is that a destination protocol address of a specific host/device will always be used, rather than a broadcast protocol address.  I understand and accept that the hardware address will be the broadcast address of FFFF.FFFF.FFFF, as this is, afterall, what the sender is trying to locate.

The article you point to is useful and explains ARP well.  It does not, however, suggest or explain why a host would ever send an ARP request to the broadcast IP address of

As I understand it, with the IP address being a broadcast address, all devices will accept the ARP request, but none of them will respond because the IP address is not their own.  I would therefore expect that the only outcome of sending an ARP to the IP address would be for the recipients to populate their own ARP table with the sender's IP and MAC addresses.  (If my understanding is correct?)

The trouble is, the example given in the ICND2 book suggests that PC1 is sending the ARP request to receive the MAC address from the router, R1.  The suggestion that R1s IP address is seems to me to be quite wrong; no device should ever be allocated a broadcast IP address.  This suggestion is backed up by the example which follows the ARP broadcast example, starting on page 151, which deals with a unicast reply from R1 to PC1, "...R1's reply in response to PC1s ARP reques/broadcast."

One explanation could be that routers (just Cisco or in general?) are designed to reply to an ARP request sent to the broadcast IP address of with their own IP and MAC addresses?  I have not, however, found anything to substaniate this - and to be honest, I don't expect to as I think that it would have been mentioned in the link you provided, or in one of the ICND books, and I haven't found one Internet search result which would support the concept either.  Additionally, if this was truly the case, I would have expected it to be metioned in the ARP RFC (RFC 826: but it isn't.  The mentions setting the hardware address to all ones, but not the protocol address.

Another explanation could be that the author arbitrarily used  I find this unlikely though, given the otherwise excellent quality and thought that appears to have gone into the book.

Finally, it may be the case that there is more recent documentation on the use of ARP which I haven't yet come across which explains the use of the broadcast address.

The lack of clarification is frustrating and distracting.


narainarun Fri, 06/08/2012 - 03:49

Hi Tim,

Your understanding is correct. When a router sends a ARP request for router, the destination IP is set to that particular IP only(this is in ARP packet). Only Destination MAC address of the Layer 2 frame is Broadcast address.

ARP Request packet format:

Layer 2 Frame:

DA=FF.FF.FF.FF.FF.FF, SA=source mac. Ethertype= ARP (0806)

ARP packet:

sender mac address = mac of host

sender protocol address= source ip of host

destination mac address=

destination protocol address=destination ip of host

For the second part (destination of internet but router responds with ARP reply) Nate explained, it is possible when "proxy-arp" is enabled.



TimOnCisco Fri, 06/08/2012 - 04:10


thanks for your reply and confirmation.

Why is the line 'destination mac address='  not destination mac address=FF.FF.FF.FF.FF.FF'?

I'm happy with routers responding to ARPs for IPs which are outside of the local network (provided the router has, or thinks that it has, a route to that IP) with their own MAC address.  But... is the broadcast IP of considered to be such an address (either ever one when used in an ARP request)?  If so, that would answer my original question. If not, the original question of why Wendell Odom would use a broadcast IP address in the example still remains.


narainarun Fri, 06/08/2012 - 04:53

Hi Tim,

Actual ARP packet looks like this = Ethernet Frame then ARP Packet.

ARP packet contains the following fields: Hardware type (ethernet), Protocol type (IP), sender mac address, sender protocol address, destination mac address, destination protocol address.

Destination MAC in Ethernet frame is broadcast = FF.FF.FF.FF.FF.FF, but in ARP request packet, destination MAC is set to Switch forwards broadcast to all since it only looks into the broadcast destination MAC of ethernet frame. Once the host receives the ARP request, it looks into the Destination Protocol Address in ARP packet to its own. If it is the corresponding host, then only it replies back to ARP request.

I have not come across a ARP packet with destination IP as When I tried to ping such an address in my windows xp machine, it says it could not find host



narainarun Fri, 06/08/2012 - 09:13

Hi Tim,

The router will not respond to packets with destination IP The actual mechanism is called Proxy-ARP, where in

1. when a router receives ARP request for a destination IP which is not in that segment,

2. the interface where ARP request is received enabled with Proxy-ARP

3. the router has got a routing table entry (atleast a default route)

then only the router will do a ARP reply for destination which is outside of the segment.

But in case of, I think there is no routing entry which matches in RIB so router will not respond with its own physical address.



TimOnCisco Fri, 06/08/2012 - 10:07

Hi Arun,

I was in the process of replying to your previous post when I was notified of the next one...

Regarding the previous post:

I'm not surprised that Windows had kittens when you asked it to ping

I did a test in Packet Tracer (I don't have a physical lab) and PINGing produced a whole heap of replies from various IPs but none of them were placed into the ARP table of the device sending the ping.  Just for laughs, I also tried PINGing, with the same result.  Of course the PT sim can't be trusted to produce real-life results; trying to ping or in a PT simulated PC does not cause any failures!

Regarding the latest post:

1st paragraph, all understood and as I would expect to happen.  So, happy with that!

That just leaves the issue of why Wendell used in the example.  It's a mystery.

Thanks again for taking the time to discuss the matter.


Hari Haran S M Thu, 07/05/2012 - 04:55

Hi Tim,

ARP packets is not a L3 packet. It's a L2 packet with L3 information as payload. So the packet will look something like this,

L2 Header


Souce MAC - MAC of the machine that initiates the ARP request

Destination MAC - Broadcast MAC

Type - 0x806 [ARP]



Sender MAC - MAC of the device that initiates the ARP

Sender IP - IP of the device that initiates the ARP

Target MAC - All Zero's

Target IP - IP for which you are sending the ARP

Some other headers will be there

The above information is taken from a packet capture.

Since the packet is just a L2, we won't have the destination IP itself. I don't see any connection between and a normal ARP request. If you send a packet to, it will be sent to all the device in the whole network, no matter what subnet they are in. This is used in scenarios like WOL [Wake On Lan].

I would be interested to read the ICND book you are referring. Could you please give the page No/Book Name.

Hope this helps!!!!!

TimOnCisco Thu, 07/05/2012 - 06:28

Hari Haran SM,

As it says at the top of the post.... ICND2, chapter 3, page 147.

I've got the Third Edition book:

ISBN-10: 1-58720-435-5

ISBN-13: 978-1-58720-435-7

I look forward to reading what you make of it.


burleyman Thu, 07/05/2012 - 09:46

I think what he is saying is.... if the MAC address is not found it sends an ARP broadcast to find the MAC address, and when it sends that broadcast it uses the broadcast address of as the L3 address so it reaches everywhere, but the packet still has the IP address for the original destination you are trying to get to and find the MAC address for.


TimOnCisco Fri, 07/06/2012 - 09:50


Thank you for your reply and interpretation.  I understand what you're saying and I hope that it's accurate!  Note, I'm not questioning your knowledge!  I just that I hope that it is what the author truly meant to say.  Your interpretation is quite a bit different from the passage in the book.  If it was a small semantic thing or if the style of the passage was such that various interpretations could be made/observered I'd feel much happier.  If it is the case that the mean is, effectively, entirely different to the wording this one passage is letting down what is otherwise an excellent book (so far, still reading...:-) )


Hari Haran S M Mon, 07/09/2012 - 05:08

Hi Tim,

I read the passage and it seems to be different from what I saw in the packet capture. In the packet capture, there were no packets with the IP



brute-force Tue, 04/16/2013 - 03:34

Hi Tim, I have been studying with the same book and had the exact same question on chapter 3. If PC1 sends an ARP with destination ipv4, then the reader is owed an explanation, when the rest of the text examples of ARP requests have a specific, non-broadcast destination ipv4.  as compared what is said elsewhere in the textbook.

It is possible to have a case where the destination of the ARP request is a ipv4 broadcast address, the MAC dest is FFFF:FFFF:FFFF,  and a host on the LAN replies. In my case it was a 2950 switch replying to a broadcast ping or arping made from Linux.

I haven't practiced on enough Cisco hardware to know, however, if these results can be generalized to a router as in

Wendell Odom's example.  ARP is a protocol, but so is DHCP which replies to DHCP requests. In the end it appears that the real-life implementation of the protocol has the final say in how closely it follows the theory.


Login or Register to take actions

This Discussion

Posted June 7, 2012 at 4:48 AM
Updated June 7, 2012 at 8:37 AM
Replies:13 Overall Rating:3
Views:4447 Votes:1

Related Content


Discussions Leaderboard

Rank Username Points
Jon Marshall
Richard Burts
Joseph W. Doherty
Leo Laohoo
Rank Username Points
Wassim Aouadi
Roberto Kippins
Henrik Grankvist