Router Expert: IOS DHCP, part 2 -- Support options and configuration

Router Expert: IOS DHCP, part 2 -- Support options and configuration

Read about Michael

Last month we looked at the DHCP protocol and its component services. This month we will look at how to configure those services on Cisco routers running IOS, as well as some approaches for implementing DHCP on your network.

DHCP and Cisco routers?
By design, IP gateways depend on static L3 address assignments to function properly. So DHCP support in the IOS might seem odd at first. However, changes in networking design philosophy and network operational requirements driven by increases in hardware performance and application requirements have made DHCP support in the IOS as essential as the development and support of the protocol on the "systems" side of house. Realizing its value for network designers and administrators, Cisco has embraced DHCP by currently providing support for DHCP client, relay and server services in the IOS. DHCP relay support has been in place since IOS version 10.2 -- first in the form of explicit UDP port broadcast forwarding in 11.x, and later in a slightly more refined (but functionally identical) "default port forwarding" approach. IOS 12.0.1T introduced IOS DHCP server support, followed by client support in IOS 12.1x.

Configuring IOS DHCP relay services
The above statement with the term "broadcast forwarding" is not a typo. DHCP, IP multicast and a number of other applications depend on the use of network broadcast addresses for data exchange.

While IP addresses are expressed in "human terms" as Octal (0 to 255) and hexadecimal (0 to F) values, the computer sees IP addresses as binary (0 and 1) values. There are two IP broadcast addresses -- 0.0.0.0 (all zeros) and 255.255.255.255 (all ones). The current trend is to use a "ones broadcast" for addressing broadcast messages. Originally the "zeros broadcast" address was used. IP broadcasts are sent either as directed or flooded broadcast messages. Directed broadcast messages are sent to a specific group of hosts. A directed broadcast message will have a destination address containing the network or subnet prefix and ones or zeros in the host portion address. For example, a directed broadcast destination address for the network address 147.225.128/24 would look like 147.225.128.0 or 147.225.128.255. A flooded broadcast message will have a destination address of all zeros (0.0.0.0) or all ones (255.255.255.255).

In order for applications and services that depend on the use of IP broadcasts to exchange messages between clients and servers in routed environments, UDP broadcast forwarding needs to be enabled. The idea of forwarding any broadcasts, especially UDP broadcasts, does not sit well with some network and security administrators. For starters, it's just contrary to what routers are for -- they ROUTE packets between subnets and (typically) do not BRIDGE subnets. But when you enable broadcast forwarding, you're basically implementing a broadcast bridge.

Then there is UDP, which is a connectionless "datagram" transport protocol. Every UDP datagram is an island -- an autonomous request or reply message with little error checking or control capability. Once the message is sent, it may or may not be delivered. Any host running a UDP-based service has very little in terms of local control when it comes to verifying message integrity or access restriction. The recipient host is "open" once the UDP service is active, because there is no connection state with UDP. Forwarding broadcasts using a connectionless transport protocol is basically a network administrator's nightmare because it leaves the network open to the potential for broadcast storms and various denial-of-service attacks.

Once you are sure that you want to implement DHCP relay services on your routers, you can tackle how to do it. DHCP relay support (a.k.a. broadcast forwarding) is enabled using the interface configuration command <ip helper-address {server address}>. When it was first introduced, this option was supported by the global configuration command <ip forward-protocol udp {port number}>, which was used to declare what UDP ports were forwarded. Today's iteration of the command implements broadcast port forwarding for the following UDP services by default:

         TFTP -- Trivial File Transfer Protocol, UDP port 69
         DHCPC -- DHCP Client, UDP port 67
         DHCPS -- DHCP Server, UDP port 68
         TIME -- Timeserver, UDP port 37
         TACACS -- AAA service, UDP port 49 (not TACACS+ which uses TCP)
         DNS -- Domain Name Service, UDP port 53 (resolver service only)
         NetBIOS -- DATAGRAM Service, UDP port 138
         NetBIOS -- Name Service, UDP port 137 (WINS)

