[nsp] "ip dhcp database" issue

[Mark E. Mallett]

Hi-

We've got a cisco 7206 doing DSL aggregation using RBE with IP subnets
spanning multiple unnumbered ATM PVCs.  RBE will only install arp
entries when it seems a valid DHCP assignment fly by.  I configured
a dhcp database via "ip dhcp database" so that the arp entries
can survive a reboot.  So I have something like:

  ip dhcp database rcp://username@10.0.0.1/dhcp.database

In some initial tests a few weeks ago (before I had figured out
how to populate the database from IRB information) (*), this was
working fine.  But now on the production system with fully-populated
arp info, it is doing strange things.  "show ip dhcp database"
will say that the database has been written recently, but the
timestamp on the dhcp.database file on the server never gets
updated.  If I rename the file, the next time the router thinks
it has written the data successfully, I do see a new database file,
but it is zero length.

Is there an issue with this facility not being able to store more
than a small number of bytes via rcp?

I added a line like:

  ip dhcp database ftp://userx:password@10.0.0.2/dhcp.database

and THAT file is getting written just fine.  (So it's probably not
an issue with the data itself.)

And a related question: with both of those configuration entries
(ip dhcp database using rcp to one system, ftp to another), which
database will be chosen when the system reboots?  Will there be a
merge of the data?

I suppose I could just leave the ftp-style configuration.  Somehow
none of {tftp,rcp,ftp} seem ideal though.

Yours,
-mm-

(*)PS: I had wondered here a couple of weeks ago if there was a way to
populate RBE's arp cache from IRB information.  It's easy enough to
build a fake dhcp database file if one could only get the data.
Eventually I realized that I could get the data from "show bridge
verbose" (MAC address and interface) and "show ip arp" (MAC address
and IP address) and simply do a join to get IP address and interface,
then obtain the lease expire info from elsewhere.  And indeed that
worked fine.