-
This documentation has been moved
-
Overview: Secure Connectivity
-
Internet Key Exchange for IPsec VPNs
-
Configuring Internet Key Exchange for IPsec VPNs
-
Call Admission Control for IKE
-
Certificate to ISAKMP Profile Mapping
-
Encrypted Preshared Key
-
Fragmentation of IKE Packets
-
IKE Responder-Only Mode
-
Distinguished Name Based Crypto Maps
-
IPsec and Quality of Service
-
VRF-Aware IPsec
-
IKE: Initiate Aggressive Mode (12.2(8)T FM)
-
Configuring Internet Key Exchange Version 2 (IKEv2)
-
-
Security for VPNs with IPsec
-
Configuring Security for VPNs with IPsec
-
IPsec Virtual Tunnel Interface
-
L2TP-IPsec Support for NAT and PAT Windows Clients
-
SafeNet IPsec VPN Client Support
-
Ability to Disable Extended Authentication for Static IPsec Peers
-
Sharing IPsec with Tunnel Protection
-
Crypto Conditional Debug Support
-
VPN Acceleration Module (VAM)
-
Option to Disable Hardware Crypto Engine Failover to Software Crypto Engine
-
- VPN Availability
-
IPsec Data Plane
-
IPsec Anti-Replay Window: Expanding and Disabling
-
Pre-Fragmentation for IPsec VPNs
-
Invalid Security Parameter Index Recovery
-
IPsec Dead Peer Detection Periodic Message Option
-
IPsec NAT Transparency
-
DF Bit Override Functionality with IPsec Tunnels
-
Crypto Access Check on Clear-Text Packets
-
IPsec Security Association Idle Timers
-
Low Latency Queueing (LLQ) for IPsec Encryption Engines
-
- IPsec Management
-
Public Key Infrastructure (PKI)
-
Implementing and Managing PKI Features Roadmap
-
Cisco IOS PKI Overview: Understanding and Planning a PKI
-
Deploying RSA Keys Within a PKI
-
Configuring Authorization and Revocation of Certificates in a PKI
-
Configuring Certificate Enrollment for a PKI
-
Setting Up Secure Device Provisioning (SDP) for Enrollment in a PKI
-
Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment
-
Storing PKI Credentials
-
Source Interface Selection for Outgoing Traffic with Certificate Authority (CA)
-
IOS PKI Performance Monitoring and Optimization
-
- Dynamic Multipoint VPN (DMVPN)
- Easy VPN
-
Cisco Group Encrypted Transport VPN
- SSL VPN
-
Feedback
Table Of Contents
Restrictions for DHCP—Tunnels Support
Information About DHCP—Tunnels Support
DHCP Behavior on a Tunnel Network
DMVPN Hub as a DHCP Relay Agent
Dual-Hub Single-DMVPN Topology
How to Configure DHCP—Tunnels Support
Configuring a DMVPN Spoke to Acquire an IP Address from the DHCP Server
Configuring the DHCP Relay Agent to Unicast DHCP Replies
Configuring a DMVPN Spoke to Clear the Broadcast Flag
Configuration Examples for DHCP—Tunnels Support
Example: Configuring a DMVPN Spoke to Acquire an IP Address from the DHCP Server
Example: Configuring a DHCP Relay Agent to Unicast DHCP Replies
Example: Configuring a DMVPN Spoke to Clear the Broadcast Flag
Feature Information for DHCP—Tunnels Support
DHCP—Tunnels Support
First Published: November 5, 2010Last Updated: November 5, 2010The DHCP—Tunnels Support feature provides the capability to configure the node (or spoke) of the generic routing encapsulation (GRE) tunnel interfaces dynamically using DHCP.
In a Dynamic Multipoint VPN (DMVPN) network each participating spoke must have a unique IP address belonging to the same IP subnet. It is difficult for a network administrator to configure the spoke addresses manually on a large DMVPN network. Hence, DHCP is used to configure the spoke address dynamically on a DMVPN network.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for DHCP—Tunnels Support" section.
Use Cisco Feature Navigator to find information about platform support and Cisco 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
•
Restrictions for DHCP—Tunnels Support
•
•
•
•
Restrictions for DHCP—Tunnels Support
•
•
Information About DHCP—Tunnels Support
•
•
DHCP Overview
DHCP is based on the Bootstrap Protocol (BOOTP), which provides the framework for passing configuration information to hosts on a TCP/IP network. DHCP adds the capability to automatically allocate reusable network addresses and configuration options to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocating network addresses to hosts. DHCP is built on a client/server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. See the "DHCP" section of the Cisco IOS IP Addressing Configuration Guide for more information.
DHCP Behavior on a Tunnel Network
DMVPN spoke nodes establish a tunnel with a preconfigured DMVPN next hop server (NHS) (hub node) and exchange IP packets with the NHS before an IP address is configured on the tunnel interface. This allows the DHCP client on the spoke and the DHCP relay agent or the DHCP server on the NHS to send and receive the DHCP messages. A DHCP relay agent is any host that forwards DHCP packets between clients and servers.
When the tunnel on a spoke is in the UP state or becomes active, the spoke establishes a tunnel with the preconfigured hub node. The tunnel formation may include setting up IP Security (IPsec) encryption for the tunnel between the spoke and the hub. DHCP receives the GRE tunnel interface UP notification only after the spoke establishes a tunnel with the hub. The DHCP client configured on the spoke must exchange the DHCP IP packets with the hub (DHCP relay agent or server) to obtain an IP address for the GRE tunnel interface. Therefore, the spoke-to-hub tunnel must be in active state before the GRE tunnel interface UP notification is sent to the DHCP server or the relay agent.
IP packets that are broadcast on the DMVPN spoke reache the DMVPN hub. The spoke broadcasts a DHCPDISCOVER message to the DHCP relay agent on the DMVPN hub, prior to the spoke having an IP address on the GRE tunnel interface. By using the DHCPDISCOVER message, DHCP unicasts the offer back to the client. The hub cannot send IP packets to the spoke before the hub receives a Next Hop Resolution Protocol (NHRP) registration from the spoke. The DHCP relay agent configured on the DMVPN hub adds mapping information to the DHCP client packets (DHCPDISCOVER and DHCPREQUEST). The mapping information is added to the DHCP client so that it is available for the DMVPN hub to relay the DHCP server response.
Note
DMVPN Hub as a DHCP Relay Agent
Relay agents are not required for DHCP to work. Relay agents are used only when the DHCP client and server are in different subnets. The relay agent acts as a communication channel between the DHCP client and server. The DHCP—Tunnels Support feature requires the DMVPN hub to act as a relay agent to relay the DHCP messages to the DHCP server.
The DHCP server is located outside the DMVPN network and is accessible from the DMVPN hub nodes through a physical path. The spoke nodes reach the DHCP servers through the hub-to-spoke tunnel (GRE tunnel). The DHCP server is not directly reachable from the DMVPN spoke. The DHCP relay agent on the DMVPN hub helps the DHCP protocol message exchange between the DHCP client on the spoke and the DHCP server.
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.
Dual-Hub Dual-DMVPN Topology
In the dual-hub dual-DMVPN topology, each hub is connected to a separate DHCP server. The DMVPN hubs (DHCP relay agents) include a client-facing tunnel IP address in the relayed DHCP requests. DHCP requests are used by the DHCP server to allocate an IP address from the correct pool.
Hierarchical DMVPN Topology
In a DMVPN hierarchical topology, there are multiple levels of DMVPN hubs. However, all the tunnel interface IP addresses are allocated from the same IP subnet address. The DHCP client broadcast packets are broadcast to the directly connected hubs. Hence, the DMVPN hubs at all levels must either be DHCP servers or DHCP relay agents. If DHCP servers are used then the servers must synchronize their databases. The DMVPN hubs must be configured as DHCP relay agents to forward the DHCP client packets to the central DHCP servers. If the DHCP server is located at the central hub, all DHCP broadcasts are relayed through the relay agents until they reach the DHCP server.
How to Configure DHCP—Tunnels Support
•
•
•
Configuring a DMVPN Spoke to Acquire an IP Address from the DHCP Server
Perform this task to configure a DMVPN spoke to acquire an IP address from the DHCP server.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring the DHCP Relay Agent to Unicast DHCP Replies
Perform this task to configure the DHCP relay agent to unicast DHCP replies.
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.
2.
3.
4.
DETAILED STEPS
Configuring a DMVPN Spoke to Clear the Broadcast Flag
Perform this task to configure a DMVPN spoke to clear the broadcast flag.
By default, DMVPN spokes set the broadcast flag in the DHCP DISCOVER and REQUEST messages. Therefore the DHCP relay agent is forced to broadcast the DHCP replies back to the spokes, even though the relay agent has sufficient information to unicast DHCP replies. Hence, you must clear the broadcast flag from the DMVPN spoke.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuration Examples for DHCP—Tunnels Support
•
•
•
Example: Configuring a DMVPN Spoke to Acquire an IP Address from the DHCP Server
The following example shows how to configure a DMVPN spoke to acquire an IP address from the DHCP server:
Router# configure terminalRouter(config)# interface tunnel 1Router(config-if)# ip address dhcp hostname host1Router(config-if)# exitExample: Configuring a DHCP Relay Agent to Unicast DHCP Replies
The following example shows how to configure a DHCP relay agent to unicast DHCP replies:
Router# configure terminalRouter(config)# ip dhcp support tunnel unicastRouter(config)# exitExample: Configuring a DMVPN Spoke to Clear the Broadcast Flag
The following example shows how to configure a DMVPN spoke to clear the broadcast flag:
Router# configure terminalRouter(config)# interface tunnel 1Router(config-if)# ip dhcp client broadcast-flag clearRouter(config-if)# exitAdditional References
Related Documents
Standards
—
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
MIBs
RFCs
Technical Assistance
Feature Information for DHCP—Tunnels Support
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at 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. (1005R)
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.
© 2010 Cisco Systems, Inc. All rights reserved.