While the "default forward" approach is supposed to be simpler then the earlier IOS approach to enable DHCP relay services securely, there is some tightening needed as far as what you will permit to forward. This is accomplished using the no form of the global configuration command <ip forward-protocol udp {port number}>. Here is a configuration example for enabling DHCP relay services:

CC2217919-C(config)#no ip forward-protocol udp 37
CC2217919-C(config)#no ip forward-protocol udp 53
CC2217919-C(config)#no ip forward-protocol udp 138
CC2217919-C(config)#no ip forward-protocol udp 69
CC2217919-C(config)#no ip forward-protocol udp 137
CC2217919-C(config)#no ip forward-protocol udp 49
CC2217919-C(config)#interface Fast Ethernet 0/0
CC2217919-C(config-if)#ip address .30.40.1 255.255.255.0
CC2217919-C(config-if)#ip helper-address 172.16.104.28
CC2217919-C(config-if)#exit
CC2217919-C(config)# ^Z

In this example, the addressed Fast Ethernet interface will forward any DHCPS or DHCPC broadcasts to the DHCP server 172.16.104.28, and any other UDP broadcast will be ignored.

Configuring IOS DHCP client services
Should you use DCHP to configure your router interface? It sounds odd at first, but when you get down to it, it's not that odd. DHCP is often thought of as just a way to dynamically assign IP addresses to hosts -- a task that it does very well -- but DHCP is really a lot more. It is a mechanism for managing IP configurations by enabling an administrator to propagate changes in the network's configuration without having to directly administer the end device. Initially, DCHP client support was only available for Ethernet interfaces, IOS version 12.2.8T, and later supported DHCP client services on ATM interfaces. For environments requiring dynamic addressing for serial links, PPP provides address negotiation support. In traditional LAN environments, the value of using DHCP for interface configuration is questionable, but does minimize configuration mistakes and make changes very easy to implement. Remote access and stub office network access routers utilizing cable or xDSL broadband connections that use DHCP or address allocation and authentication are typical scenarios for utilizing IOS DHCP client support.

Configuring DHCP client support is simple, implemented as an additional option to the IOS interface configuration sub command <ip address {Octal Address Octal Mask | dhcp | pool}>. Here is an example of the basic configuration syntax:

core(config)#
core(config)#int fa 0/1
core(config-if)#ip address dhcp

When using the default configuration, the router's global hostname is sent as part of the DHCPDISCOVER message using the hostname option (ID 12). The client ID option (ID 61) will be set using a combination of "cisco" and the interface Media Access Control (MAC) address and the ASCI abbreviation of the router interface generating the client request. The client ID of the example above would be "cisco-MAC address-fa0/1." Many broadband providers utilize the hostname or client ID options for address allocation. Typically, the ISP-provided hostname is some cryptic string of ASCI characters. To specify the value sent in the hostname option field, use the keyword <hostname {ASCII text}>. Additionally, the client ID can be set to only the MAC by following the <ip address dhcp> statement with the keyword <client-id {interface}>. The interface value specifies the router interface MAC address to be sent. Here is another example utilizing the hostname and client ID options:

core(config)#
core(config)#int fa 0/1
core(config-if)#ip address dhcp client-id FastEthernet0/1 hostname XXO65790
core(config-if)#exit

Once the router's interface has been configured, the address assignment is not visible in the running config. The IP address assignment can be viewed using the <show ip interface> or <show interface> exec commands. Here is some partial output from the <show ip interface> command:

core#sh ip interface 
Fast Ethernet0/1 is up, line protocol is up
 Internet address is 147.225.1.195/24
 Broadcast address is 255.255.255.255
 Address determined by DHCP
 MTU is 1500 bytes
 Helper address is not set
 Directed broadcast forwarding is disabled
 Outgoing access list is not set
 Inbound access list is not set
 Proxy ARP is enabled
 Local Proxy ARP is disabled

Configuring IOS DHCP server services
The router can also be used as a DHCP server -- now that makes sense. The router is perfect for this function, because it is directly connected to some or all of the "serviced" networks, functions as an "essential service" component, and plays a critical part of the network security infrastructure.

