I doubt if that will happen. But you can write the lease information ( automatic bindings) to a tftp/ftp server and make the second router also read and write the database information from that server.
Again i m not 100 percent sure about this feature working the way i said. Command used is.
ip dhcp database url [timeout seconds | write-delay seconds]
Also, DHCP will be forwarding (or serving) on both routers if configured for it. DHCP requests are broadcasts and HSRP only listens to / forwards unicast traffic sent to the active HSRP address directly.
For example, if you have 3 routers on a subnet and all of them have ip-helper configured to forward to a DHCP server all 3 routers will forward DHCP requests.
I gather the original post was curious as to how to handle it if the DHCP was specifically handled locally on the multiple router interfaces, not forwarded on to the DHCP servers elsewhere. Depending on the size of the network, there would likely be great advantage to doing the latter.
If the DHCP server was only set up on the HSRP router interface with the highest priority (ie - the one that is active under normal conditions when both interfaces are up) then the worst case exposure in the event of an outage to the primary is that clients would temporarily not get new DHCP leases or renewals. Unless you have very mobile clients, this exposure is rather minimal given DHCP clients will simply used cached prior leased information.
The ideal network DHCP solution is to have multiple DHCP servers (services) located centrally in the network, ones for which the IP address assignment ranges do not overlap for a give segment (scope in MS terms). For example, DHCP-SVR1 doles out 10.10.10.10-119, DHCP-SVR2 doles out 10.10.10.120-239 (given a net mast of 255.255.255.0, reserves 1-9 for HSRP & admin & 240+ for misc like printers). You then set up all your HSRP router interfaces, both primary and secondary, to use IP HELPER pointers to primary and secondary DHCP servers. Set half your segments to use DHCP-SVR1 as their primary and DHCP-SVR2 as their secondary. Obviously, do the opposite for the others.
On a medium to large network, having the DHCP servers certrally managed simplifies the overall management of these DHCP address leases.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...