Perform this task to configure a GRE tunnel for multipoint (NMBA) operation.

You can enable a GRE tunnel to operate in multipoint fashion. A tunnel network of multipoint tunnel interfaces can be thought of as an NBMA network. When multiple GRE tunnels are configured on the same router, they must either have unique tunnel ID keys or unique tunnel source addresses. NHRP is required on mGRE tunnel interfaces because it provides the VPN-layer-IP to NBMA-layer-IP address mappings for forwarding IP data packets over the mGRE tunnel.

Note

Prior to Cisco IOS Release 12.3(11)T, all mGRE interfaces required the configuration of a tunnel ID key. After Cisco IOS Release 12.3(11)T this is optional, but if multiple GRE (mGRE) interfaces are configured on the same router without a tunnel ID key, then the mGRE interfaces be configured with unique tunnel source addresses.

The tunnel ID key is carried in each GRE packet, it is not carried in any NHRP messages. We do not recommend relying on this key for security purposes.

Perform this task to enable NHRP for an interface on a router. In general, all NHRP stations within a logical NBMA network should be configured with the same network identifier.

The NHRP network ID is used to define the NHRP domain for an NHRP interface and differentiate between multiple NHRP domains or networks, when two or more NHRP domains (GRE tunnel interfaces) are available on the same NHRP node (router). The NHRP network ID is used to help keep two NHRP networks (clouds) separate from each other when both are configured on the same router.

The NHRP network ID is a local only parameter. It is significant only to the local router and is not transmitted in NHRP packets to other NHRP nodes. For this reason the actual value of the NHRP network ID configured on a router need not match the same NHRP network ID on another router where both of these routers are in the same NHRP domain. As NHRP packets arrive on a GRE interface, they are assigned to the local NHRP domain in the NHRP network ID that is configured on that interface.

Note

This method of assigning a network ID is similar to the Open Shortest Path First (OSPF) concept of process ID in the router ospf process- idcommand. If more than one OSPF process is configured, then the OSPF neighbors and any routing data that they provide is assigned to the OSPF process (domain) by which interfaces map to the network arguments under the different router ospf process-id configuration blocks.

We recommend that the same NHRP network ID be used on the GRE interfaces on all routers that are in the same NHRP network. It is then easier to track which GRE interfaces are members of which NHRP network.

NHRP domains (network IDs) can be unique on each GRE tunnel interface on a router. This is required when running DMVPN phase 1 or phase 2 or when using a tunnel key on the GRE interfaces. These unique IDs place each GRE interface into a different NHRP domain, which is equivalent to each being in a unique DMVPN.

NHRP domains can span across GRE tunnel interfaces on a route. This option is available when running DMVPN phase 3 and not using a tunnel key on the GRE tunnel interfaces. In this case the effect of using the same NHRP network ID on the GRE tunnel interfaces is to merge the two GRE interfaces into a single NHRP network (DMVPN network).

Perform this task to configure static IP-to-NBMA address mapping on a station (host or router). To enable IP multicast and broadcast packets to be sent to the statically configured station, use the ip nhrp map multicast nbma-addresscommand. This command is required on multipoint GRE tunnels and not required on point-point RE tunnels.

To participate in NHRP, a station connected to an NBMA network must be configured with the IP and NBMA addresses of its NHSs. The format of the NBMA address depends on the medium you are using. For example, GRE uses a network service access point (NSAP) address, Ethernet uses a MAC address, and SMDS uses an E.164 address.

These NHSs may also be the default or peer routers of the station, so their addresses can be obtained from the network layer forwarding table of the station.

If the station is attached to several link layer networks (including logical NBMA networks), the station should also be configured to receive routing information from its NHSs and peer routers so that it can determine which IP networks are reachable through which link layer networks.

Perform this task to configure static IP-to-NBMA address mapping on a station (host or router). To enable IP multicast and broadcast packets to be sent to the statically configured station, use the ip nhrp map multicast nbma-addresscommand. This step is required on multipoint GRE tunnels and not required on point-point RE tunnels.

Note	The IGP routing protocol uses IP multicast or broadcast, so the ip nhrp map multicast command, though optional, is often required.

Perform this task to statically configure a Next Hop Server.

An NHS normally uses the network layer forwarding table to determine where to forward NHRP packets and to find the egress point from an NBMA network. An NHS may also be statically configured with a set of IP address prefixes that correspond to the IP addresses of the stations it serves, and their logical NBMA network identifiers.

Perform this task to change the length of time that NBMA addresses are advertised as valid in positive NHRP responses. In this context, advertised means how long the Cisco IOS XE software tells other routers to keep the address mappings it is providing in NHRP responses. The default length of time is 7200 seconds (2 hours).

