In a DMVPN Phase 3 network, separate regional DMVPN networks are connected together into a single hierarchical DMVPN network. Spokes in different regions use NHRP to build direct spoke-to-spoke tunnels with each other, bypassing both the regional and the central hubs. When building spoke-to-spoke tunnels within a region, only the regional hubs are involved in the tunnel setup. When building spoke-to-spoke tunnels between regions, the regional and the central hubs are involved in the tunnel setup.

DMVPN Phase 3 provides improvements over a DMVPN Phase 2 network. For a DMVPN spoke-to-spoke network, the main improvements from Phase 2 are in the increased flexibility in laying out the base DMVPN network. DMVPN Phase 3 allows a hierarchical hub design whereas DMVPN Phase 2 relies on “daisy-chaining” of hubs for scaling the network. DMVPN Phase 3 also removes some of the restrictions on the routing protocols required by Phase 2 (OSPF broadcast mode and non split-tunneling). DMVPN Phase 3 is not expected to change the number of spokes that a single DMVPN hub can support but it may reduce the CPU load of the routing protocol on the hub.

Cisco has developed NHRP shortcut switching model enhancements that allow for more scalable DMVPN implementations. This model provides the following benefits:

• Allows summarization of routing protocol updates from hub to spokes. The spokes no longer need to have an individual route with an IP next hop of the tunnel IP address of the remote spoke for the networks behind all the other spokes. The spoke can use summarized routes with an IP next hop of the tunnel IP address of the hub and still be able to build spoke-to-spoke tunnels. It can reduce the load on the routing protocol running on the hub router. You can reduce the load because, when you can summarize the networks behind the spokes to a few summary routes or even one summary route, the hub routing protocol only has to advertise the few or one summary route to each spoke rather than all of the individual spoke routes. For example, with 1000 spokes and one router per spoke, the hub receives 1000 routes but only has to advertise one summary route to each spoke (equivalent to 1000 advertisements, one per spoke) instead of the 1,000,000 advertisements it had to process in the prior implementation of DMVPN.

• Provides better alternatives to static daisy-chaining of hubs for expanding DMVPN spoke-to-spoke networks. The hubs must still be interconnected, but they are not restricted to just a daisy-chain pattern. The routing table is used to forward data packets and NHRP control packets between the hubs. The routing table allows efficient forwarding of packets to the correct hub rather than having request and reply packets traversing through all of the hub routers.

• Allows for expansion of DMVPN spoke-to-spoke networks with OSPF as the routing protocol beyond two hubs. Because the spokes can use routes with the IP next-hop set to the hub router (not the remote spoke router as before), you can configure OSPF to use point-multipoint network mode rather than broadcast network mode. Configuring OSPF to use point-multipoint network mode removes the DR and BDR requirements that restricted the DMVPN network to just two hubs. When using OSPF, each spoke still has all individual routes, because the DMVPN network must be in a single OSPF area but you cannot summarize routes within an OSPF area.

• Allows routing protocols such as ODR to be used and still retain the ability to build dynamic spoke-to-spoke tunnels.

• Allows for hierarchical (greater than one level) and more complex tree-based DMVPN network topologies. Tree-based topologies allow the capability to build DMVPN networks with regional hubs that are spokes of central hubs. This architecture allows the regional hub to handle the data and NHRP control traffic for its regional spokes, but still allows spoke-to-spoke tunnels to be built between any spokes within the DMVPN network, whether they are in the same region or not.

• Enables the use of Cisco Express Forwarding to switch data packets along the routed path until a spoke-to-spoke tunnel is established.

To implement shortcut switching, NHRP works as a route source and installs shortcut paths, as NHRP routes, directly into the Routing Information Base (RIB). This means that shortcut paths appear as routes in the routing table and NHRP works in lieu of the routing protocol (for example, RIP, OSPF or EIGRP). The shortcut routes in the RIB are distributed into the Fowarding Information Base (FIB). When a spoke discovers a shortcut path, it adds the path as an NHRP route to its routing table. The RIB and FIB have no special behaviour for shortcut switching and shortcut routes are treated like any other route.

