Send dhcp-users mailing list submissions to
[email protected]
Advertising
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: General questions about failover, config changes and
restarting (James Dore)
2. Re: General questions about failover, config changes and
restarting (S Carr)
3. Setting a host lease time via OMAPI (Julien Semaan)
4. Re: General questions about failover, config changes and
restarting ([email protected])
5. Re: Setting a host lease time via OMAPI (Simon Hobson)
6. Re: Setting a host lease time via OMAPI (Julien)
7. Re: Setting a host lease time via OMAPI (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 Mar 2016 15:02:31 +0000
From: James Dore <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: General questions about failover, config changes and
restarting
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> On 2 Mar 2016, at 17:21, S Ca <[email protected]> wrote:
>
> On 2 March 2016 at 16:52, James Dore <[email protected]> wrote:> Hi
> Glenn,
>> I ask because we?ve had occasions in the past where I?ve restarted the first
>> server, but left the second for a couple of hours, and we stop getting
>> addresses issued to new clients. This is the kind of log message we get
>> during this situation -
>
> Sync is finished when both peers return to NORMAL mode. You need to
> restart both servers (just kill dhcpd and restart it) one after
> another or you're likely to run into issues with the pools not
> matching, and then you'll run into issues with not leasing IPs.
>
> Steve
Yes, that has been my normal practice, but which ever order I restart the
servers in, they never seem to sort themselves out first time round and require
a handful of restarts apiece.
My usual method is
service dhcpd restart
given my SLES12 servers use systemd for service management now. although
rcdhcpd restart achieves the same thing.
Any ideas why my servers need so many restarts? I try to leave them to settle
for five or six minutes before trying again, but they just seem to stick with
things like
dhcpd.log-20151123:2015-11-23T10:17:58.203346+00:00 garibaldi dhcpd: failover
peer newc-dhcp: I move from normal to shutdown
dhcpd.log-20151123:2015-11-23T10:18:03.848105+00:00 garibaldi dhcpd: failover
peer newc-dhcp: I move from shutdown to startup
dhcpd.log-20151123:2015-11-23T10:18:03.854208+00:00 garibaldi dhcpd: failover
peer newc-dhcp: peer moves from normal to communications-interrupted
dhcpd.log-20151123:2015-11-23T10:18:03.927644+00:00 garibaldi dhcpd: failover
peer newc-dhcp: I move from startup to shutdown
dhcpd.log-20151123:2015-11-23T10:18:03.940208+00:00 garibaldi dhcpd: failover
peer newc-dhcp: peer moves from communications-interrupted to partner-down
in the logs.
Cheers,
James
------------------------------
Message: 2
Date: Thu, 3 Mar 2016 16:45:10 +0000
From: S Carr <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: General questions about failover, config changes and
restarting
Message-ID:
<calmep04azuosjy77g60mqmjkqvbqg0m66ehy5tjla61yhen...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 3 March 2016 at 15:02, James Dore <[email protected]> wrote:
> Any ideas why my servers need so many restarts? I try to leave them to settle
> for five or six minutes before trying again, but they just seem to stick with
> things like
>
> dhcpd.log-20151123:2015-11-23T10:17:58.203346+00:00 garibaldi dhcpd: failover
> peer newc-dhcp: I move from normal to shutdown
> dhcpd.log-20151123:2015-11-23T10:18:03.848105+00:00 garibaldi dhcpd: failover
> peer newc-dhcp: I move from shutdown to startup
> dhcpd.log-20151123:2015-11-23T10:18:03.854208+00:00 garibaldi dhcpd: failover
> peer newc-dhcp: peer moves from normal to communications-interrupted
> dhcpd.log-20151123:2015-11-23T10:18:03.927644+00:00 garibaldi dhcpd: failover
> peer newc-dhcp: I move from startup to shutdown
> dhcpd.log-20151123:2015-11-23T10:18:03.940208+00:00 garibaldi dhcpd: failover
> peer newc-dhcp: peer moves from communications-interrupted to partner-down
So what version of DHCPD are you running, a (stupid) feature was
introduced in a particular version (now regressed) to automatically
enter partner-down on a shut down, that is the root of your problems,
you should not be entering partner-down at all as the partner is not
down, and then it has to go through it's recovery stage to get back
into normal mode. Also check the init script to make sure it's not
doing anything silly with omshell to initiate a shutdown as that will
also trigger partner-down.
Others on the list might be able to comment which version this change
was regressed in.
Steve
------------------------------
Message: 3
Date: Thu, 3 Mar 2016 15:47:31 -0500
From: Julien Semaan <[email protected]>
To: [email protected]
Subject: Setting a host lease time via OMAPI
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello all,
I am an engineer part of the PacketFence (http://packetfence.org/) team
which already actively uses the ISC DHCP server.
Due to the nature of our product, we need to have a lease time of 30
seconds in our DHCP scopes.
What we would like to do, is to be able to make this lease time higher
for specific hosts dynamically without restarting the DHCP server.
We already integrate with the OMAPI to get the current lease for a MAC
address, so I thought I would give it a shot for this also.
When I try to create the host with the default-lease-time and
max-lease-time attributes, it throws an error : can't open object:
unknown attribute
Now, is it me not using the right names when setting the variables or is
it that what I am trying to do is impossible ?
Here is a pastebin of my omshell session : http://pastebin.com/rbkdPqCP
If it is not possible to do this via the OMAPI, is there an alternate
way to accomplish what we want to do ?
Thanks !
--
Julien Semaan
[email protected] :: +1 (866) 353-6153 *155 ::www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160303/ff1d4245/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 03 Mar 2016 22:15:10 +0100 (CET)
From: [email protected]
To: [email protected], [email protected]
Subject: Re: General questions about failover, config changes and
restarting
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset=us-ascii
> > Sync is finished when both peers return to NORMAL mode. You need to
> > restart both servers (just kill dhcpd and restart it) one after
> > another or you're likely to run into issues with the pools not
> > matching, and then you'll run into issues with not leasing IPs.
...
> Any ideas why my servers need so many restarts? I try to leave them to settle
> for five or six minutes before trying again, but they just seem to stick with
> things like
I am somewhat mystified about why you would need many minutes for a
restart. Here's what we see on our failover pair, with around 100k
leases and a couple of hundred pools:
(master restarts, log on slave):
Mar 3 08:50:00 slam dhcpd: peer dhcp1-dhcp2: disconnected
Mar 3 08:50:00 slam dhcpd: failover peer dhcp1-dhcp2: I move from normal to
communications-interrupted
...
(a few seconds pass, and then)
Mar 3 08:50:11 slam dhcpd: failover peer dhcp1-dhcp2: peer moves from normal
to normal
Mar 3 08:50:11 slam dhcpd: failover peer dhcp1-dhcp2: I move from
communications-interrupted to normal
So a restart for us takes around 11 seconds.
It should be noted that
- The servers have plenty of memory, and hardware RAID with battery
backup for the disks.
- We use the "delayed ACK" facility.
Steinar Haug, Nethelp consulting, [email protected]
------------------------------
Message: 5
Date: Thu, 3 Mar 2016 21:33:43 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Setting a host lease time via OMAPI
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Julien Semaan <[email protected]> wrote:
> Due to the nature of our product, we need to have a lease time of 30 seconds
> in our DHCP scopes.
>
> What we would like to do, is to be able to make this lease time higher for
> specific hosts dynamically without restarting the DHCP server.
Will that help ?
The client will still come back to renew according to the lease length it was
originally given, and won't the new lease it's given get reset to the current
default lease time configured - or a length requested by the client, and
subject to max and min limits ?
------------------------------
Message: 6
Date: Thu, 3 Mar 2016 16:57:59 -0500
From: Julien <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Setting a host lease time via OMAPI
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Simon,
Thanks for taking the time to answer.
Now, the goal of this is not to affect the current lease but to affect
future leases.
Maybe a bit of context will help.
We have a network which is used for captive portal registration, when
you are done registering, you leave this network (through a VLAN change).
The lease time is set to 30 seconds so that the device tries to renew
its IP in the new network fast (and then fail, and get the proper IP)
Now, some devices connect to the network and stay there for days, months
without doing anything else than getting DHCP and without trying to
register.
We would like these devices to have a lease length that is higher than
the other ones so that it reduces the load on the DHCP server.
This above is determined at runtime since the detection occurs after the
DHCP server has started, thus the need for it to occur dynamically
through the OMAPI or another mean.
Regards,
- Julien
On 16-03-03 04:33 PM, Simon Hobson wrote:
> Julien Semaan <[email protected]> wrote:
>
>> Due to the nature of our product, we need to have a lease time of 30 seconds
>> in our DHCP scopes.
>>
>> What we would like to do, is to be able to make this lease time higher for
>> specific hosts dynamically without restarting the DHCP server.
> Will that help ?
> The client will still come back to renew according to the lease length it was
> originally given, and won't the new lease it's given get reset to the current
> default lease time configured - or a length requested by the client, and
> subject to max and min limits ?
>
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 7
Date: Fri, 4 Mar 2016 07:50:52 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Setting a host lease time via OMAPI
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Julien <[email protected]> wrote:
> Now, the goal of this is not to affect the current lease but to affect future
> leases.
I guessed that
> Maybe a bit of context will help.
>
> We have a network which is used for captive portal registration, when you are
> done registering, you leave this network (through a VLAN change).
> The lease time is set to 30 seconds so that the device tries to renew its IP
> in the new network fast (and then fail, and get the proper IP)
>
> Now, some devices connect to the network and stay there for days, months
> without doing anything else than getting DHCP and without trying to register.
> We would like these devices to have a lease length that is higher than the
> other ones so that it reduces the load on the DHCP server.
>
> This above is determined at runtime since the detection occurs after the DHCP
> server has started, thus the need for it to occur dynamically through the
> OMAPI or another mean.
As I wrote, I'm not sure that this will help. I'd suggest setting up a test lab
and try it - my feeling is that when a client renews, the lease length it's
given will depend on the rules for assigning lease lengths, not the length of
it's current lease. So when you've lengthened a lease, the client renews, the
longer lease is "forgotten about" and a replacement is done for 30s again.
Could you use classes instead. Assign these devices to a specific class (via
OMAPI) and configure that class to have longer leases ?
Or perhaps re-assign the client to a "never never land" VLAN with different
lease length rules (but still stuck behind the registration portal) ?
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 89, Issue 7
*****************************************
