Keeping all DMVPN spoke to spoke tunnels up permanently

[Ahmed Dockrat]

Hi

I've got a DMVPN running over a MPLS network, running DMVPN phase 2 between all the CE's.

All Hub to Spoke & spoke to spoke is working correctly.

Is there any way to keep all the spoke to spoke tunnels up permanently so that they don't need to dynamically initiate when traffic between spokes is generated ? Only options I can think of would be multiple IP sla monitors on each router or a Hub to spoke setup between every spoke, the 2nd option would become very messy. Ipsla could be do-able but just wondering if there's a smarter way of doing this.

Thanks

[paul driver]

Hello

Why would you want to, Thats the whole point of DWVPN - so not to create static configuration for spoke to spoke tunneling?

res

Paul

[Ahmed Dockrat]

I'm concerned that there may be issues with voip from a spoke to spoke site as there will be a slight drop when the spoke to spoke tunnel initiates, voice signalling would be from Spoke  to a gateway behind the HUB, so spoke to spoke would only initiate once the RTP stream begins.

[paul driver]

Hello

Do you has a QOS applied for the voice traffic?

res

Paul

[Ahmed Dockrat]

Hi

yes I'm using qos to protect voice traffic against link congestion

[m-avramidis]

Ahmed, what type of routing protocol are using over the tunnels? When I designed VoIp over DMVPN phase 3, then the only protocol that worked (QoS) was EIGRP and/or BGP.

[Ahmed Dockrat]

I'm using EIGRP over the DMVPN

I've disabled EIGRP split horizon & eigrp next hop self so that the spoke route directly between each other, just concerned that the delay when a spoke to spoke initiates a call may be an issue due to the tunnel initiation.

Did voip work properly over the dmvpn from spoke to spoke, and was your voip setup using RTP directly between endpoints or was RTP running through a voice gateway & back down to the remote site

[paul driver]

Hello

Would you be able you post the tunnel config of  the NHS and a NHC ?

res

paul

[m-avramidis]

this is the spoke config that I used (phase 3):

interface Tunnel1
description *** "Country" "Site"  ***
bandwidth XXXXXX
ip address 10.XX.XX.XX 255.255.255.0
no ip redirects
ip mtu 1400
ip pim sparse-dense-mode
ip flow ingress
ip flow egress
ip nhrp authentication XXXXXXX
ip nhrp map 10.XX.XX.XX "hub router public IP"
ip nhrp map multicast "hub router public IP"
ip nhrp network-id XXXXXXX
ip nhrp holdtime 600
ip nhrp nhs 10.XX.XX.XX
ip nhrp shortcut
ip nhrp redirect
ip tcp adjust-mss 1360
delay 1000
tunnel source gig0/0
tunnel mode gre multipoint
tunnel protection ipsec profile XXXXX
!

Hub RTR config:

interface Tunnel10
description *** HubTu Interface NET-10.XX.XX.1/24 ***
bandwidth 100000
ip address 10.XX.XX.1 255.255.255.0
no ip redirects
ip mtu 1400
ip pim sparse-dense-mode
ip flow ingress
ip nhrp authentication XXXXXX
ip nhrp map multicast dynamic
ip nhrp map multicast public IP
ip nhrp network-id XXXXXX
ip nhrp holdtime 600
ip nhrp nhs 10XX..XX.1
ip nhrp shortcut
ip nhrp redirect
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
ip policy route-map DMVPN
load-interval 30
delay 2000
qos pre-classify
tunnel source public IP
tunnel mode gre multipoint
tunnel protection ipsec profile XXXXXXX

The QoS is as you can see configured on the hub router. There is some kee configuration statements missing above (route-maps and such), I am not allowed to post these for the next 20 yrs....

[paul driver]

Hello

Have you tried tweaking the nhrp holdtime or using a specific registration timeout value, Maybe these are interrupting your voip traffic?

Instead of using the generic holdtime value, Currently set on both your NHS/NHC to 600 secs (10mins)
You could override this by applying specific value that will send a registration request at the value you state and not as per default every1/3 of your present hold time which in your case is every 200 secs that a registration request is hitting your hub from each client.

 
NHC
Int tun x/x
ip nhrp registration timeout 600

res

Paul

[Joseph W. Doherty]

I'm not current on the latest DMVPN versions, so I'm unaware if there's any option to keep the dynamic spoke-to-spoke tunnels up as long as you choose.

Besides using SLA, which should keep the tunnels alive, other options might include interface "keep alive" often doesn't work on crypto tunnels or perhaps enabling tunnel interface CDP (only works across later IOS version tunnels - haven't tried on DMVPN).

[fabio rocha]

You may want to take a look at this:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nhrp/configuration/15-mt/nhrp-15-mt-book.pdf