ISC-dhcp subnet limit?

Bob Harold rharolde at umich.edu
Thu Jan 28 16:23:27 UTC 2016


On Thu, Jan 28, 2016 at 7:46 AM, Rob Morin <rmorin at datavalet.com> wrote:
> Hey Chuck, sorry for late reply, i fell asleep, lol
>
> No body works on these servers other than myself, so no one put the peer in
> partner down mode...
>
> i tested the 647 ports in both directions with a simple telnet command and
> both respond in both directions...
>
> As of this morning(est time) the secondary shows the following still
>
> Jan 27 23:50:37 dhcp-2 dhcpd: Wrote 661863 leases to leases file.
> Jan 28 00:03:53 dhcp-2 dhcpd: dhcp-failover: ignored (recovering)
> Jan 28 00:15:51 dhcp-2 dhcpd: dhcp-failover: ignored (recovering)
> Jan 28 00:16:37 dhcp-2 dhcpd: dhcp-failover: ignored (recovering)
> Jan 28 07:34:44 dhcp-2 dhcpd: DHCPREQUEST for 10.39.175.168 (172.30.129.9)
> from f4:f1:e1:e5:14:1f via 10.39.175.1: not responding (recovering)
> 100's of the below
> Jan 28 07:43:08 dhcp-2 dhcpd: uid lease 10.35.166.59 for client
> a4:b8:05:8a:c3:82 is duplicate on 10.35.166.0/24
>
>
> Primary has this..
> i do not think this is a big issue for the moment as we do not care about
> resolution for the moment, should i explicitly indicate this in the conf
> file?
> 100's of the below...
> dhcp-1 dhcpd: bind update on 10.40.44.115 got ack from dhcp-failover: xid
> mismatch.
> Jan 28 07:41:35 dhcp-1 dhcpd: uid lease 10.38.115.215 for client
> 98:fe:94:85:75:3d is duplicate on 10.38.115.0/24
>
> Thanks for your help s far...
>
>
> Rob
> Montreal Canada
>
>
> On 2016-01-28 1:46 AM, Chuck Anderson wrote:
>>
>> "partner-down" state must NEVER be entered unless the failover peer
>> server is really down.  Typically, partner-down is only entered
>> manually by server administrator action (via OMAPI or by carefully
>> editing the lease file while the server is stopped) or automatically
>> if you specifically enabled the dangerous "auto-partner-down" option
>> in the config (don't do that).
>>
>> Given that I don't see the "auto-partner-down" statement configured in
>> the bits you have posted, is it possible that someone at some point in
>> the past put the server into partner-down manually?  It should come out
>> of that state automatically once contact is re-established with the
>> failover peer.  Is there a firewall or iptables rules blocking port
>> 647 communication between the two servers, preventing failover from
>> working correctly?
>>
>>> Jan 27 16:17:37 dhcp-1 dhcpd: failover peer dhcp-failover: I move from
>>> partner-down to startup
>>> Jan 27 16:17:46 dhcp-1 dhcpd: failover peer dhcp-failover: I move from
>>> startup to partner-down
>>> Jan 27 16:17:37 dhcp-1 dhcpd: failover peer dhcp-failover: I move from
>>> partner-down to startup
>>> Jan 27 16:17:46 dhcp-1 dhcpd: failover peer dhcp-failover: I move from
>>> startup to partner-down
>>>
>>> And now from dhcp-2
>>> Jan 27 16:17:19 dhcp-2 dhcpd: failover: link startup timeout
>>> Jan 27 16:17:56 dhcp-2 dhcpd: failover peer dhcp-failover: peer moves
>>> from partner-down to partner-down
>>> Jan 27 16:17:56 dhcp-2 dhcpd: failover peer dhcp-failover: peer moves
>>> from partner-down to partner-down
>>> Jan 27 16:28:41 dhcp-2 dhcpd: failover peer dhcp-failover: peer moves
>>> from partner-down to partner-down
>>>
>>>
>>> Thanks....
>>>
>>> Rob
>>> Montreal, Canada
>>>
>>> -----Original Message-----
>>> From: dhcp-users-bounces at lists.isc.org
>>> [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Rob Morin
>>> Sent: Wednesday, January 27, 2016 9:18 PM
>>> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
>>> Subject: RE: ISC-dhcp subnet limit?
>>>
>>> Thanks for the quick reply Dave, on each of the servers there are 2
>>> vlans, one is internal/admin(VLAN01) and one is dmz(VLAN02), where the
>>> requests/discovers come in. From my testing so far it seems that a discover
>>> comes in on vlan02, and the offer and ack go out on vlan01. I do not think
>>> this is an issue as per our network guys, but I thought I would mention it.
>>>
>>> Discover comes in via vlan02 through a firewall, but when it goes out on
>>> vlan01 there is no firewall.
>>>
>>> Here is /etc/dhcp/dhcpd.conf of secondary
>>>
>>>         authoritative;
>>>         log-facility local7;
>>>         option domain-name "dyn";
>>> default-lease-time 1200; # 20 minutes to match the default clients
>>> session duration max-lease-time 3600; # 1h include
>>> "/etc/dhcp/dhcpd_secondary.conf"; include "/etc/dhcp/dhcpd_pools.conf";
>>>
>>> Here is the "/etc/dhcp/dhcpd_secondary.conf file
>>>
>>>         ## SECONDARY
>>> failover peer "dhcp-failover" {
>>>   secondary; # declare this to be the secondary server  address
>>> 172.30.128.10;  port 647;  peer address 172.30.128.9;  peer port 647;
>>> max-response-delay 30;  max-unacked-updates 10;  load balance max seconds 3;
>>> # mclt 1800;  #No "split" statement on secondary }
>>>
>>> Our lease time is short as per client request, we cannot alter it, its in
>>> the contract.
>>> As for users, there are 10's of thousands of users at any given time...
>>>
>>> Here is a very recent log exert on secondary..
>>> Jan 27 21:10:29 dhcp-2 dhcpd: DHCPDISCOVER from 68:d9:3c:56:a6:bb via
>>> 10.49.66.1: not responding (recovering) Jan 27 21:10:29 dhcp-2 dhcpd:
>>> DHCPDISCOVER from 10:a5:d0:17:34:96 via 10.37.5.1: peer holds all free
>>> leases Jan 27 21:10:29 dhcp-2 dhcpd: DHCPREQUEST for 10.37.104.252
>>> (172.30.129.9) from 5c:8d:4e:a2:06:ff via 10.37.104.1: not responding
>>> (recovering) Jan 27 21:10:29 dhcp-2 dhcpd: DHCPREQUEST for 10.50.33.204
>>> (172.30.129.9) from 90:e7:c4:d3:7d:51 via 10.50.33.1: not responding
>>> (recovering)
>>>
>>> Here are some misc log entries that you might find useful...
>>>
>>> Jan 27 14:45:03 dhcp-1 dhcpd: Wrote 1169142 leases to leases file.
>>> Jan 27 15:29:21 dhcp-1 dhcpd: Wrote 1169401 leases to leases file.
>>> Jan 27 16:17:35 dhcp-1 dhcpd: Wrote 1169721 leases to leases file.
>>> Jan 27 15:50:25 dhcp-1 dhcpd: peer dhcp-failover: disconnected Jan 27
>>> 16:19:38 dhcp-1 dhcpd: peer dhcp-failover: disconnected
>>>
>>> Jan 27 16:16:39 dhcp-2 dhcpd: peer dhcp-failover: disconnected Jan 27
>>> 16:18:55 dhcp-2 dhcpd: peer dhcp-failover: disconnected Jan 27 14:15:51
>>> dhcp-2 dhcpd: Wrote 0 leases to leases file.
>>> Jan 27 15:28:38 dhcp-2 dhcpd: Wrote 29890 leases to leases file.
>>> Jan 27 15:35:41 dhcp-2 dhcpd: Wrote 29920 leases to leases file.
>>> Jan 27 15:50:28 dhcp-2 dhcpd: Wrote 29920 leases to leases file.
>>>
>>> Any help appreciated...
>>>
>>> Rob
>>> Montreal, Canada
>>>
>>> -----Original Message-----
>>> From: dhcp-users-bounces at lists.isc.org
>>> [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of dave c
>>> Sent: Wednesday, January 27, 2016 9:02 PM
>>> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
>>> Subject: Re: ISC-dhcp subnet limit?
>>>
>>> Curious why your network seems to have 6,000 subnets all living in a
>>> single vlan...
>>>
>>> But, in order to diagnose the partner issue, we'd need to see the partner
>>> config segments as well.
>>>
>>> To answer whether it matters if requests arrive on eth1 and answers go
>>> out on eth0, the real question is what are the differences between them.
>>> Does one go out to a firewall while the second is a direct connection? I
>>> don't see a statement in your config telling dhcpd which IP address/port to
>>> listen and respond on. You can force it to use eth1 if you feel it should be
>>> doing so.
>>>
>>> I'm also wondering why your lease time is so short. That would seem to
>>> generate a lot of traffic to the dhcp server that otherwise wouldn't be
>>> needed. How many users are there in these 6,000 subnets?
>>>
>>> Dave
>>>
>>> On 1/27/16 19:12, Rob Morin wrote:
>>>>
>>>> Hello all, my first post here, so please be gentle J
>>>>
>>>> I have inherited 2 dhcp servers, one primary(dhcp-1) & one
>>>> secondary(dhcp-2) running
>>>> isc-dhcpd-4.2.4 on Ubuntu 14.0(Trusty)
>>>>
>>>> We are having a few issues, and I cannot seem to figure out whats
>>>> going on. I have a few questions, maybe someone can help me with.
>>>>
>>>> Is there a max limit to how many subnets can be used in the pools? As
>>>> currently we are using just over 6000 subnets
>>>>
>>>> Currently our secondary dhcp-server is always in recovery mode, not sure
>>>> why?
>>>>
>>>> Does it matter if a DISCOVER comes in on eth1 but OFFER goes out on
>>>> eth0?
>>>>
>>>> My primary server /etc/dhcpd.conf file
>>>>
>>>> authoritative;
>>>>
>>>> log-facility local7;
>>>>
>>>> option domain-name "dyn";
>>>>
>>>> option domain-name-servers 172.30.64.210, 172.30.64.220;
>>>>
>>>> default-lease-time 1200;
>>>>
>>>> max-lease-time 3600; # 1h
>>>>
>>>> include "/etc/dhcp/dhcpd_pools.conf";
>>>>
>>>> # Include the primary configuration
>>>>
>>>> include "/etc/dhcp/dhcpd_primary.conf";
>>>>
>>>> /etc/dhcp/dhcpd_primary has the following
>>>>
>>>>                                 ## PRIMARY
>>>>
>>>> failover peer "tdl-dhcp-failover" {
>>>>
>>>>     primary; # declare this to be the primary server
>>>>
>>>>                  address 172.30.128.9;
>>>>
>>>>                  port 647;
>>>>
>>>>     peer address 172.30.128.10;
>>>>
>>>>     peer port 647;
>>>>
>>>>     max-response-delay 30;
>>>>
>>>>     max-unacked-updates 10;
>>>>
>>>>     load balance max seconds 3;
>>>>
>>>>     mclt 1800;
>>>>
>>>>     split 128;
>>>>
>>>> }
>>>>
>>>> Exert from dhcpd_pools file, starts like this....
>>>>
>>>> subnet 10.32.0.0 netmask 255.255.255.0 {
>>>>
>>>>     option routers 10.32.0.1;
>>>>
>>>>     pool {
>>>>
>>>>           failover peer "dhcp-failover";
>>>>
>>>>           range 10.32.0.5 10.32.0.254;
>>>>
>>>>     }
>>>>
>>>> }
>>>>
>>>> And finishes like this, with all the subnets in between...
>>>>
>>>> subnet 10.57.255.0 netmask 255.255.255.0 {
>>>>
>>>>     option routers 10.57.255.1;
>>>>
>>>>     pool {
>>>>
>>>>           failover peer "dhcp-failover";
>>>>
>>>>           range 10.57.255.5 10.57.255.254;
>>>>
>>>>     }
>>>>
>>>> }
>>>>
>>>> Example Exert from logs on both serves of a client that could not get
>>>> an IP
>>>>
>>>>
>>>> from dhcp-1
>>>> Jan 27 18:30:31 dhcp-1 dhcpd: DHCPDISCOVER from fc:e9:98:bc:a8:7b
>>>> (iPhone) via 10.50.170.1 Jan 27 18:30:31 dhcp-1 dhcpd: DHCPOFFER on
>>>> 10.50.170.93 to fc:e9:98:bc:a8:7b (iPhone) via
>>>> 10.50.170.1
>>>>
>>>> from dhcp-2
>>>> Jan 27 18:53:55 dhcp-2 dhcpd: DHCPDISCOVER from fc:e9:98:bc:a8:7b via
>>>> 10.50.170.1: peer holds all free leases Jan 27 18:54:04 dhcp-2 dhcpd:
>>>> DHCPDISCOVER from fc:e9:98:bc:a8:7b via 10.50.170.1: peer holds all
>>>> free leases
>>>>
>>>> Never see the ACK.
>>>>
>>>> Any suggestion would be greatly appreciated.. :
>>>>
>>>> Thanks...
>>>>
>>>> Rob
>>

Looks like you get the DHCPDISCOVER from the client, and send the
DHCPOFFER, but never see a DHCPREQUEST or DHCPACK.  So either the
client is not receiving the DHCPOFFER, or the DHCPREQUEST is not
getting back to the server.  I would suspect that sending on a
different port is a likely problem - either the remote dhcp forwarder
or the client is not receiving or not accepting the packet.  Several
things you could try:
- tell DHCP to use one interface
- change routing on the server so the interface you want is used for outgoing
- change the dhcp forwarders to forward to the port that is used for
outgoing, so it will also be the incoming port
(only one of those is needed, your choice)

If you define the subnets that the DHCP server is directly connected
to, but without a "range" statement, that will silence the complaints
in the log, but is not a big deal.

Also, you should trace the failover packets between the two servers to
figure out why that is not working.

Since it is not working, try configuring it with one subnet and get
that working, then try 6000+.

-- 
Bob Harold


More information about the dhcp-users mailing list