Introduction to DMVPN

Hi there.

In Phase 1, the spokes aren’t able to communicate with other spokes. They are only able to communicate with the hub. Also, the spokes build static point-to-point GRE tunnels to the hub.

In Phase 2, the spokes can communicate with other spokes by using the hub to reach the other spokes. In addition, the spokes build dynamic multipoint GRE tunnels to the hub (instead static of point-to-point GRE tunnels).

Hello Sirisha

@brandonwilson.mog has got it. As described in the lesson as well, Phase 1 has no spoke to spoke communication while Phase 2 does. Phase 1: all traffic goes through the hub, Phase 2: traffic can go directly from spoke to spoke WITHOUT going through the hub. If you go through the configuration of both of these, you will be able to see the differences more clearly. Take a look at these lessons:

DMVPN Phase 1 Basic Configuration

DMVPN Phase 2 Basic Configuration

I hope this has been helpful!


Hi Guys - I’m after a explanantion of of what a NBMA network actually is/means? What types of NBMA are common today apart from DMVPN? Thanks - Gareth.

Hello Gareth

NBMA essentially describes the functionality of a network at Layer 2. An NBMA network is:

  1. non broadcast - which means that communication can only occur from one host to another. Broadcast and multicast are not inherently supported.
  2. multiple access - multiple hosts share the same medium

In contrast, Ethernet is multiple access, but inherently supports broadcast communication.

For NBMAs, data is transmitted only directly from one host to another single host over a virtual circuit or across a switched fabric. Although not inherently supported, multicast and broadcast can be simulated by creating multiple unicast communications to create what are known as pseudo-broadcasts.

Once again, the NBMA operation is a Layer 2 phenomenon. You can run IP over NBMA networks and if configured correctly, IP operation will take place and will not know the difference. The only thing you may need to adjust is the split horizon rule for dynamic routing protocols.

Typical examples of NBMAs include ATM, Frame Relay, X.25 as well as home power line networks. As you can see from this list of technologies, apart from DMVPN, NBMA networks do not have an extensively wide application base, and are primarily older technologies that are on their way to being phased out. Nevertheless, there are still enough NBMA networks to warrant a good understanding of the mechanisms involved.

I hope this has been helpful!


DMVPN requires GRE, which adds an additional 4 byte header, plus a new IP header for total of 24 bytes minimum. What is best practice for tunnel MTU configuration? I’ve seen recommends of,

interface tunnel 0
ip mtu 1400
ip tcp adjust-tss 1360

Following the configuration in this lesson,

show ip interface tunnel 0
Tunnel0 is up, line protocol is up
Internet address is
Broadcast address is
Address determined by setup command
MTU is 1476 bytes

Hello Ronald

In general, if you are using GRE, you do require 24 extra bytes minimum as you correctly mentioned. As a result, you can use an MTU of 1500-24=1476 as in the configuration of the lesson, and it would work. However, it is of benefit to use something like 1400 ip mtu with a tcp adjust-tss of 1360 because this will make the IP MTU much smaller than the interface MTU of 1500 (for Ethernet) and thus allow for any stray QinQ frames (+ 4 bytes) or further tunneling that may occur. The TCP adjustment of 1360 causes hosts transmitting over such a link to negotiate TCP sessions with an even smaller MTU so that no fragmentation will be necessary.

So if you are administrator of the whole network infrastructure and you are sure that the MTU settings you are applying are enough, then you should maximize the MTU sizes to what is necessary. If however your topology involves a WAN provider or a neighboring network for which you do not have full control over, it may be a good idea to use the 1400 values to ensure that no additional overhead will cause fragmentation or packet loss.

For more info on MTU, MSS, and related configurations, take a look at the following lesson:

I hope this has been helpful!


1 Like

Thanks Laz - I’ve only ever known ethernet in my time as a network engineer so to imagine that something else can exist in it’s place at layer 2 is a strange concept for me! :open_mouth:

I’ve since heard that home power line network can actually be used to shuttle ethernet frames around too… absolute madness! :wink:

1 Like

A post was merged into an existing topic: DMVPN Phase 3 Basic Configuration

Hi Rene,

I have created the DMVPN config with EIGRP Phase 3. Everything works perfectly as described.
However, I have a question because I’m a little confused. You wrote that “It’s a hub and spoke network,
where the spokes will be able to communicate with each other directly without having to go through the hub”

What happens if the HUB device stops working? The Spoke to spoke communication will also stop, right?
Or, once the spoke to spoke tunnel is complete, the hub device is not necessary?

Thank You for you answer in advance,



Hello Laszlo

Yes, this is correct. Specifically for Phase 3, once the NHRP redirect is provided to the spokes by the hub, the hub is no longer necessary for the inter-spoke communication. Even if the hub goes down, the spoke routers have already installed a new entry in the routing table so that they can reach each other directly.

