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.
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.
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 (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:
Selecting the event for which the policy is run.
Defining the Event Detector (ED) options associated with logging and responding to the event.
Defining the environment variables, if required.
Choosing the actions to be performed when the event occurs.
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:
An NHRP event registers with the NHRP-ED.
The application creates an event definition.
A TCL script subscribes for NHRP event receipt asking that the script’s callback routine be invoked when the event is published.
The NHRP ED detects an event and contacts the EEM at the remote spoke.
The EEM schedules the event processing calling the application’s callback handler routine.
The TCL script returns the callback routine.
How to Configure DMVPN NHRP Event Publisher
Command or Action
Enables privileged EXEC mode.
Enter your password if prompted.
Router# configure terminal
Enters global configuration mode.
Router(config)# interface tunnel 100
Configures an interface and enters interface configuration mode.
Router(config-if)# tunnel mode gre multipoint
Enables a GRE tunnel to be used in multipoint NBMA mode.
Router(config-if)# tunnel key 3
(Optional) Sets the tunnel ID key.
Router(config-if)# ip nhrp network-id 1
Enables NHRP on the interface.
Router(config-if)# ip nhrp attribute set isp-name 200
Sets the local policy attributes that are carried in NHRP resolution requests.
Router(config-if)# nhrp event timer
Publishes an NHRP event with the attributes to EEM.
Exits interface configuration mode and returns to privileged EXEC mode.
Router# show ipv6 nhrp attribute
Displays the IPv6 NHRP attributes configured on the spoke.
Router# show ip nhrp attribute
Displays the IP NHRP attributes configured on the spoke.
Router# show dmvpn detail
Displays DMVPN-specific session information.
Router# debug nhrp attribute
Enables NHRP debugging.
Exits privileged EXEC mode.
What to Do Next
Configuration Examples for DMVPN NHRP Event Publisher
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
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.
The following table lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Table 1 Feature Information for DMVPN: NHRP Event Publisher
DMVPN: NHRP Event Publisher
The DMVPN: NHRP Event Publisher feature allows you to publish NHRP specific events to the ED. This feature enhances DMVPN with the capability to control the ability to build dynamic spoke-to-spoke tunnels. This feature also optimizes the conditions under which spokes build dynamic tunnels with each other. It also integrates EEM with NHRP.
The following commands were introduced or modified: ipnhrpconnect, ipnhrpreject, showipnrhpattribute, showipv6nhrpattribute.