1 © Process Software Corp. DHCP Failover Protocol Jeff DECUS Europe 2000 Thursday, 13 Apr :00 - 9:45

2 © Process Software Corp. Outline l DHCP Basic Operation l Existing forms of Redundancy l Requirements for Failover Redundancy l Problems, Goals, and Limitations l How it works

3 © Process Software Corp. Redundancies l DNS: both Primary and Secondary l Hardware configurations l But only make-shift redundancies for DHCP

4 © Process Software Corp. Basically, how DHCP works l Client: DHCPDISCOVER l Server: DHCPOFFER l Client:DHCPREQUEST –or DHCPDECLINE l Server: DHCPACK –Lease time –IP address –DNS server & other information

5 © Process Software Corp. Basically, how DHCP works l Client goes into a “bound” state and starts the T1 and T2 timers l T1 is 1/2 the Lease time l T2 is about 80% of the lease time. l At T1, client sends a (unicast) DHCPREQUEST to renew the lease.

6 © Process Software Corp. Basically, how DHCP works l 3 things can happen –Server says ‘No’ and client gives up address at the end of the lease –No response. Therefore, the client keeps trying until T2 when it sends out a broadcast. –Gets the renewal as desired. New lease starts here.

7 © Process Software Corp. Basically, how DHCP works l Clients on different network as the server: use a DHCP relay that forwards DHCP communications from one subnet to the other.

8 © Process Software Corp. Existing forms of DHCP redundancy l 2 DHCP servers, both active at the same time. –No synchronization or communications between servers –2 disjoint address pools. –inefficient –wastes addresses. –Increases network recourses –both servers respond to clients

9 © Process Software Corp. Existing forms of DHCP redundancy l Brute force: –Have a standby server and periodically save the lease database. –Performance problems. –Possibility of issuing one address to two clients. l Proprietary primary backup solutions –do not provide “safe” failover (1 address can be given to two clients).

10 © Process Software Corp. Requirements for Failover servers l Cannot give two clients the same address. l The secondary should be able to take over for the primary. l Do not change the fundamental way that DHCP works. –Do not change the client –Server can change (al biet slightly) –Client to give up the lease when told to or at the end of the lease if it does not get renewed.

11 © Process Software Corp. Things to address l How does primary server update secondary and when. l Failover assumes that an INIT_REBOOT does not have an existing address. This scenario can happen if the Client gets the 1st address while primary cannot talk to secondary, then reboots again.

12 © Process Software Corp. Things to address l Server updates require stable storage to work reliably. Don’t want to add a significant amount of time that it already takes to do this. l Clients may not be on same network Therefore need to have a DHCP relay forward the DHCP stuff to a particular server to that that can send a request to more than one server.

13 © Process Software Corp. Problems to be aware of l Primary crashes before it can update secondary. Secondary has no record of primary allocation (DHCPACK) l Primary and secondary cannot talk but clients can see both. (network partitioning) l Inherent to TCP connections, is keepalives to make sure that the secondary is there.

14 © Process Software Corp. Problems to be aware of l In a TCP connection (as opposed to a UDP) will time out and will take up to 9 minutes. This usually cannot be changed. This is too long for a DHCP. RESULTS: TCP is useful for reliable message delivery, but cannot be depended upon do detect server failover.

15 © Process Software Corp. Goals (continued) l Must work with existing clients l Must work with existing boot relay agents l Must provide failover redundancy between servers that are not located on the same subnet l Provide service to DHCP clients in the event of primary server failure.

16 © Process Software Corp. Goals (continued) l Avoid binding (giving) and address to a client that another client already has. (no duplicate addresses) l Minimize the need for manual administration intervention. l Impose no additional client delays as a result of primary-backup communications l Share IP pools between primary and secondary servers

17 © Process Software Corp. Goals (continued) l Handled partitioned networks. l Resynchronize without operator intervention when primary failure is corrected. l Enable one server to be secondary to many primary servers. l Allow proper lease renewal from either server.

18 © Process Software Corp. Goals (continued) l If either server loses all of the information that it has stored in stable storage, it should be able to refresh from the other server.

19 © Process Software Corp. Limitations l Only one secondary server. l Have a subset of addresses that only the secondary can hand out. l Neither server hand out addresses during a recovering failure.

20 © Process Software Corp. MCLT l Maximum Client Lead Time l a “lease time” known to both the secondary and primary servers. l Places an upper bound on the difference allowed between the lease time given to a client by a server and the lease time known by the other server. l Is much less than the “real” lease time.

21 © Process Software Corp. MCLT l Tell the client what the other server knows, plus MCLT l Tell the other server what the client wanted (or what the client was supposed to get) plus 1/2 of what it got l Don’t give the client more than what it asked for (or what it was supposed to get).

22 © Process Software Corp. Client Primary DHCP Server DHCPREQUEST 1 1 hour (MCLT) 2 Secondary DHCP Server Practical Use 1 day + 1/2 hour 3 1/2 Hour Later Renew Request 4 1 day (Lease) 5 1 day + 1/2 hour 6 1/2 Day Later Renew Request 7 1 day (Lease) 8 1 day + 1/2 hour 9

23 © Process Software Corp. Primary DHCP Server Primary DHCP Server Primary DHCP Server Client DHCPREQUEST 1 1 hour (MCLT) 2 Secondary DHCP Server Practical Use 1 day + 1/2 hour 3 1/2 Hour Later Renew Request 4 (No Answer) Request Broadcasted 5 1 Hour (MCLT) 6 “I’m Back” 7 “Here’s what I’ve done” 8 Primary DHCP Server Primary DHCP Server

24 © Process Software Corp. Questions That’s all folks… Any Questions?

25 © Process Software Corp. Getting the Slides Slides available via anonymous FTP: ftp://ftp.process.com/decus/europe_2000/dhcp_failover.ppt