This is not the case for Phase 2 however. This is because the hub and spokes exchange routing information, and because spoke routers need to have a route for the network they are trying to reach (remote spoke). This means that, depending on the routing protocol, it is possible that the hub may change the next hop IP address of routes that it advertises to the spokes. When this happens, a spoke will use the hub as the destination when it’s trying to reach a remote spoke. If the hub had gone down, this will cause a failure.

Phase 1 makes all traffic go though the hub, so in this case, if the hub goes down, the network will fail.

I hope this has been helpful!


Hi Guys,

I would like to know, i configured a DMVPN and used a private ip address as my tunnel source. I then natted that private to a public ip on the firewall. The DMVPN can up but on the HUB under show ip DMVPN i see my private ip. Just would like someone to explain this is possible I would upload some config but this was on a device on production. But if this will help get me an response i can make a plan.


Hello Robert

If I have understood correctly, you have a DMVPN HUB that is behind a NAT device. You are using the private IP address as the tunnel IP. In this case, when you issue the show ip dmvpn command, you will indeed see the private IP. There is no way for you to see the public IP since NATting is taking place on another device.

Is the DMVPN working correctly? I’m not sure I understood exactly what the specific problem you are facing is. Can you clarify?

In the meantime, take a look at this discussion on the Cisco Community about a similar situation that may shed some light on your issue.

I hope this has been helpful!


Hi Laz,
Thanks for quick reply, ok…

At a spoke site i have DMVPN router behind a firewall. I dont have enough public IP address at spoke site as i am also running multiple contexts on the firewall. So i used a private IP address on my Spoke router, as tunnel source, and natted that ip on my firewall ( to public ip address). when i look at the show DMVPN on the Hub im seeing my private address (not natted public ip) that Hub route. Everything is working im just curious as to how i can nat a Private ip at spoke site, to firewalls public and at the Hub site route im seeing the private ip i used at spoke.

Hello Robert

When DMVPN is configured with a spoke behind a NAT device, the NHRP table entry in the Hub contains both the post-NAT and pre-NAT address. This is because the spoke will send it’s pre-NAT address within the NBMA information, while the Hub will detect a source IP address of the packet as that of the post-NAT address. If you do a show ip nhrp on the Hub, you will see something like this:

Router# show ip nhrp via, Tunnel0 created 00:00:21, expire 00:05:38
Type: dynamic, Flags: authoritative unique registered used
NBMA address:
(Claimed NBMA address:

Where there is an NBMA address (the post-NAT address) and the claimed NBMA address (the pre-NAT address).

DMVPN can function behind a NAT router, using the The NHRP Spoke-to-Spoke Tunnel with NAT feature which is enabled automatically, so you don’t actually have to configure it. You can find out more information about this at the following Cisco documentation:

I hope this has been helpful!


Hi laz,

I am little bit confused about NHRP messages, do we use concept of NHRP Registration request and NHRP resolution reply in all phases and phases same order will follow like first NHRP registration request ti hub then Hub will send NHRP Resolution reply?

Hello Pradyumna

For phases 1 and 2, NHRP operates in the same way. The spokes register to the hub, and the hub tells the other spokes the public IP address of the spoke they are looking for when they request it. That way, communication can take place between spokes, either through the hub (Phase 1) or directly from spoke to spoke (Phase 2).

NHRP differs only for Phase 3. In this case, traffic sent from one host to another will initially go to the hub, the hub will see the destination IP address and will immediately know to which spoke this is destined. It will then respond with an NHRP redirect which gives enough information to both sender and receiver spoke to communicate with each other.

I hope this has been helpful!


Thanks for clarifying Phase 1 and phase 2 but in phase 3 as per your explanation spokes would not sent NHRP request message they will start communication by sending traffic to each other but it will go through Hub (mean they send traffic to hub and hub decide what to do) in response of that hub send NHRP redirect message post that spoke start communicating directly instead of go though Hub. Am I right?

Hello Pradyumna

Yes, this is correct. All spoke to spoke communication initially goes through the Hub. This triggers the hub responding with an NHRP redirect which contains next hop information, allowing all subsequent communication to go directly between spokes.

I hope this has been helpful!


Thanks Laz now I got it.

1 Like

Hi Laz,

1)But Laz as per this topic, In Phase 3 post receiving redirects message from hub spokes will send nhrp resolution message so my concern is that how hub will know the NBMA addresses of these spokes b/c spokes did not send any nhrp registration message to register their public addresses to the hub?
2)Could you explain this GRE encapsulated ip packet formation and removal from source to destination.
3)one more doubt is that, as we know actual source and destination ip address are public ip addresses so as per me these must be encapsulated as a inner source and destination ip addresses instead of tunnel interfaces ip address.
Kindly explain whole process if you can?