DMVPN NHRP Event Publisher
DMVPN NHRP Event Publisher
Last Updated: September 30, 2012
The DMVPN: NHRP Event Publisher feature allows you to publish Next Hop Resolution Protocol (NHRP) specific events to the Event Detector (ED). NHRP publishes NHRP events with data to the NHRP-ED handler. The DMVPN: NHRP Event Publisher feature enhances Dynamic Multipoint VPN (DMVPN) with the capability to control the building of dynamic spoke-to-spoke tunnels. This feature also optimizes the conditions under which spokes build dynamic tunnels with each other. It also integrates Embedded Event Manager (EEM) with NHRP and leverages EEM scripts to influence the behavior of NHRP. In this feature, the only event that is supported is the capability to build dynamic spoke-to-spoke tunnels.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn . An account on Cisco.com is not required.
Prerequisites for DMVPN NHRP Event Publisher
You need to use the nhrpevent-publishermax-event-timeout command to turn on the DMVPN: NHRP Event Publisher feature. For information on DMVPN configuration, see Configuring Dynamic Multipoint VPN . For information on NHRP configuration, see Configuring NHRP .
Restrictions for DMVPN NHRP Event Publisher
You cannot manually configure spoke-to-spoke tunneling with this feature. You can only build dynamic spoke-to-spoke tunnels.
Information About DMVPN NHRP Event Publisher
Dynamic Spoke-to-Spoke Tunnels
Spoke-to-spoke tunnels are designed to be dynamic, in that they are created only when there is data traffic that uses the tunnel; and they are removed when there is no data traffic using the tunnel.
In addition to NHRP registration of next hop clients (NHCs) with next hop servers (NHSs), NHRP provides the capability for NHCs (spokes) to find a shortcut path over the infrastructure of the network (IP network, Switched Multimegabit Data Service [SMDS]) or to build a shortcut switched virtual circuit (SVC) over a switched infrastructure network (Frame Relay and ATM) directly to another NHC (spoke), bypassing hops through the NHSs (hubs). This capability allows the building of very large NHRP-NBMA networks. In this way, the bandwidth and CPU limitations of the hub do not limit the overall bandwidth of the NHRP-NBMA network. This capability effectively creates a full-mesh-capable network without having to discover all possible connections beforehand. This type of network is called a dynamic-mesh network, where there is a base hub-and-spoke network of NHCs and NHSs. The network of NHCs and NHSs is used for transporting NHRP, dynamic routing protocol information, data traffic, and dynamic direct spoke-to-spoke links. The spoke-to-spoke links are built when there is data traffic to use the link, and the spoke-to-spoke links are torn down when the data traffic stops.
The dynamic-mesh network allows individual spoke routers to directly connect to anywhere in the NBMA network, even though they are capable of connecting only to a limited number at the same time. This functionality allows each spoke in the network to participate in the whole network up to its capabilities without limiting another spoke from participating up to its capability. If a full-mesh network were to be built, all spokes would have to be sized to handle all possible tunnels at the same time.
For example, in a network of 1000 nodes, a full-mesh spoke would need to be large and powerful because it must always support 999 tunnels (one to every other node). In a dynamic-mesh network, a spoke needs to support only a limited number of tunnels to its NHSs (hubs) plus any currently active tunnels to other spokes. Also, if a spoke cannot build more spoke-to-spoke tunnels, it will send its data traffic by way of the spoke-hub-spoke path. This design ensures that connectivity is always preserved, even when the preferred single hop path is not available.
DMVPN NHRP Event Publisher
Currently DMVPN establishes a direct spoke-to-spoke tunnel with shortcut switching enabled on the spoke and NHRP redirect on the hub, without performing any additional checks before establishing traffic on the tunnel. This direct spoke-to-spoke tunnel may not be the best path as there could be other alternative best paths available for this traffic.
The DMVPN: NHRP Event Publisher feature performs additional checks before establishing the spoke-to-spoke tunnel and sending traffic on the tunnel. This feature helps the administrator to decide about the local policies and attributes while building the tunnel. This prevents known bad network connections based on local history or centralized information. It also reduces the administrative overhead by monitoring available resources and selecting the best options.
Embedded Event Manager
Embedded Event Manager (EEM) is a powerful and flexible subsystem in Cisco IOS software that provides real-time network event detection and onboard automation. Using EEM, you can adapt the behavior of your network devices to align with your business needs. EEM is available on a wide range of Cisco platforms, and customers can benefit from the capabilities of EEM without upgrading to a new version of IOS.
EEM supports over 20 event detectors that are integrated with different Cisco IOS components to trigger actions in response to network events. Business logic can be injected into various networking operations using EEM policies. These policies are programmed using either a simple CLI-based interface or a scripting language called Tool Command Language (TCL). EEM harnesses the significant intelligence within Cisco devices to enable creative solutions including automated troubleshooting, automatic fault detection and troubleshooting, and device configuration automation.
EEM is implemented through the creation of policies. An EEM policy is an entity that defines an event and the actions to be taken when that event occurs. There are two types of EEM policies: an applet and a script. An applet is a simple form of policy that is defined within the CLI configuration. A script is a form of policy that is written in TCL. When an EEM policy is registered with the EEM, the software examines the policy and registers it to be run when the specified event occurs. Policies can be unregistered or suspended.
The following tasks are required to create an EEM policy:
NHRP Event Publishing Flow
When a local spoke sends a resolution request to a remote spoke, the remote spoke triggers the EEM. The EEM decides whether to connect to or reject the request. If the EEM agrees to connect, the remote spoke builds the tunnel and sends the resolution reply through the tunnel.
Making NHRP be the ED helps define your own events, and the application can create and publish these events. On the remote spoke, the TCL scripts can subscribe to these events. The published events are sent to the subscribed TCL scripts. NHRP events are published to the NHRP-ED handler. The event information is copied to the XML buffer, and the NHRP-ED publishes this buffer to the EEM server. The event subscriber (TCL scripts from the remote spoke) receives and registers the event request so that the remote spoke is notified when the event is published. The TCL script replies to NHRP with the ipnhrpconnectreqidor ipnhrprejectreqidcommand. The ipnhrpconnectreqid command enables the spoke to initiate a resolution reply for the received request to build a shortcut tunnel. The ipnhrprejectreqid command prevents the spoke from initiating the resolution reply for the received request.
The ipnhrpconnectreqid command invokes connect registry callback as an action to trigger the resolution reply. The remote spoke either builds the spoke-to-spoke tunnel and sends the resolution reply within the tunnel or sends the resolution reply with the policy attributes through the hub. If the resolution reply is sent through the hub, the spoke receiving the resolution reply builds the spoke-to-spoke tunnel.
When the TCL script responds with the ipnhrprejectreqid command, the remote spoke does not build the spoke-to-spoke tunnel. It sends the NHRP resolution NAK message with a reject time value and subnet mask to the local spoke through the hub.
The following sequence lists the NHRP event flow:
How to Configure DMVPN NHRP Event Publisher
Configuration Examples for DMVPN NHRP Event Publisher
Example Configuring DMVPN NHRP Event Publisher
Feature Information for DMVPN NHRP Event Publisher
The following table lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
© 2012 Cisco Systems, Inc. All rights reserved.