Option 50 in failover mode

[Glenn Satchell]

The other thing to consider is that the free addresses don't get used up
immediately, but rather as new clients or renewing clients start talking
to the surviving server. So if you have long lease times then you have a
greater period of time to either fix the down server or switch to
partner-down.

The other idea that no-one has mentioned is running one of the flavours of
(say) ha-linux and clustering the dhcp service. That way you don't need 2x
or 3x the number of IP addresses, but you have the added complexity of
failover and synchronising lease files. In the end it's a bunch of
different trade-offs.

Bob, I guess if the pool is big enough then the surviving server can
continue to hand out addresses without intervention, so that can also be
called "hands off" I guess. I think this debate has devolved into
semantics now. Your example of talking about it over lunch would quickly
resolve it to the point where we'd all nod our heads and agree.

Randall, my choice for auto-partner-down would be about half the lease
time if I was going to use it. IMHO auto-partner-down is a bit of a hack,
and I prefer not to use it.

regards,
-glenn

> It may not be necessary to have a show of hands to see who doesn't have
> that many addresses to spare. In fact one of the benefits of dynamic host
> configuration protocol is the ability to thrash the pool on a daily basis
> - keeping enough in reserve to handle the daily peak demand. Anyone care
> to share best practice for automated unattended partner down please?
>
> Randall Grimshaw rgrimsha at syr.edu
> ________________________________________
> From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org
> [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Simon
> Hobson [dhcp1 at thehobsons.co.uk]
> Sent: Monday, November 28, 2011 3:00 PM
> To: Users of ISC DHCP
> Subject: Re: Option 50 in failover mode
>
> 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.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>