Solved: Re: First Ping timeout

Chris Shaw · ‎01-17-2011

Hi,

I know there has already been a couple of threads on this but rather than add my question to the bottom of one of those I thought I would try afresh.

We have an 857W connected to the internet via ADSL. All works very well, however if I ping from an attached PC the first one always times out. If i ping from the router (ping www.google.com source 192.168.18.1) I get !!!!! every time. Back to the PC and 'Request timed out' on the first.

The only way I have been able to resolve this is by using no ip cef. It then works as expected, first ping and all. The problem is after much reading, it is not ideal to disable cef.

I would be very grateful for any suggestions.

Thanks,

Chris

skarthic · ‎01-19-2011

Chris,

This is a bug as mentioned in the following link

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCti13229

Affects 12.4T(14)

Has been fixed in 12.4T(15) but is releasing in march 11

Try downgrading to T13 as the bug doesnot affect the T13 version

Please rate to let me know the answer helped.

Thank you

Karthic.R.

View solution in original post

Peter Paluch · ‎01-17-2011

Chris,

Can you post the output of your show ip route command and the complete configuration? Of course, remove sensitive information.

Thank you!

Best regards,

Peter

Chris Shaw · ‎01-17-2011

Hello Peter,

Thank you for your very prompt reply.

show ip route:

Gateway of last resort is 194.159.169.244 to network 0.0.0.0

80.0.0.0/32 is subnetted, 1 subnets

C 80.xxx.xx.xxx is directly connected, Dialer0

194.159.169.0/32 is subnetted, 1 subnets

C 194.159.169.244 is directly connected, Dialer0

C 192.168.18.0/24 is directly connected, Vlan1

S* 0.0.0.0/0 [1/0] via 194.159.169.244

show run

version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname rrir02
!
boot-start-marker
boot system flash c850-advsecurityk9-mz.124-15.T14.bin
boot-end-marker
!
logging buffered 51200
logging console critical
enable secret 5 xxxx
!
no aaa new-model
clock timezone GMT 0
clock summer-time GMT recurring last Sun Mar 1:00 last Sun Oct 2:00
!

dot11 syslog
no ip source-route
!
!
no ip cef
no ip bootp server
no ip domain lookup
ip domain name huntgroup.co.uk
!
!
!
username administrator privilege 15 secret 5 xxxx
! 
!
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key xxxx address 81.xx.xx.xx
crypto isakmp invalid-spi-recovery
!
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac 
!
crypto map SDM_CMAP_1 1 ipsec-isakmp 
 description Tunnel toxx.xx.xx.xx
 set peer xx.xx.xx.xx
 set transform-set ESP-3DES-SHA 
 match address 100
!
archive
 log config
  hidekeys
!
!
ip tcp synwait-time 10
ip tftp source-interface Vlan1
ip ssh time-out 60
ip ssh authentication-retries 2
!
!
!
interface ATM0
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip route-cache flow
 no atm ilmi-keepalive
 dsl operating-mode auto 
!
interface ATM0.1 point-to-point
 description $ES_WAN$$FW_OUTSIDE$
 pvc 0/38 
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
 !
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Dot11Radio0
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip route-cache flow
 shutdown
 speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
 station-role root
!
interface Vlan1
 description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$$ES_LAN$$FW_INSIDE$
 ip address 192.168.18.1 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat inside
 ip virtual-reassembly
 ip tcp adjust-mss 1452
!
interface Dialer0
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 0
 dialer persistent
 dialer-group 1
 no cdp enable
 ppp authentication chap callin
 ppp chap hostname xxxx
 ppp chap password 7 xxxx
 ppp ipcp dns request accept
 ppp ipcp route default
 crypto map SDM_CMAP_1
!
ip forward-protocol nd
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip dns server
ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload
ip nat inside source static tcp 192.168.18.3 20 xx.xx.xx.xx 20 extendable
ip nat inside source static tcp 192.168.18.3 21 xx.xx.xx.xx 21 extendable
ip nat inside source static tcp 192.168.18.3 80 xx.xx.xx.xx 80 extendable
ip nat inside source static tcp 192.168.18.2 443 xx.xx.xx.xx 443 extendable
ip nat inside source static udp 192.168.18.3 1025 xx.xx.xx.xx 1025 extendable
ip nat inside source static udp 192.168.18.3 2074 xx.xx.xx.xx 2074 extendable
ip nat inside source static udp 192.168.18.3 2075 xx.xx.xx.xx 2075 extendable
ip nat inside source static tcp 192.168.18.2 4125 xx.xx.xx.xx 4125 extendable
!
logging trap debugging
logging source-interface Vlan1
logging 172.16.0.1
access-list 1 remark INSIDE_IF=Vlan1
access-list 1 remark CCP_ACL Category=2
access-list 1 permit 192.168.18.0 0.0.0.255
access-list 100 remark CCP_ACL Category=4
access-list 100 remark IPSec Rule
access-list 100 permit ip 192.168.18.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 100 permit ip 192.168.18.0 0.0.0.255 192.168.16.0 0.0.0.255
access-list 100 permit ip 192.168.18.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 100 permit ip 192.168.18.0 0.0.0.255 192.168.17.0 0.0.0.255
access-list 101 remark CCP_ACL Category=18
access-list 101 deny   ip 192.168.18.0 0.0.0.255 192.168.17.0 0.0.0.255
access-list 101 deny   ip 192.168.18.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 101 deny   ip 192.168.18.0 0.0.0.255 192.168.16.0 0.0.0.255
access-list 101 deny   ip 192.168.18.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 permit ip 192.168.18.0 0.0.0.255 any
dialer-list 1 protocol ip permit
snmp-server community public RO
no cdp run
route-map SDM_RMAP_1 permit 1
 match ip address 101
