Just a quick question
Is DMVPN Cisco proprietary or is there at multi vendor flavor?
Hello Orla
DMVPN is indeed a Cisco proprietary framework and is generally not interoperable with other vendors. However, some other vendors have attempted to create their own similar frameworks such has OpenNHRP which is a Linux DMVPN setup. Additionally the VyOS Linux distribution also has a similar functionality.
Ultimately, DMVPN should be used only with Cisco devices, as there is no guarantee that any use of other vendors in a DMVPN scenario will function correctly.
I hope this has been helpful!
Laz
What i think is missing on phase two DMVPN:
The hub will proxy the NHRP request to the hub owning the route. The hub receiving the NHRP request will then directly respond to the hub that originated the request.
Original story:
From: https://learningnetwork.cisco.com/s/article/dmvpn-concepts-amp-configuration
"R1 received a resolution request from R2 who says that he wants more details about the device 100.64.0.3 (R3). R1 then forwards this request down to R3. R3 then responds directly to R2 with itâs NBMA address. For resolution requests, the NHS acts as a proxy who forwards the NHRP resolution requests to the clients for them to resolve each other. "
Hello Jorisklop
Thanks for pointing this out. The lesson you are looking at is just the introduction to DMVPN and describes the various phases very briefly. For more details about DMVPN Phase 2 and how it operates, take a look at this lesson:
I hope this has been helpful!
Laz
Wouldnât the following one command accomplish the same thing as the three commands listed below it?
interface tunnel 0
+ip nhrp nhs 192.168.0.1 nbma 200.0.0.1 multicast
-ip nhrp map 192.168.0.1 200.0.0.1
-ip nhrp map multicast 200.0.0.1
-ip nhrp nhs 192.168.0.1
Hello Bruce
Since IOS 15.1(2)T and later, the ip nhrp nhs command has been expanded to support additional parameters. So to answer your question, yes, you can use the single command in your post to replace the three commands below it.
However, for the purposes of the lesson and to understand each distinct operation more clearly, the three separate commands have been used.
For more information about how the ip nhrp nhs command works, take a look at this Cisco command reference:
I hope this has been helpful!
Laz
Hi All,
What would be the impact of advertising the underlay network (NBMA Interface/network ) over the tunnels in IGP (EIGRP, ospf etc)?Please refer me to the link where this was explained if so.
Thanks
Hello PK10
Take a look at this diagram:
In this diagram, the underlay network is the 192.168.123.0/24 network. In a production DMVPN topology, those addresses would be public IP addresses on the Internet. So you are asking what the impact would be if the hub for example, advertised the 192.168.123.1 destination over the overlay DMPVN network using EIGRP or OSPF, correct?
The quick answer is it would cause a serious failure in the routing process. The overlay and underlay networks are supposed to remain separate, and advertising the underlay network on the overlay network would cause routers to attempt to reach the underlay interface addresses via the overlay network. They would attempt to reach the public addresses of their neighbors over the private DMVPN infrastructure.
Can I ask you a question too? What would be the purpose of advertising these network destinations on the overlay network?
I hope this has been helpful!
Laz
1 Like
Hello Laz,
Thatâs correct, many thanks for your support and response. Cheers.
1 Like
Hi All, I am new to this Forum. His there a lesson posted or discussion about Configuring ISP Redundancy on a DMVPN Spoke. Single Hub with One ISP and Spokes with dual ISPs.
Hello Marlon
Welcome to NetworkLessons! Great to have you with us, we hope you find the lessons and the forum useful to you.
There are many DMVPN lessons found on the site, the first of which is the following Introduction to DMVPN lesson:
You can start there and look through all the lessons. Now there is no lesson that addresses redundancy at the spoke using multiple ISPs. If you think that this would be a good lesson for Rene to create in the future, please feel free to let us know here on the Member Ideas page:
You may find that others have made similar suggestions, and you can add your voice to theirs.
In the meantime I can share with you that the use of redundancy at the spoke using multiple ISPs has become common practice, where one ISP is used as the primarily connection, and the other acts as a backup. One way to do this is to use VRF-Lite to segregate the routing table when a spoke has dual ISPs. With VRF-Lite, multiple VPN routing instances can be supported on the DMVPN spoke. An example of how to configure this can be found in the following Cisco documentation:
I hope this has been helpful!
Laz
This was what I was looking for. Thank you. However I would like to incorporate a redundant HUB router in this vrf example.
Hello Marlon
There are a couple of options for deploying hub redundancy in a DMVPN environment. You can find both of these options described in detail in the following lessons:
It is possible to combine the dual hub options above with ISP redundancy at the spokes. Although we donât have such a lesson on the site, it would be a great exercise to attempt to combine these two DMVPN design concepts. If you do attempt it please let us know how you get along, and if you need help along the way, you know where to find us!
I hope this has been helpful!
Laz
Hello, everyone!
Iâve a question about the NHRP resolution process.
After studying DMVPN for a while, Iâve noticed that this process is slightly different. It doesnât include just the originating spoke and the hub but also the destination spoke, like this:
So if I am not mistaken here, the resolution process also includes the destination Spoke as well, so it can create a mapping for the originating spoke and then send the reply. This communication doesnât take place between JUST the hub and the originator, right?
Kind regards,
David
Hello David
First of all, in the official definition of NHRP as described in RFC 2332, the hub is not required to send a resolution request to the destination spoke. However, some vendors, like Cisco, choose to send an NHRP notification to the destination spoke to let it know that another spoke has been informed of its NBMA IP address and may initiate direct communication. Although not a required part of the NHRP resolution process, it may be used to optimize the setup of the reverse path, facilitating the establishment of a bidirectional tunnel between the two spokes.
Secondly, such a behavior only really has any value for Phase 3 setups. In Phase 1, spoke-to-spoke tunnels are never established so there is no need for the hub to inform the destination spoke that another spoke wants to communicate with it. Similarly in Phase 2, while the spokes do establish direct tunnels with each other, the NHRP resolution process is typically initiated by the spoke that wants to establish the tunnel. The hub replies to this with the necessary information to establish a direct tunnel to the destination spoke.
Indeed, the NHRP process that is described in the lesson is a generic one and does not represent the specific processes seen in each phase. However, later on, when Rene describes the various phases, he does state for Phase 3 that:
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 a NHRP redirect to both spokes.
âŚwhich confirms the behavior you see.
I hope this has been helpful!
Laz
1 Like
Thank you very much Laz!
1 Like
Hi I have some questions⌠for some technologies or features like DMVPN how can i know which hardware and software is capable for this?? thx
Hello Edgar
For Cisco devices, you can use an online tool that is provided called the Cisco Feature Navigator found here:
https://cfnng.cisco.com/
You can use it as a registered Cisco user or as a guest. There you can browse all of Ciscoâs devices and IOS platforms either by feature, or by IOS version, and you can even compare the capabilities of particular OSes and platforms. Itâs the âgo-toâ place to find out what features are supported by what platforms.
I hope this has been helpful!
Laz