Running a DHCP server on a Cisco router can be perfectly reasonable for a small site, a lab, a branch, or an isolated network. It becomes unpleasant when the router reboots and clients that previously had stable leases receive different addresses—or the pool fills with false conflicts because the server lost its history.
Cisco IOS and IOS XE call the persistent binding store a DHCP database agent. It records automatic lease bindings outside the router’s working memory, so the DHCP service can reload that history after a restart. This is not merely about keeping a printer on the same address. It protects the DHCP server’s view of which addresses are in use and reduces avoidable recovery work after a reboot.
What the DHCP database stores
An automatic binding associates a client with an address and lease details. On supported Cisco platforms, the database can hold information such as lease expiration, interface context, and VRF details. IOS XE documents database agents as either remote hosts—such as FTP, TFTP, or RCP services—or supported local storage media.
That means the old advice to write a file to nvram: is not a universal answer.
Some devices may support local flash or disk storage, some may not support the
same URL syntax, and embedded storage has wear, capacity, and recovery
tradeoffs. Check the command reference for the exact model and release before
choosing a destination.
Start with the recovery requirement
Ask two questions before configuring anything:
- How disruptive is it if this router loses lease history after a reboot?
- Can the router reliably reach a protected storage service during startup and while serving clients?
For a low-stakes lab, volatile leases may be acceptable. For a branch with a small pool, phones, printers, and appliances, preserving bindings is usually worth the modest complexity. If the router cannot rely on a remote service, local storage may be the better availability choice—but only if the platform supports it and the operational team monitors it.
The current Cisco IOS XE DHCP server guide strongly recommends database agents. It also warns that if you choose not to configure one, conflict logging should be disabled; otherwise conflict records can survive in a way that leads to false conflicts after a reboot.
Configure a database agent deliberately
The general syntax is:
ip dhcp database URL [timeout seconds | write-delay seconds]
For example, a router that is authorized to write to a protected FTP service might use a URL like this:
configure terminal
ip dhcp database ftp://dhcpwriter:REDACTED@192.0.2.50/branch-a-dhcp timeout 80
end
Do not copy credentials into a shared change record or article. Use the credential-management method supported by the platform and your operations standards. If a remote database agent is used, also verify DNS or routing, firewall policy, authentication, file permissions, and the startup-time path. A database destination that is reachable only after the router has already failed over to a degraded state is not much of a recovery plan.
write-delay is a tradeoff. A short delay writes lease changes more promptly
but creates more database activity. A longer delay reduces write frequency but
increases the amount of recent lease state that can be lost in an abrupt failure.
Choose the value from client churn, storage characteristics, and the acceptable
recovery window—not from a copied example.
Verify the write, not just the configuration line
After adding a database agent, generate a known lease with a test client and inspect both the lease table and database-agent status:
show ip dhcp binding
show ip dhcp pool
show ip dhcp database
show ip dhcp conflict
show ip dhcp server statistics
show ip dhcp database is the important confirmation. Look for a successful
write, a sensible URL, a recent timestamp, and no accumulating failures. Seeing
the ip dhcp database line in the configuration proves only that the router
will try; it does not prove it can reach or write the destination.
Then perform a controlled reboot test when the change window allows it. Confirm the database is read, bindings are restored, the test client renews normally, and the pool does not show unexpected conflicts. This is one of the rare cases where a planned reboot is cheaper than learning about recovery during an outage.
Common mistakes
- Using unsupported local storage. A URL that looks plausible can still be unsupported or unreliable on the installed platform.
- Ignoring write failures. A protocol or permission error means the router is effectively running without persistence until it is fixed.
- Leaving conflict logging enabled without an agent. Cisco warns this can create false conflicts after a reboot.
- Treating the database as DHCP failover. A database agent preserves local state; it does not create a coordinated redundant DHCP service.
- Storing secrets in plain-text documentation. Use approved credential controls and protect the database endpoint like other infrastructure data.
If you do not need persistence
If this router is intentionally a disposable DHCP server and you do not configure a database agent, consider the documented companion setting:
configure terminal
no ip dhcp conflict logging
end
That is not a substitute for a database agent on a network where address continuity matters. It simply avoids keeping conflict state that the router cannot reconcile after a reboot.
A small service deserves a real recovery story
DHCP is foundational even when the implementation is small. A database agent, successful-write checks, and one controlled reboot test make router-hosted DHCP much less surprising. Pick a destination your platform supports, monitor it, and test restoration before an outage forces the lesson.
For DHCP fundamentals, read Demystifying DHCP: A Network Engineer’s Guide. For more networking and systems notes, visit Slaptijack.