Traditionally, the DHCP server is run on a "server class" system. Providing DHCP service is not a particularly taxing function, but it is a quite essential one. It is typically coupled with other services to maximize the utility of the server. With the use of DHCP relays, this approach scales well in a campus or large-scale office environments. It falls short in large scale WANs, however, because running DHCP relay services over WAN and VPN links is not ideal from a performance and reliability perspective. With the IOS DHCP server, you can put that expensive server to good use doing something else. And if you have two local routers (you have a backup link, right?), you have your primary and backup DHCP servers already.

Configuring the IOS DHCP server is a straightforward process. Implementing the IOS DHCP server is slightly more involved. First, for the router to function as a DHCP server (or relay, for that matter), the service must be enabled. The global configuration command <service dhcp> enables DHCP services. This is active by default on most routers; if your router is not going to function as a DHCP server or relay, the service should be disabled using the configuration command <no service dhcp>.

P-Router(config)#service dhcp

With the service active, the first configuration step is to create a "DHCP pool," also referred to as a "scope." A pool definition can be created for a single address, for a static address allocation, or for a range of addresses for dynamic allocation. Both definitions are created using the configuration command <ip dhcp pool {pool name}>. The pool name can be one or more ASCII characters. Once the pool definition is set, the host address to network needs to be defined. A network is defined using the dhcp pool command <network>. The fill syntax is: <network {network address} {prefix or network mask}>. The network address and network mask statements are entered using dotted quad notion. The CIDR prefix option is the number of "ones" in the network mask expressed as an integer, following the network address statement with a forward slash "/" before the prefix value. Here are examples of both methods:

P-Router(dhcp-config)#network 10.100.40.0 /24
P-Router(dhcp-config)#network 10.100.40.0 255.255.255.0

P-Router(dhcp-config)# host 10.100.40.5 255.255.255.0
P-Router(dhcp-config)# host 10.100.40.5 /24

Technically, the network/host address allocation is the only required pool value needed for the DHCP server to work. But hosts cannot function on addresses alone. So additional pool attributes (i.e. subnet mask, default gateway, DNS server, etc.) need to be defined. The IOS DHCP server supports a number of the RFC defined options. Their configuration values and function descriptions are listed here:

<bootfile> - This defines the bootimage to download, which needs to be stored on the IOS file system. This command is required for legacy support of diskless workstations that use BOOTP to boot. The command syntax is <bootfile {ASCII file name}>.

<client-identifier> - RFC 2132-compliant DHCP client implementations (i.e., Windows NT, Red Hat 7.x and 8.x, and OS X) use the client ID DHCP option as the unique host identifier over the MAC address. The advantage of using the client ID over a hardware address is that it allows a user to change network adapters and still get the same static IP address. If left unconfigured, default client ID values send the client adapter's MAC address preceded with a media type code: Ethernet = 01, IEEE 802 = 06, ATM = 16, Frame Relay = 15. On most clients, the custom client ID is set as an ASCII value and transmitted to the DHCP server as a hexadecimal value. On OS X and Red Hat 7/8 systems, the client ID is set as part of the DHCP client configuration. On Windows NT/2000 systems, a registry edit is needed to set the client ID. The client ID is configured using hexadecimal dotted quad notation. To configure a client ID using the MAC address, use the command format <client-identifier MTXX.XXXX.XXXX.XX>, where "MT" equals the media type code, followed by the MAC address. Custom values are also entered using hex dotted quad, so you will need to convert the ASCII string into hex and then enter the translated value.

<hardware-address> - RFC 1541-complaint clients (i.e., Red Hat 6.x/ Windows 3.x/95) send the MAC address as the unique host identifier. The hardware address is entered as a dotted quad hex value using the following syntax <hardware-address XXXX.XXXX.XXXX>.

<default-router>; (DR) - This sets the local subnet default route. A single entry is needed, but up to eight DR values can be set. This allows administrators to create redundant gateways and configure the end-station clients to use them if they support gateway failure detection. Windows systems can be configured to use multiple interfaces, each with discrete default gateways. Windows will select a "primary" interface and use that until it fails (i.e. hardware failure). If a secondary interface is active and has a DR set, the system deletes the failed entry and the secondary will become active. Linux systems require some additional scripting to take advantage of secondary gateways, but support having multiple default gateways. The DR syntax is <default-router {GW1 – GW8}>; the gateways are entered in dotted quad with a space between each entry.

