In previous implementations of DMVPN, the hub uses NHRP to maintain a database of the spokes' real (publicly reachable) IP addresses. Spokes in a DMVPN network register their real IP address with the hub using periodic NHRP registration packets. When a spoke has traffic for a destination behind another spoke, it uses an NHRP resolution request to query the NHRP database on the hub for the NBMA address of destination spokes. NHRP uses the resolution request process to build a direct spoke-to-spoke tunnel.

However, there were some issues with scaling implementations of DMVPN networks to large sizes (large number of spokes):

• In order for the spoke to "know" to send an NHRP resolution request to build a spoke-to-spoke tunnel, the spoke must have a route in its routing table for the remote network (behind the remote spoke) with an IP next-hop of the tunnel IP address of the remote spoke. Having each route in the routing table means that in a DMVPN network with 1000 spokes, each spoke router must have at least 1000 routes, one for each remote spoke. Having each route in the routing table also means that the hub router that helps in distributing this routing information must deal with the equivalent of 1,000,000 routes. The hub receives at least one route from each spoke, and the hub must advertise all of these routes to all of the other spokes; that is, 1000 routes advertised to 1000 spokes, which equals the processing of 1,000,000 routes. Supporting a routing table of that size can put a significant strain on the hub and routing protocol processing.
• When using the Open Shortest Path First (OSPF) routing protocol, OSPF must be configured to use broadcast network mode. Using broadcast network mode limits the number of hubs in a DMVPN network to just two. Only two hubs may be used because OSPF broadcast networks require a designated router (DR) and a backup designated router (BDR), and each spoke must be connected to both the DR and BDR. This configuration effectively limits the DMVPN network to two hubs when using OSPF.
• When using other routing protocols such as On-Demand Routing (ODR), which can only advertise a default-route 0.0.0.0/0 with an IP next-hop of the hub, the implementation could not support spoke-to-spoke tunnels.
• In order to scale DMVPN networks to larger sizes, multiple hubs are used where each one handles a subset of the spokes. For example, to handle 2000 spokes you could use four hubs, each one handling 500 spokes. The DMVPN implementation relied on hubs being "daisy-chained" together as NHRP Next Hop Servers (NHSs) of each other. In the case of daisy-chaining hubs, limitations included single hub failures breaking the chain, complexity in configuring multiple daisy chains to work around single hub failures, and delays in response time for building spoke-to-spoke tunnels as the chain of hubs grew.
• The DMVPN implementation only allowed a single hub spoke layer; hubs could not be spokes of other hubs within the same DMVPN network. You could not build complex DMVPN networks, such as having regional hubs that are spokes of central hubs. To build a similar design in previous implementations, you would have to set up different regional DMVPN networks with spokes connected to regional hubs and then interconnect the regional hubs outside of the DMVPN network or in a different DMVPN network. This design would mean that spokes in a region could only build spoke-to-spoke tunnels to spokes within the same region (same DMVPN network), but not to spokes in another region (different DMVPN network).
• In previous DMVPN implementations, the data packets were process switched at each hop along the daisy chain until the spoke-to-spoke tunnel was established. Process switching of data packets could result in unreasonable delays.

The Shortcut Switching Enhancements for NHRP in DMVPN Networks feature provides a more scalable alternative to the previous NHRP model.

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

• 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 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 in the DMVPN network, whether they are in the same region or not.
• Allows data packets to be Cisco Express Forwarding (CEF) switched along the routed path until a spoke-to-spoke tunnel is established.

NHRP shortcut switching is now a feature in the CEF output feature switching path. For each data packet that is forwarded out the multipoint Generic Routing Encapsulation (mGRE) interface, NHRP performs a lookup in its mapping table to find an entry for the destination IP address of the data packet. If there is one, it overrides the adjacency determined by CEF during the Forwarding Information Base/Adjacency (FIB/ADJ) lookup. This lookup process is how data packets are redirected over the spoke-to-spoke direct tunnel rather than being forwarded to the hub as the routing table states.

If there is not a matching entry in the NHRP mapping table then the data packet is forwarded to the IP next-hop (adjacency) from the routing table; this would be the hub router. When this packet is received on the hub and it detects that this data packet has been received on and forwarded out the same tunnel interface, the hub router sends an NHRP redirect message to the previous tunnel hop (spoke router). When the spoke router receives the NHRP redirect, it sends an NHRP resolution request for the data packet destination IP address that triggered the NHRP redirect message. The NHRP resolution request and reply messages build a spoke-to-spoke tunnel between the two spokes behind which the hosts that are communicating are located. Once the spoke-to-spoke tunnel is built, an NHRP mapping entry is created to redirect the data packets over the spoke-to-spoke tunnel. If for some reason the spoke-to-spoke tunnel cannot be built, the data packets will continue to be forwarded via the hub(s).

For each NHRP mapping entry, NHRP keeps a reference to the CEF adjacency entry. This adjacency overrides the FIB-adjacency during CEF output feature processing. The figure below shows an example of the NHRP mapping table for shortcut switching.

Note	To see if packets are being redirected over a spoke-to-spoke tunnel, you must look in the NHRP mapping table. The routing table and CEF FIB table will still show the original IP next-hop address.

Figure 1

NHRP Shortcut Switching Mapping Tables

In the figure above, the packet flow is as follows:

1. The Spoke A forwarding table lookup for N2 gives TH1 as its next-hop and adjacency.
2. NHRP in the output feature path at Spoke A performs a lookup in its mapping table and does not find an entry for the host in N2.
3. The data packet is forwarded to Hub 1 (H1) as determined in Step 2.
4. H1 follows Steps 2 and 3 and forwards the data packet to Spoke B. NHRP in the output feature path also determines that the inbound (such as Tunnel0) and the outbound (Tunnel0) interface is part of the same DMVPN network and sends an NHRP redirect traffic indication to the tunnel (Spoke A) on which the data packet was received. The NHRP redirect message includes the original IP address and first eight bytes of the data packet.
5. At Spoke B the data packet is forwarded to the original host in network N2.
6. Spoke A receives an NHRP redirect traffic indication message from H1.
7. Spoke A processes the redirect message and triggers an NHRP resolution request for the destination IP address (host in N2) of the data packet (contained in the redirect message). NHRP will trigger a resolution only if it passes the NHRP interest list configuration check.
8. The NHRP resolution request follows the Spoke A-Hub 1-Spoke B path. The NHRP resolution follows the routed path towards the destination until it reaches Spoke B.
9. Spoke B routing lookup for the destination IP address (host in N2) finds that it is the exit point of the DMVPN network.
10. Spoke B builds any IPsec tunnel required to Spoke A and sends the NHRP resolution reply directly over the tunnel to Spoke A. The Spoke B reply contains prefix information of N2 and not just the reply for the host in N2; that is, Spoke B indicates that not only Host B but the entire network N2 is reachable via Spoke B. Spoke B creates a local cache entry for N2 and a list of requestors to which it has replied for network N2.
11. Spoke A receives the reply and installs the mapping for N2 in its mapping table. Further packets for any host in network N2 is forwarded to Spoke B directly.

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 requestors. 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 requestors 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.

Perform this task to enable shortcut switching for NHRP for an interface on a router.

Note	When using this feature, we recommend configuring the ip nhrp redirect command on all the DMVPN nodes. This configuration would be useful in the event the data traffic takes a spoke-to-spoke-hub-spoke path.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip nhrp shortcut

5.    end

1.    enable

2.    configure terminal

3.    interface tunnel number

4.    ip nhrp redirect [ every {seconds}]

5.    end

6.    show ip nhrp traffic