This topic is to discuss the following lesson:
https://networklessons.com/cisco/ccie-enterprise-infrastructuredmvpn-phase-2-basic-configuration
Thanks for the good explanation Rene. I am using Cisco 7200 with IOS version 12.4(24g) but show dmvpn command is not working. Other configuration commands to setup DMVPN worked.
R1#show dmvpn
^
% Invalid input detected at '^' marker.
R1#
Hello Abhishek
It seems that this command is not available in your IOS version. You can see from the following Cisco CLI reference, that the command was introduced in the T train of code and not in the mainline which is your IOS version.
Even so, this is simply a show command that conveniently displays the components of the topology. You can still obtain the same information with a variety of other show commands such as those indicated in the following Cisco document:
Note this document was published before the introduction of of the show dmvpn command.
I hope this has been helpful!
Laz
Hello Rene
Hope you doing great.
On show dmvpn output I see Attrb → S for Spokes routers meaning that the NBMA peer Address is learned Statically.
Shouldn’t be Attrb → S like the Hub router?
Thank you in advance!
Regards,
Victor
Hello Victor
When you use DMVPN with NHRP in the configuration found in the lesson, on each spoke you use the following command:
ip nhrp map <tunnel address> <hub NBMA address>
This creates a static peer address, and that’s why you see the “S” indicator on the spoke router. This is considered a statically configured NBMA peer address.
On the hub, however, you have no such configuration. The hub is configured to accept NHRP requests to dynamically add the addresses of the spokes. For this reason, on the Hub, you will see the “D” designation that these are dynamically learned addresses.
You can, however, configure static spoke addresses on the hub if you like, but this defeats the purpose of the simplicity of implementation and the scalability of DMVPN.
I hope this has been helpful!
Laz
I hope this has been helpful!
1 Like
Hi Laz,
Please explain the commands by taking example of IPs we used in n/w topology for DMVPN.
- ip nhrp map 172.16.123.1 192.168.123.1
- ip nhrp map multicast 192.168.123.1
3)ip nhrp nhs 172.16.123.1 ( why are we using tunnel address here, it should be
public ip) - diff b/w ip nhrp map multicast dynamic and ip nhrp map multicast
192.168.123.1 - ip nhrp mode multipoint command instead of tunnel destination address.
we know tunnel destination command is being used to specify destination
address but multipoint mean it can be both source and destination ip. so how
can we replace tunnel destination command by ip nhrp mode multipoint
command?
Hello Pradyumna
For the first four points of your question, these commands are explained in detail in the following lesson:
Also keep in mind that the ip nhrp nhs command must indicate the tunnel IP as configured, and not the public IP.
For your last question, the primary difference between Phase1 and Phase2 is that in Phase2 you can have spoke to spoke communication. It is the multipoint mode that is configured on the spokes that enables this specific feature.
I hope this has been helpful!
Laz
Hello, everyone!
I have two questions.
-
What did Rene mean by “Summarization on the hub is not possible since the spoke routers require specific routes.” I can’t quite wrap my head around this.
-
How does plaintext NHRP authentication by using the
ip nhrp authenticationcommand work? The OCG says that it’s sent in plaintext, yet I can’t see it in the Authentication extension
And is it possible to configure a more secure authentication than just plaintext?
Thank you!
Kind regards,
David
Hello David
First of all, this statement is made in the Introduction to DMVPN lesson, and is specifically referring to the DMVPN Phase 2 topology.
Phase 2 enables the direct communication between spokes, however, this can be achieved only if the following two prerequisites are fulfilled:
- 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.
If summarization were configured on the hub in a Phase 2 DMVPN network, the spokes would not learn about the specific networks behind other spokes through the summarized routes. This is because summarization introduces a loss of specificity in route information. In other words, the hub would advertise only the summary route to the spokes, not the individual subnet routes that make up the summary. Thus, the prerequisite is not fulfiled.
When ip nhrp authentication is configured for a DMVPN setup, all NHRP control messages that are exchanged between devices include the authentication string within an NHRP Authentication Extension. This extension is a part of the NHRP packet and is used to carry the plaintext authentication string. In the wireshark capture that you shared, you can see the NHRP Authentication Extension that you have expanded. The value shown in the “data” section is the plain text password you used, in hexidecimal. If you look at the pane to the right in your wireshark capture, you will see the plain text password. Here is an example of another NHRP message with the plain text authentication string shown:
Although the string is shown in hex in the left pane, the pane to the right shows that the plain text password is cisco123.
Using an authentication string is actually more for the purpose of keeping multiple NHRP domains separate rather than for security reasons. The following statement is found in this Cisco documentaiton on the topic:
We recommend using an NHRP authentication string, especially to help keep multiple NHRP domains separate from each other. The NHRP authentication string is not encrypted, so it cannot be used as a true authentication for an NHRP node trying to enter the NHRP network.
Indeed there is no security extension to this particular command such as using a hash value or otherwise. If your concern is security, it is recommended to use DMVPN over IPsec which doesn’t only authenticate the spokes and hub, but also encrypts the traffic exchanged between the devices.
I hope his has been helpful!
Laz
Can anyone tell me if Cisco supports three Hubs in a single Cloud design.
Hello John
Yes, Cisco does support three hubs in a single cloud design. Indeed, it supports even more than three hubs if your network design demands it.
DMVPN supports multiple hubs, and the number and arrangement of the hubs depend upon the geographical dispersion of the specific network and its size. For extensively large networks, hubs can be arranged in a hierarchical or tiered structure to optimize traffic flow and management.
DMVPN has been designed to be highly scalable, and this of course means that you can indeed have three or even more hubs.
I hope this has been helpful!
Laz
Spoke2#show dmvpn
.......
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 01:09:20 S
Spoke2#ping 2.2.2.2 source loop 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/16/35 ms
Spoke2#show dmvpn
........
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 01:19:05 S
1 192.168.123.2 172.16.123.2 UP 00:08:25 D
Spoke2#
You can see at the beginning, Spoke2 didn’t know Spoke1’s NBMA physical interface IP, but after ping was done, Spoke2 knew it.
Can you explain how Spoke2 sent NHRP request to Hub to request mapping information of Spoke1’s tunnel physical IP？I used wireshark, but couldn’t find that. I expect Hub could include Spoke2’s tunnel-to-physical mapping in its NRHP reply. Thanks.
Hello Martin
This is expected behavior, especially for DMVPN Phase 2.
In DMVPN Phase 2, spokes dynamically resolve each other’s NBMA (physical) IP addresses using the NHRP. Here’s the step-by-step process:
- Initial Traffic Trigger:
- When Spoke2 (3.3.3.3) sends a ping to Spoke1 (2.2.2.2), it first checks its routing table. The route to 2.2.2.2 points to the hub’s tunnel IP (172.16.123.1) as the next hop (Phase 2 uses “split-horizon” disabled for spoke-to-spoke routing).
- NHRP Resolution Request:
- Spoke2 realizes the destination (2.2.2.2) is not directly in its NHRP cache. It sends an NHRP Resolution Request to the hub (172.16.123.1) over the existing mGRE tunnel. This request asks:
- “What is the NBMA (physical) IP address for the tunnel IP 2.2.2.2?”
- Hub’s NHRP Reply: The hub maintains an NHRP database of all registered spokes. It replies with an NHRP Resolution Reply containing Spoke1’s NBMA IP (192.168.123.2) and tunnel IP (172.16.123.2).
- Spoke2 realizes the destination (2.2.2.2) is not directly in its NHRP cache. It sends an NHRP Resolution Request to the hub (172.16.123.1) over the existing mGRE tunnel. This request asks:
- Direct Spoke-to-Spoke Tunnel: Spoke2 uses this information to build a direct IPSec/GRE tunnel to Spoke1 (192.168.123.2). Subsequent traffic bypasses the hub (as seen in your show dmvpn output, where Spoke1’s entry now appears with attribute D = Dynamic).
Now, why didn’t wireshark capture the NHRP request? There may be several reasons. It may be the way you captured your packets. Remember NHRP traffic travels over the tunnel interface not the physical interface. Ensure you captured traffic on the tunnel interface to see NHRP messages. Also note that NHRP uses UDP port 4500. Apply a Wireshark filter (udp.port == 4500) to isolate NHRP traffic to help you identify the specific messages.
Keep the following in mind concerning the behavior or DMVPN Phase 2:
- NHRP Registration: Spokes dynamically register their NBMA IPs with the hub when the tunnel comes up.
- On-Demand Resolution: Spokes only query the hub for mappings when traffic requires it (e.g., your ping triggered the resolution).
I hope this information is helpful for your to further troubleshoot your topology and to identify any issues as well. Let us know how you get along!
I hope this has been helpful!
Laz