The logged entries as the DHCP server completes the start process should look similar to those below:ĭhcpd: Wrote 0 deleted host decls to leases file.ĭhcpd: Wrote 0 new dynamic host decls to leases file.ĭhcpd: Wrote 72468 leases to leases file.ĭhcpd: Listening on LPF/eth0/00:19:b9:df:24:3b/172.16.201.32/27ĭhcpd: Sending on LPF/eth0/00:19:b9:df:24:3b/172.16.201.32/27ĭhcpd: Sending on Socket/fallback/fallback-net Inspect the log entries as the server is restarting:.Two strategies exist for script-managing this (apart from manually observing the servers as they are logging): How can I tell that the first server's restart has completed fully? Modify the primary's configuration file.Stop and restart the secondary using the new configuration.Modify the secondary's configuration file.the parts describing the addresses and pools and such) will be identical between the two peers once they have both restarted, although there may be a period during the transition where they are not.įor making the transition, the process flow would be similar to: ![]() Your goal is that the non-partnership parts of the configuration (i.e. If you've made significant changes such as extending or removing failover ranges, then on restarting one server, there will be a mismatch and some errors logged until both have been restarted. Restarting the secondary first is held to be better in this situation - but probably won't make that much of a difference to the overall start-up times. That allows them time to reestablish communications and do pool balancing before you take the second one offline for its restart. When restarting the pair, wait for the restart of the first one to complete fully before restarting the second one.The servers will log all of these transitions and the server status can also be confirmed via OMAPI. ![]()
0 Comments
Leave a Reply. |