- Preface
- Product Overview
- Command-Line Interfaces
- Configuring the Switch for the First Time
- Administering the Switch
- Configuring Virtual Switching Systems
- Configuring the Cisco IOS In-Service Software Upgrade Process
- Configuring the Cisco IOS XE In Service Software Upgrade Process
- Configuring Interfaces
- Checking Port Status and Connectivity
- Configuring Supervisor Engine Redundancy Using RPR and SSO on Supervisor Engine 6-E and Supervisor Engine 6L-E
- Configuring Supervisor Engine Redundancy Using RPR and SSO on Supervisor Engine 7-E, Supervisor Engine 7L-E, and Supervisor Engine 8-E
- Configuring Cisco NSF with SSO Supervisor Engine Redundancy
- Environmental Monitoring and Power Management
- Configuring Power over Ethernet
- Configuring the Catalyst 4500 Series Switch with Cisco Network Assistant
- Configuring VLANs, VTP, and VMPS
- Configuring IP Unnumbered Interface
- Configuring Layer 2 Ethernet Interfaces
- Configuring EVC-Lite
- Configuring Cisco IOS Auto Smartport Macros
- Configuring SmartPort Macros
- Configuring STP and MST
- Configuring Flex Links and MAC Address-Table Move Update
- Configuring Resilient Ethernet Protocol
- Configuring Optional STP Features
- Configuring EtherChannel and Link State Tracking
- Configuring IGMP Snooping and Filtering, and MVR
- Configuring IPv6 Multicast Listener Discovery Snooping
- Configuring 802.1Q Tunneling, VLAN Mapping, and Layer 2 Protocol Tunneling
- Configuring Cisco Discovery Protocol
- Configuring LLDP, LLDP-MED, and Location Service
- Configuring UDLD
- Configuring Unidirectional Ethernet
- Configuring Layer 3 Interfaces
- Configuring Cisco Express Forwarding
- Configuring Unicast Reverse Path Forwarding
- Configuring IP Multicast
- Configuring ANCP Client
- Configuring Bidirectional Forwarding Detection
- Configuring Policy-Based Routing
- Configuring VRF-lite
- Configuring Quality of Service
- Configuring Voice Interfaces
- Configuring Private VLANs
- Configuring MACsec Encryption
- Configuring 802.1X Port-Based Authentication
- Configuring the PPPoE Intermediate Agent
- Configuring Web-Based Authentication
- Configuring Wired Guest Access
- Configuring Port Security
- Configuring Auto Security
- Configuring Control Plane Policing and Layer 2 Control Packet QoS
- Configuring Dynamic ARP Inspection
- Configuring DHCP Snooping, IP Source Guard, and IPSG for Static Hosts
- Configuring DHCP Snooping, IP Source Guard, and IPSG for Static Hosts
- Configuring Network Security with ACLs
- Support for IPv6
- Port Unicast and Multicast Flood Blocking
- Configuring Storm Control
- Configuring SPAN and RSPAN
- Configuring Wireshark
- Configuring Enhanced Object Tracking
- Configuring System Message Logging
- Onboard Failure Logging (OBFL)
- Configuring SNMP
- Configuring NetFlow-lite
- Configuring Flexible NetFlow
- Configuring Ethernet OAM and CFM
- Configuring Y.1731 (AIS and RDI)
- Configuring Call Home
- Configuring Cisco IOS IP SLA Operations
- Configuring RMON
- Performing Diagnostics
- Configuring WCCP Version 2 Services
- Configuring MIB Support
- ROM Monitor
- Acronyms and Abbreviations
- Finding Feature Information
- Prerequisites for Configuring the DHCP Server
- Information About Cisco IOS DHCP Server
- How to Configure the Cisco IOS DHCP Server
- Configuring DHCP Address Pools
- Configuring Manual Bindings
- Configuring the DHCP Server to Read a Static Mapping Text File
- Customizing DHCP Server Operation
- Configuring a Remote Device to Import DHCP Server Options from a Central DHCP Server
- Configuring DHCP Address Allocation Using Option 82
- Configuring Static Route with the Next-Hop Dynamically Obtained Through DHCP
- Clearing DHCP Server Variables
- Example: Configuring a DHCP Database Agent or Disabling Conflict Logging
- Example: Excluding IP Addresses
- Example: Configuring a DHCP Address Pool
- Example: Configuring Manual Bindings
- Example: Configuring Static Mapping
- Example: Customizing DHCP Server Operation
- Example: Configuring a Remote Device to Import DHCP Server Options from a Central DHCP Server
- Example: Configuring DHCP Address Allocation Using Option 82
- Example: Configuring a Static Route with the Next-Hop Dynamically Obtained Through DHCP
Configuring the Cisco IOS DHCP Server
Cisco devices running Cisco software include Dynamic Host Configuration Protocol (DHCP) server and the relay agent software. The Cisco IOS DHCP server is a full DHCP server implementation that assigns and manages IP addresses from specified address pools within the device to DHCP clients. The DHCP server can be configured to assign additional parameters such as the IP address of the Domain Name System (DNS) server and the default device.
This module describes the concepts and the tasks needed to configure the Cisco IOS DHCP server.
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 the IOS DHCP Server” 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.
Prerequisites for Configuring the DHCP Server
- Before you configure a Cisco Dynamic Host Control Protocol (DHCP) server, you must understand the concepts documented in the “Overview of the DHCP Server” section.
- The Cisco DHCP server and the relay agent services are enabled by default. Use the no service dhcp command to disable the Cisco DHCP server and the relay agent and the service dhcp command to reenable the functionality.
- Port 67 (the DHCP server port) is closed in the Cisco DHCP/BOOTP default configuration. There are two logical parts to the service dhcp command: service-enabled and service running. The DHCP service is enabled by default, but port 67 does not open until the DHCP service is running. If the DHCP service is running, the show ip sockets details or the show sockets detail command displays port 67 as open.
- The Cisco DHCP relay agent is enabled on an interface only when you configure the ip helper-address command. This command enables a DHCP broadcast to be forwarded to the configured DHCP server.
Information About Cisco IOS DHCP Server
- Overview of the DHCP Server
- DHCP Attribute Inheritance
- DHCP Server Address Allocation Using Option 82
- Disabling Conflict Logging
- DHCP Address Pools
- Manual Bindings
- DHCP Static Mapping
- DHCP Server Operation
- Static Route with the Next-Hop Dynamically Obtained Through DHCP
Overview of the DHCP Server
The Cisco DHCP server accepts address assignment requests and renewals from the client and assigns the addresses from predefined groups of addresses within DHCP address pools. These address pools can also be configured to supply additional information to the requesting client such as the IP address of the Domain Name System (DNS) server, the default device, and other configuration parameters. The Cisco DHCP server can accept broadcasts from locally attached LAN segments or from DHCP requests that have been forwarded by other DHCP relay agents within the network.
DHCP Attribute Inheritance
The DHCP server database is organized as a tree. The root of the tree is the address pool for natural networks, branches are subnetwork address pools, and leaves are manual bindings to clients. Subnetworks inherit network parameters and clients inherit subnetwork parameters. Therefore, common parameters (for example, the domain name) should be configured at the highest (network or subnetwork) level of the tree.
Inherited parameters can be overridden. For example, if a parameter is defined in both the natural network and a subnetwork, the definition of the subnetwork is used.
Address leases are not inherited. If a lease is not specified for an IP address, by default, the DHCP server assigns a one-day lease for the address.
DHCP Server Address Allocation Using Option 82
The Cisco IOS DHCP server can allocate dynamic IP addresses based on the relay information option (option 82) sent by the relay agent.
DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the options field of the DHCP message. The data items are also called options. Option 82 is organized as a single DHCP option that contains information known by the relay agent.
Automatic DHCP address allocation is based on an IP address. This IP address can either be the gateway address (giaddr field of the DHCP packet) or the IP address of an incoming interface. In some networks, it is necessary to use additional information to further determine which IP addresses to allocate. By using option 82, the Cisco IOS DHCP relay agent can include additional information about itself when forwarding client-originated DHCP packets to a DHCP server. The Cisco IOS DHCP server can also use option 82 to provide additional information to properly allocate IP addresses to DHCP clients. The information sent via option 82 is used to identify the port where the DHCP request arrives. Automatic DHCP address allocation does not parse out the individual suboptions contained in option 82. Rather, the address allocation is done by matching a configured pattern byte by byte.
This feature introduces a new DHCP class capability, which is a method to group DHCP clients based on some shared characteristics other than the subnet in which the clients reside.
For example, DHCP clients are connected to two ports of a single switch. Each port can be configured to be a part of two VLANs: VLAN1 and VLAN2. DHCP clients belong to either VLAN1 or VLAN2 and the switch can differentiate the VLAN that a particular DHCP Discover message belongs to (possibly through Layer 2 encapsulation). Each VLAN has its own subnet and all DHCP messages from the same VLAN (same switch) have the giaddr field set to the same value indicating the subnet of the VLAN.
Problems can occur while allocating IP addresses to DHCP clients that are connected to different ports of the same VLAN. These IP addresses must be part of the same subnet but the range of IP addresses must be different. In the preceding example, when a DHCP client that is connected to a port of VLAN1 must be allocated an IP address from a range of IP addresses within the VLAN’s subnet, whereas a DHCP client connecting to port 2 of VLAN1 must be allocated an IP address from another range of IP addresses. The two range of IP addresses are part of the same subnet (and have the same subnet mask). Generally, during DHCP address allocation, the DHCP server refers only to the giaddr field and is unable to differentiate between the two ranges.
To solve this problem, a relay agent residing at the switch inserts the relay information option (option 82), which carries information specific to the port, and the DHCP server inspects both the giaddr field and the inserted option 82 during the address selection process.
When you enable option 82 on a device, the following sequence of events occurs:
1. The host (DHCP client) generates a DHCP request and broadcasts it on the network.
2. When the device receives the DHCP request, it adds the option 82 information in the packet. The option 82 information contains the device MAC address (the remote ID suboption) and the port identifier, vlan-mod-port, from which the packet is received (the circuit ID suboption).
3. The device adds the IP address of the relay agent to the DHCP packet.
4. The device forwards the DHCP request that includes the option 82 field to the DHCP server.
5. The DHCP server receives the packet. If the server is option 82 capable, it uses the remote ID, the circuit ID, or both to assign IP addresses and implement policies, such as restricting the number of IP addresses that can be assigned to a single remote ID or circuit ID. The DHCP server echoes the option 82 field in the DHCP reply.
6. The DHCP server unicasts the reply to the device if the request is relayed to the server by the device. The device verifies that it originally inserted the option 82 data by inspecting remote ID and possibly circuit ID fields. The device removes the option 82 field and forwards the packet to the interface that connects to the DHCP client that sent the DHCP request.
The Cisco software refers to a pool of IP addresses (giaddr or incoming interface IP address) and matches the request to a class or classes configured in the pool in the order the classes are specified in the DHCP pool configuration.
When a DHCP address pool is configured with one or more DHCP classes, the pool becomes a restricted access pool, which means that no addresses are allocated from the pool unless one or more classes in the pool matches. This design allows DHCP classes to be used either for access control (no default class is configured on the pool) or to provide further address range partitions within the subnet of the pool.
Multiple pools can be configured with the same class, eliminating the need to configure the same pattern in multiple pools.
The following capabilities are supported for DHCP class-based address allocation:
- Specifying the full relay agent information option value as a raw hexadecimal string by using the relay-information hex command in new relay agent information configuration mode.
- Support for bit-masking the raw relay information hexadecimal value.
- Support for a wildcard at the end of a hexadecimal string specified by the relay-information hex command.
If the relay agent inserts option 82 but does not set the giaddr field in the DHCP packet, the DHCP server interface must be configured as a trusted interface by using the ip dhcp relay information trusted command. This configuration prevents the server from dropping the DHCP message.
Disabling Conflict Logging
A DHCP database agent is any host (for example, an FTP, a TFTP, or a remote copy protocol [RCP] server) or storage media on a DHCP server (for example, disk0) that stores the DHCP bindings database. You can configure multiple DHCP database agents, and the interval between database updates and transfers for each agent.
Automatic bindings are IP addresses that are automatically mapped to the MAC addresses of hosts that are found in the DHCP database. Automatic binding information (such as lease expiration date and time, interface index, and VPN routing and forwarding [VRF] name) is stored in a database agent. The bindings are saved as text records for easy maintenance.
An address conflict occurs when two hosts use the same IP address. During address assignment, DHCP checks for conflicts by using ping and gratuitous Address Resolution Protocol (ARP). If a conflict is detected, the address is removed from the pool. The address is not assigned until the administrator resolves the conflict.
Note We strongly recommend using database agents. However, the Cisco DHCP server can run without database agents. If you choose not to configure a DHCP database agent, disable the recording of DHCP address conflicts on the DHCP server by using the no ip dhcp conflict logging command in global configuration mode. If there is a conflict logging but no database agent is configured, bindings during a switchover are lost when a device reboots. Possible false conflicts can occur causing the address to be removed from the address pool.
DHCP Address Pools
You can configure a DHCP address pool with a name that is a string (such as “engineering”) or an integer (such as 0). Configuring a DHCP address pool also puts the device into DHCP pool configuration mode—identified by the (dhcp-config)# prompt—from which you can configure pool parameters (for example, the IP subnet number and default device list).
DHCP defines a process by which the DHCP server knows the IP subnet in which the DHCP client resides, and it can assign an IP address from a pool of valid IP addresses in that subnet. The process by which the DHCP server identifies the DHCP address pool to use for a client request is described in the Configuring Manual Bindings section.
The DHCP server identifies and uses DHCP address pools for a client request, in the following manner:
- If the client is not directly connected to the DHCP server (the giaddr field of the DHCPDISCOVER broadcast message is nonzero), the server matches the DHCPDISCOVER with the DHCP pool that has the subnet that contains the IP address in the giaddr field.
- If the client is directly connected to the DHCP server (the giaddr field is zero), the DHCP server matches the DHCPDISCOVER with DHCP pools that contain the subnets configured on the receiving interface. If the interface has secondary IP addresses, subnets associated with the secondary IP addresses are examined for possible allocation only after the subnet associated with the primary IP address (on the interface) is exhausted.
Cisco DHCP server software supports advanced capabilities for IP address allocation. See the Configuring DHCP Address Allocation Using Option 82 section for more information.
DHCP Address Pool with Secondary Subnets
Each subnet is a range of IP addresses that the device uses to allocate an IP address to a DHCP client. The DHCP server multiple subnet functionality enables a Cisco DHCP server address pool to manage additional IP addresses by adding the addresses to a secondary subnet of an existing DHCP address pool (instead of using a separate address pool).
Configuring a secondary DHCP subnetwork places the device in DHCP pool secondary subnet configuration mode—identified by the (config-dhcp-subnet-secondary)# prompt—where you can configure a default address list that is specific to the secondary subnet. You can also specify the utilization rate of the secondary subnet, which allows pools of IP addresses to dynamically increase or reduce in size depending on the address utilization level. This setting overrides the global utilization rate.
- If the DHCP server selects an address pool that contains multiple subnets, the DHCP server allocates an IP address from the subnets as follows:
- When the DHCP server receives an address assignment request, it looks for an available IP address in the primary subnet.
- When the primary subnet is exhausted, the DHCP server automatically looks for an available IP address in any of the secondary subnets maintained by the DHCP server (even though the giaddr does not necessarily match the secondary subnet). The server inspects the subnets for address availability in the order of subnets that were added to the pool.
Note If the giaddr matches a secondary subnet in the pool, the DHCP server allocates an IP address from that particular secondary subnet (even if IP addresses are available in the primary subnet and irrespective of the order of secondary subnets that were added).
The secondary subnet in the pool is supported only for directly connected clients. To avoid multiple IP address allocation from multiple subnets, you should configure secondary IP address on the interface connected to clients. Note that the secondary subnets should not be used in pools that are used for servicing requests from DHCP relay.
Manual Bindings
An address binding is a mapping between the IP address and MAC address of a client. The IP address of a client can be assigned manually by an administrator or assigned automatically from a pool by a DHCP server.
Manual bindings are IP addresses that are manually mapped to MAC addresses of hosts that are found in the DHCP database. Manual bindings are stored in the NVRAM of the DHCP server. Manual bindings are just special address pools. There is no limit to the number of manual bindings, but you can configure only one manual binding per host pool.
Automatic bindings are IP addresses that have been automatically mapped to MAC addresses of hosts that are found in the DHCP database. Because the bindings are stored in the volatile memory of the DHCP server, binding information is lost in the event of power failures or on device reloads. To prevent the loss of automatic binding information, a copy of the automatic binding information is stored on a remote host called the DHCP database agent. The bindings are periodically written to the database agent. When the device reloads, the bindings are read from the database agent to the DHCP database in the DHCP server.
Note We strongly recommend that you use database agents. However, Cisco DHCP server can function even without database agents.
Some DHCP clients send a client identifier (DHCP option 61) in the DHCP packet. To configure manual bindings for such clients, you must enter the client-identifier command with the hexadecimal values that identify the DHCP client. To configure manual bindings for clients that do not send a client identifier option, you must enter the hardware-address DHCP pool configuration command with the hexadecimal hardware address of the client.
Depending on your release, the DHCP server sends infinite lease time to the clients for which manual bindings are configured.
Depending on your release, the DHCP server sends lease time that is configured using the lease command to clients for which manual bindings are configured.
Note You cannot configure manual bindings within the same pool that is configured with the network command in DHCP pool configuration mode. See the Configuring DHCP Address Pools section for information about DHCP address pools and the network command.
DHCP Static Mapping
The DHCP Static Mapping feature enables the assignment of static IP addresses (without creating numerous host pools with manual bindings) by using a customer-created text file that the DHCP server reads. The benefit of this feature is that it eliminates the need for a long configuration file and reduces the space required in NVRAM to maintain address pools.
A DHCP database contains the mappings between a client IP address and the hardware address, which is referred to as a binding. There are two types of bindings: manual bindings that map a single hardware address to a single IP address, and automatic bindings that dynamically map a hardware address to an IP address from a pool of IP addresses. Manual (also known as static) bindings can be configured individually directly on the device or by using the DHCP Static Mapping feature. These static bindings can be read from a separate static mapping text file. The static mapping text files are read when a device reloads or the DHCP service restarts. These files are read-only.
The read static bindings are treated just like the manual bindings, in that they are:
- Retained across DHCPRELEASEs from the clients.
- Not timed out.
- Deleted only upon deletion of the pool.
- Provided appropriate exclusions for the contained addresses, which are created at the time of the read.
Just like automatic bindings, manual (or static) bindings from the static mapping text file are also displayed by using the show ip dhcp binding command.
To create a static mapping text file, input your addresses in the text file that is stored in the DHCP database for the DHCP server to read. There is no limit to the number of addresses that can be stored in the file. The file format has the following elements:
- Database version number
- End-of-file designator
- Hardware type
- Hardware address
- IP address
- Lease expiration
- Time the file was created
The following is a sample static mapping text file:
!IP address Type Hardware address Lease expiration
10.0.0.4 /24 1 0090.bff6.081e Infinite
10.0.0.5 /28 id 00b7.0813.88f1.66 Infinite
10.0.0.2 /21 1 0090.bff6.081d Infinite
Table 54-1 Static Mapping Text File Field Descriptions
|
|
---|---|
Specifies the time the file was created. This field allows DHCP to differentiate between the new and old database versions when multiple agents are configured. The valid format of the time is mm dd yyyy hh:mm AM/PM. |
|
Specifies the static IP address. If the subnet mask is not specified, a mask is automatically assigned depending on the IP address. The IP address and the mask is separated by a space. |
|
Specifies the hardware type. For example, type “1” indicates Ethernet. The type “id” indicates that the field is a DHCP client identifier. Legal values can be found online at http://www.iana.org/assignments/arp-parameters in the “Number Hardware Type” list. |
|
Specifies the hardware address. When the type is numeric, the type refers to the hardware media. Legal values can be found online at http://www.iana.org/assignments/arp-parameters in the “Number Hardware Type” list. When the type is “id,” the type refers to a match on the client identifier. For more information about the client identifier, see RFC 2132, DHCP Options and BOOTP Vendor Extensions, section 9.14, located at http://www.ietf.org/rfc/rfc2132.txt, or the client-identifier command. If you are unsure about the client identifier to match with the hardware type, use the debug dhcp detail command to display the client identifier being sent to the DHCP server from the client. |
DHCP Server Operation
By default, the DHCP server pings a pool address twice before assigning a particular address to a requesting client. If the ping is unanswered, the DHCP server assumes (with a high probability) that the address is not in use and assigns the address to the requesting client.
By default, the DHCP server waits for 2 seconds before timing out a ping packet.
You can configure the DHCP server to ignore and not reply to any BOOTP requests that the server receives. This functionality is beneficial when there is a mix of BOOTP and DHCP clients in a network segment and there is a BOOTP server and a Cisco DHCP server servicing the network segment. The BOOTP server is configured with static bindings for the BOOTP clients and the BOOTP clients must obtain their addresses from the BOOTP server. However, DHCP servers can also respond to BOOTP requests and the DHCP server may offer an address that causes the BOOTP clients to boot with the address from the DHCP server, instead of the address from the BOOTP server. Configuring the DHCP server to ignore BOOTP requests ensures that the BOOTP clients will receive address information from the BOOTP server and will not accept an address from a DHCP server.
Cisco software can forward these ignored BOOTP request packets to another DHCP server if the ip helper-address command is configured on the incoming interface.
Static Route with the Next-Hop Dynamically Obtained Through DHCP
Static routes are updated in the routing table when the default gateway is assigned by the DHCP server. These routes remain in the routing table until the DHCP lease expires and then the routes are removed.
When a DHCP client releases an address, the corresponding static route (the route configured using the ip route command) is automatically removed from the routing table. If the DHCP router option (option 3 of the DHCP packet) changes during the client renewal, the DHCP default gateway changes to the new IP address supplied after the renewal.
This feature is particularly useful for VPN deployments such as Dynamic Multipoint VPNs (DMVPNs). It is useful when a nonphysical interface, such as a multipoint generic routing encapsulation (mGRE) tunnel, is configured on a device and certain traffic must be excluded from entering the tunnel interface.
Note ● If the DHCP client is not able to obtain an IP address or the default device IP address, the static route is not installed in the routing table.
How to Configure the Cisco IOS DHCP Server
- Configuring a DHCP Database Agent or Disabling Conflict Logging
- Excluding IP Addresses
- Configuring Manual Bindings
- Configuring the DHCP Server to Read a Static Mapping Text File
- Customizing DHCP Server Operation
- Configuring a Remote Device to Import DHCP Server Options from a Central DHCP Server
- Configuring DHCP Address Allocation Using Option 82
- Configuring Static Route with the Next-Hop Dynamically Obtained Through DHCP
- Clearing DHCP Server Variables
Configuring a DHCP Database Agent or Disabling Conflict Logging
Excluding IP Addresses
The IP address configured on a device interface is automatically excluded from the DHCP address pool. The DHCP server assumes that all other IP addresses in a DHCP address pool subnet are available for assigning to DHCP clients.
You must exclude addresses from the pool if the DHCP server does not allocate those IP addresses to DHCP clients. Consider a scenario where two DHCP servers are set up for the same network segment (subnet) for redundancy. If DHCP servers do not coordinate their services with each other using a protocol such as DHCP failover, each DHCP server must be configured to allocate addresses from a nonoverlapping set of addresses in the shared subnet. See the Example: Configuring Manual Bindings section for a configuration example.
Configuring DHCP Address Pools
- Configuring a DHCP Address Pool
- Configuring a DHCP Address Pool with Secondary Subnets
- Troubleshooting Tips
- Verifying the DHCP Address Pool Configuration
Configuring a DHCP Address Pool
On a per-address pool basis, specify DHCP options for the client as necessary.
Before you configure the DHCP address pool, you must:
– Domain Name System (DNS) servers
– Network Basic Input/Output System (NetBIOS) name server
– Secondary subnets and subnet-specific default device lists (see Configuring a DHCP Address Pool with Secondary Subnets section for information on secondary subnets).
Note You cannot configure manual bindings within the same pool that is configured with the network DHCP pool configuration command. To configure manual bindings, see the Configuring Manual Bindings section.
Configuring a DHCP Address Pool with Secondary Subnets
For any DHCP pool, you can configure a primary subnet and any number of secondary subnets.
Troubleshooting Tips
If you are using secondary IP addresses under a single loopback interface and using secondary subnets under a DHCP pool, use one DHCP pool to configure networks for all the secondary subnets instead of using one pool per secondary subnet. The network network-number [ mask | / prefix-length ] [ secondary ] command must be configured under a single DHCP address pool rather than multiple DHCP address pools.
The following is the correct configuration:
ip dhcp pool dhcp_1
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0 secondary
network 172.16.3.0 255.255.255.0 secondary
network 172.16.4.0 255.255.255.0 secondary
!
interface Loopback111
ip address 172.16.1.1 255.255.255.255 secondary
ip address 172.16.2.1 255.255.255.255 secondary
ip address 172.16.3.1 255.255.255.255 secondary
ip address 172.16.4.1 255.255.255.255 secondary
The following is the incorrect configuration:
ip dhcp pool dhcp_1
network 172.16.1.0 255.255.255.0
lease 1 20 30
accounting default
!
ip dhcp pool dhcp_2
network 172.16.2.0 255.255.255.0
lease 1 20 30
accounting default
!
ip dhcp pool dhcp_3
network 172.16.3.0 255.255.255.0
lease 1 20 30
accounting default
!
ip dhcp pool dhcp_4
network 172.16.4.0 255.255.255.0
lease 1 20 30
accounting default
!
interface Loopback111
ip address 172.16.1.1 255.255.255.255 secondary
ip address 172.16.2.1 255.255.255.255 secondary
ip address 172.16.3.1 255.255.255.255 secondary
ip address 172.16.4.1 255.255.255.255 secondary
Verifying the DHCP Address Pool Configuration
Configuring Manual Bindings
You can determine the client identifier by using the debug ip dhcp server packet command. In the following sample output, the client is identified by the value 0b07.1134.a029:
Switch#
debug ip dhcp server packet
DHCPD:DHCPDISCOVER received from client 0b07.1134.a029 through relay 10.1.0.253.
DHCPD:assigned IP address 10.1.0.3 to client 0b07.1134.a029.
.
Configuring the DHCP Server to Read a Static Mapping Text File
The administrator must create the static mapping text file in the correct format and configure the address pools before performing this task.
Before editing the file, you must disable the DHCP server using the no service dhcp command.
The static bindings must not be deleted when a DHCPRELEASE is received or must not be timed out by the DHCP timer. The static bindings should be created by using the ip dhcp pool command.
Customizing DHCP Server Operation
Configuring a Remote Device to Import DHCP Server Options from a Central DHCP Server
The Cisco DHCP server can dynamically configure options such as the Domain Name System (DNS) and Windows Internet Name Service (WINS) addresses to respond to DHCP requests from local clients behind the customer premises equipment (CPE). Earlier, network administrators configured the Cisco DHCP server on each device manually. Now, the Cisco DHCP server is enhanced to allow configuration information to be updated automatically. Network administrators can configure one or more centralized DHCP servers to update specific DHCP options within the DHCP pools. The remote servers can request or “import” these option parameters from centralized servers.
Configuring the Central DHCP Server to Update DHCP Options
Configuring the Remote Device to Import DHCP Options
Perform the following task to configure the remote device to import DHCP options:
Note When two servers provide DHCP addresses to a single device configured with ip address dhcp on two different interfaces, the imported information is merged and, for those options that take a single value, the last known option value will be used.
Configuring DHCP Address Allocation Using Option 82
Enabling Option 82 for DHCP Address Allocation
By default, the Cisco DHCP server uses information provided by option 82 to allocate IP addresses. If the DHCP address allocation is disabled, perform the task described in this section to reenable this capability.
|
|
|
---|---|---|
|
||
|
||
|
||
Exits global configuration mode and returns to privileged EXEC mode. |
If DHCP classes are configured in the pool, but the DHCP server does not use the classes, verify if the no ip dhcp use class command was configured.
Defining the DHCP Class and Relay Agent Information Patterns
You must know the hexadecimal value of each byte location in option 82 to configure the relay-information hex command. The option 82 format may vary from product to product. Contact the relay agent vendor for this information.
Perform this task to define the DHCP class and relay agent information patterns.
Use the debug ip dhcp server class command to display the class matching results.
Defining the DHCP Address Pool
Configuring Static Route with the Next-Hop Dynamically Obtained Through DHCP
This task enables static routes to be assigned using a DHCP default gateway as the next-hop device. Without this feature the gateway IP address is not known until after the DHCP address assignment. You cannot configure a static route with the CLI without knowing that DHCP-supplied address.
Verify all DHCP client and server configuration steps. Ensure that the DHCP client and server are properly defined to supply a DHCP device option 3 of the DHCP packet.
Clearing DHCP Server Variables
|
||
|
Deletes an automatic address binding from the DHCP database. |
|
|
||
Configuration Examples for the Cisco IOS DHCP Server
- Example: Configuring a DHCP Database Agent or Disabling Conflict Logging
- Example: Excluding IP Addresses
- Example: Configuring a DHCP Address Pool
- Example: Configuring Manual Bindings
- Example: Configuring Static Mapping
- Example: Customizing DHCP Server Operation
- Example: Configuring a Remote Device to Import DHCP Server Options from a Central DHCP Server
- Example: Configuring DHCP Address Allocation Using Option 82
- Example: Configuring a Static Route with the Next-Hop Dynamically Obtained Through DHCP
Example: Configuring a DHCP Database Agent or Disabling Conflict Logging
The following example shows how to store bindings on host 172.16.4.253. The file transfer protocol is FTP. The server waits for 2 minutes (120 seconds) before performing database changes.
Example: Excluding IP Addresses
In the following example, server A and server B service the subnet 10.0.20.0/24. If the subnet is split equally between the two servers, server A is configured to allocate IP addresses 10.0.20.1 to 10.0.20.125 and server B is configured to allocate IP addresses 10.0.20.126 to 10.0.20.254.
Example: Configuring a DHCP Address Pool
In the following example, three DHCP address pools are created: one in network 172.16.0.0, one in subnetwork 172.16.1.0, and one in subnetwork 172.16.2.0. Attributes from network 172.16.0.0—such as the domain name, Domain Name System (DNS) server, (Network Basic Input/Output System) NetBIOS name server, and NetBIOS node type—are inherited in subnetworks 172.16.1.0 and 172.16.2.0. In each pool, clients are granted 30-day leases and all addresses in each subnetwork, except the excluded addresses, are available to the DHCP server for assigning to clients. The table below lists the IP addresses for the devices in three DHCP address pools.
Table 54-2 DHCP Address Pool Configuration
|
|
|
|
---|---|---|---|
Example: Configuring a DHCP Address Pool with Multiple Disjoint Subnets
Multiple disjoint subnets in a DHCP pool can be used in any of the following network topologies:
- IP address pooling—The DHCP client and server reside on the same subnet.
- DHCP relay—The DHCP client and DHCP server communicate through a DHCP relay agent where the relay interface is configured with secondary IP addresses.
- Hierarchical DHCP—The DHCP server is configured as the DHCP subnet allocation server. The DHCP client and DHCP subnet allocation server communicate through an on-demand address pool (ODAP) router.
In the following example, one DHCP address pool named pool3 is created; the primary subnet is 172.16.0.0/16, one secondary subnet is 172.16.1.0/24, and the other secondary subnet is 172.16.2.0/24.
- When IP addresses in the primary subnet are exhausted, the DHCP server inspects the secondary subnets in the order in which the subnets were added to the pool.
- When the DHCP server allocates an IP address from the secondary subnet 172.16.1.0/24, the server uses the subnet-specific default device list that consists of IP addresses 172.16.1.100 and 172.16.1.101. However, when the DHCP server allocates an IP address from the subnet 172.16.2.0/24, the server uses the pool-wide list that consists of the four IP addresses from 172.16.0.100 to 172.16.0.103.
- Other attributes from the primary subnet 172.16.0.0/16—such as the domain name, DNS server, NetBIOS name server, and NetBIOS node type—are inherited in both the secondary subnets.
- DHCP clients are granted 30-day leases on IP addresses in the pool. All addresses in each subnet, except the excluded addresses, are available to the DHCP server for assigning to clients.
The table below lists the IP addresses for the devices in the DHCP address pool that consists of three disjoint subnets.
Table 54-3 DHCP Address Pool Configuration
|
|
|
|
---|---|---|---|
Example: Configuring Manual Bindings
The following example shows how to create a manual binding for a client named example1.abc.com that sends a client identifier in the DHCP packet. The MAC address of the client is 02c7.f800.0422 and the IP address of the client is 172.16.2.254.
The following example shows how to create a manual binding for a client named example2.abc.com that does not send a client identifier in the DHCP packet. The MAC address of the client is 02c7.f800.0422 and the IP address of the client is 172.16.2.253.
Because attributes are inherited, the two preceding configurations are equivalent to the following:
Example: Configuring Static Mapping
The following example shows how to restart the DHCP server, configure the pool, and specify the URL where the static mapping text file is stored:
Switch#
configure terminal
Note The static mapping text file can be copied to flash memory on the device and served by the TFTP process of the device. In this case, the IP address in the original file line must be an address owned by the device and one additional line of configuration is required on the device:tftp-server flash static-filename.
The following sample output from the show ip dhcp binding command displays address bindings that are configured:
00:05:14:%SYS-5-CONFIG_I: Configured from console by console
Bindings from all pools not associated with VRF:
IP address Client-ID/ Ls expir Type Hw address User name
10.9.9.4/8 0063.7363.2d30.3036. Infinite Static 302e.3762.2e39.3634. 632d.4574.8892.
10.9.9.1/24 0063.6973.636f.2d30. Infinite Static 3036.302e.3437.3165. 2e64.6462.342d.
The following sample output displays each entry in the static mapping text file
*time* Jan 21 2005 22:52 PM
!IP address Type Hardware address Lease expiration
10.19.9.1 /24 id 0063.6973.636f.2d30.3036.302e.3437
10.9.9.4 id 0063.7363.2d30.3036.302e.3762.2e39.3634.632d Infinite
*end*
The following sample debug output shows the reading of the static mapping text file from the TFTP server:
Loading abc/static_pool from 10.19.192.33 (via Ethernet0):
[OK - 333 bytes]
*May 26 23:14:21.259: DHCPD: contacting agent tftp://10.19.192.33/abc/static_pool (attempt 0)
*May 26 23:14:21.467: DHCPD: agent tftp://10.19.192.33/abc/static_pool is responding.
*May 26 23:14:21.467: DHCPD: IFS is ready.
*May 26 23:14:21.467: DHCPD: reading bindings from tftp://10.19.192.33/abc/static_pool.
*May 26 23:14:21.707: DHCPD: read 333 / 1024 bytes.
*May 26 23:14:21.707: DHCPD: parsing text line
*time* Apr 22 2002 11:31 AM
*May 26 23:14:21.707: DHCPD: parsing text line ““
*May 26 23:14:21.707: DHCPD: parsing text line
!IP address Type Hardware address Lease expiration
*May 26 23:14:21.707: DHCPD: parsing text line
“10.9.9.1 /24 id 0063.6973.636f.2d30.3036.302e.3437”
*May 26 23:14:21.707: DHCPD: creating binding for 10.9.9.1
*May 26 23:14:21.707: DHCPD: Adding binding to radix tree (10.9.9.1)
*May 26 23:14:21.707: DHCPD: Adding binding to hash tree
*May 26 23:14:21.707: DHCPD: parsing text line
“10.9.9.4 id 0063.7363.2d30.3036.302e.3762.2e39.3634.632d”
*May 26 23:14:21.711: DHCPD: creating binding for 10.9.9.4
*May 26 23:14:21.711: DHCPD: Adding binding to radix tree (10.9.9.4)
*May 26 23:14:21.711: DHCPD: Adding binding to hash tree
*May 26 23:14:21.711: DHCPD: parsing text line “Infinite”
*May 26 23:14:21.711: DHCPD: parsing text line “”
*May 26 23:14:21.711: DHCPD: parsing text line
!IP address Interface-index Lease expiration VRF
*May 26 23:14:21.711: DHCPD: parsing text line “*end*”
*May 26 23:14:21.711: DHCPD: read static bindings from tftp://10.19.192.33/abcemp/static_pool.
Example: Customizing DHCP Server Operation
Example: Configuring the Option to Ignore all BOOTP Requests
The following example shows two DHCP pools that are configured on the device and that the device’s DHCP server is configured to ignore all received BOOTP requests. If a BOOTP request is received from subnet 10.0.18.0/24, the request will be dropped by the device (because the ip helper-address command is not configured). If there is a BOOTP request from subnet 192.168.1.0/24, the request will be forwarded to 172.16.1.1 via the ip helper-address command.
Example: Configuring a Remote Device to Import DHCP Server Options from a Central DHCP Server
Example: Importing DHCP Options
The following example shows how to configure a remote and central server to support the importing of DHCP options. The central server is configured to automatically update DHCP options, such as DNS and WINS addresses, within the DHCP pools. In response to a DHCP request from a local client behind CPE equipment, the remote server can request or “import” these option parameters from the centralized server. See the figure below for a diagram of the network topology.
Example: Configuring the Remote Device to Import DHCP Options
Example: Configuring DHCP Address Allocation Using Option 82
This example shows how to configure two DHCP classes. CLASS1 defines the group of DHCP clients whose address requests contain the relay agent information option with the specified hexadecimal values. CLASS2 defines the group of DHCP clients whose address requests contain the configured relay agent information suboptions. CLASS3 has no pattern configured and is treated as a “match to any” class. This type of class is useful for specifying a “default” class.
The subnet of pool ABC has been divided into three ranges without further subnetting the 10.0.20.0/24 subnet. If there is a DHCP Discover message from the 10.0.20.0/24 subnet with option 82 matching that of class CLASS1, an available address in the range from 10.0.20.1 to 10.0.20.100 will be allocated. If there is no free address in CLASS address range, the DHCP Discover message will be matched against CLASS2, and so on.
Therefore, each class in the DHCP pool will be examined for a match in the order configured by the user. In pool ABC, the order of matching is CLASS1, CLASS2, and finally CLASS3. In pool DEF, class CLASS2 does not have any address range configured. By default, the address range for a particular class is the pool’s entire subnets. Therefore, clients matching CLASS2 may be allocated addresses from 10.0.20.1 to 10.0.20.254.
Multiple pools can be configured with the same class, eliminating the need to configure the same patterns in multiple pools. For example, there may be a need to specify that one or more pools must be used only to service a particular class of devices (for example, cable modems and IP phones).
Example: Configuring a Static Route with the Next-Hop Dynamically Obtained Through DHCP
The following example shows how to configure two Ethernet interfaces to obtain the next-hop device IP address from the DHCP server:
Additional References for the Cisco IOS DHCP Server
Related Documents
|
|
---|---|
Standards & RFCs
|
|
---|---|
MIBs
|
|
---|---|
|
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Technical Assistance
Feature Information for the IOS DHCP Server
Table 4 lists the features in this module and provides links to specific configuration information.
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 Table 4 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.