Do you mean the loopback address 127.0.0.1. That is more related to hosts than routers/switches. On routers/switches you can use single /32 addresses for loopbacks if you want.
127.0.0.1 is a universally accepted convention for a loopback on a host.
The dot is a timeout because when you first ping the router does not have an arp entry for the IP address ie. the router needs to mac-address to send the packet. So it arps out for the mac-address.
While it is waiting for the response it cannot send the icmp traffic to the destination so the first packet does not get a response. Once the router has the mac-address of the destination it can then send the packets and receives responses.
If you then ping straight away again you should not see any dots because the router will have stored the mac-address to IP mapping in it's arp table.
for the second question when we make a ping the rtr should determine the mac address of the destination, so it sends an ARP request packet, wehn the answer arrives it then can send the pings.while waiting for the ARP answer, the first timer will expire so first packet seems to be lost. now the rtr knows the mac address of destination, timers will not expire for 4 remaining pings.
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?
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.
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?"
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...