The developmental phases described in this section are actually DMVPN phases combining mGRE plus NHRP and IPsec. Phase 2 and 3 are important because they provide the functionality needed to support dynamic spoke-to-spoke tunnels.
Phase 1 is the hub-and-spoke capability only. This phase will not be discussed here because phase 1 does not support spoke-to-spoke tunnels.
Phase 2 adds spoke-to-spoke capability.
Phase 3 changes spoke-to-spoke capability in order to scale to larger NBMA networks.
NHRP gathers the information that it needs to build spoke-to-spoke tunnels by using NHRP resolution request and reply packets that are sent via the spoke-hub-spoke path through the NBMA network. NHRP also has to be triggered (or know when) to collect this information for building the spoke-to-spoke tunnels, because it brings up the spoke-to-spoke tunnel only when there is data traffic to use it. The two ways that NHRP does this are described the following sections.
The IP routing table and the routes learned by way of the hub are important when building spoke-to-spoke tunnels. Therefore, the availability of the NHSs (hubs) is critical for the functioning of an NHRP-based network. When there is only one hub and that hub goes down, the spoke removes the routes that it learned from the hub from its routing table, because it lost the hub as its routing neighbor. However, the spoke does not delete any of the spoke-to-spoke tunnels (NHRP mappings) that are now up. Even though the spoke-to-spoke tunnel is still there the spoke will not be able to use the tunnel because its routing table no longer has a route to the destination network. The spoke has a path (spoke-to-spoke tunnel), but does not know to use it (because there is no routing table entry).
In addition, when the routing entries are removed there is no trigger into NHRP for NHRP to remove NHRP mapping entries. Eventually NHRP will time out the current dynamic NHRP mapping entries that it had when the hub went down because they are not being used. Only at that time does NHRP remove the mapping entry.
In phase 2, if there still happened to be a route in the routing table (could be a static route) with the correct IP next hop, then the spoke could still use the spoke-to-spoke tunnel even when the hub is down. NHRP will not be able to refresh the mapping entry because the NHRP resolution request or response would need to go through the hub.
In phase 3, you would need a route that only points out the tunnel interface. It would not need to have the correct IP next hop (NHRP ignores the IP next-hop in phase 3). Also NHRP will be able to refresh the NHRP mapping entry, because the NHRP resolution request or response will go over the direct spoke-to-spoke tunnel.
If you have two (or more) NHS hubs within a single NBMA network (single mGRE, Frame Relay, or ATM interface), then when the first (primary) hub goes down, the spoke router will still remove the routes from the routing table that it learned from this hub, but it will also be learning the same routes (higher metric) from the second (backup) hub, so it will immediately install these routes. Therefore the spoke-to-spoke traffic would continue going over the spoke-to-spoke tunnel and be unaffected by the primary hub outage.
The following sections describe the DMVPN phases that implement the spoke-to-spoke tunnel function.
In phase 3, NHRP brings up the NHC and NHS tunnel and a dynamic routing protocol is used to distribute routing information about the networks that are available behind all of the spokes to the hub. The hub then resends this routing information out to the spokes, but in this case, the hub can summarize the routing information. It sets the IP next hop for all the network destinations to be the NHS (hub) itself. This function can significantly reduce the amount of information that the routing protocol needs to distribute from the hub to the spokes, thus reducing the load on the routing protocol running on the hub.
When a data packet is forwarded, it obtains the outbound interface and the IP next hop from the matching routing table network entry. If the NHRP interface is the outbound interface, it looks for an NHRP mapping entry for that IP next hop. In this case the IP next hop will be the hub for which it already has an NHRP mapping entry (it already has a tunnel with the hub[NHS]), so the spoke will send only the data packet to the hub.
The hub receives the data packet and checks its routing table. Because this data packet is destined for a network behind another spoke, it is forwarded back out the NHRP interface to the next hop toward that spoke. At this point the hub detects that the packet arrived and was sent back out the NHRP interface. This behavior means that the data packet is taking at least two hops within the NHRP network and therefore this path via the hub is not the optimal one-hop path. The hub therefore sends an NHRP redirect message to the spoke. The redirect message gives information to the spoke about the data packet IP destination that triggered the NHRP redirect message.
When the spoke receives the NHRP redirect, it creates and sends an NHRP resolution request for the data IP destination from the NHRP redirect message. The NHRP resolution request will be forwarded through the path to the remote spoke that services the network for that IP destination.
The remote spoke will generate an NHRP resolution reply with its own NBMA address and the whole subnet (from its routing table) that matches the data IP destination from the NHRP resolution request packet. The remote spoke will then send the NHRP resolution reply directly back to the local spoke. At this point there is now enough information for data traffic to be sent over the direct spoke-to-spoke path that was just built.
The method for phase 3 was implemented in Cisco IOS Release 12.4(6)T and uses the NHRP
shortcutcommands. See the “Shortcut Switching Enhancements for NHRP in DMVPN Networks” module for more information.