DMVPN Phase 3 Basic Configuration

Hello Roman

Typically, when running DMVPN behind an ASA firewall, there are several options, two of which suit your situation.

The first involves placing the DMVPN router in the DMZ of your ASA, and assigning it a public address, which means you can filter traffic, but you don’t actually have to open specific ports. The other involves having the DMVPN router behind the firewall, in which case you will need to open/forward some ports. From my understanding, it is the second scenario that you require.

For this you must forward ports udp 500 and udp 4500 for nat-t, but also, as per this Cisco documentation, you have the following restrictions:

  • For the NAT-Transparency Aware enhancement to work, you must use IPsec transport mode on the transform set.
  • If one spoke is behind one NAT device and another different spoke is behind another NAT device, and Peer Address Translation (PAT) is the type of NAT used on both NAT devices, then a session initiated between the two spokes cannot be established.
  • For best DMVPN functionality, it is recommended that you run the latest Cisco IOS software Release 12.4 mainline,12.4T, or 12.2(18)SXF.

I hope this has been helpful!

Laz

Laz ,

Thanks for your response. The 2nd scenario is something that I would like to eventually implement in my lab. I will go over the Cisco doc. and play with it. Hopefully I will figured out , it will be great opportunity to learn something new. Thanks again to point me in right direction.

-Roman

1 Like

Hi Laz,

In DMVPN Phase 3 when spokes router receive NHRP redirect message then they send NHRP resolution request message so question is here that to whom they send NHRP Resolution Request message, to each other or Hub router ?

Hello Pradyumna

Take a look at this post:

You should find your answer there.

I hope this has been helpful!

Laz

Hi Laz,

I got it but still have a doubt is that post getting NBMA address of spoke 2 through redirect message then why spoke 1 router still sending a NHRP resolution request through Hub to the spoke 2 as you mentioned?

Hello Pradyumna

Yes, it is interesting that when the originating router (spoke 1) receives the redirect message from the HUB, it then sends an NHRP request to the proper spoke (spoke 2). Notice here that the target of the request is not the hub, but the request does traverse the hub. This is because the resolution request travels via the regular IP routing path, which is via the HUB, because the HUB originated the prefix to spoke 2. It is only when spoke 2 responds to the resolution request that it responds directly (not via the HUB). Once spoke 1 receives this, it can then communicate directly with spoke 2.

I hope this has been helpful!

Laz

Ok got it Laz so we can say it will be send two times by spoke 1, first for getting a nbma address of spoke 2 and second for getting a response directly from spoke 2 so they communicate directly, am i right…

Hello Pradyumna

Yes you got it!! Glad to be of help!

Laz

1 Like

This version dont work either.

HUB(config)#interface tunnel 0
HUB(config-if)#ip nhrp redirect
% NHRP-WARNING: 'ip nhrp redirect' failed to initialise
HUB(config-if)#



HUB(config-if)#do sh ver | i IOS
Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)S6, RELEASE SOFTWARE (fc1)

NOT WORKING FOR ME.
ANY WORKING IOS CODE PLEASE.

Hello Network J

As Andrew has mentioned in his post, the solution to the problem is to use the M-train image c7200-adventerprisek9-mz.152-4.M6. It seems that you are using the S-train image. Now the S-train image does indeed support this command on real hardware, but for some reason, it doesn’t work on GNS3.

This has also been confirmed at this GNS3 forum post.

I hope this has been helpful!

Laz

Hi,

In the OCG book I found this question.

“Which DMVPN phase introduced hierarchical tunnel structures?”
The answer is phase 3.

Can you explain this question ? What is exactly meaning with “hierarchical tunnel structures”?

Thanks

Hello Giovanni

A hierarchical DMVPN topology is one where you have multiple levels of hubs. In other words, you can have a spoke that plays the role of a hub to multiple sub-spokes. The following Cisco documentation describes this in detail:

https://www.cisco.com/c/en/us/support/docs/security/dynamic-multipoint-vpn-dmvpn/211292-Configure-Phase-3-Hierarchical-DMVPN-wit.html

Only Phase 3 DMVPN supports this topology.

I see that this question is specifically in the CCNP Enterprise Advanced Routing ENARSI 300-410 Official Cert Guide. Note that this type of DMVPN topology is not explicitly described as being in the list of covered topics, however, it is good to know about it.

I hope this has been helpful!

Laz

Hi
I need help for another question about DMVPN. (Ref. BosonExamSim)

Based on this output.

RouterA#show ip nhrp detail
10.10.10.5/32 via 10.10.10.5, Tunnel0 created 00:05:40, expire 00:00:41
  Type: dynamic, Flags: authoritative unique nat registered used
  NBMA address: 172.16.0.44

Which of the following statements is true?

  • The mapping cannot be overwritten by a different NBMA entry with the same IP address
  • The mapping was obtained from NHRP resolution request or packet
  • something wrong

The first answer is correct (the unique keyword is the key of the question), but why the second one is considered wrong?

Also, why we need a phase 3 DMVPN if phase 2 can provide a direct connectivity between spokes?

Thank you

Hello Giovanni

The question has to do with the specific flags that are outputted by this command. Each flag has a different meaning. You can see the meaning of each one at the following command reference:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/s1/sec-s1-cr-book/sec-cr-s4.html#wp2302625547

According to this command reference for the unique flag, "This flag indicates that an NHRP mapping entry cannot be overwritten by a mapping entry that has the same IP address and a different NBMA address.

Similarly, it is the implicit flag that “Indicates that the local node learned about the NHRP mapping entries from the source mapping information of an NHRP resolution request received by the local router, or from an NHRP resolution packet being forwarded through the local router.”