NHRP acts as a route producer to the RIB, but it does not function as a full routing protocol. NHRP manages the route registration, resolution, and purge messages but it does not discover or maintain NHRP neighbors, advertise NHRP routing messages, or inform the network of any network topology changes.

Consider Spoke A in the figure below. It discovers a shortcut path to N2 via Spoke 2’s tunnel (overlay) address TS2. It installs the shortcut path in its NHRP mapping table via the entry N2-PS2 (TS2) and it also adds the route to the RIB. The new route in the RIB is then distributed into the FIB and the FIB installs the corresponding adjacency TS2-PS2 in the adjacency table. The new route TS2-PS2 can now be used for forwarding. Note the consistency between the RIB, the FIB, and the adjacency table.

If an NHRP route in the RIB is identical to another route (owned by another protocol) in the RIB then NHRP overrides the other protocol’s next hop entries by installing shortcut next hops in the RIB. NHRP installs shortcut paths into the routing table, not as NHRP routes but as local forwarding paths. The other routing protocols continue to function as normal managing route redistribution and advertisement. NHRP only overrides local forwarding decisions by installing alternate or backup next hops into the routing table.

In a DMVPN full-mesh design, the hub creates summary routes to each of the spokes (Interior Gateway Protocol (IGP) routes). Specific NHRP shortcuts are installed at the spokes by NHRP as and when required. These shortcuts can be viewed as a refinement of the route summaries because they deal with a specific subnet while the summary routes represent super-nets. If the summary route is absent, NHRP cannot discover a shortcut path.

The summary route, or “covering prefix”, governs the existence of the NHRP route in the RIB. The removal of a covering prefix in the RIB would lead to the removal of the all the corresponding NHRP routes, that were learnt via this covering prefix, from the RIB. The tracking of covering prefixes is done via the Route Watch infrastructure.

A "watched prefix" is a route that immediately precedes an NHRP route. For example, if an NHRP route is 172.16.3.0/24, then the watch-prefix corresponding to it would be 172.16.2.0/23. Each “watched prefix” and its associated “covering prefixes” are tracked by the Route Watch service. A “covering prefix” is defined as the longest matching IGP route in the RIB which is less specific than the “watched prefix”. The validity of each NHRP shortcut is determined by the following events:

• If a “covering prefix” is removed so that there is no other IGP route in the RIB "covering" the watched prefix, (the watched prefix is unreachable), then the corresponding NHRP shortcut route is removed.

• If a new IGP route, which is more specific than the covering prefix but less specific than watched prefix, is installed in RIB, then it will become the covering prefix for the watched prefix. If the new covering prefix has a different next hop associated with it, the original shortcut is removed.

In summary, the validity of an NHRP route in the RIB is determined by the less specific, longest match IGP route present in the RIB. NHRP shortcuts are refinements to the routing topology, so shortcut paths are added to the RIB without modifying the routing topology.

From Cisco IOS XE Release 17.10.1a, NHRP supports the Route Watch attribute for the next hop of a cache entry that has a destination of a different subnet. This behavior is automatically triggered and does not depend on whether Route Watch is enabled or not. Therefore, a cache entry can now have two Route Watch instances: One Route Watch instance for the prefix entry and another Route Watch instance for the next hop.

Supporting the Route Watch attribute for next hop entries ensures that cache entries are cleaned up and monitored when route details disappear or are modified therefore preventing traffic drops.

When an NHRP hub replies to a resolution request, it creates a local NHRP mapping entry. The local mapping entry is a network entry for which NHRP has sent a reply. The local mapping entry maintains a list of requesters. When a network entry is modified or deleted in the routing table, NHRP is notified of the event. NHRP finds the local cache entry for the network and sends a purge request to the requesters that the network to which it previously replied has changed. The receivers of the purge message delete the corresponding NHRP mapping entry from its table and send a purge reply indicating that the purge message was processed successfully.