04-06-2017 07:03 PM - edited 03-05-2019 08:19 AM
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
04-07-2017 12:24 AM
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 ?
04-09-2017 06:52 PM
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!
04-09-2017 11:18 PM
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.
04-09-2017 07:49 PM
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.
04-10-2017 05:15 AM
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.
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