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