VPN Tunnel drops with high internet usage

[sfairbanks]

Hi,

I am very new to Cisco and have inherited a network that has a VPN tunnel to a branch office in Manila from Sydney. The manila branch is noticing that when high utilisation occurs on their 25Mbps link that the tunnel drops and their VOIP (and other services that rely on the tunnel) stops working.

Does anyone have any suggestions on how to go about troubleshooting any further? I am thinking that maybe its the QOS settings or the allocated bandwidth for the tunnel? I have posted a cleaned up config for any comments suggestions?

no ipv6 cef
ip source-route
ip cef
!
!
ip nbar port-map cifs tcp 137 138 139 445
ip nbar port-map smtp tcp 25
ip nbar port-map netbios tcp 137 138 139
ip nbar custom REMOTE tcp 3389
ip nbar custom LDAP tcp 389
!
!
!
!
multilink bundle-name authenticated

class-map match-any VOIP
 match ip dscp ef
class-map match-any REMOTE
 match protocol REMOTE
class-map match-any SHARED
 match protocol netbios
class-map match-any LDAP
 match protocol LDAP
class-map match-any SMTP
 match protocol smtp
class-map match-any EXCHANGE
 match protocol exchange
class-map match-any SIGNAL
 match ip dscp cs3
class-map match-any HTTPS
 match protocol secure-http
!
!
policy-map MQC
 class VOIP
  priority 1000
  set ip dscp ef
 class SIGNAL
  bandwidth 200
  set ip dscp cs3
 class REMOTE
  bandwidth 500
 class SHARED
  bandwidth 500
 class LDAP
  bandwidth 500
 class SMTP
  bandwidth 1500
 class EXCHANGE
  bandwidth 500
 class HTTPS
  bandwidth 2000
 class class-default
  fair-queue
  random-detect
  set ip dscp default
  shape average 10000000
!
!
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key XX address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TS XXX
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set TS
!
!
!
!
!
!
interface Loopback100
 ip address 172.16.100.6 255.255.255.0
!
interface Tunnel100
 description DMVPN Interface
 ip address 172.16.1.6 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication cbdmvpn1
 ip nhrp map multicast dynamic
 ip nhrp map multicast 202.X.X.X
 ip nhrp map 172.16.1.1 202.X.X.X
 ip nhrp network-id 1
 ip nhrp holdtime 600
 ip nhrp nhs 172.16.1.1
 ip ospf network broadcast
 ip ospf hello-interval 30
 ip ospf priority 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN
!
interface GigabitEthernet0/0
 description Connects to ADSL Router
 ip address 112.X.X.X 255.255.255.248
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 description Connects to XXX SIN LAN
 ip address 10.10.1.253 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 duplex full
 speed 1000

[Georg Pauwen]

Hello,

the config looks good actually, the only thing you could add is 'tunnel path-mtu-discovery' under your tunnel interface configurations.

Also, you might want to consider using OSPF as non-broadcast, which requires to statically define the OSPF neighbors at both ends:

interface Tunnel 100

ip ospf network non-broadcast

router ospf 1

neighbor x.x.x.x

This could add stability to your connection. Can you try that and see if it makes a difference ?

[sfairbanks]

Hi Georg,

I have added the first suggeston of tunnel path-mtu-discovery into both locations to see how that goes. I also have a branch in Mumbai and Bankok, how would I configure non-ospf-broadcast for these also, same command in each tunnel? Just nervous about shutting the vpn down and having no access to fix it!

[Georg Pauwen]

Hello,

yes, the non broadcast OSPF would be configuredon all tunnels.

When you don't have out of band access, a good practice would be to save the current running (and working) configuration to nvram (copy run start), then issue a 'reload in 3', which would reload the router in 3 minutes. So in case you lose connectivity, caused by entering anything that doesn't work, the router would reload in 3 minutes, and you would have connectivity back. Otherwise, cancel the reload.

[Paul Smith]

The tunnel may not actually drop, it may just be saturated. Logging would you tell you if the interface did go offline.

It makes sense that VOIP would stop working if the connection gets flooded. The fact that the tunnel can achieve speeds of 25Mbps is a good sign in itself. Maybe try and get some sort of netflow data and see what is saturating the tunnel, then try and control it.

You could also put some QoS in place to ensure VOIP gets first priority.

[Joseph W. Doherty]

First part of trouble shooting might be to clarify what exactly a "tunnel drop" means.

Next part of trouble shooting is obtaining a full understanding of your DMVPN topology.

Some tunnels will "drop" when there's enough congestion to drop (or sometimes sufficiently delay) certain control packets.