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,
Regards,
Laca
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!
Laz
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.
Regard
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!
Laz
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
10.0.0.11/32 via 10.0.0.11, Tunnel0 created 00:00:21, expire 00:05:38
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 172.18.2.1
(Claimed NBMA address: 172.16.2.1)
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!
Laz
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!
Laz
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!
Laz
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?
Hello Pradyumna
In all three phases of DMVPN, NHRP is used to allow spokes to register with the hub. NHRP clients register themselves with the NHRP server and report their public IP address. This does not change for Phase 3. If you look at the DMVPN Phase 3 Basic Configuration lesson, you will see that the output of the show dmvpn command on the hub displays the tunnel and peer addresses of the spokes.
What does change in Phase 3 is that spokes no longer need specific routes to reach other spokes. Specifically, it doesnāt matter what the next hop IP is. As Rene states:
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.
The hub sends this NHRP redirect to the addresses of the spokes, which it knows.
The logic behind a multipoint GRE tunnel used in DMVPN and a normal GRE tunnel is the same. The difference is in implementation. When you want to send a packet over a GRE tunnel, you must know the tunnel destination (which is the public IP address) and the IP address of the tunnel interface (the addresses used by the tunneled packets). With normal GRE, you simply configure these statically. When multipoint GRE, the NHRP protocol is used to determine the addresses. Take a look at the following lesson on GRE tunnels which describes this process, and then you can apply the process to the multipoint GRE tunnels as described in the DMVPN lesson.
As mentioned before, the logic of DMVPN GRE multipoint tunnels is the same as normal GRE tunnels. The public IP addresses are always on the outside IP packet, (the IP address of the interface in the case of normal GRE) and the private addresses are the tunneled addresses, which are those of the tunnel interface. The following image from this Cisco documentation shows the outer tunnel header containing the public IPs and the inner IP header containing the private IPs.
I hope this has been helpful!
Laz
Hi Rene,
Shall we use static route for routing in DMVPN?
Hello Ajimal
It is possible to use static routing for DMVPN. This would be an acceptable scenario if we had two or three spokes. However, the advantage of DMVPN is the fact that you can easily add dozens of spokes quickly with little administrative overhead, but this requires the use of a dynamic routing protocol. Otherwise, administratively, it would be very difficult to have to adjust the static routes of dozens of spokes every time a new spoke is added.
I hope this has been helpful!
Laz
Hello facilitators,
I enjoyed reading DMVPN topic which was presented in a concise, illustrated manner. I have questions. Is the dynamic GRE related to DMVPN or an alternative name of DMVPN? If not, where may I find the dynamic GRE within NetworkLessonsā learning topics? Thank you.
Hi
Is DMVPN a deprecated technology?
If so, which one is the new alternative?
Thanks
Hello Giovanni
DMVPN is alive and well and is used often in production environments. It has many advantages including:
- cheap - itās much cheaper than MPLS or Metro Ethernet since it is used over regular Internet connections
- scalable - you can easily and dynamically add more spokes with minimal configuration and parameterization as your network grows
- secure - by adding IPSec, you can ensure confidentiality of communications
Alternatives that you can use include FlexVPN, MPLS, or SD-WAN.
I hope this has been helpful!
Laz
Hello Hoang
Multipoint GRE or mGRE is a protocol that is used to enable point to multipoint GRE tunnels. An excellent example of how this can be configured is found in the following Cisco community forum thread:
mGRE can use NHRP for correct routing between interconnected networks, but it is not obligatory. All you need is IP reachability between endpoints.
Now where does DMVPN come in? Well, DMVPN uses mGRE to dynamically create and tear down mGRE tunnels as needed in order to enable its operation. DMVPN requires both mGRE and NHRP to operate.
So DMVPN is a configuration framework, which uses the mGRE protocol to dynamically create and tear down tunnels, and NHRP to correctly be informed about specific routes to particular destinations.
I hope this has been helpful!
Laz