Option 50 in failover mode

Simon Hobson dhcp1 at thehobsons.co.uk
Mon Nov 28 20:00:31 UTC 2011


Bob Proulx wrote:
>Glenn Satchell wrote:
>>  I think there are two different ideas of "hands off" failover. It's true
>>  that the failover protocol has been around for a long time, and I recall
>>  running it myself in the early 2000s. But while that protocol
>>  automatically handled failure of one system it was not entirely hands off.
>>  The surviving dhcp server would only allocate new IPs from it's share of
>>  the pool. If the pool didn't have enough spare IPs to handle all the
>>  clients then eventually it would run out of addresses to allocate.
>
>Hence why I said that the pool needed to be large enough.  The
>original question was asking about a failover configuration and the
>ability of a dhcp client to keep the same address through the failure
>of a server.  In regards to that original question the client can keep
>the same address if the pool configured on each failover server is
>large enough to handle the entire network itself.
>
>If the pool is large enough then it won't run out of addresses to
>allocate and everything will work correctly without interaction.  If a
>server runs out of addresses because the pool is too small then I
>claim that is configured to be load balancing only and not configured
>for high availability.

I'm no expert on failover, but AIUI you are wrong there. AIUI, if one 
server is down, it's partner cannot renew leases for addresses owned 
by that server - so although having your pools very large (minimum 2x 
max number of active clients*) will mean clients will still be able 
to renew, they will not be able to keep their address if they are 
using leases from the failed server. So large pools do *not* avoid 
clients changing their addresses without you putting the surviving 
server in partner-down mode.

* Actually, I don't think that is a sufficient condition, I think I 
can come up with a situation where it would need to be 3x the max 
number of active clients.

Remember that you do **NOT** define pools per server - only shared 
pools. The division of ownership of the addresses between servers is 
dynamic. It's possible  after an outage to have one server holding 
all the active leases - and the free addresses will be split 50-50 
between the two servers once the failed server recovers. If the 
previously good server now fails, the remaining one only has half the 
free addresses to play with - hence you need a pool that is 3x the 
max number of active clients.


Bob Proulx wrote:

>It would be better if it
>handled more than exactly two machines but that just increases the
>complexity.

Actually you can.
Failover is defined per pool, not per subnet. So if you wanted (say) 
3 servers, then define 3 pools and do failover between the servers 
thus :
Pool 1 between servers A & B
Pool 2 between servers B & C
Pool 3 between servers C & A
You now have 3 way redundancy, and if your pools are large enough, 
then you could survive indefinitely with just one server - although 
you might find some dynamic DNS issues and a large number (typically 
about 2/3) of your clients will get a new address.
With 4 servers you can have a 6-way split (A-B, B-C, C-D, D-A, A-C, 
and B-D) - wouldn't that be fun to manage !

>  > But to get full functionality back requires either setting the new
>>  option, or manually putting (or scripting) the remaining server into
>>  partner-down mode.
>
>The words "full functionality" trigger me to disagree.  Going to
>partner-down doesn't give you full funcationality.

I disagree.
Fully functional means all clients get to renew their leases, keep 
the same IP addresses, and it all happens invisibly to users and 
devices on the network. You may have lost redundancy, but not full 
functionality.

Again, a difference of opinion on the meaning of words.
-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.



More information about the dhcp-users mailing list