!
!
control-plane
!
banner login ^CAuthorized access only!
 Disconnect IMMEDIATELY if you are not an authorized user!^C
!
line con 0
 login local
 no modem enable
 transport output telnet
line aux 0
 login local
 transport output telnet
line vty 0 4
 privilege level 15
 login local
 transport input telnet ssh
!
scheduler max-task-time 5000
scheduler allocate 4000 1000
scheduler interval 500
sntp server 172.16.0.1
sntp source-interface Vlan1

Thanks,

Chris

Message was edited by: Chris Shaw

Peter Paluch · ‎01-17-2011

Hi Chris,

I see no obvious issues with your configuration. You have deactivated the CEF in your current configuration - can you please turn it back on? It is indeed not a good idea to deactivate it.

Also, I would be interested... when you try to ping an external IP from your PC, the first ping may indeed get lost - that is caused by throttling the ARP process on the router. All subsequent pings should be fine, however. Did you observe that out of 4 pings that the command ping sends in one run, every first packet is lost every time you run the command, even if you run it twice in succession?

In other words, I am trying to better understand what exactly is needed to make the ping packets get lost - different destination IP addresses, enough time between pings, ...

Also, do you experience any other connectivity issues or is this the only symptom you have been observing?

Best regards,

Peter

Chris Shaw · ‎01-17-2011

Hi Paul,

Thank you once again for you help with this.

I have re-enabled cef and sent two pings from an attached PC. The output is below:

C:\Documents and Settings\jayneh>ping www.google.com

Pinging www.l.google.com [209.85.227.147] with 32 bytes of data:

Request timed out.

Reply from 209.85.227.147: bytes=32 time=35ms TTL=54

Reply from 209.85.227.147: bytes=32 time=36ms TTL=54

Ping statistics for 209.85.227.147:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 35ms, Maximum = 36ms, Average = 35ms

C:\Documents and Settings\jayneh>ping www.google.com

Pinging www.l.google.com [209.85.227.104] with 32 bytes of data:

Request timed out.

Reply from 209.85.227.104: bytes=32 time=35ms TTL=54

Reply from 209.85.227.104: bytes=32 time=38ms TTL=54

Reply from 209.85.227.104: bytes=32 time=37ms TTL=54

Ping statistics for 209.85.227.104:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 35ms, Maximum = 38ms, Average = 36ms

I ran one directly after the other with virtually no delay.

If I try pinging the IP address directly, it seems to work ok but if I leave a small gap of 10-15 seconds the first pings times out again. For example:

C:\Documents and Settings\jayneh>ping 209.85.227.104

Pinging 209.85.227.104 with 32 bytes of data:

Request timed out.

Reply from 209.85.227.104: bytes=32 time=35ms TTL=54

Reply from 209.85.227.104: bytes=32 time=36ms TTL=54

Ping statistics for 209.85.227.104:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 35ms, Maximum = 36ms, Average = 35ms

NO GAP LEFT

C:\Documents and Settings\jayneh>ping 209.85.227.104

Pinging 209.85.227.104 with 32 bytes of data:

Reply from 209.85.227.104: bytes=32 time=36ms TTL=54

Reply from 209.85.227.104: bytes=32 time=35ms TTL=54

Ping statistics for 209.85.227.104:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 35ms, Maximum = 36ms, Average = 35ms

Gap of 12 seconds left

C:\Documents and Settings\jayneh>ping 209.85.227.104

Pinging 209.85.227.104 with 32 bytes of data:

Request timed out.

Reply from 209.85.227.104: bytes=32 time=36ms TTL=54

Reply from 209.85.227.104: bytes=32 time=37ms TTL=54

Reply from 209.85.227.104: bytes=32 time=36ms TTL=54

Ping statistics for 209.85.227.104:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 36ms, Maximum = 37ms, Average = 36ms

When CEF is disabled it doesn't matter how long I leave it. The first ping will always work.

There are no other problems, except the perceived delay in browsing the web.

Thanks,

Chris

Peter Paluch · ‎01-17-2011

Chris,

