The IOS DHCP Server in Depth

Most people configure an IOS DHCP server once, with three lines - network, default-router, dns-server - and never touch it again. That is fine until you need a switch to PXE-boot from a TFTP server, a phone to find its call manager, or a specific device to always get the same address. Then you discover the IOS DHCP server is a genuinely capable service with options, classes, and manual bindings that most engineers never use.

This article covers the IOS DHCP server in depth, with real lease output from a CML lab. For the fundamentals, see the IP services pillar.

The basic pool, and what it is actually doing

ip dhcp excluded-address 10.7.7.1 10.7.7.9
!
ip dhcp pool CLIENTS
 network 10.7.7.0 255.255.255.0
 default-router 10.7.7.1
 dns-server 10.7.7.1
 option 150 ip 10.7.7.200
 lease 0 0 10

From the lab, a client (R2) requested and got a lease:

R1#show ip dhcp binding
IP address    Client-ID/Hardware address    Lease expiration       Type       State    Interface
10.7.7.10     0063.6973.636f...             Jul 12 2026 09:27 AM   Automatic  Active   Ethernet0/3

R1#show ip dhcp pool CLIENTS
Pool CLIENTS :
 Total addresses    : 254
 Leased addresses   : 1
 Excluded addresses : 9
 10.7.7.11   10.7.7.1 - 10.7.7.254   1 / 9 / 254

show ip dhcp pool is the operational view you want - total, leased, and excluded counts, plus the current index (where the next lease will come from). The 1 / 9 / 254 reads leased / excluded / total. When a pool "runs out", this is where you see it.

The excluded-address is not optional discipline

ip dhcp excluded-address is easy to skip and painful to omit. The DHCP server will happily hand out the gateway's own address, or a static server's address, to a client - and then you have a duplicate-IP conflict that is maddening to diagnose. Always exclude the addresses you have assigned statically, including the gateway, DNS, and any servers in the subnet. Exclude a small range at the bottom (here .1 to .9) as a reservation for infrastructure.

DHCP options: the part that matters

The three basic parameters (default-router, dns-server) are themselves DHCP options with friendly IOS keywords. But many services need other options, and you configure those by number:

Option 150 TFTP server address (Cisco). Phones and switches use it to find their config/image server. option 150 ip 10.7.7.200.

Option 66 TFTP server name (the standard equivalent of 150). option 66 ascii tftp.example.com.

Option 43 Vendor-specific - used by Cisco APs to find a wireless controller, and by many vendors for bootstrap. Encoded as hex or type-length-value.

Option 82 Relay agent information (circuit/remote ID) - added by a relay, and the basis for DHCP snooping and class matching.

Option 150 in the lab (option 150 ip 10.7.7.200) is the classic case: it hands every client a TFTP server address, which is how a Cisco phone finds its call manager or a switch finds its boot image. When a device "boots but never finds its config", a missing or wrong option 150/66 is the usual cause.

DHCP classes: different options for different devices

A single subnet often has different device types that need different treatment - phones need option 150, PCs do not; a specific vendor's IoT needs option 43. DHCP classes let one pool serve them differently, matching on something in the request (commonly option 82's circuit-id, or the vendor class identifier option 60):

ip dhcp class PHONES
 option 60 hex 436973636f          ! match vendor-class "Cisco"
!
ip dhcp pool ACCESS
 network 10.7.7.0 255.255.255.0
 class PHONES
  address range 10.7.7.100 10.7.7.150
 class default
  address range 10.7.7.10 10.7.7.99

Now phones (identifying themselves via option 60) get addresses from one range, everything else from another - within the same subnet, from one pool. Classes are how you apply per-device-type policy without carving up subnets or running multiple pools per VLAN.

Manual bindings: a fixed address by identity

When a device must always get the same address - a printer, a server, a piece of network gear you manage by DHCP - you create a manual binding tied to its client identifier or MAC:

ip dhcp pool PRINTER-BINDING
 host 10.7.7.50 255.255.255.0
 client-identifier 0100.1122.3344.55       ! or hardware-address
 default-router 10.7.7.1

This is a DHCP reservation done the IOS way - a dedicated single-host pool matched to the client's identity. The device uses DHCP (so it is managed centrally, its options come from the server) but always receives 10.7.7.50. It combines the convenience of DHCP with the predictability of a static address, which is exactly what you want for infrastructure devices.

The subtlety: match on the client-identifier (option 61) if the client sends one, or the hardware-address if it does not. Cisco routers acting as clients send a client-identifier derived from the interface, which is why the lab binding above shows a long client-id rather than a plain MAC. Get the wrong one and the reservation never matches.

Lease time: shorter than you think for churn

The default lease is one day. That is fine for stable devices but wrong for high-churn environments - a guest network, a conference room, anywhere devices come and go. A too-long lease on a churny subnet exhausts the pool with dead reservations for devices that left hours ago.

lease 0 0 10       ! days hours minutes - here 10 minutes
lease 8            ! 8 days
lease infinite     ! never expires - only for truly static devices

The lab used a 10-minute lease to demonstrate churn behaviour. In production, match the lease to the dwell time: a day for offices, an hour or less for guest and public networks. lease infinite is a trap - it defeats the point of DHCP and slowly fills the pool; use a manual binding instead if you want a device to keep an address permanently.

VRF-aware DHCP

The IOS DHCP server is VRF-aware, which matters when you serve overlapping tenants (as in the VRF-aware NAT scenario). A pool bound to a VRF serves clients in that VRF's address space:

ip dhcp pool RED-POOL
 vrf RED
 network 10.5.5.0 255.255.255.0
 default-router 10.5.5.1
 option 150 ip 10.5.5.200

The vrf RED keyword scopes the pool. Two pools with the same network in different VRFs coexist happily - the DHCP server tracks bindings per VRF, so overlapping tenant DHCP works the same way overlapping tenant NAT does.

Troubleshooting

Clients not getting addresses? Check show ip dhcp pool for exhaustion, show ip dhcp conflict for detected duplicates, and confirm the relay path if the server is not on the client's subnet.
Device boots but finds no config/controller? A missing or wrong option (150/66 for TFTP, 43 for a WLC). show ip dhcp binding confirms it got an address; the option is a separate matter.
Duplicate IP conflict? A statically-assigned address was not excluded. show ip dhcp conflict, then add ip dhcp excluded-address.
A reservation not honoured? Wrong match type - client-identifier vs hardware-address. Cisco clients send a client-id; match that.
Pool exhausting on a busy subnet? Lease too long. Shorten it to the device dwell time.

Key takeaways

The IOS DHCP server does far more than the three basic lines. show ip dhcp pool (leased/excluded/total) and show ip dhcp binding are the operational views.
Always exclude statically-assigned addresses, or you get duplicate-IP conflicts.
Options drive the interesting behaviour: 150/66 (TFTP, for phones and boot images), 43 (vendor-specific, WLC discovery), 82 (relay info, basis for snooping and classes).
Classes let one pool serve different device types differently, matching on option 60/82.
Manual bindings give a device a fixed address by identity - a reservation the IOS way. Match on client-identifier for Cisco clients, hardware-address otherwise.
Set the lease to the device dwell time; short for guest/public, long for offices, infinite almost never.
The server is VRF-aware - a vrf keyword scopes the pool, so overlapping tenants work.