<dns-server> - This sets the client's Domain Name Service (DNS) resolution servers. One entry is needed, but up to eight can be entered. The command syntax is <dns-server {DNS1 – DNS8}>; each entry is entered as a dotted quad address, separated by a space between each entry.

<domain-name> - This sets the client's domain name. The domain name value is needed in order for "short name" DNS queries to resolve properly. The command syntax is <domain-name {ASCII text}>. The domain name value can contain one or more sub-domains, each separated by a period, ending with the proper domain type (i.e., .net, ,com, .edu, etc.) descriptor.

<client-name> - This sets a searchable string value for the client as an alternative to using the IP address. The syntax for setting the client name is <client-name {ASCII text}>. Only the unqualified hostname should be set.

<netbios-name-server> - Windows NT/95/98 systems use NetBIOS for computer name resolution for Server Message Block (SMB) file and print servers and peer to peer file sharing. To resolve hosts that are not local, the Windows Internet Naming Service (WINS) is used to resolve NetBIOS names into IP addresses. Microsoft DHCP clients look for WINS servers as part of the address request. To configure a WINS server value, use the following syntax: <netbios-name-server {S1 – S8>. Only one entry is needed, and up to eight can be defined. Each entry is in dotted quad separated by a single space.

<netbios-node-type> - Windows NT/95/98 systems can use a broadcast query, WINS, or a locally stored lmhosts file to resolve NetBIOS names. One or all resolution methods can be defined, along with the order in which they are used. To set the host's node type, use the command syntax <netbios-node-type {b-node} {p-node} {m-node} {h-node} {hex value}>. Only one type of value may be defined. If you wish, you could enter the hexadecimal equivalent of the node definition in place of one of the defined options.

<lease> - The IOS DHCP server supports the T1 (renewal, sent 1/2 of the T lease time) and T2 (rebinding, sent 3/4 of the T lease time) timers defined in the RFC. The default lease file is 24 hours. The lease time can be defined in days, hours, and/or minutes. The command syntax is <lease {D:H:M} {infinite}>. Alternatively, a lease can be permanently assigned by defining the lease period as infinite. While that option does allow for permanent address assignments, its random nature makes for administration problems.

<option> - In addition to the defined DHCP options, it is possible to set additional DHCP options using the <option> command. The syntax is <option {0 –254} {ascii|hex|instance|ip} {value}>. The first field defines the DHCP option code, the second field defines the data value type, and the third field is the configuration data.

To leave the DHCP config mode, type <exit>. As with all other IOS commands, a <no> proceeding any command disables or deletes the statement. Here is a complete "dialog" example for both a dynamic and static pool configuration:


P-Router(config)# ip dhcp pool R&D
P-Router(dhcp-config)#network 10.100.40.0/24
P-Router(dhcp-config)#default-router 10.100.40.1 10.100.40.2
P-Router(dhcp-config)# domain-name r-d.anycompany.com
P-Router(dhcp-config)# lease 0 3 59
P-Router(dhcp-config)# dns-server 10.100.32.254 10.100.45.129
P-Router(dhcp-config)# netbios-name-server 10.100.31.10 10.100.60.100
P-Router(dhcp-config)# netbios-node-type h-node
P-Router(dhcp-config)#exit 
P-Router(config)#ip dhcp pool r-d-fileserver
P-Router(dhcp-config)#host 10.100.40.5 255.255.255.0
P-Router(dhcp-config)#client-name rd-fs
P-Router(dhcp-config)#client-identifier 0100.07e9.c464.15
P-Router(dhcp-config)#exit

The above example configures both a dynamic pool and a static host binding assignment. Notice that only the client ID and client name options have been set for the host pool entry. Unless a specified alternative is set, a host pool will inherit the options defined in the dynamic pool statement of the same network prefix. This simplifies the creation of host entries and does not clutter up the router configuration with unneeded, redundant information.

Now that our DHCP pool has been created, we need to get the server into a supportable state. For the DHCP server to work properly, it needs to keep track of the bindings it allocates (make sure that it does not allocate addresses that have been statically assigned outside of its scope), retract and renew leases when they expire, and detect and resolve address conflicts.

The first step is to configure timestamps for logging messages and configure the router's clock. In order to do this, we need to enable the timestamp service, set the router's time zone and configure the router to use the Network Time Protocol. Here is the configuration dialog for these steps:

P-Router(config)#service timestamps log datetime localtime show-timezone
P-Router(config)#clock timezone EST –5
P-Router(config)#clock summer-time EDT recurring
P-Router(config)#ntp server 17.254.0.31
P-Router(config)# ntp source Ethernet0

The <service timestamp> command sets the logging parameters for log and debug announcements. The example above set the options for logging only, but it's a good idea to set both. The <clock timezone> command asks you for the correct three-letter time zone abbreviation followed by UTC offset (the example shows the UTC offset for the U.S. Eastern Seaboard). The <clock summer {TZ} recurring> configures the router to account for daylight savings time. Enabling NTP on the router only requires the <ntp server {x.x.x.x}> value to be configured. The <ntp source {int}> configures the IP address the NTP request comes from. This is only needed if the NTP server uses authentication or filters its sync requests.

Once the elements needed to support conflict logging and lease management have been configured, it is time to configure conflict logging and lease management. By default, a DHCP pool will allocate all of the addresses within the scope. To avoid conflicts, it is a good idea to define which addresses should not be allocated. This is done using the <ip dhcp excluded-address {low_addr high_addr}> configuration command. The command can set a range of addresses or a single address that should be excluded from allocation. (If you are using static allocations they should be excluded from the dynamic pool with this command.) Here is a syntax example:

P-Router(config)# ip dhcp excluded-address 172.30.71.1172.30.71.10
P-Router(config)# ip dhcp excluded-address 172.30.71.240172.30.71.254
P-Router(config)# ip dhcp excluded-address 172.30.71.144

The "range" statements exclude the bottom 10 addresses and the top 14 addresses from the dynamic pool 172.30.71.0/24. The "single" exclude statement removes the address from the dynamic pool so that it can be statically allocated.

The router keeps track of all dynamic allocations in the DHCP bindings database, which is stored on the router and is viewable using the exec command <show ip dhcp bindings>. Here is an output example:

P-Router #sh ip dhcp binding 
Bindings from all pools not associated with VRF:
IP address    Hardware address    Lease expiration    Type
172.16.1.10   0000.d1ed.6c49     Infinite        Manual
172.16.1.100   6f72.696f.6e      Infinite        Manual
172.16.1.101   756e.6465.7267.726f.  Infinite        Manual
         756e.64
172.16.1.105   0000.861b.38f3     Infinite        Manual
172.30.71.4   0100.022d.01de.dc    Infinite        Manual

The bindings database can be cleared using the exec command <clear ip dhcp bindings {* | X.X.X.X>. The bindings database is stored in DRAM, so if the router is rebooted, dynamic allocations are lost. The bindings database can be written to one or more remote sources, using TFTP, RCP, SCP, HTTP, or FTP. The global configuration command is <ip dhcp database {URL://username:password@host_addr/filename}>. The transfer method is defined using the Universal Resource Locater format; a username and password only need to be defined for protocols that require them. Here is a syntax example:

P-Router(config)#ip dhcp database scp://dhcp:ciscodhcp@172.30.71.6/dhcp

The IOS DHCP server performs address conflict checking prior to allocating a dynamic address. This is achieved by the "server" sending a number of ICMP echo messages (pings) to an allocation candidate. If no reply is received within a specified period, the address is assigned. If a conflict is detected, the address is logged to the conflict database (stored on the router in DRAM) and removed from the dynamic address pool. The address will remain out of circulation until the conflict is resolved. Conflict logging is enabled by default. To view the database, use the exec command <show ip dhcp conflict>. The number of ICMP echo messages and the timeout for the expected ICMP echo-reply messages are set using the configuration commands <ip dhcp ping packets {0-10}> and < ip dhcp ping timeout {100 – 10000ms)>. The default is one ICMP echo with a 100-ms timeout.

Commands for checking service operation and debugging are also available. To check on the DHCP server operational stats, use the command <show ip dhcp server statistics>. This provides details on memory usage, number of DHCP messages received and sent, current number of bindings, etc. There are two debug command sets for DHCP. To debug client issues, use the command <debug dhcp detail>. To debug server issues, use the command <debug ip dhcp server {events | packet | linkage}>. The events mode provides operational information, packet mode provides DHCP message decoding, and linkage mode provides details on the bindings database. For more information on IOS DHCP server configuration, you can consult the documentation on the Cisco Web site.

DHCP implementation strategies
We all have pet peeves. DHCP abuse is one of mine. Before you go tend to your next network problem, hear me out about how you should implement DHCP.

There are three address allocation methods defined in the RFC. While the "dynamic" approach gets the hosts on the network, that's about all it does, and it is insecure to boot. The "automatic" and "manual" methods really empower the administrator.

Your firewall and intrusion detection systems all track by IP address. So if you just dole out IP addresses, how do you know who is using what address? Chances are that if you are simply assigning IP addresses, you are probably not keeping track of the MAC addresses of each system on the network. In the event that you have an incident and you are asked to look at the logs and find out who did what, you can look at the DHCP binding logs and match up the hardware address to the IP lease. Once you pinpoint a MAC address that may be responsible for the incident, you have to hunt down where that MAC is on the network. If you have a switched network this is possible, but certainly a pain. If you have shared media, good luck.

Here is a little food for thought on how you should be implementing DHCP. Unless you have implemented IEEE 802.1x, your network is open. All someone needs is an open network port or an unsecured wireless access point to get on your network. The more sane and secure approach requires a little more work up front, but pays back big when you need it. The secure way to implement DHCP is to statically assign addresses to hosts and have the server provide the configuration to the clients. While dynamic address allocation is a big part of DHCP, the ability to change client addresses, DNS servers, default gateways, WINS servers, etc. is also just as important. These are the network resources that most often change, and when they do they make problems for you. There are a number of ways to implement DHCP securely. Like most things in networking, there is no real "right way," so we will look at a couple of approaches that may help you determine what works for your environment.

The automatic approach
Set up an address pool for each network, reserving the top 10 and bottom 10 addresses for buffer and special use. Configure the server to never expire the leases. Apply an outbound SACL on each subnet's gateway interface. As new systems are added to the subnet, the users inform the help desk of their IP assignment. Once verified, the address is added to the ACL. The leases are permanent, so as long as the user does not change their network card they have access. If they do change their network card, they of course need to register and you will have to purge the old binding from the DHCP bindings database. This approach works well if you administer the DHCP server and the router. If management is split, then some coordination is needed, which can result in wait time for your user. A modification of this approach is to permit some basic service access with application and patch installers. This way the user (or support staff) can get resources they need to get their system up and running, but your network is not potentially exposed.

The manual approach
Just as you did with the auto approach, set up the pools and reserve some addresses. This method requires that the user is assigned a client ID or the MAC address of the host is provided before the host connects to the network. For each host, a lease is configured on the DHCP server using the hardware address or client ID as the binding value. If no lease is configured, there is no access to the network. A modification of this approach is to allocate a small dynamic address pool with limited network access so that users and support staff can get access to patches and application installers and the Internet. (For additional security, use a secondary interface on the router and have the dynamic pool allocate addresses different from those being assigned to the permanent users.) This helps if you have transit or guest users who just need Internet access for VPN clients, or if a user needs to get his host up and running and did not request a lease in time. The bonus with this approach is that the filtering on the router just needs to be in place to limit access for the dynamic pool. All of the other modifications are done on the DHCP server, accommodating environments where administrative responsibilities are diffused across support groups.

Regardless of the approach, both scenarios give the administrator better control and visibility to the subnets being administered. That makes configuration changes easy to implement with little or no impact on the user.

Click here for part 1 and learn about DHCP from a practical hands-on viewpoint with the information you need to support and implement DHCP services in an IOS environment.

Was this article helpful to you? Do you have suggestions for topics you'd like to see covered? Please e-mail us and let us know!

This was first published in January 2003

Dig deeper on Network Management Software, Tools and Utilities

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close