Thank you very much for your reply. I wonder: Is there any difference when you ping the router itself, i.e. the IP address of its Ethernet and Dialer interface? Do the packets also get lost when you ping the router itself? Please enclose the output just like you did the first time - that is most helpful!

And also please enclose the output of show ip cef - thanks!

Best regards,

Peter

P.S.: I am beginning to suspect the NAT, not the CEF, to perhaps be at the root of this issue. But I have to confirm that yet.

Chris Shaw · ‎01-17-2011

Peter,

Please don't thank me. I'm the one providing you with this lovely headache!!

Pinging the router is always ok:

Inside interface

C:\Documents and Settings\jayneh>ping 192.168.18.1

Pinging 192.168.18.1 with 32 bytes of data:

Reply from 192.168.18.1: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.18.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

Outside interface (Dialer0)

C:\Documents and Settings\jayneh>ping 80.xx.xx.xx

Pinging 80.xx.xx.xx with 32 bytes of data:

Reply from 80.xx.xx.xx: bytes=32 time<1ms TTL=255

Ping statistics for 80.xx.xx.xx:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

sh ip cef

Prefix Next Hop Interface

0.0.0.0/0 194.159.169.244 Dialer0

0.0.0.0/32 receive

80.xx.xx.xx/32 receive

192.168.18.0/24 attached Vlan1

192.168.18.0/32 receive

192.168.18.1/32 receive

192.168.18.2/32 192.168.18.2 Vlan1

192.168.18.3/32 192.168.18.3 Vlan1

192.168.18.23/32 192.168.18.23 Vlan1

192.168.18.24/32 192.168.18.24 Vlan1

192.168.18.25/32 192.168.18.25 Vlan1

192.168.18.27/32 192.168.18.27 Vlan1

192.168.18.28/32 192.168.18.28 Vlan1

192.168.18.29/32 192.168.18.29 Vlan1

192.168.18.255/32 receive

194.159.169.244/32 attached Dialer0

224.0.0.0/4 drop

224.0.0.0/24 receive

255.255.255.255/32 receive

Thanks,

Chris

Peter Paluch · ‎01-17-2011

Chris,

Let me make one, possibly blind, experiment: remove your current default route and replace it with a default route pointing directly towards the Dialer0 interface instead of an IP next-hop address:

no ip route 0.0.0.0 0.0.0.0

ip route 0.0.0.0 0.0.0.0 Dialer0

Usually, with ADSL, this is the preferred way of configuring the default route, as it removes the dependency on the opposite IP address. I have a slight feeling that I've seen some problems with the CEF that were also related to the handling of the default route, and we may be dealing with one of them.

Please give this a try and let me know. Back up your configuration and be careful - removing a default route may disconnect you from the router if you are accessing it remotely.

Best regards,

Peter

Chris Shaw · ‎01-17-2011

Peter,

Thanks for your reply.

I did initially have the default route set to the Dialer interface and thought that might be the problem, so after looking at this document http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ftdlrcef.html I removed the default route and added ppp ipcp route default to the Dialer interface.

Chris.

Peter Paluch · ‎01-17-2011

Hi Chris,

Okay, I see - sorry, I've missed that in your config. Your current config with the IPCP providing the default route is just fine.

So let me reiterate one more question: you can ping the 192.168.x.x on your router without any losses, and you can also ping the 80.x.x.x just fine. Can you also ping the 194.159.169.244 (or whatever your current next-hop in the default route is) - are there any losses, then? Of course, the CEF shall be active.

Note that everything seems so far to work as long as we do not actually traverse the router. As your router seems to be able to ping anything without losses, we can, for now, exclude a faulty DSL line as the cause. My focus is moving towards the NAT - because that one is involved strongly in the process of your packets traversing through the router.

Best regards,

Peter

Chris Shaw · ‎01-17-2011

Hello Peter,

Apologies for the delay in replying to you. I have now finished work for the day. I'll do the tests tomorrow at around 09:00 GMT. Thank you again for your help.

Chris

Chris Shaw · ‎01-18-2011

Good morning Peter,

I have tried pinging the next hop from the client PC with the same results. First ping times out. Again, pinging it from the router itself works perfectly. CEF is still enabled.

Thanks,

Chris

Peter Paluch · ‎01-18-2011

Chris,

Are you perhaps able to upgrade your IOS to a more recent 12.4T version? There may be issues related to this one.

Best regards,

Peter

Chris Shaw · ‎01-18-2011

Hello Peter,

I have already tried that. The IOS version on the router is 12.4(15)T14 which, as far as I can see, is the current release. Perhaps it's my lack of understanding of CEF that is causing my problem.

Chris

hobbe · ‎01-18-2011

well

I have learnet long ago that the reason the first icmp packet times out is because the router has to do a arp lookup of the mac address, and since icmp is not prioritized it times out the first time.

It makes sence to me so I have never realy questioned it.

ping router from switch drops first packet due to the arp lookup, and all consecutive icmp packets works fine

good luck

HTH