Configuring a DHCP Database Client

Problem

Solution

You can ensure your DHCP address assignments are not lost when a router reloads by configuring the router to periodically copy its DHCP database to a remote server.

The first example configures a router to use FTP to copy the DHCP database to a remote server:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp database ftp://dhcp:bindsave@172.25.1.1/dhcp-leases
Router1(config)#end
Router1#

The second example uses TFTP as the transport protocol:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp database tftp://172.25.1.1/dhcp-leases
Router1(config)#end
Router1#

And the third configures RCP as the transport protocol:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip dhcp database rcp://dhcp@172.25.1.1/dhcp-leases
Router1(config)#end
Router1#

Discussion

By default, the router stores its DHCP binding database in memory. So when the router reloads, all DHCP database information is lost. You can configure the router to periodically send a copy this database to a remote server to avoid losing this important information. If the router reloads for any reason, it will automatically load the last version of the database file from the remote server and proceed from where it left off.

In our example, we have configured our test router to store its DHCP database to the server at 172.25.1.1 via FTP. FTP uses a simple username and password authentication system, so we have included the userid dhcp and password bindsave in the command. After authenticating, the router will store its database in a file called dhcp-leases in the default directory for this userid. If you have multiple routers storing their databases to the same server, make sure to use a unique filename that includes the router name. This will assist in troubleshooting later.

Notice that the router is storing the database to the URL we specified, and that its last write was successful. The output also tells us that the router has successfully written its database to the server 30 times and only experienced a single failure. All of this indicates that the DHCP backup is working well. If we log on the server and view the contents of the database file, we will see the current DCHP bindings:

Freebsd% cat dhcp-leases
*time* Apr 09 2003 10:24 PM

!IP address     Type  Hardware address   Lease expiration
172.25.1.52     id    0100.50da.2a5e.a2  Apr 10 2006 09:00 PM
172.25.1.53     id    0100.0103.ea1b.ed  Apr 10 2006 08:58 PM

!IP address     Interface-index  Lease expiration       Vrf
*end*
Freebsd%

Fortunately, the file is a human-readable form and lets us see the latest DHCP bindings. Note that static address bindings are not sent to the remote database server, because they never change.

We will simulate a power failure by reloading the router:

Router1#show ip dhcp database 
URL      : ftp://dhcp:bindsave@172.25.1.1/dhcp-leases
Read     : Apr 10 2006 10:35 PM
Written  : Never
Status   : Last read succeeded. Bindings have been loaded in RAM.
Delay    : 300 seconds
Timeout  : 300 seconds
Failures : 0
Successes: 1

Router1#

Now when we display the database information, we see that the router successfully read the database from the server and loaded the bindings into memory. Viewing the router bindings now, you can see that the database has been recovered:

Router1#show ip dhcp binding 
IP address       Hardware address        Lease expiration        Type
172.25.1.33      0100.0103.85e9.87       Infinite                Manual
172.25.1.52      0100.50da.2a5e.a2       Apr 10 2006 09:00 PM    Automatic
172.25.1.53      0100.0103.ealb.ed       Apr 10 2006 08:58 PM    Automatic
Router1#

See Also