DMVPN Phase 3 Basic Configuration

Lessons Discussion
42

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

43

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

44

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

45

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

46

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?

47

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

48

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

49

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

50

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

51

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