02-06-2003 11:15 AM - edited 03-02-2019 04:52 AM
I have a connection at one of my branches that is experiencing packet loss in the 10% range. I have been doing some ping tests and have noticed something strange. When i ping from within the network to anywhere outside the network i get a reply from the first 222 pings and than a time out request for the next 25(give or take 1) and than a reply for the next 222 packets sent and than a time out for the next 25. This happens over and over.
I have ruled out the inside of my network. We are currently on a DSL line with very little traffic right now.
Any suggestions on what might be a place to start troubleshooting or what can be causing this?
I have posted the router config with public ip's changed.
Tony
IT Manager
LANGLEY#sh run
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname LANGLEY
!
enable secret
!
ip subnet-zero
no ip source-route
no ip finger
!
ip inspect max-incomplete high 1100
ip inspect one-minute high 1100
ip inspect name ETHERNET_0 tcp
ip inspect name ETHERNET_0 udp
ip inspect name ETHERNET_0 ftp
ip inspect name ETHERNET_0 smtp
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key xxxxxxxx address 10.1.1.177
!
!
crypto ipsec transform-set PH esp-des
mode transport
!
!
crypto map TUNNELMAP 10 ipsec-isakmp
set peer 10.1.1.177
set transform-set PH
match address 155
!
!
!
!
interface Tunnel0
description LANGLEY-LIVONIA
ip address 192.168.0.2 255.255.255.0
no ip directed-broadcast
no ip route-cache
no ip mroute-cache
tunnel source Ethernet0/1
tunnel destination 10.1.1.177
crypto map TUNNELMAP
!
interface Ethernet0/0
description LAN
ip address 192.168.55.1 255.255.255.0
ip access-group 100 in
no ip directed-broadcast
no ip proxy-arp
ip nat inside
!
interface Ethernet0/1
description INTERNET
ip address 172.16.119.179 255.255.252.0
ip access-group 101 in
no ip directed-broadcast
no ip proxy-arp
ip nat outside
ip inspect ETHERNET_0 out
crypto map TUNNELMAP
!
ip nat inside source route-map NONAT interface Ethernet0/1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.116.254
ip route 192.168.2.0 255.255.255.0 Tunnel0
no ip http server
!
access-list 1 permit 192.168.0.0 0.0.255.255
access-list 100 deny ip 127.0.0.0 0.255.255.255 any log-input
access-list 100 deny ip 224.0.0.0 31.255.255.255 any log-input
access-list 100 deny ip host 0.0.0.0 any log-input
access-list 100 permit ip 192.168.0.0 0.0.255.255 any
access-list 100 permit icmp any any
access-list 101 deny ip 127.0.0.0 0.255.255.255 any log-input
access-list 101 deny ip 224.0.0.0 31.255.255.255 any log-input
access-list 101 deny ip host 0.0.0.0 any log-input
access-list 101 permit udp any host 172.16.119.179 eq isakmp
access-list 101 permit esp any host 172.16.119.179
access-list 101 permit gre any host 172.16.119.179
access-list 101 permit icmp any any
access-list 150 deny ip 192.168.55.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 150 permit ip 192.168.55.0 0.0.0.255 any
access-list 155 permit gre host 172.16.119.179 host 10.1.1.177
route-map NONAT permit 10
match ip address 150
!
banner motd ^C!!! This router is property of xxxxxxxx. Any unauthorized use
is strictly prohibited.!!!
^C
!
line con 0
exec-timeout 15 0
password
logging synchronous
login
transport input none
line aux 0
password
login
modem InOut
modem autoconfigure type usr_sportster
transport input all
speed 115200
line vty 0 4
access-class 1 in
exec-timeout 15 0
password
logging synchronous
login
transport input telnet
!
no scheduler allocate
end
02-06-2003 01:10 PM
Sounds like it might be an MTU and fragmentation problem. Is your ping tool making the packets bigger as it progresses? Try single pings of large packets that require fragmentation 1500+ bytes, and see if any get through. I dont know if IPSEC with ESP-DES expands packet length but the result may be that packets that the hosts think should get through end up being too big and are getting fragmented and trashed by IPSEC or rejected somewhere because fragmentation is required.
02-07-2003 03:00 AM
I agree. Sounds like a typical tunneling problem where a host sets dont fragment bit. This will make the router drop the packet.
Here is a fix with routemap supported from 12.0.1
Use policy routing to clear and set the DF bit in the data IP packet (available in Cisco IOS® release 12.1(6) and higher).
interface ethernet0
ip policy route-map clear-df
!
route-map clear-df permit 10
match ip address 101
set ip df 0
!
access-list 101 permit tcp any any
/Regards Jonas
02-07-2003 06:03 AM
Thanks for the reply.
This is happening for traffic not hitting the tunnel also. Would this still be the case?
I am on Ver. 12.0.4T. Would changing the MTU resolve this issue also?
Thanks
Tony
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide