When pinging a directly-attached host (end-station) from a router, it's quite common to lose the first reply, as shown in the following example (the same symptom might occur when pinging a remote host that has been inactive).
a2#ping 10.0.0.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
Actually,
it's not the reply that was lost, the request was never sent out. Whenever a router has to send a packet to the next-hop (or directly attached destination) that has no entry in the ARP table, the ARP request is sent out, but the original packet is unconditionally dropped.
it's not the reply that was lost, the request was never sent out. Whenever a router has to send a packet to the next-hop (or directly attached destination) that has no entry in the ARP table, the ARP request is sent out, but the original packet is unconditionally dropped.
You can easily test this behavior in the lab (live networks are too busy for that) by debugging ARP requests while performing the ping command:
a2#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.0.6 - 0016.c876.8b38 ARPA FastEthernet0/0
Internet 10.0.0.5 0 0016.c7fe.f150 ARPA FastEthernet0/0
a2#debug arp
ARP packet debugging is on
a2#ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
08:26:21: IP ARP: creating incomplete entry for IP address: 10.0.0.10 interface
FastEthernet0/0
08:26:21: IP ARP: sent req src 10.0.0.6 0016.c876.8b38,
dst 10.0.0.10 0000.0000.0000 FastEthernet0/0
08:26:21: IP ARP: rcvd rep src 10.0.0.10 000c.29a7.8ade, dst 10.0.0.6 FastEthernet0/0
No comments:
Post a Comment