This configuration controls how long a spoke-to-spoke shortcut path will stay up after it is no longer used or how often the spoke-to-spoke short-cut path mapping entry will be refreshed if it is still being used. We recommend that a value from 300 to 600 seconds be used.

The ip nhrp holdtimecommand controls how often the NHRP NHC will send NHRP registration requests to its configured NHRP NHSs. The default is to send NHRP registrations every one-third the NHRP holdtime value (default = 2400 seconds (40 minutes)). The optional ip nhrp registration timeout value command can be used to set the interval for sending NHRP registration requests independently from the NHRP holdtime.

Perform this task to specify the authentication string for NHRP on an interface.

Configuring an authentication string ensures that only routers configured with the same string can communicate using NHRP. Therefore, if the authentication scheme is to be used, the same string must be configured in all devices configured for NHRP on a fabric.

Note	We recommend using an NHRP authentication string, especially to help keep multiple NHRP domains separate from each other. The NHRP authentication string is not encrypted, so it cannot be used as a true authentication for an NHRP node trying to enter the NHRP network.

Perform this task to configure NHRP server-only mode.

You can configure an interface so that it cannot initiate NHRP resolution requests to establish NHRP shortcut SVCs but can respond only to NHRP resolution requests. Configure NHRP server-only mode on routers you do not want placing NHRP resolution requests.

If an interface is placed in NHRP server-only mode, you have the option to specify the ip nhrp server-only [non-caching] command keyword. In this case, NHRP does not store mapping information in the NHRP cache, such as NHRP responses that go through the router. To save memory and block building of NHRP shortcuts, the noncaching option is generally used on a router located between two other NHRP routers (NHRP hubs).

Perform this task to configure NHRP server-only mode.

Perform this task to change the maximum rate at which NHRP packets will be handled.

There is the maximum value (max-send interval) for the number of NHRP messages that the local NHRP process can handle within a set period of time. This limit protects the router against events like a runaway NHRP process sending NHRP requests or an application (worm) that is doing an IP address scan that is triggering many spoke-to-spoke tunnels.

The larger the max-send interval the more NHRP packets the system can process and send. These messages do not use much memory and the CPU usage is not very large per message; however, excessive messages causing excessive CPU usage can degrade system performance.

To set a reasonable max-send-interval, consider the following information:

• Number of spoke routers being handled by this hub and how often they send NHRP registration requests. To support this load you would need:

Number of spokes/registration timeout * max-send interval

For example, 500 spokes with a 100-second registration timeout would equate as follows:

max-send interval = 500/100*10 = 50

• The maximum number of spoke-to-spoke tunnels that are expected to be up at any one time across the NBMA network:

spoke-to-spoke tunnels/NHRP holdtime * max-send interval

This would cover spoke-to-spoke tunnel creation and the refreshing of spoke-to-spoke tunnels that are used for longer periods of time.

Then add these values together and multiply the result by 1.5 or 2.0 to give a buffer.

• The max-send interval can be used to keep the long-term average number of NHRP messages allowed to be sent constant, but allow greater peaks.

By default, the maximum rate at which the software sends NHRP packets is five packets per 10 seconds. The software maintains a per-interface quota of NHRP packets (whether generated locally or forwarded) that can be sent.

To dynamically detect link layer filtering in NBMA networks (for example, SMDS address screens), and to provide loop detection and diagnostic capabilities, NHRP incorporates a Route Record in request and reply packets. The Route Record options contain the network (and link layer) addresses of all intermediate Next Hop Servers between the source and destination (in the forward direction) and between the destination and source (in the reverse direction).

By default, Forward Record options and Reverse Record options are included in NHRP request and reply packets. Perform this task to suppress forward and reverse record options.

Note	Forward and Reverse Record information is required for the proper operation of NHRP, especially in a DMVPN network. Therefore you must not configure suppression of this information.

An NHRP requester that wants to know which Next Hop Server generates an NHRP reply packet can include the responder address option in its NHRP request packet. The Next Hop Server that generates the NHRP reply packet then complies by inserting its own IP address in the NHRP reply. The Next Hop Server uses the primary IP address of the specified interface.

Perform this task to specify which interface the Next Hop Server uses for the NHRP responder IP address.

The NHRP cache can contain entries of statically configured NHRP mappings and dynamic entries caused by the Cisco IOS XE software learning addresses from NHRP packets. To clear statically configured entries, use the no ip nhrp map command in interface configuration mode.

Perform the following task to clear the NHRP cache.

