When I'm building an isolated network for a class, lab, or troubleshooting exercise, one of the first things I need is a DHCP server. Manually configuring an IP address on every device works, but it quickly becomes tedious and introduces opportunities for duplicate addresses, incorrect subnet masks, or simple typing mistakes. DHCP is particularly useful when the network contains laptops, smartphones, tablets, wireless devices, or other equipment that may be connected temporarily. A Cisco router can handle this job without requiring a separate DHCP server, which makes it a convenient option for small networks and lab environments.
The basic configuration is straightforward. First, create a DHCP address pool and specify the network from which addresses should be assigned. A simple example for a 192.168.10.0/24 network would look like this:
ip dhcp pool LAB-NETWORK
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
dns-server 192.168.10.1
The network command defines the subnet used by the pool, while default-router tells DHCP clients which gateway they should use. The dns-server command supplies the DNS server address to clients. Cisco's IOS documentation supports these commands as part of the DHCP pool configuration, along with additional options such as domain names, lease periods, boot information, and other DHCP options.
Before allowing the router to hand out addresses, it's also important to exclude addresses that are already being used by infrastructure devices. For example, if the router itself uses 192.168.10.1 and you want to reserve the first 20 addresses for switches, access points, servers, printers, or other equipment, you could use:
ip dhcp excluded-address 192.168.10.1 192.168.10.20
That prevents the DHCP service from assigning those addresses to clients. This is an important step because a DHCP server doesn't automatically know which addresses you have manually configured on other devices. Cisco also supports DHCP leases and additional pool options, so the configuration can be expanded as the network becomes more complex.
Once the configuration is in place, I always recommend verifying that the router is actually handing out addresses rather than simply assuming the configuration worked. Cisco provides commands such as show ip dhcp binding to display active DHCP bindings and show ip dhcp pool to show information about the configured pools and their utilization. You can also check the client itself to confirm that it received the expected IP address, subnet mask, default gateway, and DNS server. If clients aren't receiving addresses, check the interface status, VLAN configuration, DHCP pool network, and whether the DHCP request is actually reaching the router. In a switched network with multiple VLANs, remember that DHCP broadcasts normally don't cross Layer 3 boundaries without a DHCP relay configuration.
The nice thing about using a Cisco router as a DHCP server is that it provides everything needed for many small networks and training environments without adding another server to the lab. It is also a useful exercise because it demonstrates how DHCP options are actually delivered to clients rather than hiding the process behind a graphical configuration interface. If you're building a temporary test network, teaching networking fundamentals, or troubleshooting DHCP behavior, configuring the router yourself gives you a good opportunity to see exactly how the pieces fit together. And if something doesn't work, Wireshark can take the investigation one step further by letting you watch the DHCP Discover, Offer, Request, and Acknowledgment packets as they cross the network.
