Introduction to DMVPN

Could you give some examples of how this would be good for a back up network? If our circuit to the internet goes down, arent we kinda screwed anyway? Thanks…

Not in the case where sites might have multiple circuits. For example, in my company, where we have locations all over the country, MPLS is our primary means of connecting sites, but if there is a problem with this circuit, or the provider, then a secondary standard Internet connection (many of our smaller sites simply use DSL or even 4G cellular), could take over with DMVPN configured over it.

Do you guys have GNS3 topology file for it?

We don’t have any GNS3 topology files but each DMVPN example does have configuration files. You will only have to create a new GNS3 topology, then copy/paste the commands.

Hi Rene
Could you help me with Phase 3. Since I read when we use phase 3 spoke router 1 want send data to spoke router 2 but it has to forward the traffic to hub router and hub router will it will realize that another spoke is the destination and it will then send a NHRP redirect to both spokes.
After that spoke1 will know how to establish direct GRE tunnel to spoke router 2 , then start to send their traffic. So does it mean that Spoke router 1 need to send its data 2 time ? since first one send to hub to get NHRP and after establish direct GRE with Spoke router 2 it start to send data again.
Please help

Hello Heng

This is a very good question. Looking at the process in more detail, when using Phase 3.

Initially, (and that is the key word) all spoke to spoke packets are switched across the hub. In order for a spoke to learn about the true NBMA IP address of another spoke, the NHRP redirect message is used.

So when a hub receives an IP packet inbound on its interface and switches it out of the same interface, it sends a special NHRP redirect message to the source indicating that this is a suboptimal path. It should look for a better way using NHRP resolution. The original packet however is still routed to its destination.

When the originating router receives the redirect message, it contains the destination IP address of the original IP packet as its payload. The router then sends the NHRP request for the redirected destination IP targeted originally, that is, the destination spoke. The resolution request travels via the regular IP routing path, through the hub until it reaches the target spoke.

The destination spoke responds to the resolution request using the IP of the source router sending it directly AND NOT THROUGH THE HUB, thus completing the spoke to spoke communication.

Now for your specific question, because the initial communication occurs via the hub, the hub still routes the packet successfully to the destination spoke. So the initial traffic sent does arrive at the destination spoke (via the hub) so it does not have to be resent. All subsequent communications that occur without the use of the hub will continue the flow of data.

I hope this has been helpful!



Hello lagapides
oh I almost got it, just a bit more. So mean when spoke 1 want to send data to spoke 2 first ip package is contain its data via destination of spoke 2 then hub router saw spoke 2 destination in its own NHRP cache so it will send redirect message back to spoke 1 to told that there is a better way to go to spoke 2 without through me (include NMBA address of spoke 2). am i right ?
Thank for you explaination

Hello Heng.

Yes you are correct!


1 Like

Hello Lagapides
Thank you so much for your time. I got it now .

Does DMVPN support QoS and multicast within the tunnels themselves? And can you use dynamic IPs for the hub and spokes? It seems hard to for the Hub, because you have to configure the NHS.

Hello Chris

It is possible to implement what is called Per Tunnel QoS for DMVPN. More information can be found here:

Secondly, multicast is also configurable over DMVPN. You can find out more about it at the following link. (Cisco refers to DMVPN using the iWAN marketing term in the document, but rest assured it is DMVPN).

As for the dynamic IPs, the hub MUST have a static IP, but the spokes can have dynamic IPs. Because the hub is a Next Hop Server (NHS), when the spoke brings the tunnel up it will register with the NHS via NHRP. Via this procedure, the hub will be informed of the dynamic mapping of public to private IPs for the spokes. Just make sure that the IP address of the hub is correctly referenced in the configurations of the spokes so they can register. This clearly shows why the hub IP must be static.

I hope this has been helpful!


1 Like

I notice that on all of your examples, you don’t use the “tunnel key” command? Is this only needed when multiple DMVPN configurations are used?

1 Like

Hello Chris

You are absolutely right. The tunnel key command is used to differentiate between the existing tunnels. The IP alone is not enough since the packet must be decapsulated to determine that, and you can’t do that unless you have the tunnel key. If there is only one tunnel, however, the tunnel key command is not needed.

In older IOS versions, this command was mandatory for DMVPN even if a single tunnel interface was used. This has been changed however, and this is why it is no longer necessary.

I hope this has been helpful!


1 Like

Hello Laz,

I don’t quite get the advantage Phase 3 has over Phase 2. Can you explain a little bit more?


Hello sales2161

The primary difference between the two has to do with how NHRP operates. As stated in the lesson, with Phase 2,

There are two requirements to make spoke to spoke tunnels work:

  • Spoke routers need to have a route for the network that they are trying to reach.
  • The next hop IP address of the route has to be the remote spoke.

Now the problem with this is stated like so in the lesson:

We are using a hub and spoke topology so only the hub will exchange routing information with the spokes. Depending on the routing protocol, it’s possible that the hub changes the next hop IP address of routes that it advertises to the spokes. When it does then a spoke will use the hub as the destination when it’s trying to reach a remote spoke.

This means that there will still be cases where the route the packets take will be via the hub, something that is undesirable and inefficient. Phase 3 solves this problem.

In Phase 3, the spoke routers don’t need to have a route for the remote spoke destination nor do they need a next hop address. Traffic from one spoke destined to another will begin being sent to the hub. When the hub receives the first packet, it discovers that the traffic is coming from a spoke, and that the destination is another spoke and it will send an NHRP redirect to both spokes. When this occurs, both spokes will send an NHRP resolution packet to discover each other’s NBMA IP address. This will then be installed in the routing table as new entries in both routers, and they can reach each other directly.

I hope this has been helpful!


Hi ,
Both Phase-1 & Phase-2 seems to be same. I didn’t find any difference in them . Can you please comment on this .

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!