This topic is to discuss the following lesson:
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