Dynamic Multipoint VPN Configuration Guide
Dynamic Multipoint VPN Configuration Guide
15M&T
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of
the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com
go trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any
other company. (1721R)
© 2020 Cisco Systems, Inc. All rights reserved.
CONTENTS
CHAPTER 9 DMVPN Dynamic Tunnels Between Spokes Behind a NAT Device 141
Glossary 173
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
• For the NAT-Transparency Aware enhancement to work, you must use IPsec transport mode on the
transform set. Also, even though NAT-Transparency can support two peers (IKE and IPsec) being
translated to the same IP address (using the User Datagram Protocol [UDP] ports to differentiate them
[that is, Peer Address Translation (PAT)]), this functionality is not supported for DMVPN. All DMVPN
spokes must have a unique IP address after they have been NAT translated. They can have the same IP
address before they are NAT translated.
• To enable 2547oDMPVN--Traffic Segmentation Within DMVPN you must configure multiprotocol
label switching (MPLS) by using the mpls ip command.
Note It is highly recommended that you do not use wildcard preshared keys because the attacker will have access
to the VPN if one spoke router is compromised.
• GRE tunnel keepalives (that is, the keepalive command under a GRE interface) are not supported on
point-to-point or multipoint GRE tunnels in a DMVPN Network.
• For best DMVPN functionality, it is recommended that you run the latest Cisco IOS software Release
12.4 mainline,12.4T, or 12.2(18)SXF.
• If one spoke is behind one NAT device and another different spoke is behind another NAT device, and
Peer Address Translation (PAT) is the type of NAT used on both NAT devices, then a session initiated
between the two spokes cannot be established.
mGRE Interfaces
• If there are two mGRE interfaces on the same DMVPN node and they both do not have a tunnel key, the
two mGRE interfaces must each have a unique tunnel source address (or interface) configured.
• On the Cisco 6500 and Cisco 7600, each GRE interface (multipoint or point-to-point) must have a unique
tunnel source address (or interface).
• The following commands are not supported under mGRE with DMVPN: ip tcp adjust-mss, qos
pre-classify tunnel vrf, tunnel path-mtu-discovery, and tunnel vrf.
Tunnel Key
• The use of a tunnel key on a GRE (multipoint or point-to-point) interface is not supported in the hardware
switching ASICs on the Cisco 6500 and Cisco 7600 platforms. If a tunnel key is configured, throughput
performance is greatly reduced.
• In Cisco IOS Release 12.3(11)T3 and Release 12.3(14)T, the requirement that a mGRE interface must
have a tunnel key was removed. Therefore, in a DMVPN network that includes a Cisco 6500 or Cisco
7600 as a DMVPN node, you should remove the tunnel key from all DMVPN nodes in the DMVPN
network, thus preserving the throughput performance on the Cisco 6500 and Cisco 7600 platforms.
• If the tunnel key is not configured on any DMVPN node within a DMVPN network, it must not be
configured on all DMVPN nodes with the DMVPN network.
The topology shown in the diagram below and the corresponding bullets explain how this feature works.
Figure 1: Sample mGRE and IPsec Integration Topology
• Each spoke has a permanent IPsec tunnel to the hub, not to the other spokes within the network. Each
spoke registers as clients of the NHRP server.
• When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the
NHRP server for the real (outside) address of the destination (target) spoke.
• After the originating spoke “learns” the peer address of the target spoke, it can initiate a dynamic IPsec
tunnel to the target spoke.
• The spoke-to-spoke tunnel is built over the multipoint GRE interface.
• The spoke-to-spoke links are established on demand whenever there is traffic between the spokes.
Thereafter, packets can bypass the hub and use the spoke-to-spoke tunnel.
Note After a preconfigured amount of inactivity on the spoke-to-spoke tunnels, the router will tear down those
tunnels to save resources (IPsec security associations [SAs]).
IPsec Profiles
IPsec profiles abstract IPsec policy information into a single configuration entity, which can be referenced
by name from other parts of the configuration. Therefore, users can configure functionality such as GRE
tunnel protection with a single line of configuration. By referencing an IPsec profile, the user does not have
to configure an entire crypto map configuration. An IPsec profile contains only IPsec information; that is, it
does not contain any access list information or peering information.
Note Clear-text data IP packets are forwarded in a VRF using the ip vrf forwarding command, and encrypted
tunnel IP packets are forwarded in a VRF using the tunnel vrf command.
The ip vrf forwarding and tunnel vrf commands may be used at the same time. If they are used at the same
time, the VRF name of each command may be the same or different.
For information about configuring the forwarding of clear-text data IP packets into a VRF, see the section
“Configuring the Forwarding of Clear-Text Data IP Packets into a VRF.” For information about configuring
the forwarding of encrypted tunnel packets into a VRF, see the section “Configuring the Forwarding of
Encrypted Tunnel Packets into a VRF.”
For more information about configuring VRF, see reference in the “Related Documents” section.
The diagram below illustrates a typical VRF Integrated DMVPN scenario.
• The hub shown in the diagram is a WAN-PE and a route reflector, and the spokes (PE routers) are clients.
• There are three VRFs, designated “red,” “green,” and “blue.”
• Each spoke has both a neighbor relationship with the hub (multiprotocol Border Gateway Protocol
[MP-iBGP] peering) and a GRE tunnel to the hub.
• Each spoke advertises its routes and VPNv4 prefixes to the hub.
• The hub sets its own IP address as the next-hop route for all the VPNv4 addresses it learns from the
spokes and assigns a local MPLS label for each VPN when it advertises routes back to the spokes. As a
result, traffic from Spoke A to Spoke B is routed via the hub.
Note In Cisco IOS Release 12.4(6)T or earlier, DMVPN spokes behind NAT will not participate in dynamic direct
spoke-to-spoke tunnels. Any traffic to or from a spoke that is behind NAT will be forwarded using the DMVPN
hub routers. DMVPN spokes that are not behind NAT in the same DMVPN network may create dynamic
direct spoke-to-spoke tunnels between each other. In Cisco IOS Release 12.4(6)T or later releases, DMVPN
spokes behind NAT will participate in dynamic direct spoke-to-spoke tunnels. The spokes must be behind
NAT boxes that are preforming NAT, not PAT. The NAT box must translate the spoke to the same outside
NAT IP address for the spoke-spoke connections as the NAT box does for the spoke-hub connection. If there
is more than one DMVPN spoke behind the same NAT box, then the NAT box must translate the DMVPN
spokes to different outside NAT IP addresses. It is also likely that you may not be able to build a direct
spoke-spoke tunnel between these spokes. If a spoke-spoke tunnel fails to form, then the spoke-spoke packets
will continue to be forwarded via the spoke-hub-spoke path.
For more information about this system message, see the document 12.4T System Message Guide.
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
SUMMARY STEPS
1. enable
2. configure terminal
3. crypto ipsec profile name
4. set transform-set transform-set-name
5. set identity
6. set security association lifetime {seconds seconds | kilobytes kilobytes}
7. set pfs [group1 | group14 | group15 | group16 | group19 | group2 | group20 | group24 | group5]
DETAILED STEPS
Step 4 set transform-set transform-set-name Specifies which transform sets can be used with the IPsec
profile.
Example:
• The transform-set-name argument specifies the name
Router(config-crypto-map)# set transform-set trans2 of the transform set.
Step 5 set identity (Optional) Specifies identity restrictions to be used with the
IPsec profile.
Example:
Step 6 set security association lifetime {seconds seconds | (Optional) Overrides the global lifetime value for the IPsec
kilobytes kilobytes} profile.
Example: • The seconds seconds option specifies the number of
seconds a security association will live before expiring;
Router(config-crypto-map)# set security association the kilobytes kilobytesoption specifies the volume of
lifetime seconds 1800 traffic (in kilobytes) that can pass between IPsec peers
using a given security association before that security
association expires.
• The default for the seconds argument is 3600 seconds.
Step 7 set pfs [group1 | group14 | group15 | group16 | group19 (Optional) Specifies that IPsec should ask for perfect
| group2 | group20 | group24 | group5] forward secrecy (PFS) when requesting new security
associations for this IPsec profile. If this command is not
Example:
specified, the default Diffie-Hellman (DH) group, group1
will be enabled.
Router(config-crypto-map)# set pfs group14
• 1—768-bit DH (No longer recommended.)
• 2—1024-bit DH (No longer recommended)
• 5—1536-bit DH (No longer recommended)
• 14—Specifies the 2048-bit DH group.
• 15—Specifies the 3072-bit DH group.
• 16—Specifies the 4096-bit DH group.
• 19—Specifies the 256-bit elliptic curve DH (ECDH)
group.
• 20—Specifies the 384-bit ECDH group.
What to Do Next
Proceed to the following sections “Configuring the Hub for DMVPN” and “Configuring the Spoke for
DMVPN.”
Note NHRP network IDs are locally significant and can be different. It makes sense from a deployment and
maintenance perspective to use unique network IDnumbers (using the ip nhrp network-id command) across
all routers in a DMVPN network, but it is not necessary that they be the same.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip address ip-address mask secondary
5. ip mtu bytes
6. ip nhrp authentication string
7. ip nhrp map multicast dynamic
8. ip nhrp network-id number
9. tunnel source {ip-address | type number}
10. tunnel key key-number
11. tunnel mode gre multipoint
12. tunnel protection ipsec profile name
13. bandwidth kbps
14. ip tcp adjust-mss max-segment-size
15. ip nhrp holdtime seconds
16. delay number
DETAILED STEPS
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode
Example:
• The number argument specifies the number of the
Router(config)# tunnel interface that you want to create or configure.
interface tunnel 5 There is no limit on the number of tunnel interfaces
you can create.
Step 4 ip address ip-address mask secondary Sets a primary or secondary IP address for the tunnel
interface.
Example:
Note All hubs and spokes that are in the same
Router(config-if)# ip address 10.0.0.1 DMVPN network must be addressed in the
255.255.255.0 same IP subnet.
Step 5 ip mtu bytes Sets the maximum transmission unit (MTU) size, in bytes,
of IP packets sent on an interface.
Example:
Step 6 ip nhrp authentication string Configures the authentication string for an interface using
NHRP.
Example:
Note The NHRP authentication string must be set to
Router(config-if)# ip nhrp authentication donttell the same value on all hubs and spokes that are
in the same DMVPN network.
Step 7 ip nhrp map multicast dynamic Allows NHRP to automatically add spoke routers to the
multicast NHRP mappings.
Example:
Step 9 tunnel source {ip-address | type number} Sets source address for a tunnel interface.
Example:
Step 11 tunnel mode gre multipoint Sets the encapsulation mode to mGRE for the tunnel
interface.
Example:
Router(config-if)#
tunnel mode gre multipoint
Step 12 tunnel protection ipsec profile name Associates a tunnel interface with an IPsec profile.
Example: • The name argument specifies the name of the IPsec
profile; this value must match the name specified in
Router(config-if)# the crypto ipsec profile namecommand.
tunnel protection ipsec profile vpnprof
Step 13 bandwidth kbps Sets the current bandwidth value for an interface to
higher-level protocols.
Example:
• The kbps argument specifies the bandwidth in kilobits
Router(config-if)# bandwidth 1000 per second. The default value is 9. The recommend
bandwidth value is 1000 or greater.
Step 14 ip tcp adjust-mss max-segment-size Adjusts the maximum segment size (MSS) value of TCP
packets going through a router.
Example:
• The max-segment-size argument specifies the
Router(config-if)# ip tcp adjust-mss 1360 maximum segment size, in bytes. The range is from
500 to 1460.
Step 16 delay number (Optional) Used to change the EIGRP routing metric for
routes learned over the tunnel interface.
Example:
• The number argument specifies the delay time in
Router(config-if)# delay 1000 seconds. The recommend value is 1000.
Note NHRP network IDs are locally significant and can be different. It makes sense from a deployment and
maintenance perspective to use unique network IDnumbers (using the ip nhrp network-id command) across
all routers in a DMVPN network, but it is not necessary that they be the same.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip address ip-address mask secondary
5. ip mtu bytes
6. ip nhrp authentication string
7. ip nhrp map hub-tunnel-ip-address hub-physical-ip-address
8. ip nhrp map multicast hub-physical-ip-address
9. ip nhrp nhs hub-tunnel-ip-address
10. ip nhrp network-id number
11. tunnel source {ip-address | type number}
12. tunnel key key-number
13. Do one of the following:
• tunnel mode gre multipoint
• tunnel destination hub-physical-ip-address
14. tunnel protection ipsec profile name
15. bandwidth kbps
DETAILED STEPS
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
• The number argument specifies the number of the
Router(config)# tunnel interface that you want to create or configure.
interface tunnel 5 There is no limit on the number of tunnel interfaces
you can create.
Step 4 ip address ip-address mask secondary Sets a primary or secondary IP address for the tunnel
interface.
Example:
Note All hubs and spokes that are in the same
Router(config-if)# ip address 10.0.0.2 DMVPN network must be addressed in the
255.255.255.0 same IP subnet.
Step 5 ip mtu bytes Sets the MTU size, in bytes, of IP packets sent on an
interface.
Example:
Step 6 ip nhrp authentication string Configures the authentication string for an interface using
NHRP.
Example:
Note The NHRP authentication string be set to the
Router(config-if)# ip nhrp authentication donttell same value on all hubs and spokes that are in
the same DMVPN network.
Step 7 ip nhrp map hub-tunnel-ip-address hub-physical-ip-address Statically configures the IP-to-NBMA address mapping
of IP destinations connected to an MBMA network.
Example:
• hub-tunnel-ip-address --Defines the NHRP server at
Router(config-if)# ip nhrp map 10.0.0.1 172.17.0.1 the hub, which is permanently mapped to the static
public IP address of the hub.
Step 8 ip nhrp map multicast hub-physical-ip-address Enables the use of a dynamic routing protocol between the
spoke and hub, and sends multicast packets to the hub
Example:
router.
Router(config-if)# ip nhrp map multicast
172.17.0.1
Step 9 ip nhrp nhs hub-tunnel-ip-address Configures the hub router as the NHRP next-hop server.
Example:
Step 11 tunnel source {ip-address | type number} Sets the source address for a tunnel interface.
Example:
Step 12 tunnel key key-number (Optional) Enables an ID key for a tunnel interface.
Example: • The key-number argument specifies a number from
0 to 4,294,967,295 that identifies the tunnel key.
Router (config-if)# tunnel key 100000
• The key number must be set to the same value on all
hubs and spokes that are in the same DMVPN
network.
Step 13 Do one of the following: Sets the encapsulation mode to mGRE for the tunnel
interface.
• tunnel mode gre multipoint
• tunnel destination hub-physical-ip-address Use this command if data traffic can use dynamic
spoke-to-spoke traffic.
Example:
Specifies the destination for a tunnel interface.
Router(config-if)#
tunnel mode gre multipoint
Use this command if data traffic can use hub-and-spoke
tunnels.
Example:
Router(config-if)#
tunnel destination 172.17.0.1
Step 15 bandwidth kbps Sets the current bandwidth value for an interface to
higher-level protocols.
Example:
• The kbps argument specifies the bandwidth in kilobits
Router(config-if)# bandwidth 1000 per second. The default value is 9. The recommend
bandwidth value is 1000 or greater.
The bandwidth setting for the spoke does not need to equal
the bandwidth setting for the DMVPN hub. It is usually
easier if all of the spokes use the same or similar value.
Step 16 ip tcp adjust-mss max-segment-size Adjusts the maximum segment size (MSS) value of TCP
packets going through a router.
Example:
• The max-segment-size argument specifies the
Router(config-if)# ip tcp adjust-mss 1360 maximum segment size, in bytes. The range is from
500 to 1460.
Step 17 ip nhrp holdtime seconds Changes the number of seconds that NHRP NBMA
addresses are advertised as valid in authoritative NHRP
Example:
responses.
Router(config-if)# ip nhrp holdtime 450 • The seconds argument specifies the time in seconds
that NBMA addresses are advertised as valid in
positive authoritative NHRP responses. The
recommended value ranges from 300 seconds to 600
seconds.
Step 18 delay number (Optional) Used to change the EIGRP routing metric for
routes learned over the tunnel interface.
Example:
• The number argument specifies the delay time in
Router(config-if)# delay 1000 seconds. The recommend value is 1000.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip vrf forwarding vrf-name
DETAILED STEPS
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example:
Step 4 ip vrf forwarding vrf-name Associates a VPN VRF with an interface or subinterface.
Example:
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. tunnel vrf vrf-name
DETAILED STEPS
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example:
Step 4 tunnel vrf vrf-name Associates a VPN VRF instance with a specific tunnel
destination, interface, or subinterface.
Example:
Prerequisites
The tasks that follow assume that the DMVPN tunnel and the VRFs “red” and “blue” have already been
configured.
For information on configuring a DMVPN tunnel, see the Configuring the Hub for DMVPN task and the
Configuring the Spoke for DMVPN. For details about VRF configuration, see the Configuring the Forwarding
of Clear-Text Data IP Packets into a VRF task and the Configuring the Forwarding of Encrypted Tunnel
Packets into a VRF task.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. mpls ip
DETAILED STEPS
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example:
SUMMARY STEPS
1. enable
2. configure terminal
3. router bgp
4. neighbor ipaddress remote-as as - number
5. neighbor ipaddress update-source interface
6. address-family vpnv4
7. neighbor ipaddress activate
8. neighbor ipaddress send-community extended
9. neighbor ipaddress route-reflector-client
10. neighbor ipaddress route-map nexthop out
11. exit-address-family
12. address-family ipv4 vrf-name
13. redistribute connected
14. route-map
15. set ip next-hop ipaddress
DETAILED STEPS
Step 4 neighbor ipaddress remote-as as - number Adds an entry to the BGP or multiprotocol BGP neighbor
table.
Example:
Step 5 neighbor ipaddress update-source interface Configures the Cisco IOS software to allow BGP sessions
to use any operational interface for TCP connections.
Example:
Step 7 neighbor ipaddress activate Enables the exchange of information with a BGP neighbor.
Example:
Step 8 neighbor ipaddress send-community extended Specifies that extended community attributes should be
sent to a BGP neighbor.
Example:
Step 9 neighbor ipaddress route-reflector-client Configures the router as a BGP route reflector and
configures the specified neighbor as its client.
Example:
Step 10 neighbor ipaddress route-map nexthop out Forces all traffic to be routed via the hub.
Example:
Step 11 exit-address-family Exits the address family configuration mode for VPNv4.
Example:
Step 12 address-family ipv4 vrf-name Enters address family configuration mode to configure a
routing session using standard IP Version 4 address
Example:
prefixes.
Router (config)# address-family ipv4 vrf red
Step 15 set ip next-hop ipaddress Sets the next hop to be the hub.
Example:
SUMMARY STEPS
1. enable
2. configure terminal
3. router bgp
4. neighbor ipaddress remote-as as - number
5. neighbor ipaddress update-source interface
6. address-family vpnv4
DETAILED STEPS
Step 4 neighbor ipaddress remote-as as - number Adds an entry to the BGP or multiprotocol BGP neighbor
table.
Example:
Step 5 neighbor ipaddress update-source interface Configures the Cisco IOS software to allow BGP sessions
to use any operational interface for TCP connections.
Example:
Step 7 neighbor ipaddress activate Enables the exchange of information with a BGP neighbor.
Example:
Step 8 neighbor ipaddress send-community extended Specifies that extended community attributes should be
sent to a BGP neighbor.
Example:
Step 10 address-family ipv4 vrf-name Enters address family configuration mode to configure a
routing session using standard IP Version 4 address
Example:
prefixes.
Router (config)# address-family ipv4 vrf red
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
SUMMARY STEPS
1. The clear dmvpn session command is used to clear DMVPN sessions.
2. The clear dmvpn statistics command is used to clear DMVPN related counters. The following example
shows how to clear DMVPN related session counters for the specified tunnel interface:
3. The debug dmvpn command is used to debug DMVPN sessions. You can enable or disable DMVPN
debugging based on a specific condition. There are three levels of DMVPN debugging, listed in the
order of details from lowest to highest:
4. The debug nhrp conditioncommand enables or disables debugging based on a specific condition. The
following example shows how to enable conditional NHRP debugging:
5. The debug nhrp errorcommand displays information about NHRP error activity. The following example
shows how to enable debugging for NHRP error messages:
6. The logging dmvpn command is used to enable DMVPN system logging. The following command
shows how to enable DMVPN system logging at the rate of 1 message every 20 seconds:
7. The show crypto ipsec sacommand displays the settings used by the current SAs. The following example
output shows the IPsec SA status of only the active device:
8. The show crypto isakmp sacommand displays all current IKE SAs at a peer. For example, the following
sample output is displayed after IKE negotiations have successfully completed between two peers.
9. The show crypto map command displays the crypto map configuration.
10. The show dmvpn command displays DMVPN specific session information. The following example
shows example summary output:
11. The show ip nhrp trafficcommand displays NHRP statistics. The following example shows output for
a specific tunnel, tunnel7:
DETAILED STEPS
Step 1 The clear dmvpn session command is used to clear DMVPN sessions.
The following example clears only dynamic DMVPN sessions:
Router# clear dmvpn session peer nbma
The following example clears all DMVPN sessions, both static and dynamic, for the specified tunnel:
Router# clear dmvpn session interface tunnel 100 static
Step 2 The clear dmvpn statistics command is used to clear DMVPN related counters. The following example shows how
to clear DMVPN related session counters for the specified tunnel interface:
Router# clear dmvpn statistics peer tunnel 192.0.2.3
Step 3 The debug dmvpn command is used to debug DMVPN sessions. You can enable or disable DMVPN debugging based
on a specific condition. There are three levels of DMVPN debugging, listed in the order of details from lowest to
highest:
• Error level
• Detail level
• Packet level
The following example shows how to enable conditional DMVPN debugging that displays all error debugs for next
hop routing protocol (NHRP), sockets, tunnel protection and crypto information: Router# debug dmvpn error all
Step 4 The debug nhrp conditioncommand enables or disables debugging based on a specific condition. The following
example shows how to enable conditional NHRP debugging:
Router# debug nhrp condition
Step 5 The debug nhrp errorcommand displays information about NHRP error activity. The following example shows how
to enable debugging for NHRP error messages:
Router# debug nhrp error
Step 6 The logging dmvpn command is used to enable DMVPN system logging. The following command shows how to
enable DMVPN system logging at the rate of 1 message every 20 seconds:
Router(config)# logging dmvpn rate-limit 20
The following example shows a sample system log with DMVPN messages:
Example:
Step 7 The show crypto ipsec sacommand displays the settings used by the current SAs. The following example output shows
the IPsec SA status of only the active device:
Example:
Router#
show crypto ipsec sa active
interface: Ethernet0/0
Crypto map tag: to-peer-outside, local addr 209.165.201.3
protected vrf: (none
local ident (addr/mask/prot/port): (192.168.0.1/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (172.16.0.1/255.255.255.255/0/0)
current_peer 209.165.200.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 209.165.201.3, remote crypto endpt.: 209.165.200.225
path mtu 1500, media mtu 1500
current outbound spi: 0xD42904F0(3559458032)
inbound esp sas:
spi: 0xD3E9ABD0(3555306448)
transform: esp-aes ,
in use settings ={Tunnel, }
conn id: 2006, flow_id: 6, crypto map: to-peer-outside
sa timing: remaining key lifetime (k/sec): (4586265/3542)
HA last key lifetime sent(k): (4586267)
ike_cookies: 9263635C CA4B4E99 C14E908E 8EE2D79C
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
Step 8 The show crypto isakmp sacommand displays all current IKE SAs at a peer. For example, the following sample output
is displayed after IKE negotiations have successfully completed between two peers.
Example:
Step 9 The show crypto map command displays the crypto map configuration.
The following sample output is displayed after a crypto map has been configured:
Example:
Step 10 The show dmvpn command displays DMVPN specific session information. The following example shows example
summary output:
Example:
Step 11 The show ip nhrp trafficcommand displays NHRP statistics. The following example shows output for a specific tunnel,
tunnel7:
Router# show ip nhrp traffic interface tunnel7
Example:
What to Do Next
If you have troubleshooted your DMVPN configuration and proceed to contact technical support, the show
tech-support command includes information for DMVPN sessions. For more information, see the show
tech-supportcommand in the Cisco IOS Configuration Fundamentals Command Reference.
For information about defining and configuring ISAKMP profiles, see the references in the “Related
Documents” section.
Note If you use the shared keyword, then you should be running Cisco IOS Release 12.4(5) or Release 12.4(6)T,
or a later release. Otherwise the IPsec/GRE tunnels under the two mGRE tunnel interfaces may not function
correctly.
Hub Configuration
interface Tunnel0
! Note the next line.
ip vrf forwarding BLUE
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1436
! Note the next line.
ip nhrp authentication BLUE!KEY
ip nhrp map multicast dynamic
! Note the next line
ip nhrp network-id 100000
ip nhrp holdtime 600
no ip split-horizon eigrp 1
no ip next-hop-self eigrp 1
ip tcp adjust-mss 1360
delay 1000
! Note the next line.
tunnel source Ethernet0
tunnel mode gre multipoint
tunnel protection ipsec profile vpnprof!
interface Tunnel1
! Note the next line.
ip vrf forwarding RED
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1436
! Note the next line.
ip nhrp authentication RED!KEY
ip nhrp map multicast dynamic
! Note the next line.
ip nhrp network-id 20000
ip nhrp holdtime 600
no ip split-horizon eigrp 1
no ip next-hop-self eigrp 1
ip tcp adjust-mss 1360
delay 1000
! Note the next line.
tunnel source Ethernet1
tunnel mode gre multipoint
tunnel protection ipsec profile vpnprof!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
interface Ethernet1
ip address 192.0.2.171 255.255.255.0
Note For the hub configuration shown above, a separate DMVPN network is configured for each VPN. The NHRP
network ID and authentication keys must be unique on the two mGRE interfaces.
router eigrp 1
auto-summary
!
address-family ipv4 vrf BLUE
network 10.0.0.0 0.0.0.255
no auto-summary
autonomous-system 1
exit-address-family
!
address-family ipv4 vrf RED
network 10.0.0.0 0.0.0.255
no auto-summary
autonomous-system 1
exit-address-family
Spoke Configurations
Spoke 1:
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.0
ip mtu 1436
! Note the next line.
ip nhrp authentication BLUE!KEY
ip nhrp map 10.0.0.1 172.17.0.1
ip nhrp network-id 100000
Spoke 2:
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.0
ip mtu 1436
ip nhrp authentication RED!KEY
ip nhrp map 10.0.0.1 192.0.2.171
ip nhrp network-id 200000
ip nhrp holdtime 300
ip nhrp nhs 10.0.0.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Ethernet0
tunnel destination 192.0.2.171
tunnel protection ipsec profile vpnprof!
Hub Configuration
hostname hub-pe1
boot-start-marker
boot-end-marker
no aaa new-model
resource policy
clock timezone EST 0
ip cef
no ip domain lookup
!This section refers to the forwarding table for VRF blue:
ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2
!This section refers to the forwarding table for VRF red:
ip vrf red
rd 1:1
route-target export 1:1
route-target import 1:1
mpls label protocol ldp
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set t1 esp-aes
mode transport
Spoke Configurations
Spoke 2
hostname spoke-pe2
boot-start-marker
boot-end-marker
no aaa new-model
resource policy
clock timezone EST 0
ip cef
no ip domain lookup
!This section refers to the forwarding table for VRF blue:
ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2
!This section refers to the forwarding table for VRF red:
ip vrf red
rd 1:1
route-target export 1:1
route-target import 1:1
mpls label protocol ldp
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set t1 esp-aes
mode transport
crypto ipsec profile prof
set transform-set t1
interface Tunnel1
ip address 10.0.0.11 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp map 10.0.0.1 172.0.0.1
ip nhrp map multicast 172.0.0.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
!The command below enables MPLS on the DMVPN network:
mpls ip
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile prof
interface Loopback0
ip address 10.9.9.11 255.255.255.255
interface Ethernet0/0
ip address 172.0.0.11 255.255.255.0
!
!
interface Ethernet1/0
ip vrf forwarding red
ip address 192.168.11.2 255.255.255.0
interface Ethernet2/0
ip vrf forwarding blue
ip address 192.168.11.2 255.255.255.0
!The multiprotocol BGP route reflector (the hub) configuration changes the next-hop
information to set itself as the next-hop and assigns a new VPN label for the prefixes
learned from the spokes and advertises the VPN prefix:
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 1
neighbor 10.0.0.1 update-source Tunnel1
no auto-summary
address-family vpnv4
neighbor 10.0.0.1 activate
neighbor 10.0.0.1 send-community extended
exit-address-family
!
address-family ipv4 vrf red
redistribute connected
no synchronization
exit-address-family
!
address-family ipv4 vrf blue
redistribute connected
no synchronization
exit-address-family
no ip http server
no ip http secure-server
control-plane
line con 0
logging synchronous
line aux 0
line vty 0 4
no login
end
Spoke 3
hostname spoke-PE3
boot-start-marker
boot-end-marker
no aaa new-model
resource policy
clock timezone EST 0
ip cef
no ip domain lookup
!This section refers to the forwarding table for VRF blue:
ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2
!This section refers to the forwarding table for VRF red:
ip vrf red
rd 1:1
route-target export 1:1
route-target import 1:1
mpls label protocol ldp
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set t1 esp-aes
mode transport
crypto ipsec profile prof
set transform-set t1
interface Tunnel1
ip address 10.0.0.12 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map multicast dynamic
Hub Configuration
hostname HUB
boot-start-marker
boot-end-marker
no aaa new-model
resource policy
clock timezone EST 0
ip cef
no ip domain lookup
!This section refers to the forwarding table for VRF blue:
ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2
!This refers to the forwarding table for VRF red:
ip vrf red
rd 1:1
route-target export 1:1
route-target import 1:1
mpls label protocol ldp
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set t1 esp-aes
mode transport
crypto ipsec profile prof
set transform-set t1
interface Tunnel1
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
!EIGRP is enabled on the DMVPN network to learn the IGP prefixes:
no ip split-horizon eigrp 1
!The command below enables MPLS on the DMVPN network:
mpls ip
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile prof
!This address is advertised by EIGRP and used as the BGP endpoint:
interface Loopback0
ip address 10.9.9.1 255.255.255.255
interface Ethernet0/0
ip address 172.0.0.1 255.255.255.0
!EIGRP is configured to learn the BGP peer addresses (10.9.9.x networks)
router eigrp 1
network 10.9.9.1 0.0.0.0
network 10.0.0.0 0.0.0.255
no auto-summary
!The multiprotocol BGP route reflector (the hub) configuration changes the next-hop
information to set itself as the next-hop and assigns a new VPN label for the prefixes
learned from the spokes and advertises the VPN prefix:
router bgp 1
no synchronization
bgp router-id 10.9.9.1
bgp log-neighbor-changes
neighbor 10.9.9.11 remote-as 1
neighbor 10.9.9.11 update-source Loopback0
neighbor 10.9.9.12 remote-as 1
neighbor 10.9.9.12 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 10.9.9.11 activate
neighbor 10.9.9.11 send-community extended
Spoke Configurations
Spoke 2
hostname Spoke2
boot-start-marker
boot-end-marker
no aaa new-model
resource policy
clock timezone EST 0
ip cef
no ip domain lookup
!This section refers to the forwarding table for VRF blue:
ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2
!This section refers to the forwarding table for VRF red:
ip vrf red
rd 1:1
route-target export 1:1
route-target import 1:1
mpls label protocol ldp
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set t1 esp-aes
mode transport
crypto ipsec profile prof
set transform-set t1
interface Tunnel1
ip address 10.0.0.11 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp map 10.0.0.1 172.0.0.1
ip nhrp map multicast 172.0.0.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
!The command below enables MPLS on the DMVPN network:
mpls ip
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile prof
!This address is advertised by EIGRP and used as the BGP endpoint:
interface Loopback0
ip address 10.9.9.11 255.255.255.255
interface Ethernet0/0
ip address 172.0.0.11 255.255.255.0
interface Ethernet1/0
ip vrf forwarding red
ip address 192.168.11.2 255.255.255.0
interface Ethernet2/0
ip vrf forwarding blue
ip address 192.168.11.2 255.255.255.0
!EIGRP is enabled on the DMVPN network to learn the IGP prefixes:
router eigrp 1
network 10.9.9.11 0.0.0.0
network 10.0.0.0 0.0.0.255
no auto-summary
!The multiprotocol BGP route reflector (the hub) configuration changes the next-hop
information to set itself as the next-hop and assigns a new VPN label for the prefixes
learned from the spokes and advertises the VPN prefix:
router bgp 1
no synchronization
bgp router-id 10.9.9.11
bgp log-neighbor-changes
neighbor 10.9.9.1 remote-as 1
neighbor 10.9.9.1 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 10.9.9.1 activate
neighbor 10.9.9.1 send-community extended
exit-address-family
address-family ipv4 vrf red
redistribute connected
no synchronization
exit-address-family
address-family ipv4 vrf blue
redistribute connected
no synchronization
exit-address-family
no ip http server
no ip http secure-server
control-plane
line con 0
logging synchronous
line aux 0
line vty 0 4
no login
end
Spoke 3
hostname Spoke3
boot-start-marker
boot-end-marker
no aaa new-model
resource policy
clock timezone EST 0
ip cef
no ip domain lookup
!This section refers to the forwarding table for VRF blue:
ip vrf blue
rd 2:2
route-target export 2:2
route-target import 2:2
!This section refers to the forwarding table for VRF red:
ip vrf red
rd 1:1
route-target export 1:1
route-target import 1:1
mpls label protocol ldp
crypto isakmp policy 1
encr aes
authentication pre-share
group 14
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set t1 esp-aes
mode transport
crypto ipsec profile prof
set transform-set t1
interface Tunnel1
ip address 10.0.0.12 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp map 10.0.0.1 172.0.0.1
ip nhrp map multicast 172.0.0.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
!The command below enables MPLS on the DMVPN network:
mpls ip
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile prof
!This address is advertised by EIGRP and used as the BGP endpoint:
interface Loopback0
ip address 10.9.9.12 255.255.255.255
interface Ethernet0/0
ip address 172.0.0.12 255.255.255.0
interface Ethernet1/0
ip vrf forwarding red
ip address 192.168.12.2 255.255.255.0
interface Ethernet2/0
ip vrf forwarding blue
ip address 192.168.12.2 255.255.255.0
!EIGRP is enabled on the DMVPN network to learn the IGP prefixes:
router eigrp 1
network 10.9.9.12 0.0.0.0
network 10.0.0.0 0.0.0.255
no auto-summary
!The multiprotocol BGP route reflector (the hub) configuration changes the next-hop
information to set itself as the next-hop and assigns a new VPN label for the prefixes
learned from the spokes and advertises the VPN prefix:
router bgp 1
no synchronization
bgp router-id 10.9.9.12
bgp log-neighbor-changes
neighbor 10.9.9.1 remote-as 1
neighbor 10.9.9.1 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 10.9.9.1 activate
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 4 4
Keepalives: 4 4
Route Refresh: 0 0
Total: 9 9
Default minimum time between advertisement runs is 0 seconds
Additional References
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
GRE tunnel keepalive information The chapter "Implementing Tunnels" in the Interface and
Hardware Component Configuration Guide.
IKE configuration tasks such as defining The chapter "Configuring Internet Key Exchange for IPSec VPNs"
an IKE policy in the Cisco IOS Security Configuration Guide: Secure
Connectivity
IPsec configuration tasks The chapter "Configuring Security for VPNs with IPsec" in the
Cisco IOS Security Configuration Guide: Secure Connectivity
Configuring VRF-Aware IPsec The chapter "VRF-Aware IPsec" in the Cisco IOS Security
Configuration Guide: Secure Connectivity
Configuring BGP The chapter "Cisco BGP Overview" in the Cisco IOS IP Routing:
BGP Protocols Configuration Guide
Defining and configuring ISAKMP "Certificate to ISAKMP Profile Mapping" chapter in the Cisco
profiles IOS Security Configuration Guide: Secure Connectivity
Standards
Standards Title
None --
MIBs
None To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use
Cisco MIB Locator found at the following URL:
http://www.cisco.com/go/mibs
RFCs
RFCs Title
Technical Assistance
Description Link
DMVPN--Enabling 12.4(11)T The 2547oDMVPN feature allows users to segment VPN traffic
Traffic Segmentation within a DMVPN tunnel by applying MPLS labels to VRF instances
Within DMVPN to indicate the source and destination of each VRF.
Mangeability 12.4(9)T DMVPN session manageabilty was expanded with DMVPN specific
Enhancements for commands for debugging, show output, session and counter control,
DMVPN and system log information.
The following sections provide information about this feature:
• Troubleshooting Dynamic Multipoint VPN (DMVPN)
DMVPN Phase 2 12.2(18)SXE DMVPN Spoke-to-Spoke functionality was made more production
12.3(9)a ready. If you are using this functionality in a production network,
12.3(8)T1 the minimum release is Release 12.3(9a) or Release 12.3(8)T1.
In Release 12.2(18)SXE, support was added for the Cisco Catalyst
6500 series switch and the Cisco 7600 series router.
Dynamic Multipoint 12.2(13)T The Dynamic Multipoint VPN (DMVPN) feature allows users to
VPN (DMVPN) better scale large and small IPsec Virtual Private Networks (VPNs)
Phase 1 by combining generic routing encapsulation (GRE) tunnels, IP
security (IPsec) encryption, and Next Hop Resolution Protocol
(NHRP).
Glossary
AM --aggressive mode. A mode during IKE negotiation. Compared to MM, AM eliminates several steps,
making it faster but less secure than MM. Cisco IOS software will respond in aggressive mode to an IKE peer
that initiates aggressive mode.
GRE --generic routing encapsulation. Tunnels that provide a specific pathway across the shared WAN and
encapsulate traffic with new packet headers to ensure delivery to specific destinations. The network is private
because traffic can enter a tunnel only at an endpoint. Tunnels do not provide true confidentiality (encryption
does) but can carry encrypted traffic.
GRE tunneling can also be used to encapsulate non-IP traffic into IP and send it over the Internet or IP network.
The Internet Package Exchange (IPX) and AppleTalk protocols are examples of non-IP traffic.
IKE --Internet Key Exchange. A hybrid protocol that implements Oakley key exchange and Skeme key
exchange inside the ISAKMP framework. Although IKE can be used with other protocols, its initial
implementation is with IPsec. IKE provides authentication of the IPsec peers, negotiates IPsec keys, and
negotiates IPsec security associations.
IPsec --IP security. A framework of open standards developed by the Internet Engineering Task Force (IETF).
IPsec provides security for transmission of sensitive information over unprotected networks such as the
Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec
devices (“peers”), such as Cisco routers.
ISAKMP --Internet Security Association Key Management Protocol. A protocol framework that defines
payload formats, the mechanics of implementing a key exchange protocol, and the negotiation of a security
association.
MM --main mode. Mode that is slower than aggressive mode but more secure and more flexible than aggressive
mode because it can offer an IKE peer more security proposals. The default action for IKE authentication
(rsa-sig, rsa-encr, or preshared) is to initiate main mode.
NHRP --Next Hop Resolution Protocol. Routers, access servers, and hosts can use NHRP to discover the
addresses of other routers and hosts connected to a NBMA network.
The Cisco implementation of NHRP supports the IETF draft version 11 of NBMA Next Hop Resolution
Protocol (NHRP).
The Cisco implementation of NHRP supports IP Version 4, Internet Packet Exchange (IPX) network layers,
and, at the link layer, ATM, Ethernet, SMDS, and multipoint tunnel networks. Although NHRP is available
on Ethernet, NHRP need not be implemented over Ethernet media because Ethernet is capable of broadcasting.
Ethernet support is unnecessary (and not provided) for IPX.
PFS --Perfect Forward Secrecy. A cryptographic characteristic associated with a derived shared secret value.
With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent
keys are not derived from previous keys.
SA --security association. Describes how two or more entities will utilize security services to communicate
securely. For example, an IPsec SA defines the encryption algorithm (if used), the authentication algorithm,
and the shared session key to be used during the IPsec connection.
Both IPsec and IKE require and use SAs to identify the parameters of their connections. IKE can negotiate
and establish its own SA. The IPsec SA is established either by IKE or by manual user configuration.
transform --The list of operations done on a dataflow to provide data authentication, data confidentiality,
and data compression. One example of a transform is ESP with the 256-bit AES encryption algorithm and
the AH protocol with the HMAC-SHA authentication algorithm.
VPN --Virtual Private Network. A framework that consists of multiple peers transmitting private data securely
to one another over an otherwise public infrastructure. In this framework, inbound and outbound network
traffic is protected using protocols that tunnel and encrypt all data. This framework permits networks to extend
beyond their local topology, while remote users are provided with the appearance and functionality of a direct
network connection.
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
In DMVPN for IPv6, the public network (the Internet) is a pure IPv4 network, and the private network (the
intranet) is IPv6 capable. The intranets could be a mix of IPv4 or IPv6 clouds connected to each other using
DMVPN technologies, with the underlying carrier being a traditional IPv4 network.
NHRP Routing
The NHRP protocol resolves a given intranet address (IPv4 or IPv6) to an Internet address (IPv4 nonbroadcast
multiaccess [NBMA] address).
In the figure below, the intranets that are connected over the DMVPN network are IPv6 clouds, and the Internet
is a pure IPv4 cloud. Spokes S1 and S2 are connected to Hub H over the Internet using a statically configured
tunnel. The address of the tunnel itself is the IPv6 domain, because it is another node on the intranet. The
source and destinations address of the tunnel (the mGRE endpoints), however, are always in IPv4, in the
Internet domain. The mGRE tunnel is aware of the IPv6 network because the GRE passenger protocol is an
IPv6 packet, and the GRE transport (or carrier) protocol is an IPv4 packet.
When an IPv6 host in LAN L1 sends a packet destined to an IPv6 host in LAN L2, the packet is first routed
to the gateway (which is Spoke S1) in LAN L1. Spoke S1 is a dual-stack device, which means both IPv4 and
IPv6 are configured on it. The IPv6 routing table in S1 points to a next hop, which is the IPv6 address of the
tunnel on Spoke S2. This is a VPN address that must be mapped to an NBMA address, triggering NHRP.
IPv6 Routing
NHRP is automatically invoked for mGRE tunnels carrying the IPv6 passenger protocol. When a packet is
routed and sent to the switching path, NHRP looks up the given next hop and, if required, initiates an NHRP
resolution query. If the resolution is successful, NHRP populates the tunnel endpoint database, which in turn
populates the Cisco Express Forwarding adjacency table. The subsequent packets are Cisco Express Forwarding
switched if Cisco Express Forwarding is enabled.
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
The IPsec profile shares most commands with the crypto map configuration, but only a subset of the commands
are valid in an IPsec profile. Only commands that pertain to an IPsec policy can be issued under an IPsec
profile; you cannot specify the IPsec peer address or the access control list (ACL) to match the packets that
are to be encrypted.
SUMMARY STEPS
1. enable
2. configure terminal
3. crypto identity name
4. exit
DETAILED STEPS
Device> enable
Step 3 crypto identity name Configures the identity of the device with a given list of
distinguished names (DNs) in the certificate of the device.
Example:
Step 4 exit Exits crypto identity configuration mode and enters global
configuration mode.
Example:
Device(config-crypto-identity)# exit
Step 5 crypto ipsec profile name Defines the IPsec parameters that are to be used for IPsec
encryption between "spoke and hub" and "spoke and
Example:
spoke" routers.
Device(config)# crypto ipsec profile example1 This command places the device in crypto map
configuration mode.
Step 6 set transform-set transform-set-name Specifies which transform sets can be used with the IPsec
profile.
Example:
Device(config-crypto-map)# set
security-association lifetime seconds 1800
Step 9 set pfs [group1 | group14 | group15 | group16 | group19 (Optional) Specifies that IPsec should ask for perfect
| group2 | group20 | group24 | group5] forward secrecy (PFS) when requesting new security
associations for this IPsec profile. If this command is not
Example:
specified, the default Diffie-Hellman (DH) group, group1
will be enabled.
Device(config-crypto-map)# set pfs group14
• 1—768-bit DH (No longer recommended.)
• 2—1024-bit DH (No longer recommended)
• 5—1536-bit DH (No longer recommended)
• 14—Specifies the 2048-bit DH group.
• 15—Specifies the 3072-bit DH group.
• 16—Specifies the 4096-bit DH group.
• 19—Specifies the 256-bit elliptic curve DH (ECDH)
group.
• 20—Specifies the 384-bit ECDH group.
• 24—Specifies the 2048-bit DH/DSA group.
Device(config-crypto-map)# end
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ipv6 address {ipv6-address / prefix-length | prefix-name sub-bits / prefix-length
5. ipv6 address ipv6-address / prefix-length link-local
6. ipv6 mtu bytes
DETAILED STEPS
Device> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
• The number argument specifies the number of the
Device(config)# interface tunnel 5 tunnel interfaces that you want to create or configure.
There is no limit on the number of tunnel interfaces
you can create.
Step 4 ipv6 address {ipv6-address / prefix-length | prefix-name Configures an IPv6 address based on an IPv6 general prefix
sub-bits / prefix-length and enables IPv6 processing on an interface.
Example:
Step 5 ipv6 address ipv6-address / prefix-length link-local Configures an IPv6 link-local address for an interface and
enables IPv6 processing on the interface.
Example:
• A unique IPv6 link-local address (across all DMVPN
Device(config-if)# ipv6 address fe80::2001 nodes in a DMVPN network) must be configured.
link-local
Step 6 ipv6 mtu bytes Sets the maximum transmission unit (MTU) size of IPv6
packets sent on an interface.
Example:
Step 7 ipv6 nhrp authentication string Configures the authentication string for an interface using
the NHRP.
Example:
Note The NHRP authentication string must be set to
Device(config-if)# ipv6 nhrp authentication the same value on all hubs and spokes that are
examplexx in the same DMVPN network.
Step 8 ipv6 nhrp map multicast dynamic Allows NHRP to automatically add routers to the multicast
NHRP mappings.
Example:
Note Effective with Cisco IOS XE Denali 16.3 ipv6
Device(config-if)# ipv6 nhrp map multicast dynamic nhrp map multicast dynamic is enabled by
default.
Step 10 tunnel source ip-address | ipv6-address | interface-type Sets the source address for a tunnel interface.
interface-number
Example:
Step 11 tunnel mode {aurp | cayman | dvmrp | eon | gre| gre Sets the encapsulation mode to mGRE for the tunnel
multipoint[ipv6] | gre ipv6 | ipip decapsulate-any] | ipsec interface.
ipv4 | iptalk | ipv6| ipsec ipv6 | mpls | nos | rbscp
Example:
Step 12 Do one of the following: Associates a tunnel interface with an IPsec profile.
• tunnel protection ipsec profile name [shared] • The name argument specifies the name of the IPsec
• tunnel protection psk key profile; this value must match the name specified in
the crypto ipsec profile namecommand.
Example:
or
Router(config-if)# tunnel protection ipsec profile
vpnprof Simplifies the tunnel protection configuration for
Example: pre-shared key (PSK) by creating a default IPsec profile.
Router(config-if)#
tunnel protection psk test1
Step 14 ipv6 nhrp holdtime seconds Changes the number of seconds that NHRP NBMA
addresses are advertised as valid in authoritative NHRP
Example:
responses. The default time is 600 seconds.
Device(config-if)# ipv6 nhrp holdtime 600
Step 15 ipv6 nhrp max-send pkt-count every seconds Changes the maximum frequency at which NHRP packets
can be sent. Number of packets that can be sent in the range
Example:
from 1 to 65535. Default is 100 packets.
Device(config-if)# ipv6 nhrp max-send 10000 every
10
Step 16 ip nhrp registration [timeout seconds | no-unique] Enables the client to not set the unique flag in the NHRP
request and reply packets. The default is no-unique.
Example:
Device(config-if)# end
DETAILED STEPS
Device> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
• The number argument specifies the number of the
Device(config)# interface tunnel 5 tunnel interfaces that you want to create or configure.
There is no limit on the number of tunnel interfaces
you can create.
Step 4 ipv6 address {ipv6-address / prefix-length | prefix-name Configures an IPv6 address based on an IPv6 general prefix
sub-bits / prefix-length and enables IPv6 processing on an interface.
Example:
Example:
Device(config-if)# end
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ipv6 address {ipv6-address / prefix-length | prefix-name sub-bits / prefix-length
5. ipv6 address ipv6-address / prefix-length link-local
6. ipv6 mtu bytes
7. ipv6 nhrp authentication string
8. ipv6 nhrp map ipv6-address nbma-address
9. ipv6 nhrp map multicast ipv4-nbma-address
10. ipv6 nhrp nhs ipv6- nhs-address
11. ipv6 nhrp network-id network-id
12. tunnel source ip-address | ipv6-address | interface-type interface-number
13. Do one of the following:
• tunnel mode {aurp | cayman | dvmrp | eon | gre| gre multipoint [ipv6] | gre ipv6 | ipip
decapsulate-any] | ipsec ipv4 | iptalk | ipv6| ipsec ipv6 | mpls | nos | rbscp
• tunnel destination {host-name | ip-address | ipv6-address}
14. Do one of the following:
• tunnel protection ipsec profile name [shared]
• tunnel protection psk key
15. bandwidth {interzone | total | session} {default | zone zone-name} bandwidth-size
16. ipv6 nhrp holdtime seconds
17. end
DETAILED STEPS
Device> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
Step 4 ipv6 address {ipv6-address / prefix-length | prefix-name Configures an IPv6 address based on an IPv6 general prefix
sub-bits / prefix-length and enables IPv6 processing on an interface.
Example:
Step 5 ipv6 address ipv6-address / prefix-length link-local Configures an IPv6 link-local address for an interface and
enables IPv6 processing on the interface.
Example:
• A unique IPv6 link-local address (across all DMVPN
Device(config-if)# ipv6 address fe80::2001 nodes in a DMVPN network) must be configured.
link-local
Step 6 ipv6 mtu bytes Sets the MTU size of IPv6 packets sent on an interface.
Example:
Step 7 ipv6 nhrp authentication string Configures the authentication string for an interface using
the NHRP.
Example:
Note The NHRP authentication string must be set to
Device(config-if)# ipv6 nhrp authentication the same value on all hubs and spokes that are
examplexx in the same DMVPN network.
Step 8 ipv6 nhrp map ipv6-address nbma-address Statically configures the IPv6-to-NBMA address mapping
of IPv6 destinations connected to an NBMA network.
Example:
Note Only IPv4 NBMA addresses are supported, not
Device(config-if)# ipv6 nhrp map ATM or Ethernet addresses.
2001:DB8:3333:4::5 10.1.1.1
Step 9 ipv6 nhrp map multicast ipv4-nbma-address Maps destination IPv6 addresses to IPv4 NBMA addresses.
Example:
Step 10 ipv6 nhrp nhs ipv6- nhs-address Specifies the address of one or more IPv6 NHRP servers.
Example:
Step 12 tunnel source ip-address | ipv6-address | interface-type Sets the source address for a tunnel interface.
interface-number
Example:
Step 13 Do one of the following: Sets the encapsulation mode to mGRE for the tunnel
interface.
• tunnel mode {aurp | cayman | dvmrp | eon | gre|
gre multipoint [ipv6] | gre ipv6 | ipip • Use the tunnel mode command if data traffic can use
decapsulate-any] | ipsec ipv4 | iptalk | ipv6| ipsec dynamic spoke-to-spoke traffic.
ipv6 | mpls | nos | rbscp
• tunnel destination {host-name | ip-address | or
ipv6-address} Specifies the destination for a tunnel interface.
Example: • Use the tunnel destination command if data traffic
can use hub-and-spoke tunnels.
Device(config-if)# tunnel mode gre multipoint
Example:
Step 14 Do one of the following: Associates a tunnel interface with an IPsec profile.
• tunnel protection ipsec profile name [shared] • The name argument specifies the name of the IPsec
• tunnel protection psk key profile; this value must match the name specified in
the crypto ipsec profile namecommand.
Example:
or
Router(config-if)# tunnel protection ipsec profile
vpnprof Simplifies the tunnel protection configuration for
Example: pre-shared key (PSK) by creating a default IPsec profile.
Router(config-if)#
tunnel protection psk test1
Step 15 bandwidth {interzone | total | session} {default | zone Sets the current bandwidth value for an interface to
zone-name} bandwidth-size higher-level protocols.
Example: • The bandwidth-size argument specifies the bandwidth
in kilobits per second. The default value is 9. The
Device(config-if)# bandwidth total 1200 recommended bandwidth value is 1000 or greater.
• The bandwidth setting for the spoke need not equal
the bandwidth setting for the DMVPN hub. It is
usually easier if all of the spokes use the same or
similar value.
Device(config-if)# end
DETAILED STEPS
Device> enable
Step 2 show dmvpn [ipv4 [vrf vrf-name] | ipv6 [vrf vrf-name]] Displays DMVPN-specific session information.
[debug-condition | [interface tunnel number | peer
{nbma ip-address | network network-mask | tunnel
ip-address}] [static] [detail]]
Example:
Step 4 show ipv6 nhrp multicast [ipv4-address | interface | Displays NHRP multicast mapping information.
ipv6-address]
Example:
Step 5 show ip nhrp multicast [nbma-address | interface] Displays NHRP multicast mapping information.
Example:
Step 6 show ipv6 nhrp summary Displays NHRP mapping summary information.
Example:
Step 7 show ipv6 nhrp traffic [ interfacetunnel number Displays NHRP traffic statistics information.
Example:
Step 9 show ip route Displays the current state of the IPv4 routing table.
Example:
Step 10 show ipv6 route Displays the current contents of the IPv6 routing table.
Example:
Step 11 show nhrp debug-condition Displays the NHRP conditional debugging information.
Example:
DETAILED STEPS
Device> enable
Step 2 clear dmvpn session [interface tunnel number | peer Clears DMVPN sessions.
{ipv4-address | fqdn-string | ipv6-address} | vrf vrf-name]
[static]
Example:
Step 3 clear ipv6 nhrp [ipv6-address | counters Clears all dynamic entries from the NHRP cache.
Example:
Step 4 debug dmvpn {all | error | detail | packet} {all | Displays debug DMVPN session information.
debug-type}
Example:
Step 5 debug nhrp [cache | extension | packet | rate] Enables NHRP debugging.
Example:
Step 6 debug nhrp condition [interface tunnel number | peer Enables NHRP conditional debugging.
{nbma {ipv4-address | fqdn-string | ipv6-address} | tunnel
{ip-address | ipv6-address}} | vrf vrf-name]
Examples
The following sample output is from the show dmvpn command, with the ipv6 and detail keywords, for the
hub:
Interface: Tunnel1
IKE SA: local 192.169.2.9/500 remote 192.169.2.10/500 Active
Crypto Session Status: UP-ACTIVE
fvrf: (none), Phase1_id: 192.169.2.10
IPSEC FLOW: permit 47 host 192.169.2.9 host 192.169.2.10
Active SAs: 2, origin: crypto map
Outbound SPI : 0x BB0ED02, transform : esp-aes esp-sha-hmac
Socket State: Open
Interface: Tunnel1
IKE SA: local 192.169.2.9/500 remote 192.169.2.11/500 Active
Crypto Session Status: UP-ACTIVE
fvrf: (none), Phase1_id: 192.169.2.11
IPSEC FLOW: permit 47 host 192.169.2.9 host 192.169.2.11
The following sample output is from the show dmvpn command, with the ipv6 and detail keywords, for the
spoke:
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel1
IKE SA: local 192.169.2.10/500 remote 192.169.2.9/500 Active
Crypto Session Status: UP-ACTIVE
fvrf: (none), Phase1_id: 192.169.2.9
IPSEC FLOW: permit 47 host 192.169.2.10 host 192.169.2.9
Active SAs: 2, origin: crypto map
Outbound SPI : 0x6F75C431, transform : esp-aes esp-sha-hmac
Socket State: Open
Example: Configuring the NHRP Redirect and Shortcut Features on the Hub
Device(config)# interface tunnel 5
Device(config-if)# ipv6 address 2001:DB8:1:1::72/64
Spoke
2001::8/128
Tunnel1 created 00:00:13, expire 00:02:51
Type: incomplete, Flags: negative
Cache hits: 2
2001::/112 via 2001::6
Tunnel1 created 00:01:16, never expire
Type: static, Flags: used
NBMA address: 192.169.2.9
FE80::1/128 via FE80::1
Tunnel1 created 00:01:15, expire 00:00:43
Type: dynamic, Flags:
NBMA address: 192.169.2.9
Additional References
Related Documents
Standard/RFC Title
Technical Assistance
Description Link
SUMMARY STEPS
1. enable
2. configure terminal
3. ip name-server ip-address
4. exit
DETAILED STEPS
Router> enable
Router(config)# exit
SUMMARY STEPS
1. enable
2. configure terminal
3. ip dns server
4. ip host hostname ip-address
5. exit
DETAILED STEPS
Router> enable
Step 4 ip host hostname ip-address Maps a FQDN (hostname) with the IP address in the DNS
hostname cache for a DNS view.
Example:
Note Configure the ip host command on a DNS server
Router(config)# ip host host1.example.com 192.0.2.2 if you have configured a DNS server on the
spoke and configure the command on the spoke
if you have not configured a DNS server on the
spoke. See the Configuring a DNS Server on a
Spoke task.
Router(config)# exit
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip nhrp nhs nhs-address [nbma {nbma-address | FQDN-string}] [multicast] [priority value] [cluster
number]
5. end
DETAILED STEPS
Router> enable
Router(config-if)# end
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip nhrp nhs dynamic nbma {nbma-address | FQDN-string} [multicast] [priority value] [cluster
value]
5. end
DETAILED STEPS
Router> enable
Note You can use the ipv6 nhrp nhs dynamic nbma
{nbma-address | FQDN-string} [multicast]
[priority value] [cluster value] command for
registering IPv6 address.
Router(config-if)# end
SUMMARY STEPS
1. enable
2. show dmvpn
3. show ip nhrp nhs
4. show running-config interface tunnel tunnel-number
5. show ip nhrp multicast
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Example:
Router# enable
Displays the contents of the current running configuration file or the tunnel interface configuration.
Example:
enable
configure terminal
ip host host1.example.com 192.0.2.2
On a spoke
enable
configure terminal
ip name-server 192.0.2.1
On a DNS Server
enable
configure terminal
ip dns server
ip host host1.example.com 192.0.2.2
enable
configure terminal
interface tunnel 1
ip nhrp nhs 192.0.2.1 nbma 209.165.200.225
enable
configure terminal
interface tunnel 1
ip nhrp nhs 192.0.2.1 nbma examplehub.example1.com
enable
configure terminal
interface tunnel 1
ip nhrp nhs dynamic nbma 192.0.2.1
enable
configure terminal
interface tunnel 1
ip nhrp nhs dynamic nbma examplehub.example1.com
Additional References
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
DMVPN complete command syntax, command mode, Cisco IOS Security Command Reference
defaults, usage guidelines, and examples
Standards
Standard Title
No new or modified standards are supported by this feature and support for existing standards has not --
been modified by this feature.
MIBs
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco
feature, and support for existing MIBs has not software releases, and feature sets, use Cisco MIB Locator
been modified by this feature. found at the following URL:
http://www.cisco.com/go/mibs
RFCs
RFC Title
Technical Assistance
Description Link
DMVPN Configuration The DMVPN Configuration Using FQDN feature enables the NHC
Using FQDN to register with the NHS. It uses the NHRP without using the protocol
address of the NHS.
The following commands were introduced or modified: clear dmvpn
session, debug nhrp condition, ip nhrp nhs,and ipv6 nhrp nhs.
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
• Before you can configure an Next Hop Resolution Protocol (NHRP) group on a spoke and map the NHRP
group to a QoS policy on a hub, the spoke and the hub must already be configured for DMVPN without
the per-tunnel QoS.
DETAILED STEPS
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
Device(config)# interface tunnel 1
Step 4 nhrp group group-name Configures a Next Hop Resolution Protocol (NHRP) group
on the spoke.
Example:
Device(config-if)# nhrp group spoke_group1
DETAILED STEPS
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
Device(config)# interface tunnel 1
Step 4 nhrp attribute group group-name Configures the QoS group identity information on the spoke.
Example:
Device(config-if)# nhrp attribute group spoke1
Step 5 nhrp map group group-name service-policy output Adds the Next Hop Resolution Protocol (NHRP) group to
qos-policy-map-name the quality of service (QoS) policy mapping.
Example:
Device(config-if)# nhrp map group spoke_group1
service-policy output group1_parent
DETAILED STEPS
Device> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
Step 4 nhrp map group group-name service-policy output Adds the Next Hop Resolution Protocol (NHRP) group to
qos-policy-map-name the quality of service (QoS) policy mapping on the hub.
Example:
Device(config-if)# nhrp map group spoke_group1
service-policy output group1_parent
Device(config-if)# end
Note Before configuring the command, you must remove the 'port channel interface' and ‘channel-group’
configuration from physical interface.
1. Enable the command platform qos port-channel-aggregate <port-channel number> before configuring
port channel.
DETAILED STEPS
Step 2 show dmvpn detail Displays detailed Dynamic Multipoint VPN (DMVPN)
information for each session, including the Next Hop Server
Example:
(NHS) and NHS status, crypto session information, and
Device# show dmvpn detail socket details.
• The output includes the Next Hop Resolution Protocol
(NHRP) group received from the spoke and the quality
of service (QoS) policy applied to the spoke tunnel.
Step 3 show nhrp Displays the NHRP cache and the NHRP group received
from the spoke.
Example:
Step 5 show nhrp group-map [group-name] Displays the group-to-policy maps configured on the hub
and also displays the tunnels on which the QoS policy is
Example:
applied.
Device# show nhrp group-map group1-parent
Step 7 show tunnel endpoints Displays information about the source and destination
endpoints for multipoint tunnels and the QoS policy applied
Example:
on the spoke tunnel.
Device# show tunnel endpoints
interface tunnel 1
ip address 209.165.200.225 255.255.255.224
no ip redirects
ip mtu 1400
ip nhrp authentication testing
nhrp group spoke_group1
ip nhrp map 209.165.200.226 203.0.113.1
ip nhrp map multicast 203.0.113.1
ip nhrp network-id 172176366
ip nhrp holdtime 300
ip tcp adjust-mss 1360
ip nhrp nhs 209.165.200.226
tunnel source fastethernet 2/1/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
interface fastethernet 2/1/1
ip address 203.0.113.2 255.255.255.0
interface tunnel 1
ip address 209.165.200.227 255.255.255.224
no ip redirects
ip mtu 1400
ip nhrp authentication testing
nhrp group spoke_group1
ip nhrp map 209.165.200.226 203.0.113.1
ip nhrp map multicast 203.0.113.1
ip nhrp network-id 172176366
ip nhrp holdtime 300
interface tunnel 1
ip address 209.165.200.228 255.255.255.224
no ip redirects
ip mtu 1400
ip nhrp authentication testing
nhrp group spoke_group2
ip nhrp map 209.165.200.226 203.0.113.1
ip nhrp map multicast 203.0.113.1
ip nhrp network-id 172176366
ip nhrp holdtime 300
ip tcp adjust-mss 1360
ip nhrp nhs 209.165.200.226
tunnel source fastethernet 2/1/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
interface fastethernet 2/1/1
ip address 203.0.113.4 255.255.255.0
policy-map policy p1
class class1
priority 70
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip mtu 1436
ip nhrp authentication h1there
ip nhrp attribute group1
ip nhrp map group group1 service-policy output p1
ip nhrp map multicast 172.17.0.2
ip nhrp map 10.0.0.2 172.17.0.2
ip nhrp network-id 253
ip nhrp nhs 10.0.0.2
ip nhrp registration timeout 600
ip nhrp cache non-authoritative
no ip mroute-cache
tunnel source 172.17.0.1
tunnel mode gre multipoint
tunnel key 253
tunnel protection ipsec profile dmvpn-profile
end
policy-map group2
class group2_voice
priority percent 20
class group2_Routing
bandwidth percent 10
policy-map group2_parent
class class-default
shape average 2000000
service-policy group2
interface tunnel 1
ip address 209.165.200.225 255.255.255.224
no ip redirects
ip mtu 1400
ip nhrp authentication testing
ip nhrp map multicast dynamic
ip nhrp map group spoke_group1 service-policy output group1_parent
ip nhrp map group spoke_group2 service-policy output group2_parent
ip nhrp network-id 172176366
ip nhrp holdtime 300
ip nhrp registration unique
tunnel source fastethernet 2/1/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
interface fastethernet 2/1/1
ip address 209.165.200.226 255.255.255.224
The following example shows how to display information about the NHRP groups that are received from the
spokes. You can enter this command on the hub.
The following example shows how to display the details of NHRP group mappings on a hub and the list of
tunnels using each of the NHRP groups defined in the mappings. You can enter this command on the hub.
Interface: tunnel1
NHRP group: spoke_group1
QoS policy: group1_parent
Tunnels using the QoS policy:
Tunnel destination overlay/transport address
198.51.100.220/203.0.113.240
198.51.100.221/203.0.113.241
NHRP group: spoke_group2
QoS policy: group2_parent
Tunnels using the QoS policy:
Tunnel destination overlay/transport address
198.51.100.222/203.0.113.242
The following example shows how to display statistics about a specific QoS policy as it is applied to a tunnel
endpoint. You can enter this command on the hub.
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 6
Queueing
queue limit 150 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 20% (600 kbps)
Class-map: class-default (match-any)
29 packets, 4988 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
queue limit 350 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Interface tunnel1 <--> 203.0.113.254
Service-policy output: group2_parent
Class-map: class-default (match-any)
14 packets, 2408 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 500 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 2000000, bc 8000, be 8000
target shape rate 2000000
Service-policy : group2
queue stats for all priority classes:
queue limit 100 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: group2_voice (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Priority: 20% (400 kbps), burst bytes 10000, b/w exceed drops: 0
Class-map: group2_Routing (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 6
Queueing
queue limit 50 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 10% (200 kbps)
Class-map: class-default (match-any)
14 packets, 2408 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
queue limit 350 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Cisco IOS commands Cisco IOS Master Command List, All Releases
Configuring Basic Cisco Express IP Switching Cisco Express Forwarding Configuration Guide
Forwarding
Technical Assistance
Description Link
Per-Tunnel QoS 15.4(1)T / The Per-Tunnel QoS for DMVPN feature introduces per-tunnel QoS
3.11S support for DMVPN and increases per-tunnel QoS performance for
IPsec tunnel interfaces.
In , this feature was enhanced to provide support for IPv6 addresses.
The following commands were introduced or modified: ip nhrp map,
nhrp group, nhrp map group, show dmvpn, show ip nhrp, show
ip nhrp group-map, show nhrp group-map, show policy-map
multipoint tunnel.
The commands ip nhrp group and ip nhrp map group were
depreciated and hidden in the CLI. They are replaced with protocol
agnostic nhrp group and nhrp map group. The configuration needs
to be manually migrated to the new syntax.
16.6.5, 16.8.1 The commands ip nhrp group and ip nhrp map group are removed
from CLI. Manual migration before or after upgrade is required.
QoS: Spoke to Spoke The QoS: Spoke to Spoke per tunnel QoS for DMVPN feature enables
Per-tunnel QoS for a DMVPN client to establish a direct crypto tunnel with another
DMVPN DMVPN client leveraging the per-tunnel QoS policy, using Next Hop
Resolution Protocol (NHRP) to build spoke-to-spoke connections.
The following commands were introduced or modified: nhrp
attribute group, show dmvpn, show ip nhrp.
Note The command show ip nhrp group is deprecated and is
not in use.
QoS: DMVPN Cisco IOS XE The QoS: DMVPN Per-tunnel QoS over Aggregate GEC feature is
Per-tunnel QoS over Everest 16.4.1 supported.
Aggregate GEC
RestrictionsforDMVPNTunnelHealthMonitoringandRecovery
MIB SNMP
• SNMP SET UNDO is not supported.
• The MIB Persistence feature that enables the MIB-SNMP data to persist across reloads is not supported.
However, a virtual persistence for the MIB notification control object happens, because that information
is also captured via the configuration command line interface (CLI).
• Notifications and syslogs are not virtual routing and forwarding (VRF)-aware.
• The Rate Limit Exceeded notification does not differentiate between the IPv4 or IPv6 protocol type.
The agent implementation of the MIB provides a means to enable and disable specific traps, from either the
network management system or the CLI.
• If the interface state changes to down, the system clears any static routes that use the mGRE interface
as the next hop. The Interface State Control feature provides a failover mechanism for routing when the
mGRE interface is down.
The interface state control feature works on both point-to-point and mGRE interfaces.
SUMMARY STEPS
1. enable
2. configure terminal
3. snmp-server community string rw
4. snmp-server enable traps nhrp nhs
5. snmp-server enable traps nhrp nhc
6. snmp-server enable traps nhrp nhp
7. snmp-server enable traps nhrp quota-exceeded
8. snmp-server host ip-address version snmpversion community-string
9. end
DETAILED STEPS
Device> enable
Step 3 snmp-server community string rw Configures the community access string to permit access
to the SNMP.
Example:
Step 4 snmp-server enable traps nhrp nhs Enables NHRP NHS notifications.
Example:
Step 5 snmp-server enable traps nhrp nhc Enables NHRP NHC notifications.
Example:
Step 6 snmp-server enable traps nhrp nhp Enables NHRP NHP notifications.
Example:
Step 7 snmp-server enable traps nhrp quota-exceeded Enables notifications for when the rate limit set on the
NHRP packets is exceeded on the interface.
Example:
Step 8 snmp-server host ip-address version snmpversion Specifies the recipient of an SNMP notification operation.
community-string
• By default, SNMP notifications are sent as traps.
Example:
• All NHRP traps are sent to the notification receiver
Device(config)# snmp-server host 192.40.3.130
with the IP address 192.40.3.130 using the community
version 2c public string public.
Device(config)# end
Troubleshooting Tips
Use the debug snmp mib nhrp command to troubleshoot SNMP NHRP notifications.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. if-state nhrp
5. end
DETAILED STEPS
Device> enable
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example:
Step 4 if-state nhrp Enables NHRP to control the state of the tunnel interface.
Example:
Device(config-if)# end
interface Tunnel 1
ip address 209.165.200.228 255.255.255.0
no ip redirects
ip nhrp authentication cisco
ip nhrp map 209.165.201.2 209.165.201.10
ip nhrp map 209.165.201.3 209.165.201.11
ip nhrp map multicast 209.165.201.10
ip nhrp map multicast 209.165.201.11
ip nhrp network-id 1
ip nhrp holdtime 90
ip nhrp nhs 209.165.201.3
ip nhrp nhs 209.165.201.2
ip nhrp shortcut
if-state nhrp
tunnel source Ethernet0/0
tunnel mode gre multipoint
!
end
Cisco IOS commands Cisco IOS Master Commands List, All Releases
Dynamic Multipoint VPN information “Dynamic Multipoint VPN (DMVPN)” module in the Cisco IOS
Security Configuration Guide: Secure Connectivity
IKE configuration tasks such as defining “Configuring Internet Key Exchange for IPsec VPNs” module in
an IKE policy the Cisco IOS Security Configuration Guide: Secure Connectivity
IPsec configuration tasks “Configuring Security for VPNs with IPsec” module in the Cisco
IOS Security Configuration Guide: Secure Connectivity
Standard/RFC Title
RFC 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
MIBs
• CISCO-NHRP-EXT-MIB To locate and download MIBs for selected platforms, Cisco IOS releases, and
feature sets, use Cisco MIB Locator found at the following URL:
• NHRP-MIB
http://www.cisco.com/go/mibs
Technical Assistance
Description Link
State Description
PROBE NHS is declared as “DOWN” but it is still actively probed by the spoke to bring it “UP”.
NHS Priorities
NHS priority is a numerical value assigned to a hub that controls the order in which spokes select hubs to
establish a spoke-to-hub tunnel. The priority value ranges from 0 to 255, where 0 is the highest and 255 is the
lowest priority.
You can assign hub priorities in the following ways:
• Unique priorities to all NHS.
• Same priority level to a group of NHS.
• Unspecified priority (value 0) for an NHS, a group of NHSs, or all NHSs.
NHS A1 1 UP UP
NHS B1 1 UP PROBE
NHS C1 1 UP UP
NHS A2 2 DOWN UP
Consider a scenario with three data centers A, B, and C. Each data center consists of two NHSs: NHSs A1
and A2 comprise one data center, NHS B1 and B2 another, and C1 and C3 another.
Although two NHSs are available for each data center, the spoke is connected to only one NHS of each data
center at any point in time. Hence, the maximum connection value is set to 3. That is, three spoke-to-hub
tunnels are established. If any one NHS, for example, NHS B1, becomes inactive, the spoke-to-hub tunnel
associated with NHS B1 goes down. Based on the priority model, NHS A2 has the next priority value and
the next available NHS in the queue, so it forms the spoke-to-hub tunnel and goes up. However, this does not
meet the requirement that a hub from data center B be associated with the spoke to form a tunnel. Hence, no
connection is made to data center B.
This problem can be addressed by placing NHSs into different groups. Each group can be configured with a
group specific maximum connection value. NHSs that are not assigned to any groups belong to the default
group.
NHS Clusters
The table below presents an example of cluster functionality. NHSs corresponding to different data centers
are grouped to form clusters. NHS A1 and NHS A2 with priority 1 and 2, respectively, are grouped as cluster1,
NHS B1 and NHS B2 with prirority 1 and 2, respectively, are grouped as cluster2, and NHS C1 and NHS C2
with prirority 1 and 2, respectively, are grouped as cluster3. NHS 7, NHS 8, and NHS 9 are part of the default
cluster. The maximum cluster value is set to 1 for each cluster so that at least one spoke-to-hub tunnel is
continuously established with all the four clusters.
In scenario 1, NHS A1, NHS B1, and NHS C1 with the highest priority in each cluster are in the UP state. In
scenario 2, the connection between the spoke and NHS A1 breaks, and a connection is established between
the spoke and NHS A2 (hub from the same cluster). NHS A1 with the highest priority attains the PROBE
state. In this way, at any point in time a connection is established to all the three data centers.
NHS A1 1 1 1 UP PROBE
NHS A2 2 DOWN UP
NHS B1 1 2 1 UP UP
NHS C1 1 3 1 UP UP
NHS 8 2 UP UP
NHS 9 0 PROBE UP
In scenario 1, NHS 5 with the lowest priority value is connected to the spoke to form a tunnel. All the other
NHSs having higher priorities than NHS 5 are in the PROBE state.
In scenario 2, when NHS 4 becomes active, the spoke breaks connection with the existing tunnel and establishes
a new connection with NHS 4. In scenario 3 and scenario 4, the spoke breaks the existing connections as soon
as an NHS with a higher priority becomes active and establishes a new tunnel. In scenario 5, as the NHS with
the highest priority (NHS 1) becomes active, the spoke connects to it to form a tunnel and continues with it
until the NHS becomes inactive. Because NHS 1 is having the highest priority, no other NHS is in the PROBE
state.
The table below shows how to avoid the excessive flapping by configuring the fallback time. The maximum
number of connection is one. A fallback time period of 30 seconds is configured on the spoke. In scenario 2,
when an NHS with a higher priority than the NHS associated with the spoke becomes active, the spoke does
not break the existing tunnel connection until the fallback time. Hence, although NHS 4 becomes active, it
does not form a tunnel and attain the UP state. NHS 4 remains active but does not form a tunnel untill the
fallback time elapses. Once the fallback time elapses, the spoke connects to the NHS having the highest priority
among the active NHSs.
This way, the flaps that occur as soon as an NHS of higher priority becomes active are avoided.
NHS NHS Priority Cluster Maximum Number of Connections Scenario Scenario Scenario
1 2 3
NHS NHS Priority Cluster Maximum Number of Connections Scenario Scenario Scenario
1 2 3
Four NHSs belonging to cluster 1 and cluster 3 and two NHSs belonging to the default cluster are available
for setting up spoke-to-hub tunnels. All NHSs have different priorities. The maxmum number of connections
is set to 1 for all the three clusters. That is, at any point in time, at least one NHS from each cluster must be
connected to the spoke to form a tunnel.
In scenario 1, NHS A1 from cluster 1, NHS B1 from cluster 3, and NHS 9 from the default cluster are UP.
They establish a contact with the spoke to form different spoke-to-hub tunnels. In scenario 2, NHS A1 and
NHS B1 with the highest priority in their respective clusters become inactive. Hence a tunnel is established
from the spoke to NHS A2 and NHS B2, which have the next highest priority values. However, the spoke
continues to probe NHS A1 and NHS B1 because they have the highest priority. Hence, NHS A1 and NHS
B1 remain in the PROBE state.
In scenario 3, NHS A2, NHS B2, and NHS 9 become inactive. The spoke checks if the NHSs in PROBE state
have turned active. If yes, then the spoke establishes a connection to the NHS that has turned active. However,
as shown in scenario 3, because none of the NHSs in the PROBE state is active, the spoke connects to NHS
A3 of cluster 1 and NHS B3 of cluster 2. NHS A1 and NHS B1 continue to be in the PROBE state until they
associate themselves with the spoke to form a tunnel and attain the UP state.
no other NHSs in cluster 2 are in the PROBE state. However, because NHS 10 having the lowest priority
value in the default cluster is in the UP state, the spoke continues to probe NHS 9 having the highest priority
in the cluster.
In scenario 4, NHS A1 and NHS B1 continue to be in the UP state and NHS 9 having the highest priority in
the default cluster attains the UP state. Hence, because the spoke is associated with the NHSs having the
highest priority in all the clusters, none of the NHSs are in the PROBE state.
NHS A1 1 1 1 PROBE UP UP UP
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip nhrp nhs cluster cluster-number max-connections value
DETAILED STEPS
Router> enable
Step 4 ip nhrp nhs cluster cluster-number max-connections Configures the desired maximum number of connections.
value
Note Use the ipv6 nhrp nhs cluster cluster-number
Example: max-connections value command for IPv6
configuration.
Router(config-if)# ip nhrp nhs cluster 5
max-connections 100
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip nhrp nhs fallback fallback-time
DETAILED STEPS
Router> enable
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip nhrp nhs nhs-address priority nhs-priority cluster cluster-number
DETAILED STEPS
Router> enable
Step 4 ip nhrp nhs nhs-address priority nhs-priority cluster Configures the desired priority and cluster values.
cluster-number
Note Use the ipv6 nhrp nhs nhs-address priority
Example: nhs-priority cluster cluster-number command
for IPv6 configuration.
SUMMARY STEPS
1. enable
2. show ip nhrp nhs
3. show ip nhrp nhs redundancy
4. show ipv6 nhrp nhs
5. show ipv6 nhrp nhs redundancy
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Example:
Router# enable
No. Interface Cluster Status Max-Con Total-NHS Responding Expecting Waiting Fallback
1 Tunnel0 0 Enable 3 3 3 0 0 0
interface tunnel 0
bandwidth 1000
ip address 10.0.0.1 255.0.0.0
no ip redirects
ip mtu 1400
ip nhrp authentication test
ip nhrp map multicast 172.0.2.1
ip nhrp map 10.0.0.253 172.0.2.1
ip nhrp map multicast 172.0.2.2
ip nhrp map 10.0.0.251 172.0.2.2
ip nhrp map multicast 172.0.2.3
ip nhrp map 10.0.0.252 172.0.2.3
ip nhrp network-id 100000
ip nhrp holdtime 300
ip nhrp nhs 10.0.0.252 priority 2
ip nhrp nhs 10.0.0.251 priority 1
ip nhrp nhs 10.0.0.253 priority 3
ip nhrp nhs cluster 0 max-connections 3
ip nhrp shortcut
delay 100
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel key 100000
tunnel protection ipsec profile vpnprof
!
!
configure terminal
interface tunnel 1
ip nhrp nhs fallback 25
Configure terminal
interface tunnel 0
ip nhrp nhs 10.0.0.251 priority 1 cluster 1
ip nhrp map 10.0.0.251 192.0.2.4
ip nhrp map multicast 192.0.2.4
end
configure terminal
interface tunnel 0
ip nhrp nhs 10.0.0.252 priority 2 cluster 2
ip nhrp map 10.0.0.252 192.0.2.5
ip nhrp map multicast 192.0.2.5
end
configure terminal
interface tunnel 0
ip nhrp nhs 10.0.0.253 priority 3 cluster 3
ip nhrp map 10.0.0.253 192.0.2.6
ip nhrp map multicast 192.0.2.6
end
configure terminal
interface tunnel 0
ip nhrp nhs cluster 1 max 1
ip nhrp nhs cluster 2 max 1
ip nhrp nhs cluster 3 max 1
end
Additional References
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
DMVPN complete command syntax, command mode, Cisco IOS Security Command Reference
defaults, usage guidelines, and examples
Standards
Standard Title
No new or modified standards are supported by this feature and support for existing standards has not --
been modified by this feature.
MIBs
No new or modified standards are supported by To locate and download MIBs for selected platforms, Cisco
this feature and support for existing standards has software releases, and feature sets, use Cisco MIB Locator
not been modified by this feature. found at the following URL:
http://www.cisco.com/go/mibs
RFCs
RFC Title
Technical Assistance
Description Link
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.
Table 13: Feature Information for DMVPN-Tunnel Health Monitoring and Recovery Backup NHS
NHRP Event Trace General Next Hop Resolution Protocol (NHRP) events, such as NHRP protocol,
NHRP messages, changes in NHRP data structure, NHRP NBMA or protocol
address change, and NHRP traps.
SUMMARY STEPS
1. enable
2. monitor event-trace dmvpn {nhrp {error | event | exception} | tunnel} {clear | continuous [cancel]
| disable | enable | one-shot} | tunnel}
DETAILED STEPS
Router> enable
Step 2 monitor event-trace dmvpn {nhrp {error | event | Monitors and controls DMVPM traces.
exception} | tunnel} {clear | continuous [cancel] | disable
| enable | one-shot} | tunnel}
SUMMARY STEPS
1. enable
2. configure terminal
3. monitor event-trace dmvpn {dump-file url | {nhrp {error | event | exception} | tunnel} {disable |
dump-file url | enable | size | stacktrace value}}
4. exit
DETAILED STEPS
Router> enable
Step 3 monitor event-trace dmvpn {dump-file url | {nhrp Monitors and controls DMVPM traces.
{error | event | exception} | tunnel} {disable | dump-file
url | enable | size | stacktrace value}}
Example:
Router(config)# exit
Router> enable
Router# monitor event-trace dmvpn nhrp error enable
Router> enable
Router# configure terminal
Router(config)# monitor event-trace dmvpn nhrp error enable
Additional References
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
Standards
Standard Title
None --
MIBs
None --
RFCs
RFC Title
None --
Technical Assistance
Description Link
DMVPN Event The DMVPN Event Tracing feature provides a trace facility for
Tracing troubleshooting Cisco IOS DMVPN. This feature enables you to monitor
DMVPN events, errors, and exceptions. During runtime, the event trace
mechanism logs trace information in a buffer space. A display mechanism
extracts and decodes the debug data.
The following commands were introduced or modified: monitor
event-trace dmvpn, show monitor event-trace dmvpn.
Note Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
The Cisco implementation supports all of the tables except the NHRP Purge Request Table.
RFC-2677
RFC-2677 - Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP), describes
managed objects that can be used to remotely monitor NHRP using SNMP and provide management information
on the performance of NHRP.
SUMMARY STEPS
1. enable
2. show snmp mib nhrp status
DETAILED STEPS
Router> enable
Step 2 show snmp mib nhrp status Displays the status of the NHRP MIB.
Example:
The “Enabled” status of “NHRP-SNMP Agent Feature:” indicates that the NHRP MIB is enabled. If the
NHRP MIB was disabled, it would display “Disabled”. “ListEnqueue Count” and “Node Malloc Counts”
counts are internal counts. “ListEnqueue Count” indicates how many nodes are queued for freeing. “Node
Malloc Counts” displays how many nodes are allocated.
ip vrf V3red
rd 198102
! Name of the SNMP VPN context
context V3red_context
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.0
ip mtu 1400
ip nhrp authentication donttell
ip nhrp map 10.0.0.1 172.17.0.1
ip nhrp map multicast 172.17.0.1
ip nhrp network-id 99
ip nhrp holdtime 300
ip nhrp nhs 10.0.0.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Ethernet0
tunnel mode gre multipoint
tunnel key 100000
tunnel protection ipsec profile vpnprof
!
interface Ethernet0
ip address dhcp hostname Spoke1
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
router eigrp 1
network 10.0.0.0 0.0.0.255
network 192.168.1.0 0.0.0.255
Additional References
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
Description of SNMP, SNMP MIBs, and how to The chapter “Configuring SNMP Support ” in the Cisco
configure SNMP on Cisco devices IOS Network Management Configuration Guide
Standards
Standard Title
None --
MIBs
CISCO-NHRP-MIB To locate and download MIBs for selected platforms, Cisco software releases, and
feature sets, use Cisco MIB Locator found at the following URL:
http://www.cisco.com/go/mibs
RFCs
RFC Title
RFC 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
Technical Assistance
Description Link
NHRP MIB 12.4(20)T The Cisco NHRP MIB feature introduces support for the NHRP MIB, which
helps to manage and monitor Next Hop Resolution Protocol (NHRP) via Simple
Network Management Protocol (SNMP). Statistics can be collected and monitored
via standards-based SNMP techniques (get operations) to query objects defined
in the NHRP MIB.
The following commands were introduced or modified: debug snmp mib nhrp,
show snmp mib nhrp status.
• Hub or spoke can be reached through pre-NAT addresses --It is possible for two or more spokes to
be behind the same NAT device, which can be reached through a pre-NAT IP address. Only the post-NAT
IP address is relied on even if it means that a tunnel may take a less desirable path. If both spokes use
NAT through the same device, then a packet may not travel inside-out or outside-in as expected by the
NAT device and translations may not occur correctly.
• Interoperability between NAT and non-NAT capable devices --In networks that are deployed with
DMVPN, it is important that a device with NHRP NAT functionality operate together with non-NAT
supported devices. A capability bit in the NHRP packet header indicates to any receiver whether a sending
device understands a NAT extension.
• Same NAT translation --A spoke’s post-NAT IP address must be the same when the spoke is
communicating with its hubs and when it is communicating with other spokes. For example, a spoke
must have the same post-NAT IP address no matter where it is sending tunnel packets within the DMVPN
network.
• If one spoke is behind one NAT device and another different spoke is behind another NAT device, and
Peer Address Translation (PAT) is the type of NAT used on both NAT devices, then a session initiated
between the two spokes cannot be established.
Figure 7: Implementation of DMVPN Spoke-to-spoke Tunneling Limited to Spokes Not Behind a NAT Device
NHRP Registration
When an NHRP registration is received, the hub checks the source IP address on the encapsulating GRE/IP
header of the NHRP packet with the source NBMA IP address, which is contained in the NHRP registration
packet. If these IP addresses are different, then NHRP knows that NAT is changing the outer IP header source
address. The hub preserves both the pre- and post-NAT address of the registered spoke.
Note If encryption is used, then IPsec transport mode must be used to enable NHRP.
The following show ip nhrp command output example shows the source IP address of the NHRP packet and
tunnel information for Spoke B in the figure above:
Note The NBMA (post-NAT) address for Spoke B is 172.18.2.1 (the claimed NBMA (pre-NAT) source address
is 172.16.2.1).
NHRP Resolution
The following describes the NHRP resolution process between Spoke A and Spoke B shown in the figure
above, where Spoke B is behind a NAT device with pre-NAT address of 172.16.2.1 and a post-NAT address
of 172.18.2.1:
• The NHRP table entry for Spoke B on the hub contains both the post-NAT and pre-NAT addresses.
When the hub receives an NHRP resolution request for the VPN address (tunnel address) of Spoke B, it
answers with its own NBMA address instead of Spoke B’s NBMA address.
• When the hub receives an NHRP resolution request sourced from Spoke B for any other spoke, the hub
also answers with its own NBMA address. This ensures that any attempt to build a spoke-to-spoke tunnel
with Spoke B results in the data packets being sent through the hub rather than through a spoke-to-spoke
tunnel.
For example:
• • Data traffic from source IP address 192.168.1.1 (behind Spoke A) to destination IP address
192.168.2.1 (behind Spoke B) triggers Spoke A to send a resolution request for Spoke B (10.0.0.12)
to the next hop router (hub).
• The hub receives the resolution request and finds a mapping entry for Spoke B (10.0.0.12). Because
Spoke B is behind a NAT device, it acts as a proxy and replies with its own NBMA address
(172.17.0.1).
• The hub also receives a resolution request from Spoke B for Spoke A (10.0.0.11). Because Spoke
B is behind a NAT device, it acts as a proxy and replies with its own NBMA address (172.17.0.1).
This restricts any spoke-to-spoke traffic to or from Spoke B to travel through the hub router, which
is done rather than having a tunnel between the spokes.
Note The spoke-to-spoke tunnel may fail to come up, but it is detected and the data traffic flows through the hub,
rather than being lost (black-holed).
the diagram below shows how the NHRP spoke-to-spoke tunnel works with NAT.
server) along the path. However, if the hub is forwarding the request to a non-NAT extension capable
node, it rewrites the source-NBMA inside the packet to be the post-NAT IP address for the requesting
spoke rather than its pre-NAT IP address.
3. The receiver (spoke) uses a NAT NHRP extension record (NAT capable) or the source NBMA address
(non-NAT capable information) to build the tunnel. This spoke’s reply includes its own NAT extension
if it is behind a NAT device.
Note Hubs do not answer NHRP resolution requests on behalf of spokes. Hubs always forward NHRP resolution
requests to the end spoke that has the requested tunnel IP address or services the requested data from the host
IP address.
The following describes the NHRP resolution process between Spoke A and Spoke B shown in the figure
above, where Spoke B is behind a NAT device with pre-NAT address 172.16.2.1 and post-NAT address of
172.18.2.1:
• Data traffic to the 192.168.2.0/24 network from hosts behind Spoke A triggers an NHRP resolution
request for Spoke B’s tunnel IP address (10.0.0.12) to be sent through the hub. The hub receives a
resolution request and forwards it to Spoke B. Spoke B creates a dynamic spoke-to-spoke tunnel using
the source NBMA IP address for Spoke A from the NHRP resolution request and sends an NHRP
resolution reply directly to Spoke A. It includes its post-NAT address in the NAT NHRP-extension
header.
• Alternatively, traffic to the192.168.1.0/24 network from hosts behind the NAT device on Spoke B triggers
an NHRP resolution request for Spoke A’s tunnel IP address (10.0.0.11). Spoke B adds its own post-NAT
IP address in the NHRP NAT-extension in the resolution request. The hub receives a resolution request
and forwards it to Spoke A. Spoke A parses the NHRP NAT-extension and builds a tunnel using Spoke
B’s post-NAT address and replies directly to Spoke B.
Additional References
Related Documents
NHRP commands: complete command syntax, command Cisco IOS IP Addressing Services Command
mode, command history, defaults, usage guidelines, and Reference
examples
Standards
Standard Title
No new or modified standards are supported by this feature, and support for existing standards has not --
been modified by this feature.
MIBs
• No new or modified MIBs are supported To locate and download MIBs for selected platforms, Cisco
by this feature, and support for existing IOS software releases, and feature sets, use Cisco MIB
MIBs has not been modified by this feature. Locator found at the following URL:
http://www.cisco.com/go/mibs
RFCs
RFC Title
Technical Assistance
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/techsupport
documentation and tools for troubleshooting and resolving technical issues
with Cisco products and technologies.
To receive security and technical information about your products, you
can subscribe to various services, such as the Product Alert Tool (accessed
from Field Notices), the Cisco Technical Services Newsletter, and Really
Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com
user ID and password.
Table 17: Feature Information for DMVPN: Dynamic Tunnels Between Spokes Behind a NAT Device
DMVPN: Dynamic Tunnels 12.4(15)T The DMVPN: Dynamic Tunnels Between Spokes Behind a
Between Spokes Behind a NAT NAT Device feature allows NHRP spoke-to-spoke tunnels
Device to be built in DMVPN networks, even if one or more spokes
is behind a Network Address Translation (NAT) device.
• When using the Dual-hub single-DMVPN topology, Cisco DHCP server automatically changes the
unicast flag to broadcast mode. To prevent this automatic change, run the following command on the
Cisco DHCP server:
no ip dhcp auto-broadcast
• When DHCP is configured on an interface, the interface may take more time than usual to shutdown.
Note The NHRP registration sent by the spoke is suppressed until DHCP obtains an address for the GRE tunnel
interface. Hence allows reliable exchange of standard DHCP messages.
DMVPN Topologies
Dual-Hub Single-DMVPN Topology
In a dual-hub single-DMVPN topology, both the hubs must be connected to the same DHCP server that has
the high availability (HA) support to maintain DMVPN redundancy. If the hubs are connected to different
DHCP servers, they must be configured with mutually exclusive IP address pools for address allocation.
By default, the DHCP replies are broadcast from the DMVPN hub to the spoke. Therefore a bandwidth burst
occurs. The DHCP Tunnels Support feature does not function if the DHCP messages are broadcast. Hence,
you must configure the DHCP relay agent to unicast the DHCP messages for the DHCP to be functional in a
DMVPN environment.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip dhcp support tunnel unicast
4. exit
DETAILED STEPS
Router> enable
Step 3 ip dhcp support tunnel unicast Configures a spoke-to-hub tunnel to unicast DHCP replies
over the DMVPN network.
Example:
Router(config)# exit
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
DETAILED STEPS
Router> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
Step 4 ip dhcp client broadcast-flag clear Configures the DHCP client to clear the broadcast flag.
Example:
Router(config-if)# exit
Example Configuring a DMVPN Spoke to Clear the Broadcast Flag and Set the
IP Address to DHCP
The following example shows how to configure a DMVPN spoke to clear the broadcast flag and set the IP
address to DHCP:
Additional References
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
Cisco IOS IP addressing configuration tasks Cisco IOS IP Addressing Configuration Guide
Cisco IOS IP addressing services commands Cisco IOS IP Addressing Services Command Reference
Standards
Standard Title
-- No new or modified standards are supported by this feature, and support for existing standards
has not been modified by this feature.
MIBs
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco
feature, and support for existing MIBs has not software releases, and feature sets, use Cisco MIB Locator
been modified by this feature. found at the following URL:
http://www.cisco.com/go/mibs
RFCs
RFC Title
Technical Assistance
Description Link
DHCP--Tunnels Cisco IOS XE The DHCP--Tunnels Support feature provides the capability
Support Release 16.12 to configure the node (or spoke) of the GRE tunnel interfaces
dynamically using DHCP.
The following commands were introduced or modified: ip
address dhcp, ip dhcp client broadcast-flag, ip dhcp
support tunnel unicast.
Note Security threats and the cryptographic technologies to help protect against such threats are constantly changing.
For more information about the latest Cisco cryptographic recommendations, see the Next Generation
Encryption (NGE) white paper.
• Different IPsec profile names must be used for shared and unshared tunnels. For example, if “tunnel 1”
is configured with the tunnel source loopback1 command, and “tunnel 2” and “tunnel 3” are shared
using the tunnel source loopback2 command, use separate IPsec profiles, for example, define
IPsec_profile_1 for tunnel 1 and IPsec_profile_2 for tunnels 2 and 3.
• Different IPsec profile must be used for each set of shared tunnels. For example, if tunnels 1 through 5
use tunnel source loopback1 and tunnels 6 through 10 use tunnel source loopback2, use IPsec_profile_1
for tunnels 1 through 5 and ipsec_profile_2 for tunnels 6 through 10.
• There are few exceptions to the above rules:
• Several mGRE tunnels sharing the same tunnel source interface can be configured without the
shared keyword in the tunnel protection command if they use different IPsec profiles with different
IPsec transform sets. Different IPsec transform sets disambiguate tunnel setup in this case. Each
mGRE tunnel interface must still be configured with a different tunnel key. This applies to several
mGRE tunnels and point-to-point GRE tunnels sharing the same tunnel source. This method cannot
be used if several point-to-point GRE tunnels share the same tunnel source interface and the same
tunnel destination address.
• Sometimes, it may be desirable not to share an IPsec session between two or more tunnel interfaces
using the same tunnel source. For example, in a service provider environment, each DMVPN cloud
can represent a different customer. It is desirable to lock the connections from a customer to a tunnel
interface and not share or allow IPsec sessions from other customers. In such scenarios, Internet
Security Association and Key Management Protocol (ISAKMP) profiles can be used to identify
and bind customer connections to an ISAKMP profile and through that to an IPsec profile. This
ISAKMP profile limits the IPsec profile to accept only those connections that match the corresponding
ISAKMP profile. Separate ISAKMP and IPsec profiles can be obtained for each DMVPN cloud
(tunnel interface) without sharing the same IPsec Security Association Database (SADB).
Note An exception is multiple ISAKMP sessions between same peers, which will not
work. For example, in a dual hub dual DMVPN setup, the security associations
(SAs) for the second tunnel interface between the hubs will not come up without
sharing the SADB. Hence, the hubs cannot register to themselves on both mGRE
tunnel interfaces without using the shared keyword in the IPsec profile.
• Shared tunnel protection is not supported for a IPsec virtual tunnel interface (VTI). If there are VTI
tunnels sharing the same tunnel source with other GRE or mGRE tunnels that have shared tunnel
protection, these VTI tunnels should be configured with different IPsec profiles without using the shared
keyword.
Note The tunnel source, tunnel destination, and tunnel key (triplet) must be unique for all tunnel interfaces on a
device. For a multipoint GRE interfaces where the tunnel destination is not configured, the pair (tunnel source
and tunnel key) must be unique. Incoming GRE packets are also matched to point-to-point GRE tunnels first;
if there is no match, they are matched to mGRE tunnels.
DETAILED STEPS
Device> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
• The number argument specifies the number of the
Device(config)# interface tunnel 5 tunnel interface that you want to create or configure.
There is no limit on the number of tunnel interfaces
that you can create.
Step 4 tunnel source {ip-address | interface-type number} Sets the source IP address or source interface type and
number for a tunnel interface.
Example:
• When using the tunnel protection IPsec profile
Device(config-if)# tunnel source Ethernet 0 shared command, the tunnel source must specify an
interface, not an IP address.
Step 5 tunnel protection IPsec profile name shared Associates a tunnel interface with an IPsec profile.
Example: • The name argument specifies the name of the IPsec
profile; this value must match the name specified in
the crypto IPsec profile name command.
Device(config-if)# end
Hub 1 Configuration
The Hub 1 and Hub 2 configurations are similar, except that each hub belongs to a different DMVPN.
Hub 1 has the following DMVPN configuration:
• IP subnet: 10.0.0.0/24
• Next Hop Resolution Protocol (NHRP) network ID: 100000
• Tunnel key: 100000
• Dynamic routing protocol: Enhanced Interior Gateway Routing Protocol (EIGRP)
!
hostname Hub1
!
crypto isakmp policy 1
encryption aes
authentication pre-share
group 14
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0
!
crypto IPsec transform-set trans2 esp-aes esp-sha-hmac
mode transport
!
crypto IPsec profile vpnprof
set transform-set trans2
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
no ip next-hop-self eigrp 1
Hub 2 Configuration
Hub 2 has the following DMVPN configuration:
• IP subnet: 10.0.1.0/24
• NHRP network ID: 100001
• Tunnel key: 100001
• Dynamic routing protocol: EIGRP
!
hostname Hub2
!
crypto isakmp policy 1
encryption aes
authentication pre-share
group 14
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0
!
crypto IPsec transform-set trans2 esp-aes esp-sha-hmac
mode transport
!
crypto IPsec profile vpnprof
set transform-set trans2
!
interface Tunnel0
bandwidth 1000
ip address 10.0.1.1 255.255.255.0
ip mtu 1400
no ip next-hop-self eigrp 1
ip nhrp authentication test
ip nhrp map multicast dynamic
ip nhrp network-id 100001
ip nhrp holdtime 600
no ip split-horizon eigrp 1
ip tcp adjust-mss 1360
delay 1000
tunnel source Ethernet 0
tunnel mode gre multipoint
tunnel key 100001
tunnel protection IPsec profile vpnprof
!
interface Ethernet0
ip address 172.16.0.5 255.255.255.252
!
interface Ethernet1
ip address 192.168.0.2 255.255.255.0
!
router eigrp 1
network 10.0.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
no auto-summary
!
Spoke 1 Configuration
Spoke 1 has the following DMVPN configuration:
!
hostname Spoke1
!
crypto isakmp policy 1
encryption aes
authentication pre-share
group 14
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0
!
crypto IPsec transform-set trans2 esp-aes esp-sha-hmac
mode transport
!
crypto IPsec profile vpnprof
set transform-set trans2
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.11 255.255.255.0
ip mtu 1400
ip nhrp authentication test
ip nhrp map 10.0.0.1 172.16.0.1
ip nhrp map multicast 172.16.0.1
ip nhrp network-id 100000
ip nhrp holdtime 300
ip nhrp nhs 10.0.0.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Ethernet 0
tunnel mode gre multipoint
tunnel key 100000
tunnel protection IPsec profile vpnprof shared
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.11 255.255.255.0
ip mtu 1400
ip nhrp authentication test
ip nhrp map 10.0.1.1 172.16.0.5
ip nhrp map multicast 172.16.0.5
ip nhrp network-id 100001
ip nhrp holdtime 300
Spoke 2 Configuration
Spoke 2 has the following DMVPN configuration:
!
hostname Spoke2
!
crypto isakmp policy 1
encryption aes
authentication pre-share
group 14
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0
!
crypto IPsec transform-set trans2 esp-aes esp-sha-hmac
mode transport
!
crypto IPsec profile vpnprof
set transform-set trans2
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.12 255.255.255.0
ip mtu 1400
ip nhrp authentication test
ip nhrp map 10.0.0.1 172.16.0.1
ip nhrp map multicast 172.16.0.1
ip nhrp network-id 100000
ip nhrp holdtime 300
ip nhrp nhs 10.0.0.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Ethernet 0
tunnel mode gre multipoint
tunnel key 100000
tunnel protection IPsec profile vpnprof shared
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.12 255.255.255.0
ip mtu 1400
ip nhrp authentication test
ip nhrp map 10.0.1.1 172.16.0.5
Spoke 1 Output
Spoke 1 displays the following output for its DMVPN configuration:
Note There are only three crypto connections because the two NHRP sessions (10.0.0.12, Tunnel0) and (10.0.1.12,
Tunnel1) are only one IPsec session, because they both have the same nonbroadcast multiaccess (NBMA)
IPsec peer address.
/172.17.0.5
Local Ident (addr/mask/port/prot): (172.16.0.11/255.255.255.255/0/47)
Remote Ident (addr/mask/port/prot): (172.16.0.5/255.255.255.255/0/47)
Flags: shared
IPsec Profile: "vpnprof"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Shd Peers (local/remote): 172.16.0.11
/172.17.0.1
Local Ident (addr/mask/port/prot): (172.17.0.11/255.255.255.255/0/47)
Remote Ident (addr/mask/port/prot): (172.17.0.1/255.255.255.255/0/47)
Flags: shared
IPsec Profile: "vpnprof"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Crypto Sockets in Listen state:
Client: "TUNNEL SEC" Profile: "vpnprof" Map-name: "vpnprof-head-1"
Note All three crypto sessions are shown under each tunnel interface (three entries, twice) in the show crypto IPsec
sa command output, because both interfaces are mapped to the same IPsec SADB, which has three entries.
This duplication of output is expected in this case.
interface: Tunnel0
Crypto map tag: vpnprof-head-1, local addr 172.16.0.11
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.11/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.0.1/255.255.255.255/47/0)
current_peer 172.16.0.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 134, #pkts encrypt: 134, #pkts digest: 134
#pkts decaps: 118, #pkts decrypt: 118, #pkts verify: 118
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 22, #recv errors 0
local crypto endpt.: 172.16.0.11, remote crypto endpt.: 172.16.0.1
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0xA75421B1(2807308721)
inbound esp sas:
spi: 0x96185188(2518176136)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 3, flow_id: SW:3, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4569747/3242)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xA75421B1(2807308721)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 4, flow_id: SW:4, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4569745/3242)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.11/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.0.5/255.255.255.255/47/0)
current_peer 172.16.0.5 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 244, #pkts encrypt: 244, #pkts digest: 244
#pkts decaps: 253, #pkts decrypt: 253, #pkts verify: 253
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 172.16.0.11, remote crypto endpt.: 172.16.0.5
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x3C50B3AB(1011921835)
inbound esp sas:
spi: 0x3EBE84EF(1052673263)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 1, flow_id: SW:1, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4549326/2779)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x3C50B3AB(1011921835)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2, flow_id: SW:2, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4549327/2779)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.11/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.0.12/255.255.255.255/47/0)
current_peer 172.16.0.12 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.16.0.11, remote crypto endpt.: 172.16.0.12
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x38C04B36(952126262)
inbound esp sas:
spi: 0xA2EC557(170837335)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 5, flow_id: SW:5, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4515510/3395)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x38C04B36(952126262)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 6, flow_id: SW:6, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4515511/3395)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel1
Crypto map tag: vpnprof-head-1, local addr 172.16.0.11
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.11/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.0.1/255.255.255.255/47/0)
current_peer 172.16.0.1 port 500
PERMIT, flags={origin_is_acl,}
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.11/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.0.12/255.255.255.255/47/0)
current_peer 172.16.0.12 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.16.0.11, remote crypto endpt.: 172.16.0.12
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x38C04B36(952126262)
inbound esp sas:
spi: 0xA2EC557(170837335)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 5, flow_id: SW:5, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4515510/3395)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x38C04B36(952126262)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 6, flow_id: SW:6, crypto map: vpnprof-head-1
sa timing: remaining key lifetime (k/sec): (4515511/3395)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Spoke1#
Cisco IOS commands Cisco IOS Master Command List, All Releases
Implementing DMVPN with IPsec VPN Dynamic Multipoint IPsec VPNs (Using Multipoint GRE/NHRP
solution to Scale IPsec VPNs)
Configuring basic IPsec VPNs Configuring Security for VPNs with IPsec
Standard/RFC Title
Technical Assistance
Description Link
Table 19: Feature Information for Sharing IPsec with Tunnel Protection
Sharing IPsec 12.4(15)T The Sharing IPsec with Tunnel Protection feature allows sharing an IPsec
with Tunnel security association database (SADB) between two or more generic routing
Protection encapsulation (GRE) tunnel interfaces when tunnel protection is used. Shared
tunnel interfaces have a single underlying cryptographic SADB, cryptographic
map, and IPsec profile in the Dynamic Multipoint Virtual Private Network
(DMVPN) configuration.
The Sharing IPsec with Tunnel Protection feature is required in some DMVPN
configurations. If IPsec SA sessions are not shared within the same IPsec
SADB, an IPsec SA may be associated with the wrong IPsec SADB and
therefore with the wrong tunnel interface, thereby causing duplicate IPsec
security associations (SAs) and tunnel interfaces to flap, which in turn results
in network connectivity problems.
The following command was introduced or modified: tunnel protection IPsec
profile.
Glossary
GRE—generic routing encapsulation. Tunnels that provide a specific pathway across the shared WAN and
encapsulate traffic with new packet headers to ensure delivery to specific destinations. The network is private
because traffic can enter a tunnel only at an endpoint. Tunnels do not provide true confidentiality (encryption
does) but can carry encrypted traffic.
GRE tunneling can also be used to encapsulate non-IP traffic into IP and send it over the Internet or IP network.
The Internet Package Exchange (IPX) and AppleTalk protocols are examples of non-IP traffic.
IKE—Internet Key Exchange. A hybrid protocol that implements Oakley key exchange and Skeme key
exchange inside the ISAKMP framework. Although IKE can be used with other protocols, its initial
implementation is with IPsec. IKE provides authentication of the IPsec peers, negotiates IPsec keys, and
negotiates IPsec security associations.
IPsec—IP security. A framework of open standards developed by the Internet Engineering Task Force (IETF).
IPsec provides security for transmission of sensitive information over unprotected networks such as the
Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec
peers, such as Cisco routers.
ISAKMP—Internet Security Association Key Management Protocol. A protocol framework that defines
payload formats, the mechanics of implementing a key exchange protocol, and the negotiation of a security
association.
NHRP—Next Hop Resolution Protocol. A protocol that routers, access servers, and hosts can use to discover
the addresses of other routers and hosts connected to an NBMA network.
The Cisco implementation of NHRP supports the IETF draft version 11 of NBMA NHRP.
The Cisco implementation of NHRP supports IP Version 4, Internet Packet Exchange (IPX) network layers,
and, at the link layer, ATM, Ethernet, SMDS, and multipoint tunnel networks. Although NHRP is available
on Ethernet, NHRP need not be implemented over Ethernet media because Ethernet is capable of broadcasting.
Ethernet support is unnecessary (and not provided) for IPX.
SA—security association. Describes how two or more entities use security services to communicate securely.
For example, an IPsec SA defines the encryption algorithm (if used), the authentication algorithm, and the
shared session key to be used during the IPsec connection.
Both IPsec and IKE require and use SAs to identify the parameters of their connections. IKE can negotiate
and establish its own SA. The IPsec SA is established either by IKE or by manual user configuration.
transform—List of operations performed on a data flow to provide data authentication, data confidentiality,
and data compression. An example of a transform is the ESP with the 256-bit AES encryption algorithm and
the AH protocol with the HMAC-SHA authentication algorithm.
tunnel—In the context of this module, a secure communication path between two peers, such as two routers.
It does not refer to using IPsec in tunnel mode.
VPN—Virtual Private Network. A framework that consists of multiple peers transmitting private data securely
to one another over an otherwise public infrastructure. In this framework, inbound and outbound network
traffic is protected using protocols that tunnel and encrypt all data. This framework permits networks to extend
beyond their local topology, while remote users are provided with the appearance and functionality of a direct
network connection.
or centralized information. It also reduces the administrative overhead by monitoring available resources and
selecting the best options.
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:
1. An NHRP event registers with the NHRP-ED.
2. The application creates an event definition.
3. A TCL script subscribes for NHRP event receipt asking that the script’s callback routine be invoked when
the event is published.
4. The NHRP ED detects an event and contacts the EEM at the remote spoke.
5. The EEM schedules the event processing calling the application’s callback handler routine.
6. The TCL script returns the callback routine.
DETAILED STEPS
Router> enable
Step 3 interface type number Configures an interface and enters interface configuration
mode.
Example:
Step 4 tunnel mode gre multipoint Enables a GRE tunnel to be used in multipoint NBMA
mode.
Example:
Step 7 ip nhrp attribute set isp-name value Sets the local policy attributes that are carried in NHRP
resolution requests.
Example:
Step 8 nhrp event timer Publishes an NHRP event with the attributes to EEM.
Example:
Router(config-if)# end
Step 10 show ipv6 nhrp attribute Displays the IPv6 NHRP attributes configured on the
spoke.
Example:
Step 11 show ip nhrp attribute Displays the IP NHRP attributes configured on the spoke.
Example:
Router# exit
What to do next
Additional References
Related Documents
RFCs
RFC Title
Technical Assistance
Description Link
Note 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.
DMVPN: NHRP 15.2(2)T The DMVPN: NHRP Event Publisher feature allows you to publish NHRP
Event Publisher 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.
The TrustSec DMVPN Inline Tagging Support feature does not support the following:
• Cisco AnyConnect
• Cisco VPNClient
• DMVPN with IKEv1
• EasyVPN
• FlexVPN
• GetVPN
• IKEv1 IPsec methods
• SSLVPN
crypto ikev2 cts sgt and cts sgt inline commands on tunnel are two different features. Do not configure these
two features together as it causes the packets getting tagged twice.
cts sgt inline command does not rely on crypto or IKEv2. It can be configured statically or by NHRP. cts sgt
inline command works with DMVPN IPSEC tunnel and also in transport mode.
The TrustSec DMVPN Inline Tagging Support feature via the cts sgt inline command is supported on all
combinations of DMVPN (IKEv1, IKEv2, non-crypto, crypto accelerators such as ISM-VPN, point-to-point,
multipoint) except when running MPLS (as an MPLS cloud extension or as MPLS L3VPN) over DMVPN.
to classify packets as they enter the network. CTS maintains a classification of each packet by tagging packets
on ingress to the CTS network so that they can be properly identified for applying security and other policy
criteria along the data path. The packets or frames are tagged using the Security Group Tag (SGT), which
allows network intermediaries such as switches and firewalls, to enforce an access control policy based on
the classification.
The IPsec Inline Tagging for TrustSec feature is used to propagate the SGT to other network devices.
Note If this feature is not supported, you can use the SGT Exchange Protocol over TCP (SXP) feature.
For more information on CTS and SXP, see the Cisco TrustSec Switch Configuration Guide .
Yes Yes The VID is exchanged between the initiator and the responder, and
IPsec SA is enabled with the SGT inline tagging capability.
Yes No The initiator proposes the VID, but the responder ignores the VID.
IPsec SA is not enabled with the SGT inline tagging capability.
No Yes The initiator does not propose the VID, and the responder does not
send the VID payload. IPsec SA is not enabled with the SGT inline
tagging capability.
No No The initiator does not propose the VID, and responder also does not
send the VID payload. IPsec SA is not enabled with the SGT inline
tagging capability.
Handling Fragmentation
Fragmentation is handled in the following two ways:
• Fragmentation before IPsec—If IPsec receives fragmented packets, each fragment is tagged.
• Fragmentation after IPsec—If IPsec packets are fragmented after encryption, the first fragment will be
tagged.
DETAILED STEPS
Step 3 interface tunnel tunnel id Specifies a tunnel interface number, and enters interface
configuration mode.
Example:
Device(config)# interface tunnel 1
Step 4 cts sgt inline Enables TrustSec on DMVPN. This command is valid for
generic routing encapsulation (GRE) and to tunnel interfaces
Example:
modes only.
Device(config-if)# cts sgt inline
SUMMARY STEPS
1. enable
2. show dmvpn
DETAILED STEPS
Step 1 enable
Example:
Device> enable
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 1.1.1.99 10.1.1.99 UP 00:00:01 SC
Use this command to display Dynamic Multipoint VPN (DMVPN)-specific session information.
Step 3 show ip nhrp nhs detail
Example:
Device# show ip nhrp nhs detail
Use this command to display Next Hop Resolution Protocol (NHRP) next hop server (NHS) information.
Step 4 show tunnel endpoints
Example:
Device# show tunnel endpoints
tunnel-nhrp-sb:
NHRP subblock has 1 entries; TrustSec enabled
Use this command to display the contents of the tunnel endpoint database that is used for tunnel endpoint address resolution,
when running a tunnel in multipoint generic routing encapsulation (mGRE) mode.
Step 5 show adjacency interface-type interface-number detail
Example:
Device# show adjaceny tunnel0 detail
SUMMARY STEPS
1. enable
2. configure terminal
3. crypto ikev2 cts sgt
4. exit
DETAILED STEPS
Step 3 crypto ikev2 cts sgt Enables TrustSec on DMVPN on IKEv2 networks. This
command is valid for generic routing encapsulation (GRE)
Example:
and to tunnel interfaces modes only.
Device(config)# crypto ikev2 cts sgt
line vty 0 4
login
transport input all
!
exception data-corruption buffer truncate
scheduler allocate 20000 1000
shutdown
!
interface GigabitEthernet0/0
ip address 10.1.1.2 255.0.0.0
duplex auto
speed auto
ipv6 address 2001::7:1/112
ipv6 enable
!
interface GigabitEthernet0/1
ip address 10.10.10.2 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/2
ip address 192.168.210.144 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/0/0
no ip address
shutdown
!
interface FastEthernet0/0/1
no ip address
!
interface FastEthernet0/0/2
no ip address
!
interface FastEthernet0/0/3
no ip address
!
!
interface Virtual-Template25 type tunnel
ip unnumbered GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile prof_ipv4
!
interface Vlan1
no ip address
!
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 172.17.0.0 255.240.0.0 10.10.10.1
!
logging esm config
ipv6 route ::/0 2001::7:2
!
control-plane
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line 2
no activation-character
no exec
transport preferred none
Cisco IOS commands Cisco IOS Master Command List, All Releases
Cisco TrustSec and SXP configuration Cisco TrustSec Switch Configuration Guide
IKEv2 configuration Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN
Site-to-Site
Cisco Secure Access Control Server Configuration Guide for the Cisco Secure ACS
Technical Assistance
Description Link
Table 24: Feature Information for Configuring TrustSec DMVPN Inline Tagging Support
TrustSec DMVPN Inline The TrustSec DMVPN Inline Tagging Support feature enables IPsec
Tagging Support to carry Cisco Trust Sec (CTS) Security Group Tag (SGT) between
IPsec peers.
The following commands were introduced or modified: cts sgt inline,
show dmvpn, show ip nhrp nhs, show tunnel endpoints, show
adjacency.
The number of NHRP messages between spokes can be limited when the first NHRP resolution reply provides
information about the network behind a local spoke instead of a specific network. The spoke-to-spoke NHRP
summary map uses the configured IP address network and subnet mask in the NHRP resolution response
instead of the IP address network and subnet mask from RIB. If RIB has more number of IP address networks
(lesser subnet mask length) than the configured IP address network and subnet mask, the spoke still uses the
configured IP address network and subnet mask for NHRP resolution response thereby summarizing and
reducing the NHRP resolution traffic on the network. Use the ip nhrp summary-map command to configure
NHRP summary map on a spoke.
Note In DMVPN, it is recommended to configure a Rendezvous Point (RP) at or behind the hub. If there is an IP
multicast source behind a spoke, the ip pim spt-threshold infinity command must be configured on spokes
to avoid multicast traffic going through spoke-to-spoke tunnels.
The entire network behind the local spoke is identified to the remote spoke with one NHRP resolution request.
The following figure shows the working of spoke-to-spoke NHRP summary maps.
Figure 10: Spoke-to-Spoke NHRP Summary Maps
A local spoke with the address space 192.0.0.0/19 on its local LAN has all 32-24 RIB entries –
192.0.0.0/24,….192.0.31.0/24. When a routing protocol like EIGRP is used to advertise this local address
space, the routing protocol is configured to summarize the networks to 192.0.0.0/19 and advertise that to the
hub. The hub summarizes this further, to 192.0.0.0/16, when it advertises it to the other spokes. The other
spokes starts with only a 192.0.0.0/16 routing table entry with the next-hop of the hub in the RIB.
If a remote host communicates with 192.0.12.1, the local spoke receives the NHRP resolution request for
192.0.12.1/32. it looks into the RIB and return 192.0.12.0/24 in NHRP resolution reply.
If the local spoke is configured with NHRP summary map for eg. "ip nhrp summary-map 192.0.0.0/19", the
local spoke upon receing the resolution request for 192.0.12.1 checks the RIB which return 192.0.12.0/24.
the local spoke then check for summary map configuration 192.0.0.0/19 and verifies if the destination
192.0.12.1/32 is covered and returns 192.0.0.0/19 in NHRP resolution reply.
Note The following task can be performed to configure the spoke device.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface tunnel number
4. ip address ip-address mask secondary ip-address mask
5. ip nhrp authentication string
6. ip nhrp summary-map {ip-address | mask}
7. ip nhrp network-id number
8. ip nhrp nhs [hub-tunnel-ip-address] nbma [hub-wan--ip] multicast
9. ip nhrp shortcut
10. tunnel source {ip-address | type number}
11. tunnel mode gre multipoint
12. tunnel key key-number
13. end
DETAILED STEPS
Device> enable
Step 3 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
• number—Specifies the number of the tunnel interface
Device(config)# interface tunnel 5 that you want to create or configure. There is no limit
on the number of tunnel interfaces you can create.
Step 4 ip address ip-address mask secondary ip-address mask Sets a primary or secondary IP address for the tunnel
interface.
Example:
Note All hubs and spokes that are in the same
Device(config-if)# ip address 10.0.0.2 DMVPN network must be addressed in the
255.255.255.0 same IP subnet.
Step 5 ip nhrp authentication string Configures an authentication string for an interface using
NHRP.
Example:
Step 6 ip nhrp summary-map {ip-address | mask} Summarizes and reduces the NHRP resolution traffic on
the network.
Example:
Step 8 ip nhrp nhs [hub-tunnel-ip-address] nbma [hub-wan--ip] Configures the hub router as the NHRP next-hop server.
multicast
Example:
Step 11 tunnel mode gre multipoint Sets the encapsulation mode to Multiple Generic Routing
Encapsulation (mGRE) for the tunnel interface.
Example:
• Use this command if data traffic can use dynamic
Device(config-if)# tunnel mode gre multipoint spoke-to-spoke traffic.
Step 12 tunnel key key-number (Optional) Enables an ID key for a tunnel interface.
Example: • key-number—Specifies a number to identify a tunnel
key. This must be set to the same value on all hubs
Device(config-if)# tunnel key 100000 and spokes that are in the same DMVPN network.
DETAILED STEPS
Step 1 enable
Example:
Device> enable
DETAILED STEPS
NHRP-CACHE: Tunnel0: Cache add for target 67.0.0.0/24 vrf global(0x0) label none next-hop 15.0.0.30
80.0.0.1
NHRP-CACHE: Inserted subblock node(2 now) for cache: Target 67.0.0.0/24 nhop 15.0.0.30
NHRP-CACHE: Converted internal dynamic cache entry for 67.0.0.0/24 interface Tunnel0 vrf global(0x0)
to external
NHRP-RT: Adding route entry for 67.0.0.0/24 (Tunnel0 vrf:global(0x0)) to RIB
NHRP-RT: Route addition to RIB Successful
NHRP-RT: Route watch started for 67.0.0.0/23
NHRP-CACHE: Updating label on Tunnel0 for 15.0.0.30 vrf global(0x0), old none new none nhop 15.0.0.30
NHRP-CACHE: Tunnel0: Cache update for target 15.0.0.30/32 vrf global(0x0) label none next-hop 15.0.0.30
80.0.0.1
NHRP-CACHE: Deleting incomplete entry for 67.0.0.1/32 interface Tunnel0 vrf global(0x0)
NHRP-CACHE: Still other cache entries with same overlay nhop 67.0.0.1
NHRP-RT: Received route watch notification for 67.0.0.0/24
NHRP-RT: Covering prefix is 67.0.0.0/22
NHRP-RT: Received route watch notification for 67.0.0.0/24
interface Tunnel0
ip address 15.0.0.1 255.255.255.0
no ip redirects
no ip split-horizon eigrp 2
ip nhrp authentication cisco123
ip nhrp network-id 23
ip nhrp redirect
ip summary-address eigrp 2 190.0.0.0 255.255.252.0
ip summary-address eigrp 2 201.0.0.0 255.255.252.0
tunnel source GigabitEthernet1/0/0
tunnel mode gre multipoint
tunnel key 6
end
The following example shows how to configure spoke-to-spoke NHRP summary maps on spoke 1.
interface Tunnel0
vrf forwarding vrf1
ip address 15.0.0.10 255.255.255.0
ip nhrp authentication cisco123
ip nhrp summary-map 190.0.0.0/22
ip nhrp network-id 5
ip nhrp nhs 15.0.0.1 nbma 123.0.0.1 multicast
ip nhrp shortcut
tunnel source GigabitEthernet0/1/0
tunnel mode gre multipoint
tunnel key 6
end
The following example shows how to configure spoke-to-spoke NHRP summary maps on spoke 2.
interface Tunnel0
ip address 15.0.0.20 255.255.255.0
ip nhrp authentication cisco123
ip nhrp summary-map 201.0.0.0/22
ip nhrp network-id 5
ip nhrp nhs 15.0.0.1 nbma 123.0.0.1 multicast
ip nhrp shortcut
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 6
end
The following is a sample output of the show ip nhrp command on the hub.
Cisco IOS commands Cisco IOS Master Command List, All Releases
Cisco IOS security commands • Cisco IOS Security Command Reference: Commands A
to C
• Cisco IOS Security Command Reference: Commands D
to L
• Cisco IOS Security Command Reference: Commands M
to R
• Cisco IOS Security Command Reference: Commands S to
Z
Technical Assistance
Description Link