> ## Content Index
> Fetch the complete content index at: https://www.pinglabz.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# The IOS DHCP Server in Depth: Options, Classes, and Manual Bindings
- URL: https://www.pinglabz.com/ios-dhcp-server-in-depth/
- Published: 2026-07-12T09:34:24.000Z
- Updated: 2026-08-24T05:13:22.000Z
- Description: The IOS DHCP server does far more than network, default-router, dns-server. This article covers options for PXE boot and phones, DHCP classes, and manual bindings, with real lease output from a CML lab.
- Author: Jaime
- Tags: IP Services, Labs, CCIE, #Import 2026-08-01 19:54

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](https://www.pinglabz.com/ip-services/).

## 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](https://www.pinglabz.com/dhcp-snooping-in-depth/) 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 behavior. 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](https://www.pinglabz.com/vrf-aware-nat-ios-xe/) 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

1. **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.
2. **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.
3. **Duplicate IP conflict?** A statically-assigned address was not excluded. `show ip dhcp conflict`, then add `ip dhcp excluded-address`.
4. **A reservation not honoured?** Wrong match type - client-identifier vs hardware-address. Cisco clients send a client-id; match that.
5. **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 behavior: 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.

Next: [SNMPv3 in production - users, groups, views, traps, and informs](https://www.pinglabz.com/snmpv3-traps-informs/). The full cluster index lives on the [IP services pillar](https://www.pinglabz.com/ip-services/).