Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: How to sync a Linux secondary DHCP server? (Simon Hobson)
2. Re: How to sync a Linux secondary DHCP server?
(Sandra Schlichting)
3. Re: How to sync a Linux secondary DHCP server? (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jul 2018 15:28:22 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: How to sync a Linux secondary DHCP server?
Message-ID: <6ea71f23-8b2e-4146-a226-4c7bfd233...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Sandra Schlichting <littlesandr...@gmail.com> wrote:
> In this article [1] they don't explain how the secondary DHCP server
> gets synced and in this one [2] they sync the files with home made
> scripts.
>
> **Question**
>
> Having a secondary DHCP server is good practice I'd say, so can it
> really be correct, that DHCP on Linux doesn't have an official a way
> to sync config, leases and reservations to the secondary?
>
> [1]:
> https://www.lisenet.com/2018/configure-dhcp-failover-with-dynamic-dns-on-centos-7/
> [2]: https://steronius.blogspot.com/2015/10/dhcp-failover-on-rhel-7.html
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.
------------------------------
Message: 2
Date: Tue, 31 Jul 2018 11:16:10 +0200
From: Sandra Schlichting <littlesandr...@gmail.com>
To: dhcp-users@lists.isc.org
Subject: Re: How to sync a Linux secondary DHCP server?
Message-ID:
<caelimbm6ijbgk_w_h1qfnnvkghe29hvyueryccm4w1bpzwk...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
> 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%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.
"
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.
------------------------------
Message: 3
Date: Tue, 31 Jul 2018 10:30:10 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: How to sync a Linux secondary DHCP server?
Message-ID: <0c2cdd45-d030-4423-8211-743a7ae3e...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Sandra Schlichting <littlesandr...@gmail.com> 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 !
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 117, Issue 16
*******************************************
