Table Of Contents
Dynamic Multipoint VPN (DMVPN)
Contents
Prerequisites for Dynamic Multipoint VPN (DMVPN)
Restrictions for Dynamic Multipoint VPN (DMVPN)
DMVPN Support on the Cisco 6500 and Cisco 7600
Information About Dynamic Multipoint VPN (DMVPN)
Benefits of Dynamic Multipoint VPN (DMVPN)
Feature Design of Dynamic Multipoint VPN (DMVPN)
IPsec Profiles
VRF Integrated DMVPN
DMVPN—Enabling Traffic Segmentation Within DMVPN
NAT-Transparency Aware DMVPN
Call Admission Control with DMVPN
NHRP Rate-Limiting Mechanism
How to Configure Dynamic Multipoint VPN (DMVPN)
Configuring an IPsec Profile
Prerequisites
What to Do Next
Configuring the Hub for DMVPN
Configuring the Spoke for DMVPN
Configuring the Forwarding of Clear-Text Data IP Packets into a VRF
Configuring the Forwarding of Encrypted Tunnel Packets into a VRF
Configuring DMVPN—Traffic Segmentation Within DMVPN
Prerequisites
Enabling MPLS on the VPN Tunnel
Configuring Multiprotocol BGP on the Hub Router
Configuring Multiprotocol BGP on the Spoke Routers
Troubleshooting Dynamic Multipoint VPN (DMVPN)
What to Do Next
Configuration Examples for Dynamic Multipoint VPN (DMVPN) Feature
Hub Configuration for DMVPN: Example
Spoke Configuration for DMVPN: Example
VRF Aware DMVPN: Example
2547oDMVPN with Traffic Segmentation (with BGP only): Example
2547oDMVPN with Traffic Segmentation (Enterprise Branch): Example
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Command Reference
clear dmvpn session
clear dmvpn statistics
debug dmvpn
debug nhrp condition
debug nhrp error
logging dmvpn
show dmvpn
show ip nhrp traffic
Feature Information for Dynamic Multipoint VPN (DMVPN)
Glossary
Dynamic Multipoint VPN (DMVPN)
First Published: November 25, 2002
Last Updated: December 11, 2006
The Dynamic Multipoint VPN (DMVPN) feature allows users to better scale large and small IP Security (IPsec) Virtual Private Networks (VPNs) by combining generic routing encapsulation (GRE) tunnels, IPsec encryption, and Next Hop Resolution Protocol (NHRP).
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for Dynamic Multipoint VPN (DMVPN)" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Dynamic Multipoint VPN (DMVPN)
•Restrictions for Dynamic Multipoint VPN (DMVPN)
•Information About Dynamic Multipoint VPN (DMVPN)
•How to Configure Dynamic Multipoint VPN (DMVPN)
•Configuration Examples for Dynamic Multipoint VPN (DMVPN) Feature
•Additional References
•Command Reference
•Feature Information for Dynamic Multipoint VPN (DMVPN)
•Glossary
Prerequisites for Dynamic Multipoint VPN (DMVPN)
•Before a multipoint GRE (mGRE) and IPsec tunnel can be established, you must define an Internet Key Exchange (IKE) policy by using the crypto isakmp policy command.
•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.
Restrictions for Dynamic Multipoint VPN (DMVPN)
•If you use the Dynamic Creation for Spoke-to-Spoke Tunnels benefit of this feature, you must use IKE certificates or wildcard preshared keys for Internet Security Association Key Management Protocol (ISAKMP) authentication.
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.
DMVPN Support on the Cisco 6500 and Cisco 7600
Blade-to-Blade Switchover on the Cisco 6500 and Cisco 7600
•DMVPN does not support blade-to-blade switchover on the Cisco 6500 and Cisco 7600.
Cisco 6500 or Cisco 7600 As a DMVPN Hub
•A Cisco 6500 or Cisco 7600 that is functioning as a DMVPN hub cannot be located behind a NAT router.
•If a Cisco 6500 or Cisco 7600 is functioning as a DMVPN hub, the spoke behind NAT must be a Cisco 6500 or Cisco 7600, respectively, or the router must be upgraded to Cisco IOS software Release 12.3(11)T02 or a later release.
Cisco 6500 or Cisco 7600 As a DMVPN Spoke
•If a Cisco 6500 or Cisco 7600 is functioning as a spoke, the hub cannot be behind NAT.
•If a Cisco 6500 or Cisco 7600 is functioning as a DMVPN spoke behind NAT, the hub must be a Cisco 6500 or Cisco 7600, respectively, or the router must be upgraded to Cisco IOS Release 12.3(11)T02 or a later release.
DMVPN Hub or Spoke Supervisor Engine
•Only a Supervisor Engine 720 can be used as a DMVPN hub or spoke. A Supervisor Engine 2 cannot be used.
Encrypted Multicast with GRE
•Encrypted Multicast with GRE is not supported on the Cisco 6500 nor on the Cisco 7600.
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.
Quality of Service (QoS)
•You cannot use QoS for DMVPN packets on a Cisco 6500 or Cisco 7600.
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.
VRF-Aware DMVPN Scenarios
•The mls mpls tunnel-recir command must be configured on the provider equipment (PE) DMVPN hub if customer equipment (CE) DMVPN spokes need to "talk" to other CEs across the MPLS cloud.
•The mGRE interface should be configured with a large enough IP maximum transmission unit (1400 packets to avoid having the route processor doing fragmentation.
Information About Dynamic Multipoint VPN (DMVPN)
To configure the Dynamic Multipoint VPN (DMVPN) feature, you must understand the following concepts:
•Benefits of Dynamic Multipoint VPN (DMVPN)
•Feature Design of Dynamic Multipoint VPN (DMVPN)
•IPsec Profiles
•VRF Integrated DMVPN
•DMVPN—Enabling Traffic Segmentation Within DMVPN
•NAT-Transparency Aware DMVPN
•Call Admission Control with DMVPN
•NHRP Rate-Limiting Mechanism
Benefits of Dynamic Multipoint VPN (DMVPN)
Hub Router Configuration Reduction
•Currently, for each spoke router, there is a separate block of configuration lines on the hub router that define the crypto map characteristics, the crypto access list, and the GRE tunnel interface. This feature allows users to configure a single mGRE tunnel interface, a single IPsec profile, and no crypto access lists on the hub router to handle all spoke routers. Thus, the size of the configuration on the hub router remains constant even if spoke routers are added to the network.
•DMVPN architecture can group many spokes into a single multipoint GRE interface, removing the need for a distinct physical or logical interface for each spoke in a native IPsec installation.
Automatic IPsec Encryption Initiation
•GRE has the peer source and destination address configured or resolved with NHRP. Thus, this feature allows IPsec to be immediately triggered for the point-to-point GRE tunneling or when the GRE peer address is resolved via NHRP for the multipoint GRE tunnel.
Support for Dynamically Addressed Spoke Routers
•When using point-to-point GRE and IPsec hub-and-spoke VPN networks, the physical interface IP address of the spoke routers must be known when configuring the hub router because IP address must be configured as the GRE tunnel destination address. This feature allows spoke routers to have dynamic physical interface IP addresses (common for cable and DSL connections). When the spoke router comes online, it will send registration packets to the hub router: within these registration packets, is the current physical interface IP address of this spoke.
Dynamic Creation for Spoke-to-Spoke Tunnels
•This feature eliminates the need for spoke-to-spoke configuration for direct tunnels. When a spoke router wants to transmit a packet to another spoke router, it can now use NHRP to dynamically determine the required destination address of the target spoke router. (The hub router acts as the NHRP server, handling the request for the source spoke router.) The two spoke routers dynamically create an IPsec tunnel between them so data can be directly transferred.
VRF Integrated DMVPN
•DMVPNs can be used to extend the Multiprotocol Label Switching (MPLS) networks that are deployed by service providers to take advantage of the ease of configuration of hub and spokes, to provide support for dynamically addressed customer premises equipment (CPEs), and to provide zero-touch provisioning for adding new spokes into a DMVPN.
Feature Design of Dynamic Multipoint VPN (DMVPN)
The Dynamic Multipoint VPN (DMVPN) feature combines GRE tunnels, IPsec encryption, and NHRP routing to provide users an ease of configuration via crypto profiles—which override the requirement for defining static crypto maps—and dynamic discovery of tunnel endpoints.
This feature relies on the following two Cisco enhanced standard technologies:
•NHRP—A client and server protocol where the hub is the server and the spokes are the clients. The hub maintains an NHRP database of the public interface addresses of the each spoke. Each spoke registers its real address when it boots and queries the NHRP database for real addresses of the destination spokes to build direct tunnels.
•mGRE Tunnel Interface —Allows a single GRE interface to support multiple IPsec tunnels and simplifies the size and complexity of the configuration.
The topology shown in Figure 1 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.
VRF Integrated DMVPN
VPN Routing and Forwarding (VRF) Integrated DMVPN enables users to map DMVPN multipoint interfaces into MPLS VPNs. This mapping allows Internet service providers (ISPs) to extend their existing MPLS VPN services by mapping off-network sites (typically a branch office) to their respective MPLS VPNs. Customer equipment (CE) routers are terminated on the DMVPN PE router, and traffic is placed in the VRF instance of an MPLS VPN.
DMVPN can interact with MPLS VPNs in two ways:
1. The ip vrf forwarding command is used to inject the data IP packets (those packets inside the mGRE+IPsec tunnel) into the MPLS VPN. The ip vrf forwarding command is supported for DMVPN in Cisco IOS Release 12.3(6) and Release 12.3(7)T.
2. The tunnel vrf command is used to transport (route) the mGRE+IPsec tunnel packet itself within an MPLS VPN. The tunnel vrf command is supported in Cisco IOS Release 12.3(11)T but not in Cisco IOS Release 12.2(18)SXE.
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.
Figure 2 illustrates a typical VRF Integrated DMVPN scenario.
Figure 2 VRF Integrated DMVPN
DMVPN—Enabling Traffic Segmentation Within DMVPN
Cisco IOS Release 12.4(11)T provides an enhancement that allows you to segment VPN traffic within a DMVPN tunnel. VRF instances are labeled, using MPLS, to indicate their source and destination.
The diagram in Figure 3 and the corresponding bullets explain how traffic segmentation within DMVPN works.
Figure 3 Traffic Segmentation with DMVPN
•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.
An example illustrates the process:
1. Spoke A advertises a VPNv4 route to the hub, and applies the label X to the VPN.
2. The hub changes the label to Y when the hub advertises the route to Spoke B.
3. When Spoke B has traffic to send to Spoke A, it applies the Y label, and the traffic goes to the hub.
4. The hub swaps the VPN label, by removing the Y label and applying an X label, and sends the traffic to Spoke A.
NAT-Transparency Aware DMVPN
DMVPN spokes are often situated behind a NAT router (which is often controlled by the ISP for the spoke site) with the outside interface address of the spoke router being dynamically assigned by the ISP using a private IP address (per Internet Engineering Task Force [IETF] RFC 1918).
Prior to Cisco IOS Release 12.3(6) and 12.3(7)T, these spoke routers had to use IPsec tunnel mode to participate in a DMVPN network. In addition, their assigned outside interface private IP address had to be unique across the DMVPN network. Even though ISAKMP and IPsec would negotiate NAT-T and "learn" the correct NAT public address for the private IP address of this spoke, NHRP could only "see" and use the private IP address of the spoke for its mapping entries. Effective with the NAT-Transparency Aware DMVPN enhancement, NHRP can now learn and use the NAT public address for its mappings as long as IPsec transport mode is used (which is the recommend IPsec mode for DMVPN networks). The restriction that the private interface IP address of the spoke must be unique across the DMVPN network has been removed. It is recommended that all DMVPN routers be upgraded to the new code before you try to use the new functionality even though spoke routers that are not behind NAT do not need to be upgraded. In addition, you cannot convert upgraded spoke routers that are behind NAT to the new configuration (IPsec transport mode) until the hub routers have been upgraded.
Also added in Cisco IOS Releases 12.3(9a) and 12.3(11)T is the capability to have the hub DMVPN router behind static NAT. This was a change in the ISAKMP NAT-T support. For this functionality to be used, all the DMVPN spoke routers and hub routers must be upgraded, and IPsec must use transport mode.
For these NAT-Transparency Aware enhancements to work, you must use IPsec transport mode on the transform set. Also, even though NAT-Transparency (IKE and IPsec) can support two peers (IKE and IPsec) being translated to the same IP address (using the UDP ports to differentiate them), 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.
Figure 4 illustrates a NAT-Transparency Aware DMVPN scenario.
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.
Figure 4 NAT-Transparency Aware DMVPN
Call Admission Control with DMVPN
In a DMVPN network, it is easy for a DMVPN router to become "overwhelmed" with the number of tunnels it is trying to build. Call Admission Control can be used to limit the number of tunnels that can be built at any one time, thus protecting the memory of the router and CPU resources.
It is most likely that Call Admission Control will be used on a DMVPN spoke to limit the total number of ISAKMP sessions (DMVPN tunnels) that a spoke router will attempt to initiate or accept. This limiting is accomplished by configuring an IKE SA limit under Call Admission Control, which configures the router to drop new ISAKMP session requests (inbound and outbound) if the current number of ISAKMP SAs exceeds the limit.
It is most likely that Call Admission Control will be used on a DMVPN hub to rate limit the number of DMVPN tunnels that are attempting to be built at the same time. The rate limiting is accomplished by configuring a system resource limit under Call Admission Control, which configures the router to drop new ISAKMP session requests (new DMVPN tunnels) when the system utilization is above a specified percentage. The dropped session requests allow the DMVPN hub router to complete the current ISAKMP session requests, and when the system utilization drops, it can process the previously dropped sessions when they are reattempted.
No special configuration is required to use Call Admission Control with DMVPN. For information about configuring Call Admission Control, see the reference in the section "Related Documents."
NHRP Rate-Limiting Mechanism
NHRP has a rate-limiting mechanism that restricts the total number of NHRP packets from any given interface. The default values, which are set using the ip nhrp max-send command, are 100 packets every 10 seconds per interface. If the limit is exceeded, you will get the following system message:
%NHRP-4-QUOTA: Max-send quota of [int]pkts/[int]Sec. exceeded on [chars]
For more information about this system message, see the document 12.4T System Message Guide.
How to Configure Dynamic Multipoint VPN (DMVPN)
To enable mGRE and IPsec tunneling for hub and spoke routers, you must configure an IPsec profile that uses a global IPsec policy template and configure your mGRE tunnel for IPsec encryption. This section contains the following procedures:
•Configuring an IPsec Profile (required)
•Configuring the Hub for DMVPN (required)
•Configuring the Spoke for DMVPN (required)
•Configuring the Forwarding of Clear-Text Data IP Packets into a VRF (optional)
•Configuring the Forwarding of Encrypted Tunnel Packets into a VRF (optional)
•Configuring DMVPN—Traffic Segmentation Within DMVPN
•Troubleshooting Dynamic Multipoint VPN (DMVPN) (optional)
Configuring an IPsec Profile
The IPsec profile shares most of the same 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.
Prerequisites
Before configuring an IPsec profile, you must define a transform set by using the crypto ipsec transform-set command.
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 | group2]
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
crypto ipsec profile name
Example:
Router(config)# crypto ipsec profile vpnprof
|
Defines the IPsec parameters that are to be used for IPsec encryption between "spoke and hub" and "spoke and spoke" routers.
This command enters crypto map configuration mode.
•The name argument specifies the name of the IPsec profile.
|
Step 4
|
set transform-set transform-set-name
Example:
Router(config-crypto-map)# set transform-set
trans2
|
Specifies which transform sets can be used with the IPsec profile.
•The transform-set-name argument specifies the name of the transform set.
|
Step 5
|
set identity
Example:
Router(config-crypto-map)# set identity
|
(Optional) Specifies identity restrictions to be used with the IPsec profile.
|
Step 6
|
set security association lifetime {seconds
seconds | kilobytes kilobytes}
Example:
Router(config-crypto-map)# set security association lifetime seconds 1800
|
(Optional) Overrides the global lifetime value for the IPsec profile.
•The seconds seconds option specifies the number of seconds a security association will live before expiring; the kilobytes kilobytes option specifies the volume of 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 | group2]
Example:
Router(config-crypto-map)# set pfs group2
|
(Optional) Specifies that IPsec should ask for perfect forward secrecy (PFS) when requesting new security associations for this IPsec profile. If this command is not specified, the default (group1) will be enabled.
•The group1 keyword specifies that IPsec should use the 768-bit Diffie-Hellman (DH) prime modulus group when performing the new DH exchange; the group2 keyword specifies the 1024-bit DH prime modulus group.
|
What to Do Next
Proceed to the following sections "Configuring the Hub for DMVPN" and "Configuring the Spoke for DMVPN."
Configuring the Hub for DMVPN
To configure the hub router for mGRE and IPsec integration (that is, associate the tunnel with the IPsec profile configured in the previous procedure), use the following commands:
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
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface tunnel number
Example:
Router(config)# interface tunnel 5
|
Configures a tunnel interface and enters interface configuration mode
•The number argument specifies the number of the tunnel interface 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]
Example:
Router(config-if)# ip address 10.0.0.1
255.255.255.0
|
Sets a primary or secondary IP address for the tunnel interface.
Note All hubs and spokes that are in the same DMVPN network must be addressed in the same IP subnet.
|
Step 5
|
Example:
Router(config-if)# ip mtu 1400
|
Sets the maximum transmission unit (MTU) size, in bytes, of IP packets sent on an interface.
|
Step 6
|
ip nhrp authentication string
Example:
Router(config-if)# ip nhrp authentication
donttell
|
Configures the authentication string for an interface using NHRP.
Note The NHRP authentication string must be set to the same value on all hubs and spokes that are in the same DMVPN network.
|
Step 7
|
ip nhrp map multicast dynamic
Example:
Router(config-if)# ip nhrp map multicast dynamic
|
Allows NHRP to automatically add spoke routers to the multicast NHRP mappings.
|
Step 8
|
ip nhrp network-id number
Example:
Router(config-if)# ip nhrp network-id 99
|
Enables NHRP on an interface.
•The number argument specifies a globally unique 32-bit network identifier from a nonbroadcast multiaccess (NBMA) network. The range is from 1 to 4294967295.
|
Step 9
|
tunnel source {ip-address | type number}
Example:
Router (config-if)# tunnel source Ethernet0
|
Sets source address for a tunnel interface.
|
Step 10
|
tunnel key key-number
Example:
Router (config-if)# tunnel key 100000
|
(Optional) Enables an ID key for a tunnel interface.
•The key-number argument specifies a number from 0 to 4,294,967,295 that identifies the tunnel key.
Note The key number must be set to the same value on all hubs and spokes that are in the same DMVPN network.
Note This command should not be configured if you are using a Cisco 6500 or Cisco 7600 platform.
|
Step 11
|
tunnel mode gre multipoint
Example:
Router(config-if)# tunnel mode gre multipoint
|
Sets the encapsulation mode to mGRE for the tunnel interface.
|
Step 12
|
tunnel protection ipsec profile name
Example:
Router(config-if)# tunnel protection ipsec
profile vpnprof
|
Associates a tunnel interface with an IPsec profile.
•The name argument specifies the name of the IPsec profile; this value must match the name specified in the crypto ipsec profile name command.
|
Step 13
|
bandwidth kbps
Example:
Router(config-if)# bandwidth 1000
|
Sets the current bandwidth value for an interface to higher-level protocols.
•The kbps argument specifies the bandwidth in kilobits per second. The default value is 9. The recommend bandwidth value is 1000 or greater.
Setting the bandwidth value to at least 1000 is critical if EIGRP is used over the tunnel interface. Higher bandwidth values may be necessary depending on the number of spokes supported by a hub.
|
Step 14
|
ip tcp adjust-mss max-segment-size
Example:
Router(config-if)# ip tcp adjust-mss 1360
|
Adjusts the maximum segment size (MSS) value of TCP packets going through a router.
•The max-segment-size argument specifies the maximum segment size, in bytes. The range is from 500 to 1460.
The recommended value is 1360 when the number of IP MTU bytes is set to 1400. With these recommended settings, TCP sessions quickly scale back to 1400-byte IP packets so the packets will "fit" in the tunnel.
|
Step 15
|
ip nhrp holdtime seconds
Example:
Router(config-if)# ip nhrp holdtime 450
|
Changes the number of seconds that NHRP NBMA addresses are advertised as valid in authoritative NHRP responses.
•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 16
|
delay number
Example:
Router(config-if)# delay 1000
|
(Optional) Used to change the EIGRP routing metric for routes learned over the tunnel interface.
•The number argument specifies the delay time in seconds. The recommend value is 1000.
|
Configuring the Spoke for DMVPN
To configure spoke routers for mGRE and IPsec integration, use the following commands.
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. tunnel mode gre multipoint
or
tunnel destination hub-physical-ip-address
14. tunnel protection ipsec profile name
15. bandwidth kbps
16. ip tcp adjust-mss max-segment-size
17. ip nhrp holdtime seconds
18. delay number
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface tunnel number
Example:
Router(config)# interface tunnel 5
|
Configures a tunnel interface and enters interface configuration mode.
•The number argument specifies the number of the tunnel interface 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]
Example:
Router(config-if)# ip address 10.0.0.2
255.255.255.0
|
Sets a primary or secondary IP address for the tunnel interface.
Note All hubs and spokes that are in the same DMVPN network must be addressed in the same IP subnet.
|
Step 5
|
Example:
Router(config-if)# ip mtu 1400
|
Sets the MTU size, in bytes, of IP packets sent on an interface.
|
Step 6
|
ip nhrp authentication string
Example:
Router(config-if)# ip nhrp authentication
donttell
|
Configures the authentication string for an interface using NHRP.
Note The NHRP authentication string be set to the 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
Example:
Router(config-if)# ip nhrp map 10.0.0.1 172.17.0.1
|
Statically configures the IP-to-NBMA address mapping of IP destinations connected to an MBMA network.
•hub-tunnel-ip-address—Defines the NHRP server at the hub, which is permanently mapped to the static public IP address of the hub.
•hub-physical-ip-address—Defines the static public IP address of the hub.
|
Step 8
|
ip nhrp map multicast hub-physical-ip-address
Example:
Router(config-if)# ip nhrp map multicast 172.17.0.1
|
Enables the use of a dynamic routing protocol between the spoke and hub, and sends multicast packets to the hub router.
|
Step 9
|
ip nhrp nhs hub-tunnel-ip-address
Example:
Router(config-if)# ip nhrp nhs 10.0.0.1
|
Configures the hub router as the NHRP next-hop server.
|
Step 10
|
ip nhrp network-id number
Example:
Router(config-if)# ip nhrp network-id 99
|
Enables NHRP on an interface.
•The number argument specifies a globally unique 32-bit network identifier from a NBMA network. The range is from 1 to 4294967295.
|
Step 11
|
tunnel source {ip-address | type number}
Example:
Router (config-if)# tunnel source Ethernet0
|
Sets the source address for a tunnel interface.
|
Step 12
|
tunnel key key-number
Example:
Router (config-if)# tunnel key 100000
|
(Optional) Enables an ID key for a tunnel interface.
•The key-number argument specifies a number from 0 to 4,294,967,295 that identifies the tunnel key.
•The key number must be set to the same value on all hubs and spokes that are in the same DMVPN network.
Note This command should not be configured if you are using a Cisco 6500 or Cisco 7600 platform.
|
Step 13
|
tunnel mode gre multipoint
or
tunnel destination hub-physical-ip-address
Example:
Router(config-if)# tunnel mode gre multipoint
or
Router(config-if)# tunnel destination 172.17.0.1
|
Sets the encapsulation mode to mGRE for the tunnel interface.
Use this command if data traffic can use dynamic spoke-to-spoke traffic.
Specifies the destination for a tunnel interface.
Use this command if data traffic can use hub-and-spoke tunnels.
|
Step 14
|
tunnel protection ipsec profile name
Example:
Router(config-if)# tunnel protection ipsec
profile vpnprof
|
Associates a tunnel interface with an IPsec profile.
•The name argument specifies the name of the IPsec profile; this value must match the name specified in the crypto ipsec profile name command.
|
Step 15
|
bandwidth kbps
Example:
Router(config-if)# bandwidth 1000
|
Sets the current bandwidth value for an interface to higher-level protocols.
•The kbps argument specifies the bandwidth in kilobits 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
Example:
Router(config-if)# ip tcp adjust-mss 1360
|
Adjusts the maximum segment size (MSS) value of TCP packets going through a router.
•The max-segment-size argument specifies the maximum segment size, in bytes. The range is from 500 to 1460.
The recommended number value is 1360 when the number of IP MTU bytes is set to 1400. With these recommended settings, TCP sessions quickly scale back to 1400-byte IP packets so the packets will "fit" in the tunnel.
|
Step 17
|
ip nhrp holdtime seconds
Example:
Router(config-if)# ip nhrp holdtime 450
|
Changes the number of seconds that NHRP NBMA addresses are advertised as valid in authoritative NHRP responses.
•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
Example:
Router(config-if)# delay 1000
|
(Optional) Used to change the EIGRP routing metric for routes learned over the tunnel interface.
•The number argument specifies the delay time in seconds. The recommend value is 1000.
|
Configuring the Forwarding of Clear-Text Data IP Packets into a VRF
To configure the forwarding of clear-text date IP packets into a VRF, perform the following steps. This configuration assumes that the VRF BLUE has already been configured.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip vrf forwarding vrf-name
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface type number
Example:
Router (config)# interface tunnel0
|
Configures an interface type and enters interface configuration mode.
|
Step 4
|
ip vrf forwarding vrf-name
Example:
Router (config-if)# ip vrf forwarding BLUE
|
Associates a VPN VRF with an interface or subinterface.
|
Configuring the Forwarding of Encrypted Tunnel Packets into a VRF
To configure the forwarding of encrypted tunnel packets into a VRF, perform the following steps. This configuration assumes that the VRF RED has already been configured.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. tunnel vrf vrf-name
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface type number
Example:
Router (config)# interface tunnel0
|
Configures an interface type and enters interface configuration mode.
|
Step 4
|
tunnel vrf vrf-name
Example:
Router (config-if)# tunnel vrf RED
|
Associates a VPN VRF instance with a specific tunnel destination, interface, or subinterface.
|
Configuring DMVPN—Traffic Segmentation Within DMVPN
There are no new commands to use for configuring traffic segmentation, but there are tasks you must complete in order to segment traffic within a DMVPN tunnel:
•Enabling MPLS on the VPN Tunnel
•Configuring Multiprotocol BGP on the Hub Router
•Configuring Multiprotocol BGP on the Spoke Routers
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" section and the "Configuring the Spoke for DMVPN" section. For details about VRF configuration, see the "Configuring the Forwarding of Clear-Text Data IP Packets into a VRF" section and the "Configuring the Forwarding of Encrypted Tunnel Packets into a VRF" section.
Enabling MPLS on the VPN Tunnel
Because traffic segmentation within a DMVPN tunnel depends upon MPLS, you must configure MPLS for each VRF instance in which traffic will be segmented. For detailed information about configuring MPLS, see Cisco IOS Multiprotocol Label Switching Configuration Guide, Release 12.4.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. mpls ip
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
interface type number
Example:
Router (config)# interface tunnel0
|
Configures an interface type and enters interface configuration mode.
|
Step 4
|
mpls ip
Example:
Router (config-if)# mpls ip
|
Enables MPLS tagging of packets on the specified tunnel interface.
|
Configuring Multiprotocol BGP on the Hub Router
You must configure multiprotocol iBGP (MP-iBGP) to enable advertisement of VPNv4 prefixes and labels to be applied to the VPN traffic. Use BGP to configure the hub as a route reflector. To force all traffic to be routed via the hub, configure the BGP route reflector to change the next hop to itself when it advertises VPNv4 prefixes to the route reflector clients (spokes).
For more information about the BGP routing protocol, see the "BGP" chapter in the Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4.
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
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
Enter your password if prompted.
|
Step 2
|
