|
|
|
|
Sandra Schlichting < [hidden email]> wrote:
config - no, there's no official way
leases and reservations are handled automagically by the failover protocol
In both cases, they are configuring the failover protocol (the "failover-peer" definitions and statements in the relevant pools), but I agree do not say how it works.
It's not as simple as this, but in effect, the two servers communicate with each other so that each has a list of leases given out by the other. When a new lease is issued by one server, it tells the other so that both leases files can be updated.
If there's a failure, then once the remaining server is put into partner down mode (which is not automatic by default because there are failure modes where it could go wrong) then it will take over the entire set of pools.
By default, both servers are active, so it's not really master & slave, and they will automatically rebalance things so that both have roughly half the free addresses in each pool.
You should find better descriptions in the list archives.
The two config files need to be identical apart from the failover-peer declaration. This can be in a separate file which is pulled in wioth an include statement in the main config file. That way, you can keep the two config files in sync by editing one and copying it to the other machine (either manually or automagically) or machine generate both copies of the config file by some configuration management system.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> config - no, there's no official way
> leases and reservations are handled automagically by the failover protocol
Excellent!
> In both cases, they are configuring the failover protocol (the "failover-peer" definitions and statements in the relevant pools), but I agree do not say how it works.
> It's not as simple as this, but in effect, the two servers communicate with each other so that each has a list of leases given out by the other. When a new lease is issued by one server, it tells the other so that both leases files can be updated.
Ok, that is cool!
> If there's a failure, then once the remaining server is put into partner down mode (which is not automatic by default because there are failure modes where it could go wrong) then it will take over the entire set of pools.
At https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html#DHCP%20FAILOVERthey mention
"
It is possible to get into a dangerous situation: if you put one
server into the PARTNER-DOWN state, and then *that* server goes down,
and the other server comes back up, the other server will not know
that the first server was in the PARTNER-DOWN state, and may issue
addresses previously issued by the other server to different clients,
resulting in IP address conflicts. Before putting a server into
PARTNER-DOWN state, therefore, make sure that the other server will
not restart automatically.
"
Are there other cases that an admin should be aware of?
> By default, both servers are active, so it's not really master & slave, and they will automatically rebalance things so that both have roughly half the free addresses in each pool.
Is it possible/likely that one server gets broken/corrupt in a way
that it doesn't trigger a fail over? This is the worst case I can
think of =)
> You should find better descriptions in the list archives.
>
> The two config files need to be identical apart from the failover-peer declaration. This can be in a separate file which is pulled in wioth an include statement in the main config file. That way, you can keep the two config files in sync by editing one and copying it to the other machine (either manually or automagically) or machine generate both copies of the config file by some configuration management system.
Super. I will then probably go with rsync or scp.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Sandra Schlichting < [hidden email]> wrote:
> At https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html#DHCP%20FAILOVER> they mention
>
> "
> It is possible to get into a dangerous situation: if you put one
> server into the PARTNER-DOWN state, and then *that* server goes down,
> and the other server comes back up, the other server will not know
> that the first server was in the PARTNER-DOWN state, and may issue
> addresses previously issued by the other server to different clients,
> resulting in IP address conflicts. Before putting a server into
> PARTNER-DOWN state, therefore, make sure that the other server will
> not restart automatically.
> "
There's really no way around that corner case.
> Are there other cases that an admin should be aware of?
It is possible to have two servers that lose connectivity between themselves but can both still communicate with some or all of the clients. This could be down to a routing issue, or because a link that carries the failover traffic has failed but that link isn't used for client traffic. So the default is not to automatically go into partner down state upon loss of communications - but there is an option to do that if you are confident that this problem doesn't apply (eg both servers are on the same network segment).
If a server does fail, you do have some time to deal with it before problems start, so many just rely on system monitoring to alert them and put the surviving partner into partner-down mode.
>> By default, both servers are active, so it's not really master & slave, and they will automatically rebalance things so that both have roughly half the free addresses in each pool.
>
> Is it possible/likely that one server gets broken/corrupt in a way
> that it doesn't trigger a fail over? This is the worst case I can
> think of =)
I suppose anything is possible !
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hello all:
Firstly Simon, thank you for providing such a detailed response. It has
been my experience that you are a prompt, able, and patient presence on
our users list, and, all of us here at ISC appreciate your contributions
to the community.
One point of clarification, Host reservations are not synchronized
between servers via fail over. Any host reservations you have in one
configuration file, you must include in the peer server's configuration
file. For dynamic reservations (i.e. those that do not include a fixed
address), the leases allocated for each host will be synchronized
(assuming they come from within a FO pool), but not the actual
reservation specifications.
Regards,
Thomas Markwalder
ISC Software Engineering
PS (There are quite a few regular responders on this list, and ALL of
you are appreciated immensely. I'll be making an effort to make sure
each of you are recognized accordingly)
On 07/31/2018 05:30 AM, Simon Hobson wrote:
> Sandra Schlichting < [hidden email]> wrote:
>
>> At https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html#DHCP%20FAILOVER>> they mention
>>
>> "
>> It is possible to get into a dangerous situation: if you put one
>> server into the PARTNER-DOWN state, and then *that* server goes down,ss
>> and the other server comes back up, the other server will not know
>> that the first server was in the PARTNER-DOWN state, and may issue
>> addresses previously issued by the other server to different clients,
>> resulting in IP address conflicts. Before putting a server into
>> PARTNER-DOWN state, therefore, make sure that the other server will
>> not restart automatically.
>> "
> There's really no way around that corner case.
>
>> Are there other cases that an admin should be aware of?
> It is possible to have two servers that lose connectivity between themselves but can both still communicate with some or all of the clients. This could be down to a routing issue, or because a link that carries the failover traffic has failed but that link isn't used for client traffic. So the default is not to automatically go into partner down state upon loss of communications - but there is an option to do that if you are confident that this problem doesn't apply (eg both servers are on the same network segment).
> If a server does fail, you do have some time to deal with it before problems start, so many just rely on system monitoring to alert them and put the surviving partner into partner-down mode.
>
>
>>> By default, both servers are active, so it's not really master & slave, and they will automatically rebalance things so that both have roughly half the free addresses in each pool.
>> Is it possible/likely that one server gets broken/corrupt in a way
>> that it doesn't trigger a fail over? This is the worst case I can
>> think of =)
> I suppose anything is possible !
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> > At https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html#DHCP%20FAILOVER> > they mention
> >
> > "
> > It is possible to get into a dangerous situation: if you put one
> > server into the PARTNER-DOWN state, and then *that* server goes down,
> > and the other server comes back up, the other server will not know
> > that the first server was in the PARTNER-DOWN state, and may issue
> > addresses previously issued by the other server to different clients,
> > resulting in IP address conflicts. Before putting a server into
> > PARTNER-DOWN state, therefore, make sure that the other server will
> > not restart automatically.
> > "
>
> There's really no way around that corner case.
Maybe they should add that that case is only when reservations are not
used. For reservations it shouldn't be an issue.
> It is possible to have two servers that lose connectivity between themselves but can both still communicate with some or all of the clients. This could be down to a routing issue, or because a link that carries the failover traffic has failed but that link isn't used for client traffic. So the default is not to automatically go into partner down state upon loss of communications - but there is an option to do that if you are confident that this problem doesn't apply (eg both servers are on the same network segment).
> If a server does fail, you do have some time to deal with it before problems start, so many just rely on system monitoring to alert them and put the surviving partner into partner-down mode.
Very nice. Both my DHCP servers would be right next to each other with
a direct fail over link.
> >> By default, both servers are active, so it's not really master & slave, and they will automatically rebalance things so that both have roughly half the free addresses in each pool.
Can it be configured how many each serve?
E.g. if it were possible to have dhcp1 to serve 100% of the IP's, then
it would a classic master/slave setup. Or are there reason I wouldn't
want to do that?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> One point of clarification, Host reservations are not synchronized
> between servers via fail over. Any host reservations you have in one
> configuration file, you must include in the peer server's configuration
> file. For dynamic reservations (i.e. those that do not include a fixed
> address), the leases allocated for each host will be synchronized
> (assuming they come from within a FO pool), but not the actual
> reservation specifications.
So for the reservation I would have to rsync/scp them over?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hello Sandra:
Yes. Anything specified via configuration file must be sync'd outside of
ISC DHCP.
Fail over, in ISC DHCP, is based on draft RFC:
https://tools.ietf.org/html/draft-ietf-dhc-failover-12It does not call for exchanging information beyond lease and server
state information, and
was written such that any two servers which adhere to it, should be
inter operable. At least
that was the original intent.
Host reservations are "a policy mechanism" and as such are not governed
by RFCs. Thus they
are entirely specific to DHCP server implementations.
Regards,
Thomas Markwalder
ISC Software Engineering
On 07/31/2018 10:00 AM, Sandra Schlichting wrote:
>> One point of clarification, Host reservations are not synchronized
>> between servers via fail over. Any host reservations you have in one
>> configuration file, you must include in the peer server's configuration
>> file. For dynamic reservations (i.e. those that do not include a fixed
>> address), the leases allocated for each host will be synchronized
>> (assuming they come from within a FO pool), but not the actual
>> reservation specifications.
> So for the reservation I would have to rsync/scp them over?
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Just to clarify, "host reservations" can be two things.
Host statement, possibly with a fixed address statement -
synchronized via file transfer.
Reservation in the leases file - how would these function in a fail
over pair?
On 31/07/2018 16.16, Thomas Markwalder
wrote:
Hello
Sandra:
Yes. Anything specified via configuration file must be sync'd
outside of ISC DHCP.
Fail over, in ISC DHCP, is based on draft RFC:
https://tools.ietf.org/html/draft-ietf-dhc-failover-12
It does not call for exchanging information beyond lease and
server state information, and
was written such that any two servers which adhere to it, should
be inter operable. At least
that was the original intent.
Host reservations are "a policy mechanism" and as such are not
governed by RFCs. Thus they
are entirely specific to DHCP server implementations.
Regards,
Thomas Markwalder
ISC Software Engineering
On 07/31/2018 10:00 AM, Sandra Schlichting wrote:
One point of clarification, Host
reservations are not synchronized
between servers via fail over. Any host reservations you have
in one
configuration file, you must include in the peer server's
configuration
file. For dynamic reservations (i.e. those that do not
include a fixed
address), the leases allocated for each host will be
synchronized
(assuming they come from within a FO pool), but not the actual
reservation specifications.
So for the reservation I would have to rsync/scp them over?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hello Sten:
Those would also have to be manually sync'd. The fail over
protocol does not extend to reservations.
Regards,
Thomas
On 07/31/2018 10:21 AM, Sten Carlsen
wrote:
Just to clarify, "host reservations" can be two things.
Host statement, possibly with a fixed address statement -
synchronized via file transfer.
Reservation in the leases file - how would these function in a
fail over pair?
On 31/07/2018 16.16, Thomas
Markwalder wrote:
Hello
Sandra:
Yes. Anything specified via configuration file must be sync'd
outside of ISC DHCP.
Fail over, in ISC DHCP, is based on draft RFC:
https://tools.ietf.org/html/draft-ietf-dhc-failover-12
It does not call for exchanging information beyond lease and
server state information, and
was written such that any two servers which adhere to it, should
be inter operable. At least
that was the original intent.
Host reservations are "a policy mechanism" and as such are not
governed by RFCs. Thus they
are entirely specific to DHCP server implementations.
Regards,
Thomas Markwalder
ISC Software Engineering
On 07/31/2018 10:00 AM, Sandra Schlichting wrote:
One point of clarification, Host
reservations are not synchronized
between servers via fail over. Any host reservations you
have in one
configuration file, you must include in the peer server's
configuration
file. For dynamic reservations (i.e. those that do not
include a fixed
address), the leases allocated for each host will be
synchronized
(assuming they come from within a FO pool), but not the
actual
reservation specifications.
So for the reservation I would have to rsync/scp them over?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks, I did not know and I thought this should be part of the
answer.
On 31/07/2018 16.44, Thomas Markwalder
wrote:
Hello Sten:
Those would also have to be manually sync'd. The fail over
protocol does not extend to reservations.
Regards,
Thomas
On 07/31/2018 10:21 AM, Sten Carlsen
wrote:
Just to clarify, "host reservations" can be two things.
Host statement, possibly with a fixed address statement -
synchronized via file transfer.
Reservation in the leases file - how would these function in a
fail over pair?
On 31/07/2018 16.16, Thomas
Markwalder wrote:
Hello
Sandra:
Yes. Anything specified via configuration file must be sync'd
outside of ISC DHCP.
Fail over, in ISC DHCP, is based on draft RFC:
https://tools.ietf.org/html/draft-ietf-dhc-failover-12
It does not call for exchanging information beyond lease and
server state information, and
was written such that any two servers which adhere to it,
should be inter operable. At least
that was the original intent.
Host reservations are "a policy mechanism" and as such are not
governed by RFCs. Thus they
are entirely specific to DHCP server implementations.
Regards,
Thomas Markwalder
ISC Software Engineering
On 07/31/2018 10:00 AM, Sandra Schlichting wrote:
One point of clarification, Host
reservations are not synchronized
between servers via fail over. Any host reservations you
have in one
configuration file, you must include in the peer server's
configuration
file. For dynamic reservations (i.e. those that do not
include a fixed
address), the leases allocated for each host will be
synchronized
(assuming they come from within a FO pool), but not the
actual
reservation specifications.
So for the reservation I would have to rsync/scp them over?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
If, for example, you added fixed reservations using omapi, then you would
need to register these same configuration with both dhcp servers.
This is the only way to ensure there is consistent configuration on both
servers.
The leases files are different on the two servers, so you can't just copy
the leases file from one server to the other.
regards,
-glenn
On Wed, August 1, 2018 12:46 am, Sten Carlsen wrote:
> Thanks, I did not know and I thought this should be part of the answer.
>
> On 31/07/2018 16.44, Thomas Markwalder wrote:
>> Hello Sten:
>>
>> Those would also have to be manually sync'd. The fail over protocol
>> does not extend to reservations.Â
>>
>> Regards,
>>
>> Thomas
>>
>> On 07/31/2018 10:21 AM, Sten Carlsen wrote:
>>> Just to clarify, "host reservations" can be two things.
>>>
>>> Host statement, possibly with a fixed address statement -
>>> synchronized via file transfer.
>>>
>>> Reservation in the leases file - how would these function in a fail
>>> over pair?
>>>
>>>
>>> On 31/07/2018 16.16, Thomas Markwalder wrote:
>>>> Hello Sandra:
>>>>
>>>> Yes. Anything specified via configuration file must be sync'd
>>>> outside of ISC DHCP.
>>>> Fail over, in ISC DHCP, is based on draft RFC:
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-dhc-failover-12>>>>
>>>> It does not call for exchanging information beyond lease and server
>>>> state information, and
>>>> was written such that any two servers which adhere to it, should be
>>>> inter operable. At least
>>>> that was the original intent.
>>>>
>>>> Host reservations are "a policy mechanism" and as such are not
>>>> governed by RFCs. Thus they
>>>> are entirely specific to DHCP server implementations.
>>>>
>>>> Regards,
>>>>
>>>> Thomas Markwalder
>>>> ISC Software Engineering
>>>>
>>>> On 07/31/2018 10:00 AM, Sandra Schlichting wrote:
>>>>>> One point of clarification, Host reservations are not synchronized
>>>>>> between servers via fail over. Any host reservations you have in
>>>>>> one
>>>>>> configuration file, you must include in the peer server's
>>>>>> configuration
>>>>>> file. For dynamic reservations (i.e. those that do not include a
>>>>>> fixed
>>>>>> address), the leases allocated for each host will be synchronized
>>>>>> (assuming they come from within a FO pool), but not the actual
>>>>>> reservation specifications.
>>>>> So for the reservation I would have to rsync/scp them over?
>>>>> _______________________________________________
>>>>> dhcp-users mailing list
>>>>> [hidden email]
>>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>>
>>>> _______________________________________________
>>>> dhcp-users mailing list
>>>> [hidden email]
>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>
>>>
>>>
>>> _______________________________________________
>>> dhcp-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Good morning:
That's correct, Glen. When added via omapi, the reservation is tacked
on to the lease-file, with the keyword "dynamic". This tells the server
to preserve the reservation across reboots. The only way to convey it
the peer server is to do so either through an omapi connection to that
server,
or by adding it through some other means to the peer's configuration file.
Thank you, Glen, for your steadfast presence on the user's list. You
routinely provide valuable insight to the many questions that arrive on
the list. Your attentiveness to it is very much appreciated. From all
of us at ISC, thank you!
Cheers,
Thomas Markwalder
ISC Software Engineering
On 08/01/2018 09:07 AM, Glenn Satchell wrote:
> If, for example, you added fixed reservations using omapi, then you would
> need to register these same configuration with both dhcp servers.
>
> This is the only way to ensure there is consistent configuration on both
> servers.
>
> The leases files are different on the two servers, so you can't just copy
> the leases file from one server to the other.
>
> regards,
> -glenn
>
> On Wed, August 1, 2018 12:46 am, Sten Carlsen wrote:
>> Thanks, I did not know and I thought this should be part of the answer.
>>
>> On 31/07/2018 16.44, Thomas Markwalder wrote:
>>> Hello Sten:
>>>
>>> Those would also have to be manually sync'd. The fail over protocol
>>> does not extend to reservations.Â
>>>
>>> Regards,
>>>
>>> Thomas
>>>
>>> On 07/31/2018 10:21 AM, Sten Carlsen wrote:
>>>> Just to clarify, "host reservations" can be two things.
>>>>
>>>> Host statement, possibly with a fixed address statement -
>>>> synchronized via file transfer.
>>>>
>>>> Reservation in the leases file - how would these function in a fail
>>>> over pair?
>>>>
>>>>
>>>> On 31/07/2018 16.16, Thomas Markwalder wrote:
>>>>> Hello Sandra:
>>>>>
>>>>> Yes. Anything specified via configuration file must be sync'd
>>>>> outside of ISC DHCP.
>>>>> Fail over, in ISC DHCP, is based on draft RFC:
>>>>>
>>>>> https://tools.ietf.org/html/draft-ietf-dhc-failover-12>>>>>
>>>>> It does not call for exchanging information beyond lease and server
>>>>> state information, and
>>>>> was written such that any two servers which adhere to it, should be
>>>>> inter operable. At least
>>>>> that was the original intent.
>>>>>
>>>>> Host reservations are "a policy mechanism" and as such are not
>>>>> governed by RFCs. Thus they
>>>>> are entirely specific to DHCP server implementations.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Thomas Markwalder
>>>>> ISC Software Engineering
>>>>>
>>>>> On 07/31/2018 10:00 AM, Sandra Schlichting wrote:
>>>>>>> One point of clarification, Host reservations are not synchronized
>>>>>>> between servers via fail over. Any host reservations you have in
>>>>>>> one
>>>>>>> configuration file, you must include in the peer server's
>>>>>>> configuration
>>>>>>> file. For dynamic reservations (i.e. those that do not include a
>>>>>>> fixed
>>>>>>> address), the leases allocated for each host will be synchronized
>>>>>>> (assuming they come from within a FO pool), but not the actual
>>>>>>> reservation specifications.
>>>>>> So for the reservation I would have to rsync/scp them over?
>>>>>> _______________________________________________
>>>>>> dhcp-users mailing list
>>>>>> [hidden email]
>>>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>>> _______________________________________________
>>>>> dhcp-users mailing list
>>>>> [hidden email]
>>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>>
>>>>
>>>> _______________________________________________
>>>> dhcp-users mailing list
>>>> [hidden email]
>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>
>>>
>>> _______________________________________________
>>> dhcp-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> If, for example, you added fixed reservations using omapi, then you would
> need to register these same configuration with both dhcp servers.
>
> This is the only way to ensure there is consistent configuration on both
> servers.
>
> The leases files are different on the two servers, so you can't just copy
> the leases file from one server to the other.
My thought were to have two standalone dhcp servers. No failover, no
omapi. I would then rsync/scp the reserverations to the other when I
make changes.
Of course this means, the leases on each would be different, and that
is my question. What would happen if two identical dhcp servers with
identical reservations offer the same IP's?
The motivation would be to get a simple two dhcp server setup without
using the builtin failover.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
You could do that as long as there are no dynamic leases (ie: everyone has a fixed-address or similar).
You would want to make sure that you didn't have:
in the config file as that would cause the servers to NAK each other's traffic (I think it still would with fixed-address).
From: "Sandra Schlichting" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Wednesday, August 1, 2018 9:22:26 AM
Subject: Re: How to sync a Linux secondary DHCP server?
> If, for example, you added fixed reservations using omapi, then you would
> need to register these same configuration with both dhcp servers.
>
> This is the only way to ensure there is consistent configuration on both
> servers.
>
> The leases files are different on the two servers, so you can't just copy
> the leases file from one server to the other.
My thought were to have two standalone dhcp servers. No failover, no
omapi. I would then rsync/scp the reserverations to the other when I
make changes.
Of course this means, the leases on each would be different, and that
is my question. What would happen if two identical dhcp servers with
identical reservations offer the same IP's?
The motivation would be to get a simple two dhcp server setup without
using the builtin failover.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> You could do that as long as there are no dynamic leases (ie: everyone has a fixed-address or similar).
>
> You would want to make sure that you didn't have:
>
> authoritative;
>
> in the config file as that would cause the servers to NAK each other's traffic (I think it still would with fixed-address).
So if I made sure that each dhcp server served dynamic leases in
different ranges, so no overlap, would it then be a good setup?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
You could do that with dynamic tho I'm not sure what the point of that would be unless you are talking DHCPv6 where failover isn't supported and addresses are plentiful.
From: "Sandra Schlichting" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Wednesday, August 1, 2018 9:36:01 AM
Subject: Re: How to sync a Linux secondary DHCP server?
> You could do that as long as there are no dynamic leases (ie: everyone has a fixed-address or similar).
>
> You would want to make sure that you didn't have:
>
> authoritative;
>
> in the config file as that would cause the servers to NAK each other's traffic (I think it still would with fixed-address).
So if I made sure that each dhcp server served dynamic leases in
different ranges, so no overlap, would it then be a good setup?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On Wed, August 1, 2018 11:36 pm, Sandra Schlichting wrote:
>> You could do that as long as there are no dynamic leases (ie: everyone
>> has a fixed-address or similar).
>>
>> You would want to make sure that you didn't have:
>>
>> authoritative;
>>
>> in the config file as that would cause the servers to NAK each other's
>> traffic (I think it still would with fixed-address).
>
> So if I made sure that each dhcp server served dynamic leases in
> different ranges, so no overlap, would it then be a good setup?
Yes you could do that. But I can think of a few problems:
If one server was faster it could have more of the clients getting
addresses from it and fewer from the second server. There is no load
balancing or sharing.
If one server is shutdown or fails, then the clients would eventually
expire their leases, and would get a different address frm the other
server. So persistent connections, such as ssh, web page logns, etc, would
disconenct or need to re-authenticate.
While failover might look difficult, it is actually quite simple to set up
and works very reliably. The failover code has been around for a really
long time, early 2000s, so all the kinks have been well and truly worked
out.
regards,
-glenn
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
> > So if I made sure that each dhcp server served dynamic leases in
> > different ranges, so no overlap, would it then be a good setup?
>
> Yes you could do that. But I can think of a few problems:
>
> If one server was faster it could have more of the clients getting
> addresses from it and fewer from the second server. There is no load
> balancing or sharing.
That would be acceptable in my setup.
> If one server is shutdown or fails, then the clients would eventually
> expire their leases, and would get a different address frm the other
> server. So persistent connections, such as ssh, web page logns, etc, would
> disconenct or need to re-authenticate.
Hmm. Ok, that is not optimal.
> While failover might look difficult, it is actually quite simple to set up
> and works very reliably. The failover code has been around for a really
> long time, early 2000s, so all the kinks have been well and truly worked
> out.
Based on Paul's reply, I got the impression that the failover were
risky, when he wrote:
"
DHCP failover is a very fragile protocol under failure. It works
amazingly well under normal circumstances but if you ever get to the
point where you're thinking about doing partner-down, be prepared to
have resync take hours or lose leases.
"
But that is not your experience, I can guess?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
When you bring the failover peer back into the loop after a partner down, it will take awhile before the returning peer starts to respond to DHCP packets but that doesn't stop the existing peer that never left from still answering.
Basically, there wouldn't be an outage but it would be some period of time (MCLT) until the returning peer begins to answer.
Don't set MCLT low, however, set it to at least 3600 as if the primary goes away, the secondary will only issue new leases and renew existing ones for the length of MCLT. I usually set MCLT to the length of the lease i have set (usually I do 8 hours).
From: "Sandra Schlichting" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Wednesday, August 1, 2018 10:33:47 AM
Subject: Re: How to sync a Linux secondary DHCP server?
> > So if I made sure that each dhcp server served dynamic leases in
> > different ranges, so no overlap, would it then be a good setup?
>
> Yes you could do that. But I can think of a few problems:
>
> If one server was faster it could have more of the clients getting
> addresses from it and fewer from the second server. There is no load
> balancing or sharing.
That would be acceptable in my setup.
> If one server is shutdown or fails, then the clients would eventually
> expire their leases, and would get a different address frm the other
> server. So persistent connections, such as ssh, web page logns, etc, would
> disconenct or need to re-authenticate.
Hmm. Ok, that is not optimal.
> While failover might look difficult, it is actually quite simple to set up
> and works very reliably. The failover code has been around for a really
> long time, early 2000s, so all the kinks have been well and truly worked
> out.
Based on Paul's reply, I got the impression that the failover were
risky, when he wrote:
"
DHCP failover is a very fragile protocol under failure. It works
amazingly well under normal circumstances but if you ever get to the
point where you're thinking about doing partner-down, be prepared to
have resync take hours or lose leases.
"
But that is not your experience, I can guess?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