In the output, there is a unique flag, but no implicit flag, thus the first answer is correct and not the second.

Both Phase 2 and Phase 3 enable directly spoke to spoke communication, however, they do so in different ways. The difference is in how NHRP operates. Take a look at the explanation of both Phase 2 and Phase 3 in the following lesson:

I hope this has been helpful!

Laz

Hi rene,

Could you please tell me what are the advantages of using DMVPN phase 3 compared to phase 2. I understand that a “redirect” message is added which in a summary environment helps to create dynamic entries in Spokes (H/DT1), but there is something more? Assuming I don’t have route summarization, would there be benefits?

Hello Christian

Indeed DMVPN Phase 2 and Phase 3 sound somewhat similar, and both require the hub to inform the spokes of the next hop IP of the destination spoke using NHRP. The primary difference is the following:

Phase 2 requires:

  • spoke routers to have the route they are trying to reach in their routing table
  • the next hop IP address of the route must be the remote spoke

Whereas Phase 3:

  • Does not require a route to the specified destination in the routing table
  • Has no restriction on what the next hop is.

Now you already know this, but I’ve added it here for completion. When do these behaviors really make a difference? When you increase the number of spokes. It all has to do with scalability.

Imagine a network with hundreds of spokes. Each spoke is required to have a route to the destination network. Therefore each spoke will have a routing table entry for each of the destination networks behind all other spokes. And since summarization is not possible because by definition spokes need specific routes, there is no way to alleviate such large routing tables.

Phase 3 resolves this scalability by changing the way NHRP operates. When a spoke router wants to reach a remote spoke, they will forward their traffic to the hub. When the hub receives the traffic, it will realize that another spoke is the destination and it will then send an NHRP redirect message to both spokes allowing them to resolve each other’s NBMA IP addresses. The spoke routers will then dynamically install a new entry in the routing table so that they can reach each other directly. This results in much MUCH smaller routing tables, which becomes important when you have dozens, hundreds or even thousands of spokes.

So for small networks, Phase 3 gives you virtually no advantages compared to Phase 2, but the differences will only become significant as the number of spokes dramatically increases.

I hope this has been helpful!

Laz

Hello, Laz.

I’ve a question about your reply above.

Imagine a network with hundreds of spokes. Each spoke is required to have a route to the destination network. Therefore each spoke will have a routing table entry for each of the destination networks behind all other spokes. And since summarization is not possible because by definition spokes need specific routes, there is no way to alleviate such large routing tables.

So summarization in Phase 2 is not possible on the hub because that would break the idea behind having direct spoke-to-spoke communication. But what about summarizing networks on the spokes instead? That would work, wouldn’t it?

But then again, if we had hundreds of spokes, that would mean hundreds of summary routes, right? While with summarization performed on the hub, we could just have one large summary route generated by the hub which would include all the networks behind the spokes, right?.

Thank you.

David

Hello David

You’re correct in your understanding. In Phase 2, summarization on the hub would indeed break the direct spoke-to-spoke communication. This is because the hub would not have specific routes to each spoke, which is a prerequisite of Phase 2, making it impossible to form direct tunnels between spokes.

As for summarizing on the spokes, there are two issues here. Yes, spokes can and should summarize the networks that are behind them, so that they can share them more efficienty with the rest of the DMVPN topology. However, it is counterproductie for a spoke to have a summary route to multiple destinations behnind other spokes, as this can negate the direct spoke to spoke communication. So although it is technically possible, note that each spoke would still need to maintain a specific route for every other spoke in order to allow for direct communication. This means that even with summarization at the spokes, the routing table on each spoke could still be quite large if there are hundreds of spokes.

While it might seem like summarizing on the hub would simplify things, remember that the hub in a DMVPN Phase 2 setup doesn’t make routing decisions for the spokes. Each spoke makes its own decisions based on its own routing table. The hub merely acts as a facilitator for the initial communication between spokes using NHRP. Therefore, a summary route on the hub, even if it were possible in Phase 2, wouldn’t really help alleviate the large routing tables on the spokes.

I hope this has been helpful!

Laz

Hello, everyone!

I have a question about the NHRP timers. By default, how long will the NHS and the spokes (in Phase 2/3) keep the dynamic entries in their NHRP cache?

I’ve read that the default NHRP timer is 7200 seconds. But my spokes actually include 600 seconds in the NHRP Registration Requests
obrázok
After this time expires, they send a new registration request to keep the NHRP entry renewed.

So how do these timers work? What are their default values?

Thank you!

David

Hello David

If you look at the RFC 2332 which defines NHRP, the holding time is defined as the number of seconds for which the next hop NBMA information specified is considered valid. Cached information is discarded when the holding time expires. But there’s an additional timer value that is involved as well. The RFC also says that:

It is recommended that the NHRP Registration Request packet be sent at an interval equal to one-third of the Holding Time specified therein.

Now, nowhere in the RFC does it state a default for the holding time value, and as you can see, the reregistration is “recommended” to take place at one-third of the Holding Time. This kind of language means that vendors have flexibility in setting their own timers.

According to this Cisco Documentation, the default holding time is indeed 7200 seconds or two hours, and registrations are sent every 2400 seconds (one third of the holding time). However, Cisco recommends changing the value of the holding timer to a value between 300 and 600. Some more modern Cisco devices will have a default of 600 and that’s probably why you see that value in your packet capture.

Cisco allows you to change the holding timer using the ip nhrp holdtime command, and it also allows you to change the reregistration from the default of 1/3 of that to whatever you like, using the ip nhrp registration timeout command.

I hope this has been helpful!

Laz