DMVPN Questions

If you are not sure about DMVPN, please read our DMVPN tutorial.

Question 1

Explanation

NHRP is used to map tunnel IP addresses to “physical” or “real” IP addresses (NBMA addresses), used by endpoint routers. It resolves private addresses (those behind mGRE and optionally IPsec) to a public address.In other words, NHRP is used by a branch router connected to a non-broadcast, multi-access (NBMA) sub-network to determine the IP address of the “NBMA next hop”.

Question 2

Explanation

DMVPN Phase III is same as Phase 2 but removes some restrictions and complexities of Phase 2. Also allows greater variety of DMVPN network designs we use:
+ ip nhrp redirect in hub: tells the initiator spoke to look for a better path to the destination spoke than through the Hub. Upon receiving the NHRP redirect message the spokes communicate with each other over the hub and they have their NHRP replies for the NHRP Resolution Requests that they sent out.
+ ip nhrp shortcut in spokes: overwrite the CEF table on the spoke. It basically overrides the next-hop value for a remote spoke network from the default initial hub tunnel IP address to the NHRP resolved remote spoke tunnel IP address)

Question 3

Explanation

From the output we learn that the logical address 10.2.1.2 is mapped to the NBMA address 10.12.1.2. Type “dynamic” means NBMA address was obtained from NHRP Request packet whilw type “static” means NBMA address is statically configured. The “authoritative” flag means that the NHRP information was obtained from the Next Hop Server (NHS).

Reference: http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_addr/configuration/guide/hadnhrp.html

Question 4

Explanation

An mGRE tunnel inherits the concept of a classic GRE tunnel but an mGRE tunnel does not require a unique tunnel interface for each connection between Hub and spoke like traditional GRE. One mGRE can handle multiple GRE tunnels at the other ends. Unlike classic GRE tunnels, the tunnel destination for a mGRE tunnel does not have to be configured; and all tunnels on Spokes connecting to mGRE interface of the Hub can use the same subnet.

mGRE tunnel is treated as a non-broadcast multi-access (NBMA) environment. mGRE tunnel does not have to be configured with a tunnel destination so we need another protocol to take care of the destination addresses. In this case NHRP is used for NBMA environment.

Question 5

Explanation

Maybe this question wanted to ask “Which protocol is used in a DMVPN network to map logical IP address to physical IP addresses?”

Next Hop Resolution Protocol (NHRP), defined in RFC 2332, is a Layer 2 address resolution protocol and cache, like Address Resolution Protocol (ARP). NHRP is used by a branch router connected to a non-broadcast, multi-access (NBMA) sub-network to determine the IP address of the “NBMA next hop”; in this case, the headend router or the destination IP address of another branch router.

NHRP is used to map tunnel IP addresses to “physical” or “real” IP addresses, used by endpoint routers. It resolves private addresses (those behind mGRE and optionally IPSEC) to a public address. NHRP is layer 2 resolution protocol and cache, much like Address Resolution Protocol (ARP) or Reverse ARP (Frame Relay).

Question 6

Explanation

Reference: IP security (IPsec) virtual tunnel interfaces (VTIs) provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network. IPsec VTIs simplify configuration of IPsec for protection of remote links, support multicast, and simplify network management and load balancing.

Question 7

Explanation

The command “ip nhrp map multicast dynamic” should be only used on Hub router, not spoke. If we are running dynamic routing protocols based on multicast (like RIP, OSPF, EIGRP …) we have to add the command “ip nhrp map multicast dynamic” in Hub to replicate all multicast traffic to all dynamic entries in the NHRP table (multicast will be proceeded as unicast traffic) -> Answer A is not correct. Also another error in this answer is the “tunnel source” IP address. It should be the NBMA address of the Spoke interface: 172.17.0.2.

Answer B is not correct as the “tunnel source 1.1.1.10”, “ip nhrp map 10.0.0.11 172.17.0.2” and “tunnel mode gre” are wrong.

Answer C is not correct as there is no “ip nhrp map multicast static” command, only the “ip nhrp map multicast <static-IP>” command is available. The “tunnel source 10.0.0.1” is not correct either.

Answer D is correct. The ” tunnel source FastEthernet0/0″ is equivalent to “tunnel source 172.17.0.2”, which is the NBMA address of Spoke A.

An example of configuring DMVPN Phase II – Dynamic Mapping is shown below:

DMVPN Phase II – Dynamic Mapping Hub interface tunnel 1 ip address 192.168.100.254 255.255.255.0 tunnel source 44.44.44.4 tunnel mode gre multipoint ip nhrp network 10

Spoke 1 interface tunnel 1 ip address 192.168.100.1 255.255.255.0 tunnel source 11.11.11.1 tunnel mode gre multipoint ip nhrp network 10 ip nhrp map 192.168.100.254 44.44.44.4 ip nhrp nhs 192.168.100.254 !

Spoke 2 interface tunnel 1 ip address 192.168.100.2 255.255.255.0 tunnel source 12.12.12.2 tunnel mode gre multipoint ip nhrp network 10 ip nhrp map 192.168.100.254 44.44.44.4 ip nhrp nhs 192.168.100.254

If you want to learn more about DMVPN please read our DMVPN Tutorial.

Question 8

Question 9

Explanation

The first six commands are used to configure IPSec Phase 1 (ISAKMP Policy). Here is the details of each command used above:
+ crypto isakmp policy 10 – This command creates ISAKMP policy number 10. You can create multiple policies, for example 7, 8, 9 with different configuration. Routers participating in Phase 1 negotiation tries to match a ISAKMP policy matching against the list of policies one by one. If any policy is matched, the IPSec negotiation moves to Phase 2.
+ hash md5– MD5 algorithm will be used.
+ authentication pre-share – Authentication method is pre-shared key.
+ group 2 – Diffie-Hellman group to be used is group 2.
+ encryption 3des – 3DES encryption algorithm will be used for Phase 1.
+ crypto isakmp key cisco address 10.1.1.1 – The Phase 1 password is cisco and remote peer IP address is 10.1.1.1

The next two command lines are used to configure IPSec Phase 2 (Transform Set):
+ crypto ipsec transform-set <transform-set-name> – Creates transform-set called <transform-set-name>
+ esp-des – ESP IPSec protocol with the 56-bit Data Encryption Standard (DES) encryption algorithm will be used
+ esp-md5-hmac – ESP with the MD5 (HMAC variant) authentication algorithm will be used.
+ mode transport: only encrypts the payload and ESP trailer
or
+ mode tunnel: encrypts the IP header of the ENTIRE packet

There is an issue with above configuration in both R2 & R3: both R2 and R3 use the DMVPN tunnel address 10.1.1.1 (in the command “crypto isakmp key cisco address 10.1.1.1”. This is the tunnel interface IP address which is not correct. They must use the WAN address 192.1.1.1 instead.

We should configure the key with “address 0.0.0.0 0.0.0.0” (means remote peer is any -> any destination can try to negotiate with this router). While the hub’s public IP address is known we must keep in mind that R2 and R3 can build dynamic VPN tunnel between them. Taking into consideration that their public IP address is dynamic it is imperative to use 0.0.0.0 0.0.0.0 for the remote peer.

Note: The “mode tunnel” or “mode transport” is not the problem in this question because it said “both spoke-to-spoke and hub were not establishing”. It means either of these two modes of the spokes did not establish DMVPN tunnel with the hub R1. Notice that R1 was surely configured with one of these two modes.