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: ipv6 dhcp server not handing out addresses (Thomas Markwalder)
2. Re: expired lease problem (project722)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Nov 2017 07:18:27 -0500
From: Thomas Markwalder <tm...@isc.org>
To: dhcp-users@lists.isc.org
Subject: Re: ipv6 dhcp server not handing out addresses
Message-ID: <8ac8b4b3-46b1-0b13-edf3-ea28ab701...@isc.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello Robert:
Sorry you're having difficulties.? I tested your server config below
with 4.3.5 and locally connected clients and the server issues leases
without issue as you can see from the log output later on. So there is
nothing inherent in your server config that is causing an issue. Can you
email me, directly, a pcap file so I can see exactly what your clients
are sending? I would also suggest you (if you haven't already) try
running dhcpd in the foreground so you can capture all of the logging
down to the debug level to stdout. It is possible the solicits are being
dropped and we're not seeing why. Alternatively you can open a ticket
here: https://www.isc.org/community/report-bug/ By default new tickets
are confidential as are any attachments emailed to the bug ticket. We
are keenly aware of the sensitivity of user system information and we
never make public such information unless we have explicit permission
from users to do so. Certainly with issues such as yours the more data
you can supply us with the easier it will be for us to resolve your
issue. Regards, Thomas Markwalder ISC Software Engineering Log output
from 4.3.5 with your config: tmark@cserver isc_dhcp $ sudo bin/t.sh
4.3.5 etc/v6/spotswood.conf enp0s10 -6 wipe wiping lease file
output/spotswood.leases sbin/dhcpd enp0s10 -6 -d -cf
/labspace/var/isc_dhcp/etc/v6/spotswood.conf -pf output/spotswood.pid
-lf output/spotswood.leases Internet Systems Consortium DHCP Server
4.3.5 Copyright 2004-2016 Internet Systems Consortium. All rights
reserved. For info, please visit https://www.isc.org/software/dhcp/
Config file: /labspace/var/isc_dhcp/etc/v6/spotswood.conf Database file:
output/spotswood.leases PID file: output/spotswood.pid Wrote 0 NA, 0 TA,
0 PD leases to lease file. Bound to *:547 Listening on
Socket/5/enp0s10/fd00:220:0:1::/64 Sending on
Socket/5/enp0s10/fd00:220:0:1::/64 Server starting service. wiping lease
file output/spotswood.leases sbin/dhcpd enp0s10 -6 -d -cf
/labspace/var/isc_dhcp/etc/v6/spotswood.conf -pf output/spotswood.pid
-lf output/spotswood.leases Internet Systems Consortium DHCP Server
4.3.5 Copyright 2004-2016 Internet Systems Consortium. All rights
reserved. For info, please visit https://www.isc.org/software/dhcp/
Config file: /labspace/var/isc_dhcp/etc/v6/spotswood.conf Database file:
output/spotswood.leases PID file: output/spotswood.pid Wrote 0 NA, 0 TA,
0 PD leases to lease file. Bound to *:547 Listening on
Socket/5/enp0s10/fd00:220:0:1::/64 Sending on
Socket/5/enp0s10/fd00:220:0:1::/64 Server starting service. Solicit
message from 3002::35 port 546, transaction ID 0x000000 Picking pool
address fd00:220:0:1::800 Advertise NA: address fd00:220:0:1::800 to
client with duid 00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:04 iaid = 1
valid for 6048 seconds Sending Advertise to 3002::35 port 546 Request
message from 3002::35 port 546, transaction ID 0x1000000 Reply NA:
address fd00:220:0:1::800 to client with duid
00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:04 iaid = 1 valid for 6048
seconds Sending Reply to 3002::35 port 546 Solicit message from 3002::35
port 546, transaction ID 0x2000000 Picking pool address
fd00:220:0:1::789 Advertise NA: address fd00:220:0:1::789 to client with
duid 00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:05 iaid = 1 valid for 6048
seconds Sending Advertise to 3002::35 port 546 Request message from
3002::35 port 546, transaction ID 0x3000000 Reply NA: address
fd00:220:0:1::789 to client with duid
00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:05 iaid = 1 valid for 6048
seconds Sending Reply to 3002::35 port 546 Solicit message from 3002::35
port 546, transaction ID 0x4000000 Picking pool address
fd00:220:0:1::7da Advertise NA: address fd00:220:0:1::7da to client with
duid 00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:06 iaid = 1 valid for 6048
seconds Sending Advertise to 3002::35 port 546 Request message from
3002::35 port 546, transaction ID 0x5000000 Reply NA: address
fd00:220:0:1::7da to client with duid
00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:06 iaid = 1 valid for 6048
seconds Sending Reply to 3002::35 port 546 Solicit message from 3002::35
port 546, transaction ID 0x6000000 Picking pool address
fd00:220:0:1::717 Advertise NA: address fd00:220:0:1::717 to client with
duid 00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:07 iaid = 1 valid for 6048
seconds Sending Advertise to 3002::35 port 546 Request message from
3002::35 port 546, transaction ID 0x7000000 Reply NA: address
fd00:220:0:1::717 to client with duid
00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:07 iaid = 1 valid for 6048
seconds Sending Reply to 3002::35 port 546 Solicit message from 3002::35
port 546, transaction ID 0x8000000 Advertise NA: address
fd00:220:0:1::800 to client with duid
00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:04 iaid = 1 valid for 6048
seconds Sending Advertise to 3002::35 port 546 Request message from
3002::35 port 546, transaction ID 0x9000000 Reply NA: address
fd00:220:0:1::800 to client with duid
00:01:00:01:21:a1:8f:ab:00:0c:01:02:03:04 iaid = 1 valid for 6048
seconds Sending Reply to 3002::35 port 546
On 11/16/2017 05:35 PM, rob...@spotswood-computer.net wrote:
> You might be on to something, but the pool6 idea didn't work either. In
> between posts, I installed the kea dhcp6 server. Got a minimal config file
> cobbled together (man, it's a mess edit the config compared to the
> isc-dhcp-server) and fired it up. Clients got a lease no problem (the
> ipconfig /release6, ipconfig /renew6 dance). So 100% it's a server issue,
> and 100% not a firewall issue.
>
> That leaves two possibilities:
>
> (1) Something has changed from 4.2.2 to 4.3.5 that requires updating my
> config file.
> or
> (2) There is a bug in 4.3.5. I noticed you didn't use 4.3.5. Possibly some
> regression that was fixed in 4.3.6??? I looked at the release notes and
> didn't see anything.
>
> Unless someone spots an error in my config file (and the original works
> fine on 4.2.2), I guess I'll have to look at 4.3.6 to see if that fixes
> the issue.
>
> == current config ==
> efault-lease-time 6048;
> max-lease-time 6048;
> log-facility local7;
> ddns-updates on;
> ddns-update-style interim;
> update-static-leases on;
> authoritative;
> #log-facility debug;
>
> subnet6 fd00:220:0:1::/64 {
> pool6 {
> #Range for clients
> range6 fd00:220:0:1::601 fd00:220:0:1::800;
> allow unknown clients;
> allow known clients;
> }
> #Additional options
> option dhcp6.name-servers fd00:220:0:1::40, fd00:220:0:1::50;
> option dhcp6.domain-search "redacted.name";
> }
>
>>> On Nov 16, 2017, at 12:00 PM, rob...@spotswood-computer.net wrote:
>>>
>>> Since no one can find anything obvious, maybe the version I've got has a
>>> bug? Anyone using 4.3.5 for ipv6 successfully?
>> We used 4.3.4 successfully and now we're using 4.3.6 successfully. Our
>> config is different in a couple ways - we use classes and ranges are
>> inside pool6 blocks, e.g.
>>
>> shared-network Pine-B-net.stanford.edu {
>> subnet6 2607:f6d0:0:13af::/64 {
>> pool6 {
>> allow members of "dhcpv6test";
>> range6 2607:f6d0:0:13af:bad:c0ff:ee:1
>> 2607:f6d0:0:13af:bad:c0ff:ee:6e;
>> }
>> }
>> }
>>
>> Recommend you try pool6.
>>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 2
Date: Fri, 17 Nov 2017 08:14:26 -0600
From: project722 <project...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: expired lease problem
Message-ID:
<CAPBQMZBxj9q+x=evXNLGiya2QVedLojKX=jumxxavd65pc1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Bill for the insight. I am happy to report that the problem has been
found and corrected. We have a failover pair and in our last maintenance
the failover config on the secondary was redone with a mistake. It was
pointing to itself as the failover peer. This caused the two dhcpd.leases
file to be out of sync, skewed the pool numbers and caused the out of
leases problem. Once corrected, everything went back to normal. This is
probably a one off type thing but I hope it helps someone out there down
the road.
On Wed, Nov 15, 2017 at 3:10 PM, Bill Shirley <
b...@c3po.polymerindustries.biz> wrote:
> Do you really need the allow unknown-clients in your pool definition?
> If you define any device with a host statement then it won't be eligible
> for the only pool in the 172.210.140.0 subnet.
>
> As I understand it, DHCP will use all the available leases before it will
> recycle any for a DHCPDISCOVER.
>
> How does your DHCP know which subnet to use for a request? Do you
> have host or class statements?
>
> Bill
>
>
>
> On 11/15/2017 9:49 AM, project722 wrote:
>
> shared-network "temp" {
> subnet 172.210.140.0 netmask 255.255.252.0 {
> option domain-name "example.net";
> option routers 172.210.140.1;
> ## Define the DHCP pool and access list for this pool.
> pool {
> allow unknown-clients;
> failover peer "dhcp-failover";
> range 172.210.140.2 172.210.140.255;
> range 172.210.141.1 172.210.141.255;
> range 172.210.142.1 172.210.142.255;
> range 172.210.143.1 172.210.143.254;
>
> }
> }
> subnet 172.210.144.0 netmask 255.255.252.0 {
> option routers 172.210.144.1;
>
> }
> }
>
> I can't post log entries as we have expanded the pool to patch the issue,
> so currently there are no errors. However, this pool only shows 74%
> utilization. And all it takes is a few more turn-ups to cause this problem.
>
>
>
> Subnet 172.210.140.0/22
> --------------------------------------------------
>
>
> Monitoring: ON
> Warning limit: 80%
> Critical limit: 90%
> Active leases: 762/1018 (74.9%)
>
> As I've mentioned before, the only thing that stands out to me in
> dhcpd.leases is the fact that we have a couple hundred of "expired" leases,
> which could and should be used, even though these are actually being held
> in the expectation that the previous client will return. (At least, that is
> my understanding)
>
> But, what is expected behavior here? For example, if we have 500 leases,
> 250 of them have a binding state of active and the other 250 have expired
> if a new client comes along DHCP should free up one of the expired ones,
> correct?
>
>
>
>
> On Tue, Nov 14, 2017 at 3:24 PM, Bill Shirley <
> b...@c3po.polymerindustries.biz> wrote:
>
>> Post your pool definition and log file excerpts.
>>
>> Bill
>>
>>
>> On 11/14/2017 12:07 PM, project722 wrote:
>>
>> We had an unusual problem last night where the server was not able to
>> give out any more leases from a specific pool. The server logs showed " no
>> more free leases". This is a RHEL 6.7 server running dhcp 4.1.1.
>>
>> We have scripts that run which look for active leases. In the pool in
>> question we had over 200 available leases but the server was unable to
>> provide them to a client. I dug around in dhcpd.leases and found what I
>> think is the problem. I found a ton of leases in the "expired" state with
>> an end date of 11/6. Which, If I am correct, will never move into it next
>> binding state of free so it can be used because its a date in the past.
>>
>> Here is an example of one:
>>
>> lease 172.210.141.159 {
>> starts 2 2017/11/07 11:40:37;
>> ends 2 2017/11/07 12:10:37;
>> tstp 2 2017/11/14 11:55:37;
>> cltt 2 2017/11/07 11:40:37;
>> binding state expired;
>> next binding state free;
>>
>> Am I correct here? If so, what causes this problem and how can I fix it?
>> I have restarted dhcpd, but that does not help. If I were to edit
>> /var/lib/dhcp/dhcpd.leases manually and remove these entries what are some
>> things I should take into consideration?
>>
>>
>> _______________________________________________
>> dhcp-users mailing
>> listdhcp-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
>
> _______________________________________________
> dhcp-users mailing
> listdhcp-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/dhcp-users
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20171117/d3f9c48f/attachment.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 109, Issue 13
*******************************************
