Tunnel key in DMVPN why we need it?

[sarahr202]

Hi everbody,

I  just started reading about DMVPN and still not sure the why we need tunnel key in some cases.

Please consider the following . Below we have DMVPN phase1 set up:

HUB1 f0/0( 199.199.199.1/24)---INTERNET----- 200.200.200.1 f0/0 (SPOKE )

At HUB we have two M GRE interfaces  for two separate DMVPN , one DMVPN uses 10.0.0.0/24, the other uses 10.1.1.0/24 but both DMVPN uses the f0/0 as the tunnel source:

interface Tunnel0
 ip address 10.0.0.1/24
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel key 1
 tunnel source f0/0
 tunnel mode gre multipoint

interface Tunnel1
 ip address 10.1.1.1/24 
 ip nhrp map multicast dynamic
 ip nhrp network-id 2
  tunnel key 2
 tunnel source f0/0
 tunnel mode gre multipoint

Similarly Spoke has its own configuration 

interface Tunnel0
 ip address 10.0.0.2/24
 ip nhrp map 10.0.0.1 199.199.199.1
 ip nhrp map multicast 199.199.199.1
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1
  tunnel key 1
 tunnel source f0/0
 tunnel destination 199.199.199.1

interface Tunnel1
 ip address 10.1.1.2/24 
 ip nhrp map 10.1.1.1 199.199.199.1
 ip nhrp map multicast 199.199.199.1
 ip nhrp network-id 2
 ip nhrp nhs 10.1.1.1
 tunnel key 2
 tunnel source f0/0
 tunnel destination 199.199.199.1

Let say I issue a ping from spoke, sourced it from Tun0 to 10.0.0.1 on hub , I issue another ping from the same spoke ,  but sourced it from tun1 to 10.1.1.1 on hub .

So we will see tunnel key 1 is used in the first ping and tunnel key 2 is used in the second ping  inside GRE header, to help HUB determine which MGRE tunnel the ping belongs to.

Can't Hub determine that by looking at the destination ip in the encapsulated packet without the use of tunnel key? If yes, then why are we using tunnel key ?

Thanks and have a great weekend!!

[Karsten Iwen · Accepted solution]

Can't Hub determine that by looking at the destination ip in the encapsulated packet without the use of tunnel key? If yes, then why are we using tunnel key ?

The router first needs the tunnel key to pick the right tunnel before it can decapsulate the packet and look at the IP address. But better look at a scenario where you try to reach a destination behind the hub, or behind Spoke2-router. There, even theoretically, it couldn't be the IP address that is taken as a differentiator. It has to be the tunnel-key.

One more thing: If you extend your DMVPN with IPsec, you typically also have to apply the tunnel protection in a different way. You need the

shared

keyword when there can be two tunnels between two devices and both have the same tunnel-soource and tunnel-destination:

interface Tunnel1
 tunnel protection ipsec profile IPSEC-PROFILE shared

[sarahr202]

Thanks Karsten and Peter , it makes complete sense now.

Have a nice weekend.

[Peter Paluch · Accepted solution]

Hi Sarah,

Karsten is spot on, as always!

One more comment: In old IOS versions (I recall IOSes around 12.2, perhaps 12.3), the tunnel key was a mandatory part of DMVPN tunnel configuration even if a single tunnel interface was used. Without the key configured, NHRP simply did not come up. This is confirmed in the following document:

http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_addr/configuration/guide/hadnhrp.html#wp1060971

Old configuration examples may show the tunnel key staunchly configured even though there is no technical reason for it (you do not need to distinguish between different tunnel interfaces). Newer IOSes are fine without the tunnel key as long as you use just a single tunnel.

There is some additional technical information present on the removal of the mandatory key configuration in Petr Lapukhov's blog here:

http://blog.ine.com/2008/08/02/dmvpn-explained/

Best regards,
Peter