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: DHCP Failover - initial Configuration (Simon Hobson)
2. Re: not getting same ip for same MAC (Simon Hobson)
3. Re: not getting same ip for same MAC (perl-list)
4. Re: not getting same ip for same MAC (Simon Hobson)
5. Re: not getting same ip for same MAC (Gregory Sloop)
6. Re: DHCP Failover - initial Configuration (Philippe Maechler)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Aug 2018 18:24:04 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP Failover - initial Configuration
Message-ID: <6949b0a7-5eb0-43b9-b742-60ba3268f...@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Philippe Maechler <plcmaech...@gmail.com> wrote:
> If we wanna go for failover, what are the right steps to start?
> ? Configure failover on the primary node (in the local confg)
> ? Choose which we wanna do failover and configure them
> ? Restart the primary node and put it into partner down state
> ? Configure the second server (failover and pools)
> ? Start the second server
> ? Put the primary server into partner-up? Mode
>
> Does this sound right?
Almost, the last step is automagic - when the second server comes up, it will
communicate with the first, sync the leases, then after (AIUI) MCLT they will
both go into normal operation.
> /30 networks
> We have about ~240 pools, ~50 pools only contain one single ip address. Does
> failover makes sense here?
> We can?t use hosts definitions because we only know the option-82. Some
> customers have more than one device connected but we can only serve the
> single ip address to one of them. If we use failover, can it happen, that
> server-1 hands out the ip address to device-1 and server two hand out the ip
> to device-2?
Failover won't work with such a pool - there's no free leases to balance
between the servers. You could configure the same pool on both servers without
failover - but then, as you suggest, the same address could be leased to two
devices.
> Heavily used pools
> The bigger part is our /24 pools. These are all in a shared network config. I
> guess the failover part works pretty fine for the individual pools here. The
> shared network is sometimes at 95% usage. Can this lead to problems?
As long as there are free leases in a pool then it will work.
> Server restarts
> Currently we restart the service every 5minutes if something changed. When we
> go for failover, we should reload server one and if it synced to his partner,
> we can reload the server two. How does server two know, that the server one
> is up to date and everything is synced?
After a restart it will take time for the servers to resync. You'll need to
adapt your management system to hold off on restarts. Hopefully someone more
familiar with failover will be along soon with more details, but from things
said on here, there are some cases where the servers can take a while before
they get back to fully normal operation.
------------------------------
Message: 2
Date: Wed, 8 Aug 2018 18:40:49 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: not getting same ip for same MAC
Message-ID: <86728178-6a26-417b-b41b-9f06a6a57...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Christopher Barry <christopher.r.ba...@gmail.com> wrote:
> Problem:
> I'm booting an embedded device via u-boot over tftp, and I am getting
> one IP during boot, and another IP once Linux comes up.
...
> In the leases file it can be seen that the uid value is different
> between u-boot and linux, even though the MAC is the same.
This is a known issue. The DHCP spec requires that the Client ID (uid in the
leases file) is used as the primary key in the lease database, the MAC address
is not used at all if there is a Client ID provided.
There are 4 ways around this :
1) Just enlarge your pool
2) Use classes to make the u-boot and Linux use different pools. The booted
Linux will then behave as you were used to. In a production environment, it can
also be used to give the bootloader a short lease so that a smaller pool can be
used.
3) Configure one or both clients so that they both use the same Client ID, or
both use no Client ID
4) A long time ago someone wrote some patches - though I don't think they would
be applicable to your case. IIRC the patches did something like "if there is no
Client ID, add one using the MAC address" and were intended to deal with the
known "Linux doesn't send a Client ID, Windows uses the MAC address" dual boot
issue.
------------------------------
Message: 3
Date: Wed, 8 Aug 2018 15:20:29 -0400 (EDT)
From: perl-list <perl-l...@network1.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: not getting same ip for same MAC
Message-ID:
<1204992976.652319.1533756029672.javamail.zim...@network1.net>
Content-Type: text/plain; charset=utf-8
This could also be interesting tho I don't know how it affects lease assignment
for sure (from man dhcpd.conf):
The ignore-client-uids statement
ignore-client-uids flag ;
If the ignore-client-uids statement is present and has a value of true or on ,
the UID for clients will not be recorded.
If this statement is not present or has a value of false or off , then client
UIDs will be recorded.
----- Original Message -----
> From: "Simon Hobson" <dh...@thehobsons.co.uk>
> To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
> Sent: Wednesday, August 8, 2018 1:40:49 PM
> Subject: Re: not getting same ip for same MAC
> Christopher Barry <christopher.r.ba...@gmail.com> wrote:
> > Problem:
> > I'm booting an embedded device via u-boot over tftp, and I am getting
> > one IP during boot, and another IP once Linux comes up.
> ...
> > In the leases file it can be seen that the uid value is different
> > between u-boot and linux, even though the MAC is the same.
> This is a known issue. The DHCP spec requires that the Client ID (uid in the
> leases file) is used as the primary key in the lease database, the MAC address
> is not used at all if there is a Client ID provided.
> There are 4 ways around this :
> 1) Just enlarge your pool
> 2) Use classes to make the u-boot and Linux use different pools. The booted
> Linux will then behave as you were used to. In a production environment, it
> can
> also be used to give the bootloader a short lease so that a smaller pool can
> be
> used.
> 3) Configure one or both clients so that they both use the same Client ID, or
> both use no Client ID
> 4) A long time ago someone wrote some patches - though I don't think they
> would
> be applicable to your case. IIRC the patches did something like "if there is
> no
> Client ID, add one using the MAC address" and were intended to deal with the
> known "Linux doesn't send a Client ID, Windows uses the MAC address" dual boot
> issue.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 4
Date: Wed, 8 Aug 2018 21:36:49 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: not getting same ip for same MAC
Message-ID: <9758e818-639a-4a1e-a859-2657e371c...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
perl-list <perl-l...@network1.net> wrote:
> This could also be interesting tho I don't know how it affects lease
> assignment for sure (from man dhcpd.conf):
>
> The ignore-client-uids statement
>
> ignore-client-uids flag ;
>
> If the ignore-client-uids statement is present and has a value of true or on
> , the UID for clients will not be recorded.
> If this statement is not present or has a value of false or off , then client
> UIDs will be recorded.
Ah, I'd completely forgotten about that one. IIRC it provides exactly the
non-RFC-compliant operation needed to work around the problem.
------------------------------
Message: 5
Date: Wed, 8 Aug 2018 13:46:23 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Simon Hobson <dh...@thehobsons.co.uk>, Users of ISC DHCP
<dhcp-users@lists.isc.org>
Subject: Re: not getting same ip for same MAC
Message-ID: <201007971.20180808134...@sloop.net>
Content-Type: text/plain; charset="us-ascii"
SH> perl-list <perl-l...@network1.net> wrote:
>> This could also be interesting tho I don't know how it affects lease
>> assignment for sure (from man dhcpd.conf):
>> The ignore-client-uids statement
>> ignore-client-uids flag ;
>> If the ignore-client-uids statement is present and has a value of true or on
>> , the UID for clients will not be recorded.
>> If this statement is not present or has a value of false or off , then
>> client UIDs will be recorded.
SH> Ah, I'd completely forgotten about that one. IIRC it provides
SH> exactly the non-RFC-compliant operation needed to work around the problem.
Ok, Simon - you've had your one "I'd completely forgotten about that one"
episode this century. Don't let it happen again! ;)
[I was totally impressed with your original reply, and found this "Oh,
yeah...that..." amusing...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20180808/8da514ff/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 9 Aug 2018 08:15:25 +0200
From: Philippe Maechler <plcmaech...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP Failover - initial Configuration
Message-ID:
<CAPhukgZQmJE7_wdS+ghqG3m=VEapUujMsiHyZSz=eh4fgqf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Simon, hello list
On Wed, 8 Aug 2018 at 19:24, Simon Hobson <dh...@thehobsons.co.uk> wrote:
>
> > Server restarts
> > Currently we restart the service every 5minutes if something changed.
> When we go for failover, we should reload server one and if it synced to
> his partner, we can reload the server two. How does server two know, that
> the server one is up to date and everything is synced?
>
> After a restart it will take time for the servers to resync. You'll need
> to adapt your management system to hold off on restarts. Hopefully someone
> more familiar with failover will be along soon with more details, but from
> things said on here, there are some cases where the servers can take a
> while before they get back to fully normal operation.
>
Yes, I'm already testing a way for checking the server state before a
reload. The current idea is, that our reload script first checks via omapi
the failover-state from the other server. If the server is in ready and in
sync, we do the reload. otherwise we wait another few minutes. Since we
already rely on omapi for other things, this shouldn't be much magic :)
Something else you mentioned, mlct. On of our access system is doing
something like dhcp-snooping/dhcp-aging. When a client successfuly logs on
with a DORA sequence, the clients mac address is allowed to communicate for
a given time. unfortunately this time is hardcoded in the access system and
not learnt from the DORA sequence. If we have a lease time of 7200s but an
mlct of 3600, clients would first get a lease time of 1h and on a
Request/Ackownlede a lease time of 2h. Would that work if we set
mlct==lease-time? What are the benedits and drawbacks from such a
configuration?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20180809/160f9372/attachment-0001.html>
------------------------------
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 118, Issue 5
******************************************
