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

2. 2 ©1999-2000 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. 3 ©1999-2000 Process Software Corp. Redundancies l DNS: both Primary and Secondary l Hardware configurations l But only make-shift redundancies for DHCP

4. 4 ©1999-2000 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. 5 ©1999-2000 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. 6 ©1999-2000 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. 7 ©1999-2000 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. 8 ©1999-2000 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. 9 ©1999-2000 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. 10 ©1999-2000 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. 11 ©1999-2000 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. 12 ©1999-2000 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. 13 ©1999-2000 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. 14 ©1999-2000 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. 15 ©1999-2000 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. 16 ©1999-2000 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. 17 ©1999-2000 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. 18 ©1999-2000 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. 19 ©1999-2000 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. 20 ©1999-2000 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. 21 ©1999-2000 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. 22 ©1999-2000 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. 23 ©1999-2000 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. 24 ©1999-2000 Process Software Corp. Questions That’s all folks… Any Questions?

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