TCP/IP Network Protocols

DHCP Failover ProtocolDHCP Failover Protocol

Jeff Schreiber

schreiber@process.com

DECUS Europe 2000DECUS Europe 2000

Thursday, 13 Apr 2000Thursday, 13 Apr 2000

9:00 - 9:459:00 - 9:45

OutlineOutline

lDHCP Basic Operation

lExisting forms of Redundancy

lRequirements for Failover Redundancy

lProblems, Goals, and Limitations

lHow it works

RedundanciesRedundancies

lDNS: both Primary and Secondary

lHardware configurations

lBut only make-shift redundancies for DHCP

Basically, how DHCP worksBasically, how DHCP works

lClient: DHCPDISCOVER

lServer: DHCPOFFER

lClient:DHCPREQUEST

–or DHCPDECLINE

lServer: DHCPACK

–Lease time

–IP address

–DNS server & other information

Basically, how DHCP worksBasically, how DHCP works

lClient goes into a “bound” state and starts theT1 and T2 timers

lT1 is 1/2 the Lease time

lT2 is about 80% of the lease time.

lAt T1, client sends a (unicast)DHCPREQUEST to renew the lease.

Basically, how DHCP worksBasically, how DHCP works

l3 things can happen

–Server says ‘No’ and client gives up address atthe end of the lease

–No response. Therefore, the client keeps tryinguntil T2 when it sends out a broadcast.

–Gets the renewal as desired. New lease startshere.

Basically, how DHCP worksBasically, how DHCP works

lClients on different network as the server: usea DHCP relay that forwards DHCPcommunications from one subnet to the other.

Existing forms of DHCP redundancyExisting forms of DHCP redundancy

l2 DHCP servers, both active at the same time.

–No synchronization or communications betweenservers

–2 disjoint address pools.

–inefficient

–wastes addresses.

–Increases network recourses

–both servers respond to clients

Existing forms of DHCP redundancyExisting forms of DHCP redundancy

lBrute force:

–Have a standby server and periodically save thelease database.

–Performance problems.

–Possibility of issuing one address to two clients.

lProprietary primary backup solutions

–do not provide “safe” failover (1 address can begiven to two clients).

Requirements for Failover serversRequirements for Failover servers

lCannot give two clients the same address.

lThe secondary should be able to take over forthe primary.

lDo not change the fundamental way thatDHCP works.

–Do not change the client

–Server can change (al biet slightly)

–Client to give up the lease when told to or at theend of the lease if it does not get renewed.

Things to addressThings to address

lHow does primary server update secondaryand when.

lFailover assumes that an INIT_REBOOT doesnot have an existing address. This scenariocan happen if the Client gets the 1st addresswhile primary cannot talk to secondary, thenreboots again.

Things to addressThings to address

lServer updates require stable storage to workreliably. Don’t want to add a significantamount of time that it already takes to do this.

lClients may not be on same networkTherefore need to have a DHCP relay forwardthe DHCP stuff to a particular server to thatthat can send a request to more than oneserver.

Problems to be aware ofProblems to be aware of

lPrimary crashes before it can updatesecondary. Secondary has no record of primaryallocation (DHCPACK)

lPrimary and secondary cannot talk but clientscan see both. (network partitioning)

lInherent to TCP connections, is keepalives tomake sure that the secondary is there.

Problems to be aware ofProblems to be aware of

lIn 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 toolong for a DHCP. RESULTS: TCP is useful for reliablemessage delivery, but cannot be dependedupon do detect server failover.

Goals (continued)Goals (continued)

lMust work with existing clients

lMust work with existing boot relay agents

l Must provide failover redundancy betweenservers that are not located on the samesubnet

l Provide service to DHCP clients in the eventof primary server failure.

Goals (continued)Goals (continued)

lAvoid binding (giving) and address to a clientthat another client already has. (no duplicateaddresses)

lMinimize the need for manual administrationintervention.

lImpose no additional client delays as a result ofprimary-backup communications

lShare IP pools between primary and secondaryservers

Goals (continued)Goals (continued)

lHandled partitioned networks.

lResynchronize without operator interventionwhen primary failure is corrected.

lEnable one server to be secondary to manyprimary servers.

lAllow proper lease renewal from either server.

Goals (continued)Goals (continued)

lIf either server loses all of the information thatit has stored in stable storage, it should beable to refresh from the other server.

LimitationsLimitations

lOnly one secondary server.

lHave a subset of addresses that only thesecondary can hand out.

lNeither server hand out addresses during arecovering failure.

MCLTMCLT

lMaximum Client Lead Time

la “lease time” known to both the secondaryand primary servers.

lPlaces an upper bound on the differenceallowed between the lease time given to aclient by a server and the lease time known bythe other server.

lIs much less than the “real” lease time.

MCLTMCLT

lTell the client what the other server knows,plus MCLT

lTell the other server what the client wanted(or what the client was supposed to get) plus1/2 of what it got

lDon’t give the client more than what it askedfor (or what it was supposed to get).

Client

Primary

DHCP

Server

DHCPREQUEST

1 hour (MCLT)

Secondary

DHCP

Server

Practical UsePractical Use

1 day + 1/2 hour

1/2 Hour Later

Renew Request

1 day (Lease)

1 day + 1/2 hour

1/2 Day Later

Renew Request

1 day (Lease)

1 day + 1/2 hour

Primary

DHCP

Server

Primary

DHCP

Server

Primary

DHCP

Server

Client

DHCPREQUEST

1 hour (MCLT)

Secondary

DHCP

Server

Practical UsePractical Use

1 day + 1/2 hour

1/2 Hour Later

Renew Request

(No Answer)

Request Broadcasted

1 Hour (MCLT)

“I’m Back”

“Here’s what I’ve done”

Primary

DHCP

Server

Primary

DHCP

Server

QuestionsQuestions

That’s all folks…That’s all folks…

Any Questions?Any Questions?

Getting the SlidesGetting the Slides

Slides available via anonymous FTP:

ftp://ftp.process.com/decus/europe_2000/dhcp_failover.ppt