cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
511
Views
0
Helpful
3
Replies

Strange Packet Loss Problem

enikk
Level 1
Level 1

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

3 Replies 3

rjackson
Level 5
Level 5

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.

jonnyl
Level 1
Level 1

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

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