A logical NBMA network is considered the group of interfaces and hosts participating in NHRP and having the same network identifier. The figure below illustrates two logical NBMA networks (shown as circles) configured over a single physical NBMA network. Router A can communicate with routers B and C because they share the same network identifier (2). Router C can also communicate with routers D and E because they share network identifier 7. After address resolution is complete, router A can send IP packets to router C in one hop, and router C can send them to router E in one hop, as shown by the dotted lines.

Figure 2

Two Logical NBMA Networks over One Physical NBMA Network

The physical configuration of the five routers in the figure above might actually be that shown in the figure below. The source host is connected to router A and the destination host is connected to router E. The same switch serves all five routers, making one physical NBMA network.

Figure 3

Physical Configuration of a Sample NBMA Network

Refer again to the first figure above. Initially, before NHRP has resolved any NBMA addresses, IP packets from the source host to the destination host travel through all five routers connected to the switch before reaching the destination. When router A first forwards the IP packet toward the destination host, router A also generates an NHRP request for the IP address of the destination host. The request is forwarded to router C, whereupon a reply is generated. Router C replies because it is the egress router between the two logical NBMA networks.

Similarly, router C generates an NHRP request of its own, to which router E replies. In this example, subsequent IP traffic between the source and the destination still requires two hops to traverse the NBMA network, because the IP traffic must be forwarded between the two logical NBMA networks. Only one hop would be required if the NBMA network were not logically divided.

In the following example, only the packets that pass extended access list 101 are subject to the default SVC triggering and teardown rates:

interface tunnel 100
 ip nhrp interest 101
!
access-list 101 permit ip any any
access-list 101 deny ip any 10.3.0.0 0.0.255.255

With multipoint tunnels, a single tunnel interface may be connected to multiple neighboring routers. Unlike point-to-point tunnels, a tunnel destination need not be configured. In fact, if configured, the tunnel destination must correspond to an IP multicast address. Broadcast or multicast packets to be sent over the tunnel interface can then be sent by sending the GRE packet to the multicast address configured as the tunnel destination.

Multipoint tunnels require that you configure a tunnel key. Otherwise, unexpected GRE traffic could easily be received by the tunnel interface. For simplicity, we recommend that the tunnel key correspond to the NHRP network identifier.

In the following example, routers A, B, C, and D all share an Ethernet segment. Minimal connectivity over the multipoint tunnel network is configured, thus creating a network that can be treated as a partially meshed NBMA network. Due to the static NHRP map entries, router A knows how to reach router B, router B knows how to reach router C, router C knows how to reach router D, and router D knows how to reach Router A.

When router A initially attempts to send an IP packet to router D, the packet is forwarded through routers B and C. The routers use NHRP to quickly learn the NBMA addresses of each other (in this case, IP addresses assigned to the underlying Ethernet network). The partially meshed tunnel network readily becomes fully meshed, at which point any of the routers can directly communicate over the tunnel network without their IP traffic requiring an intermediate hop.

The significant portions of the configurations for routers A, B, C, and D follow:

Router A Configuration

interface tunnel 0
 no ip redirects
 ip address 10.0.0.1 255.0.0.0
 ip nhrp map 10.0.0.2 10.10.0.2
 ip nhrp network-id 1
 ip nhrp nhs 10.10.0.2
 tunnel source ethernet 0
 tunnel mode gre multipoint
 tunnel key 1
interface ethernet 0
 ip address 10.0.0.7 255.0.0.0

Router B Configuration

interface tunnel 0
 no ip redirects
 ip address 10.0.0.2 255.0.0.0
 ip nhrp map 10.0.0.3 10.10.0.3
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.3
 tunnel source ethernet 0
 tunnel mode gre multipoint
 tunnel key 1
interface ethernet 0
 ip address 10.0.0.6 255.0.0.0

Router C Configuration

interface tunnel 0
 no ip redirects
 ip address 10.0.0.3 255.0.0.0
 ip nhrp map 10.0.0.4 10.10.0.4
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.4
 tunnel source ethernet 0
 tunnel mode gre multipoint
 tunnel key 1
interface ethernet 0
 ip address 10.0.0.5 255.0.0.0

Router D Configuration

interface tunnel 0
 no ip redirects
 ip address 10.0.0.4 255.0.0.0
 ip nhrp map 10.0.0.1 10.10.0.1
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1
 tunnel source ethernet 0
 tunnel mode gre multipoint
 tunnel key 1
interface ethernet 0
 ip address 10.0.0.9 255.0.0.0

The following is sample output from the show ip nhrp command:

Router# show ip nhrp 
10.0.0.2 255.255.255.255, tunnel 100 created 0:00:43 expire 1:59:16
 Type: dynamic Flags: authoritative 
 NBMA address: 10.1111.1111.1111.1111.1111.1111.1111.1111.1111.11 
