Hi ,

Thanks for you reply .Again sorry for asking silly questions .I am very curious why ?the router need to send ARP packet at the first place to know the mac address of the destination,because the router would know the destination mac adddress by looking into the first request packer right ?(like broadcats first & unicast further).so why that time out for the first packet ?

You have made quite an interesting observation there. As you have seen, the first ping fails and all subsequent pings succeed. The classic answer to that is that the first ping is lost because there is no ARP table yet, so the ping times out. At first, this looks logical, but looking at it in any depth will beg a lot of questions. I don't fully understand it.

The ping timeout is 2 seconds. Should we really believe it takes more than two seconds for a ARP request to be generated and the response to come back? I don't think so. So the natural conclusion is that while the ARP entry is "incomplete" (i.e. it is waiting for a response), then any outgoing traffic for that destination is not buffered, but is discarded.

So ... why do we only lose one ping? Ping is a two-way process. A wants to ping B, sends out an ARP response, and discards the outgoing ping. A gets a response to the ARP and puts it in the ARP cache. The next ping gets sent to B via the ARP entry. Then what does B do with it? It needs to generate a response, but where does it send it? At that point, does B have an ARP cache entry for A yet? So how come B doesn't ARP for A and discard the response to the second ping?

Maybe B gleans the MAC address of A from the "Sender HA" field of A's ARP request (related to the first ping). One thing I am pretty sure of: it should not glean it from the source MAC address of A's ARP request, nor from the source MAC address of A's ping packet. If that were the case, then proxy-ARP would not work in asymetrical routing scenarios.

That sounds logical, but if you look on a sniffer, you see that B does ARP for A. So bang goes another theory.

The ARP cache aging time in a router is normally 4 hours, and is not refreshed by traffic. As each entry in the ARP cache times out, the router will ARP again, even with no traffic to send to the destination. So you will normally not see any more packets dropped. Maybe ...

I wonder what happens in that instant just after the ARP entry has aged out, and A has sent an ARP request out to refresh the entry, and is waiting for a response. If A has a packet to send to that destination, does it get discarded? Or is there a grace period between the ARP request going out and the old entry getting purged from the cache?

ARP should be the simplest protocol on the network, but actually there is more to it than meets the eye. Any comments?

Kevin Dorrell

Luxembourg

Kevin

The reason that we lose the first ping is quite simple and reflects a basic architectural decision in the design of the IOS. Yes the ping timeout is 2 seconds and if the router would buffer up the request and wait for the ARP then it probably could process the ping successfully. But that now puts a burden on the router to buffer the request, send the ARP, track the dependency of the request on the success of the ARP, match the ARP response to the ping request. That is a lot of buffering and a lot of processing for the router to do. And Cisco decided not to do it. When the router get a packet that it can not immediately forward then it drops the packet (if you do a debug ip packet you will see an encapsulation error) and waits for the originator to retransmit. The makes the process on the router more simple, reduces the demand for memory to buffer and reduces processing. It removes the router as a potential bottleneck and puts the burden to retransmit (if appropriate) on the originating host.

I think that the next paragraph asking about A and B needs to be clarified a bit. Are A and B hosts? From the context I do not think so. It seems that A is the router and B is the destination host. So the functionality really is:

- source host sends ping to destination host.

- router does not have MAC for destination host, so router discards the ping request and sends ARP to destination host.

- destination host receives ARP and sends response to the router. If it does not already have the MAC of the router it will ARP for it.

- router has now learned the MAC of the destination host, and the destination host has now learned the MAC of the router, so the next ping is successful.

HTH

Rick

Rick,

Thanks for the response. I was rather thinking of two routers on the same network, but the argument is the same with a router and a host.

In your four-step analysis, I am OK with steps 1 and 2. I'm OK with the first half of step 2, "destination host (B) receives ARP and sends response to the router (A)". It is the second half of step 3 that I have a problem with, especially if the "host B" is a router playing at being a host. What is it that causes the host/router B to send an ARP request for router A? All he has seen from A so far is an ARP request, and what he uses to respond to that is the HA field from the request packet. So far, B does not have any true layer-3 traffic for A - not until he sees the second ping.

I should really be doing this in the lab with Ethereal! The experiment would be "If I put an ACL in router B to block incoming ICMP echo from router A, and somehow I ensure that router B cannot generate ICMP unreachables, and then I ping from router A to router B, does router B generate an ARP request for router A, and does it get an entry in its ARP table for router A?"

Kevin Dorrell

Luxembourg