I have a strange issue where the first ping always times out, but the following goes through fine.I have Cisco877 and connection to the internet is fine. I connect a PC to one of the FastEther ports and I am able to ping the router without any issues. However, the moment I ping an external website i.e. ping www.google.com the first ping request fails. after that the following request come through quickly.
Has anyone come across this before?
A Cisco router has a default timout of 5 seconds, when you send a ping request and you recieve . instead of ! , this doesnt necessarly mean the packet is not transmited at all , it just means there is no reply to those packets and some time it could be due to a delay higher than those 2 seconds.
If you are pinging a website. This means we first have to get a DNS resolution then ARP resolution and once these are in order we should be able to ping. If the first ping fails that means the first 2 steps are taking longer than expected.
Make sure you have a locallly reachable DNS server instead of a public DNS like 126.96.36.199.
Try to create a static ARP and then ping the ip address and see if you are still loosing the first ping packet.
In any case you should be able to see response for ping for all five packets.
To better understand problem is it possible for you to
> Post output of show interface
> Debug ip packet detail output
Thanks for the replies.
I have an external dns address configured and works. I also extended the ping from my windows machine to 10 seconds and still the same outcome. I also ping the ip address so it isn't using the dns to resolve the name and still the same outcome (1st packet lost then the remaining 3 comes through fine).
if i ping within the Cisco877, all packets come through fine. If i ping from a pc attached to the Cisco 877 the first packet times out.
I will see if i can get those output files to see what is going on.
FastEthernet0 is up, line protocol is up
Hardware is Fast Ethernet, address is b4a4.xxxx.xxxx(bia b4a4.zzzz.zzzz)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:39, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
122099 packets input, 51749372 bytes, 0 no buffer
Received 4628 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
242460 packets output, 49370440 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
4526 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
clear interface counters: clear counters
ping your external address sending 3 icmp echo packets: ping x.x.x.x rep 3 source
show int f0/0 to see number of packets.
10 second timeout is high and we should be ableto get a response back in time.
So If I get you right...
If you ping from PC to google.com ip address - first packet lost (timed out).
If you ping from 877 to google.com ip address - no ping loss.
Do you ping from 877 sourced from the local ip(network) example : ping 188.8.131.52 source 10.1.1.1 re 3?
If you do get ping loss in the last test, do the test again with debug ip packet detailed and debug ip icmp.
It is ARP.....
If you ping something and there is no ARP entry for that it actually does not send out the first ping it drops it but instead send out an ARP request to populate the ARP table. If you ping and get this .!!!! you should ping again and you should now see this !!!!! . That is because there is now an ARP entry.
Its not an ARP issue, the OP mentioned that the first packet always get dropped, this should let us think about anohter reason for this symptoms.
if its an ARP or DNS , thats become the reason then for the delay, or normal bandwidth usage, but he was able to perofrm ping successfully from the router and always the first ping fails from the PC.
Thank you to everyone who has had input. This is the config i have on the cisco 877. I am able to ping from the device itself without any issues, but from a PC attached to the ether port the first ping always fails. If i do the ping a second time to the same place it works just fine.
Current configuration : 8267 bytes
! Last configuration change at 21:44:13 Brisban Mon Nov 29 2010 by admin
! NVRAM config last updated at 13:42:48 Brisban Sun Nov 28 2010 by admin
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
logging buffered 51200 warnings
aaa authentication login vpnuserauth local
aaa authorization network groupauthor local
aaa session-id common
clock timezone Brisban 10
crypto pki trustpoint TP-self-signed-1654664305
crypto pki certificate chain TP-self-signed-1654664305
certificate self-signed 01
30820247 308201B0 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 31363534 36363433 3035301E 170D3032 30333031 30353336
35375A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D31 36353436
36343330 3530819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
8100D2A7 4FF4E864 F3860D95 F4A80ADB 04A70ED1 30A09B0A 025B5513 8E1B8E42
8074E5CF 8C5AE7CE D08262AF FC4120E5 AB433B07 5BD9004D F5ECB457 7C6D312D
3AFF8C14 3055F08F F675EB80 32081709 D7A46438 EA413FDF E6D95759 F25A4824
80085384 202DC8D9 2D39BF8A 21B4E088 C5768231 A7CF2D35 BB0E92CD B69C8219
850D0203 010001A3 6F306D30 0F060355 1D130101 FF040530 030101FF 301A0603
551D1104 13301182 0F534250 2D474154 45574159 2D383737 301F0603 551D2304
18301680 14A52BCA 36D4EBC6 F5595602 8B29E3B2 5F7C54D5 37301D06 03551D0E
04160414 A52BCA36 D4EBC6F5 5956028B 29E3B25F 7C54D537 300D0609 2A864886
F70D0101 04050003 8181006C 89759B4D E0C47B4B 0CBD9741 5291A848 191CF71A
B7B12C72 D0D7338D 306142F5 FDSERE C7FE5BFC A768399A 4480BCDF C33E5581
B09B49A5 3DDE17DC 35AD2A11 31D83B57 9D91C9B3 02CDD370 9E734100 20F8EE19
5959AE93 75ECB285 D5F236E9 CEECD5A3 4C909D15 3992E6A0 2C9B71D6 1B12A857
D07C944D 1F4525D5 10B672
no ip source-route
no ip dhcp use vrf connected
ip dhcp excluded-address 10.10.10.1 10.10.10.49
ip dhcp excluded-address 10.10.10.100 10.10.10.254
ip dhcp pool SBP_DHCP_Pool
network 10.10.10.0 255.255.255.0
dns-server 184.108.40.206 220.127.116.11
ip domain lookup source-interface Dialer0
ip name-server 18.104.22.168
ip name-server 22.214.171.124
multilink bundle-name authenticated
username admin privilege 15 password 7 xxx
crypto isakmp policy 3
crypto isakmp client configuration group xxxx
crypto isakmp profile sdm-ike-profile-1
match identity group XXXXX
client authentication list vpnuserauth
isakmp authorization list groupauthor
client configuration address respond
crypto ipsec transform-set myset esp-3des esp-sha-hmac
crypto ipsec profile SDM_Profile1
set transform-set myset
set isakmp-profile sdm-ike-profile-1
crypto dynamic-map dynmap 10
set transform-set myset
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
ip ssh source-interface Dialer0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
interface ATM0.1 point-to-point
pppoe-client dial-pool-number 1
interface Virtual-Template1 type tunnel
ip unnumbered Dialer0
tunnel mode ipsec ipv4
tunnel protection ipsec profile SDM_Profile1
description --- Unprotected VLAN1 ---
ip address 10.10.10.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1412
ip address xxx.xxx.xxx.xxx 255.255.255.0
ip access-group 105 in
no ip proxy-arp
ip mtu 1452
ip nat outside
dialer pool 1
no cdp enable
ppp authentication chap callin
ppp chap hostname xxxx
ppp chap password 7 xxxxxxxxxxxxx
crypto map clientmap
ip local pool ippool 10.20.20.2 10.20.20.20
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer0 2
ip route 192.168.88.0 255.255.255.0 10.10.10.2 2
ip http server
ip http access-class 2
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip dns server
ip nat pool overload xxx.xxx.xxx xxx.xx.xx.xx prefix-length 24
ip nat inside source list 1 pool overload overload
ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload
access-list 1 remark SDM_ACL Category=2
access-list 1 permit 192.168.88.0 0.0.0.255
access-list 1 permit 10.10.10.0 0.0.0.255
access-list 2 deny any
access-list 102 remark Controlled Access (if VPN in place)
access-list 102 permit ip 192.168.88.0 0.0.0.255 any
access-list 102 deny ip 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255
access-list 102 permit ip 10.10.10.0 0.0.0.255 any
access-list 104 remark Telnet access from Unprotected LAN
access-list 104 permit ip 10.10.10.0 0.0.0.255 any
access-list 104 remark Telnet access from Protected Lan2
access-list 104 permit ip 192.168.88.0 0.0.0.255 any
access-list 104 remark Telnet access from Protected VPN Lan
access-list 104 permit ip 10.20.20.0 0.0.0.255 any
access-list 105 remark SDM Management Access
access-list 105 permit ip any any
access-list 106 permit ip 10.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 106 remark TO PREVENT NAT FROM VPN
access-list 106 permit ip 10.20.20.0 0.0.0.255 192.168.88.0 0.0.0.255
dialer-list 1 protocol ip permit
no cdp run
route-map SDM_RMAP_1 permit 1
match ip address 102
line con 0
no modem enable
line aux 0
line vty 0 4
access-class 104 in
privilege level 15
transport input telnet ssh
scheduler max-task-time 5000
ntp clock-period 17182182
ntp server 126.96.36.199 source Dialer0 prefer
ntp server 188.8.131.52 source Dialer0
Is the PC getting IP via DHCP? Can you check the default gateway on PC?
Note, you should configure:
default ip mtu
ip tcp adjust-mss 1452
I've seen some weird behaviour like that on 870s with access lists doing logging and ip cef enabled, doesn't look like you've got any access lists logging though. Are you in a position to try 'no ip cef' to see what happens? It was a while ago I saw that but it wasn't just ping getting lost, had issues with SNMP and certain other traffic as well.
Not sure that turning off ip cef is a solution but might give you something to go on!
This is not an ARP "problem" it is just how it works. If you try and ping something and there is not a ARP entry for that it will drop the ping packet and not even send it, instead it will send out an ARP request and once it gets a reply the rest of the pings go through. So it is not that the ARP request or reply is taking too long and you are not seeing the first ping be successful it is that the first ping is dropped on purpose so a ARP request could be sent in its place. Again this is not a problem but normal behavior, because when you ping the same address again right after all pings come back successful because there is now an ARP entry. If you were always losing the first ping even on the second try then there could be a problem with the ARP cache but that is not the case here.
It is NOT that it is slow it IS that the first ping is NOT even sent.....it IS dropped so that an ARP request can be sent in its place. Again this is normal behavior. If the first ping was ALWAYS dropped that could indicate a problem but that is not the case here. I think you may be looking for a problem where one does not exist.
I just re-read the post and he states when he ping from the PC the first time he gets this .!!!! 4 out of 5, the frist ping is dropped. He than says if he trys the ping again from the PC all 5 ping now work and he sees this !!!!! 5 out of 5. He did not say it always drops the first ping from the PC.
If we follow your reasoning then from a pc with arp cache empty for destination hrdware address the first ping is not sent and it gives . for first ping?
then if I flush my arp cache and do a ping to a destination from my windows box how come all my icmp echoes are all sent?
It's because default timeout is 4 seconds on windows xp box and 2 seconds on Cisco IOS and the arp request/reply takes longer than 2 secs but less than 4?
Can you give me more details about this please?
It is not the ARP on your PC but the ARP on the first hop router. If the first hop router does not have the ARP entry then the Router drops the ping and sends out an ARP request. Now it may also be any router on the way to the destination I am not 100% that it is only the first hop router.
I have a similar issue with IOS version 12.4(15)T14.Turned out to be something related to dynamic Nat. For me - every first packet does not leave the outside interface of the router. When I use static nat everything works normally. I changed the ios version and now everything works fine.