10.0.0.1 255.255.255.255, Tunnel0 created 0:10:03 expire 1:49:56
 Type: static Flags: authoritative 
 NBMA address: 10.1.1.2 

The fields in the sample display are as follows:

• The IP address and its network mask in the IP-to-NBMA address cache. The mask is always 255.255.255.255 because Cisco does not support aggregation of NBMA information through NHRP.
• The interface type and number and how long ago it was created (hours:minutes:seconds).
• The time in which the positive and negative authoritative NBMA address will expire (hours:minutes:seconds). This value is based on the ip nhrp holdtime command.
• Type of interface:
  • dynamic--NBMA address was obtained from the NHRP Request packet.
  • static--NBMA address was statically configured.
• Flags:
  • authoritative--Indicates that the NHRP information was obtained from the Next Hop Server or router that maintains the NBMA-to-IP address mapping for a particular destination.
  • implicit--Indicates that the information was learned from the source mapping information of an NHRP resolution request received by the local router, or from an NHRP resolution packet being forwarded through the local router.
  • negative--For negative caching; indicates that the requested NBMA mapping could not be obtained.
  • unique--Indicates that this NHRP mapping entry must be unique; it cannot be overwritten with a mapping entry that has the same IP address but a different NBMA address.
  • registered--Indicates the NHRP mapping entry was created by an NHRP registration request.
  • used--Indicates the NHRP mapping was used to forward data packets within the last 60 seconds.
  • router--Indicates an NHRP mapping entry that is from a remote router that is providing access to a network or host behind the remote router.
  • local--Indicates an NHRP mapping entry for networks local to this router for which this router has answered an NHRP resolution request.
  • (no socket)--Indicates an NHRP mapping entry for which IPsec socket (for encryption) has not been triggered. These mapping entries are not used to forward data packets.
  • nat--Indicates an NHRP mapping entry for which IPsec socket (for encryption) has not been triggered. These mapping entries are not used to forward data packets.
  • NBMA address--Nonbroadcast multiaccess address. The address format is appropriate for the type of network being used (for example, GRE, Ethernet, SMDS, or multipoint tunnel

The following is sample output from the show ip nhrp traffic command which displays NHRP traffic statistics:

Router# show ip nhrp traffic
Tunnel0
  request packets sent: 2
  request packets received: 4
  reply packets sent: 4
  reply packets received: 2
  register packets sent: 0
  register packets received: 0
  error packets sent: 0
  error packets received: 0

The fields shown in the sample display are as follows:

• Tunnel0--Interface type and number.
• request packets sent--Number of NHRP request packets originated from this station.
• request packets received--Number of NHRP request packets received by this station.
• reply packets sent--Number of NHRP reply packets originated from this station.
• reply packets received--Number of NHRP reply packets received by this station.
• register packets sent--Number of NHRP register packets originated from this station. Routers and access servers do not send register packets, so this value is 0.
• register packets received--Number of NHRP register packets received by this station. Routers or access servers do not send register packets, so this value is 0.
• error packets sent--Number of NHRP error packets originated by this station.
• error packets received--Number of NHRP error packets received by this station.

The following example shows output for a specific tunnel, tunnel7:

Router# show ip nhrp traffic interface tunnel7 
Tunnel7: Max-send limit:100Pkts/10Sec, Usage:0% 
Sent: Total 79 
18 Resolution Request 10 Resolution Reply 42 Registration Request 
0 Registration Reply 3 Purge Request 6 Purge Reply 
0 Error Indication 0 Traffic Indication 
Rcvd: Total 69 
10 Resolution Request 15 Resolution Reply 0 Registration Request 
36 Registration Reply 6 Purge Request 2 Purge Reply 
0 Error Indication 0 Traffic Indication 

NHRP holdtime = 600, NHRP registration timeout not set. NHRP registrations will be sent every 200 seconds so the time to detect that an NHS is down would range from 7 to 207 seconds with an average of 107 seconds.

Router# show ip nhrp nhs detail

Legend:
E=Expecting replies
R=Responding
Tunnel0:
10.0.0.1 E req-sent 14793 req-failed 1 repl-recv 14751 (00:25:07 ago)
10.0.0.2 req-sent 26 req-failed 9 repl-recv 0 
Legend:
E=Expecting replies
R=Responding
Tunnel1:
10.0.1.1 RE req-sent 14765 req-failed 1 repl-recv 14763 (00:01:07 ago)
Pending Registration Requests:
Registration Request: Reqid 29507, Ret 64 NHS 10.0.0.1
Registration Request: Reqid 29511, Ret 64 NHS 10.0.0.2

10.0.0.1 is new (expecting replies) and is down. 10.0.0.2 is old (not expecting replies) and is assumed up. 10.0.1.1 is new (expecting replies) and is up.