Transcript TCP/IP Network Protocols

DECUS Europe 2000
DHCP Failover Protocol
Thursday, 13 Apr 2000
9:00 - 9:45
Jeff Schreiber
©1999-2000 Process Software Corp.
[email protected]
1
Outline





DHCP Basic Operation
Existing forms of Redundancy
Requirements for Failover Redundancy
Problems, Goals, and Limitations
How it works
©1999-2000 Process Software Corp.
2
Redundancies

DNS: both Primary and Secondary
 Hardware configurations
 But only make-shift redundancies for DHCP
©1999-2000 Process Software Corp.
3
Basically, how DHCP works

Client: DHCPDISCOVER
 Server: DHCPOFFER
 Client:DHCPREQUEST
– or DHCPDECLINE

Server: DHCPACK
– Lease time
– IP address
– DNS server & other information
©1999-2000 Process Software Corp.
4
Basically, how DHCP works
Client goes into a “bound” state and starts the
T1 and T2 timers
 T1 is 1/2 the Lease time
 T2 is about 80% of the lease time.
 At T1, client sends a (unicast)
DHCPREQUEST to renew the lease.

©1999-2000 Process Software Corp.
5
Basically, how DHCP works

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.
©1999-2000 Process Software Corp.
6
Basically, how DHCP works

Clients on different network as the server: use
a DHCP relay that forwards DHCP
communications from one subnet to the other.
©1999-2000 Process Software Corp.
7
Existing forms of DHCP redundancy

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
©1999-2000 Process Software Corp.
8
Existing forms of DHCP redundancy

Brute force:
– Have a standby server and periodically save the
lease database.
– Performance problems.
– Possibility of issuing one address to two clients.

Proprietary primary backup solutions
– do not provide “safe” failover (1 address can be
given to two clients).
©1999-2000 Process Software Corp.
9
Requirements for Failover servers

Cannot give two clients the same address.
 The secondary should be able to take over for
the primary.
 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.
©1999-2000 Process Software Corp.
10
Things to address

How does primary server update secondary
and when.
 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.
©1999-2000 Process Software Corp.
11
Things to address

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.
 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.
©1999-2000 Process Software Corp.
12
Problems to be aware of

Primary crashes before it can update
secondary. Secondary has no record of primary
allocation (DHCPACK)
 Primary and secondary cannot talk but clients
can see both. (network partitioning)
 Inherent to TCP connections, is keepalives to
make sure that the secondary is there.
©1999-2000 Process Software Corp.
13
Problems to be aware of

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.
©1999-2000 Process Software Corp.
14
Goals (continued)

Must work with existing clients
 Must work with existing boot relay agents
 Must provide failover redundancy between
servers that are not located on the same
subnet
 Provide service to DHCP clients in the event
of primary server failure.
©1999-2000 Process Software Corp.
15
Goals (continued)

Avoid binding (giving) and address to a client
that another client already has. (no duplicate
addresses)
 Minimize the need for manual administration
intervention.
 Impose no additional client delays as a result of
primary-backup communications
 Share IP pools between primary and secondary
servers
©1999-2000 Process Software Corp.
16
Goals (continued)

Handled partitioned networks.
 Resynchronize without operator intervention
when primary failure is corrected.
 Enable one server to be secondary to many
primary servers.
 Allow proper lease renewal from either server.
©1999-2000 Process Software Corp.
17
Goals (continued)

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.
©1999-2000 Process Software Corp.
18
Limitations

Only one secondary server.
 Have a subset of addresses that only the
secondary can hand out.
 Neither server hand out addresses during a
recovering failure.
©1999-2000 Process Software Corp.
19
MCLT

Maximum Client Lead Time
 a “lease time” known to both the secondary
and primary servers.
 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.
 Is much less than the “real” lease time.
©1999-2000 Process Software Corp.
20
MCLT

Tell the client what the other server knows,
plus MCLT
 Tell the other server what the client wanted (or
what the client was supposed to get) plus 1/2
of what it got
 Don’t give the client more than what it asked
for (or what it was supposed to get).
©1999-2000 Process Software Corp.
21
Practical Use
1
DHCPREQUEST
1 hour (MCLT)
2
3
1 day + 1/2 hour
1/2 Hour Later
4
Client
Renew Request
1 day (Lease)
5
Primary
DHCP
Server
6
1 day + 1/2 hour
Secondary
DHCP
Server
1/2 Day Later
7
Renew Request
1 day (Lease)
©1999-2000 Process Software Corp.
8
9
1 day + 1/2 hour
22
Practical Use
1
DHCPREQUEST
1 hour (MCLT)
2
3
1 day + 1/2 hour
1/2 Hour Later
4
Renew Request
(No Answer)
Client
5
Request Broadcasted
Primary
DHCP
Server
Secondary
DHCP
Server
1 Hour (MCLT)
7
“I’m Back”
“Here’s what I’ve done”
©1999-2000 Process Software Corp.
6
8
23
Questions
That’s all folks…
Any Questions?
©1999-2000 Process Software Corp.
24
Getting the Slides
Slides available via anonymous FTP:
ftp://ftp.process.com/decus/europe_2000/dhcp_failover.ppt
©1999-2000 Process Software Corp.
25