NHRP: Examples
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
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 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.
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:
Type of interface:
–dynamic—NBMA address was obtained from the NHRP Request packet.
dynamic—NBMA address was obtained from the NHRP Request packet.
–static—NBMA address was statically configured.
static—NBMA address was statically configured.
•Flags:
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.
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 not from an NHRP request generated
from the local router, but from an NHRP packet being forwarded or from
an NHRP request being received by the local router.
implicit—Indicates
that the information was learned not from an NHRP request generated
from the local router, but from an NHRP packet being forwarded or from
an NHRP request being received by the local router.
–negative—For
negative caching; indicates that the requested NBMA mapping could not
be obtained. When NHRP sends an NHRP resolution request it inserts an
incomplete (negative) NHRP mapping entry for the address in the
resolution request. This is to keep the router from triggering more NHRP
resolution requests while this NHRP resolution request is being
resolved and the IKE or IPsec tunnel created.
negative—For
negative caching; indicates that the requested NBMA mapping could not
be obtained. When NHRP sends an NHRP resolution request it inserts an
incomplete (negative) NHRP mapping entry for the address in the
resolution request. This is to keep the router from triggering more NHRP
resolution requests while this NHRP resolution request is being
resolved and the IKE or IPsec tunnel created.
–unique—NHRP
registration request packet had the "unique" flag set (on by default).
This means that this NHRP mapping entry cannot be overwritten with a
mapping entry that has the same IP address but a different NBMA address.
When a spoke has a statically configured outside IP (NBMA) address this
flag is used to keep another spoke that is misconfigured with the same
tunnel IP address from overwriting this entry. If a spoke has a dynamic
outside IP (NBMA) address then you configure ip nhrp registration no-unique
on the spoke to clear this flag. This flag then allows the registered
NHRP mapping entry for that spoke on the hub to be overwritten with a
new NBMA address. This is necessary in this case since the spoke's
outside IP (NBMA) address may change at any time. If the "unique" flag
was set, then the spoke would have to wait for the mapping entry on the
hub to time out before it could register its new (NBMA) mapping.
unique—NHRP
registration request packet had the "unique" flag set (on by default).
This means that this NHRP mapping entry cannot be overwritten with a
mapping entry that has the same IP address but a different NBMA address.
When a spoke has a statically configured outside IP (NBMA) address this
flag is used to keep another spoke that is misconfigured with the same
tunnel IP address from overwriting this entry. If a spoke has a dynamic
outside IP (NBMA) address then you configure ip nhrp registration no-unique
on the spoke to clear this flag. This flag then allows the registered
NHRP mapping entry for that spoke on the hub to be overwritten with a
new NBMA address. This is necessary in this case since the spoke's
outside IP (NBMA) address may change at any time. If the "unique" flag
was set, then the spoke would have to wait for the mapping entry on the
hub to time out before it could register its new (NBMA) mapping.
–registered—The
mapping entry was created from receiving an NHRP registration request.
Registered mapping entries are dynamic entries, but they will not be
refreshed through the "used" mechanism. These entries are refreshed by
receiving another NHRP registration requests with the same tunnel IP to
NBMA IP address mapping. The NHC must periodically send NHRP
registration requests to keep these mappings from expiring.
registered—The
mapping entry was created from receiving an NHRP registration request.
Registered mapping entries are dynamic entries, but they will not be
refreshed through the "used" mechanism. These entries are refreshed by
receiving another NHRP registration requests with the same tunnel IP to
NBMA IP address mapping. The NHC must periodically send NHRP
registration requests to keep these mappings from expiring.
–used—When
data packets are process-switched and this mapping entry was used, the
mapping entry is marked as used. The mapping data base is checked every
60 seconds. If the used flag is set and there are more than 120 seconds
left in the expire time, the used flag is cleared. If there are fewer
than 120 seconds left in the expire time, then this mapping entry is
"refreshed" by sending another NHRP resolution request.
NBMA
address—Nonbroadcast multiaccess address. The address format is
appropriate for the type of network being used (for example, GRE,
Ethernet, SMDS, or multipoint
used—When
data packets are process-switched and this mapping entry was used, the
mapping entry is marked as used. The mapping data base is checked every
60 seconds. If the used flag is set and there are more than 120 seconds
left in the expire time, the used flag is cleared. If there are fewer
than 120 seconds left in the expire time, then this mapping entry is
"refreshed" by sending another NHRP resolution request.
–router—NHRP
mapping entries that are for a remote router itself for access to a
network or host behind the remote router are marked with the router
flag.
router—NHRP
mapping entries that are for a remote router itself for access to a
network or host behind the remote router are marked with the router
flag.
–local—NHRP
mapping entries that are for a network's local to this router (serviced
by this router) are marked with the local flag. These entries are
created when this router answers an NHRP resolution request with this
information and are used by the rouer to store the tunnel IP address of
all of the other NHRP nodes to which this router has sent this
information. If for some reason this router loses access to this local
network (it can no longer service this network) it will send an NHRP
purge message to all remote NHRP nodes listed in the 'local' entry (this
list is not visible) to tell the remote nodes to clear this information
out of their NHRP mapping tables. This 'local' mapping entry times out
of the local
NHRP mapping database at the same time that this information (from the NHRP resolution reply) would time out of the NHRP mapping database on the remote NHRP nodes.
local—NHRP
mapping entries that are for a network's local to this router (serviced
by this router) are marked with the local flag. These entries are
created when this router answers an NHRP resolution request with this
information and are used by the rouer to store the tunnel IP address of
all of the other NHRP nodes to which this router has sent this
information. If for some reason this router loses access to this local
network (it can no longer service this network) it will send an NHRP
purge message to all remote NHRP nodes listed in the 'local' entry (this
list is not visible) to tell the remote nodes to clear this information
out of their NHRP mapping tables. This 'local' mapping entry times out
of the localNHRP mapping database at the same time that this information (from the NHRP resolution reply) would time out of the NHRP mapping database on the remote NHRP nodes.
–implicit—NHRP
mapping entries that were learned by the local node by using the source
NHRP mapping information from an NHRP resolution request or reply.
implicit—NHRP
mapping entries that were learned by the local node by using the source
NHRP mapping information from an NHRP resolution request or reply.
(no socket)—NHRP mapping entries for which the
router does not need nor want to trigger IPsec to set up encryption,
because the router does not have data traffic that needs to use this
tunnel. If later on there is data traffic that needs to use this tunnel
it will be converted from a "no socket" to a "socket" entry and IPsec
will be triggered to set up the encryption for this tunnel. Local and
implicit NHRP mapping entries are always initially marked as "no
socket."
NHRP by default caches source information from
NHRP resolution request or replies as they go through the system. In
order to allow this caching to continue, but not have the entry create
an IPsec socket they are marked as (no socket). If this was not done
there woudl be extra IPsec sockets from the hubs to the various spokes
that either were not used are were used for only one or two packets
while the spoke-to-spoke tunnel was being built. Data packets and NHRP
packets that arrive on the tunnel interface and are forwarded back out
the tunnel interface are not allowed to use the (no socket) NHRP
mappings for forwarding. Because in this case, the router is an
intermediate node in the path between the two endpoints and we only want
to create short-cut tunnels between the entrance and exit point of the
DMVPN (NBMA) network and not between any intermediate nodes. If at some
point the router receives a data packet that has a source interface that
is not the tunnel interface and it would use the (no socket) mapping
entry, the router converts the (no socket) entry to a (socket) entry.
And in this case, this router is the entrance (or exit) point of the
NBMA (for this traffic stream).
Also these (no socket) mapping entries are
marked (non-authoritative); only mappings from NHRP registrations are
marked (authoritative). The NHRP resolution requests are also marked
(authoritative), which means that the NHRP resolution request can be
answered only from an (authoritative) NHRP mapping entry. A (no socket)
mapping entry will not be used to answer an NHRP resolution request and
the NHRP resolution request will be forwarded to this nodes NHS.
–nat—This
setting is on NHRP mapping entries that are from NHRP registration
packets. This indicates that the remote node (NHS client) supports the
NHRP NAT extension type for supporting dynamic spoke-to-spoke tunnels to
or from spokes behind a NAT router. This flag does not mean that the
spoke (NHS client) is behind a NAT router.
•nat—This
setting is on NHRP mapping entries that are from NHRP registration
packets. This indicates that the remote node (NHS client) supports the
NHRP NAT extension type for supporting dynamic spoke-to-spoke tunnels to
or from spokes behind a NAT router. This flag does not mean that the
spoke (NHS client) is behind a NAT router. NBMA
address—Nonbroadcast multiaccess address. The address format is
appropriate for the type of network being used (for example, GRE,
Ethernet, SMDS, or multipoint 