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: Frustrated DHCP failover not working.. :( (Simon Hobson)
2. Re: Frustrated DHCP failover not working.. :( (Rob Morin)
3. RE: ISC-dhcp subnet limit? (Denis Laventure)
----------------------------------------------------------------------
Message: 1
Date: Wed, 10 Feb 2016 15:52:19 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Frustrated DHCP failover not working.. :(
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Rob Morin <[email protected]> wrote:
> What was done is the following?.
>
> I made both our dhcp-1(primary) and our dhcp-2(secondary) into stand alone
> mode(no fail over) , I know this might have not been the correct way to do
> this, but at the time it seemed practical.
> We then configured our clients controllers to go half to dhcp-1 and half to
> dhcp-2
> This worked fine.
> We then gradually moved, over the course of a couple days, all the client
> controllers to go only to dhcp-2 server, so at that point all controllers
> were going to dhcp-2 only.
> This was working fine.
What I would have suggested was :
Just stop server 1 and put server 2 into partner down mode (or remove it's
failover config. Clients with a lease from server 1 would try and renew
directly for a while, then finally broadcast a request for the address in use.
At this point, server2 would answer and the client would "switch servers"
without changing address.
> I then swapped out dhcp-1 server for a more updated one, with the above
> mentioned specs.
So server1 is now a newer version than server 2 ? I'm not really familiar with
failover, but I suspect that there may well be some compatibility issues
between different versions - especially if one of them is 4 years old.
I would be inclined to suggest migrating clients to the new server, then
upgrade server2. The quick and easy way to do this is to :
Do not even start server 1 (or just nuke it's leases file), stop server 2, copy
the leases file from server2 to server 1, start server 1 and make sure that
server2 can't be accidentally started.
If you don't want this big-bang change, then it can be done by (assuming you
don't have the luxury of a huge address space) :
Start up server 1 with a small pool that does not overlap with the pool in use
by server 2. You need to reduce the lease length offered by server 2.
Incrementally, decrease the size of the pool offered by server 2, and increase
the size of the pool offered by server 1 - always allowing all leases in the
freed up space on server2 to expire before adding the range to server 1. The
more spare addresses you have, the faster you can do this. After a while, all
clients are using server 1.
You can avoid clients address churn by taking advantage of an undocumented
behaviour in the code (warning: undocumented and not guaranteed to never change
without warning). The ISC server allocated "never used" addresses from the top
down - ie higher addresses first. This is just an artifact of the hashing
process.
So if you put the new range used by server1 higher (numerically) than server 2,
any new clients looking for a lease will get addresses from this range. But if
you remove addresses from the top of the range offered by server 2 and
immediately add them to the bottom of the range offered by server1, clients
will keep the same address as they switch servers. Because new clients will get
addresses at the top of the range, there's a fairly good chance you'll avoid
any conflicts.
Finally, you can upgrade server2. When you've done that, add the failover
config and let it sync the client data from server 1.
------------------------------
Message: 2
Date: Wed, 10 Feb 2016 11:36:20 -0500
From: Rob Morin <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Frustrated DHCP failover not working.. :(
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Hey Simon, sorry if most post was confusing a bit...
dhcp-2 server is new and has all the new hardware and is running version
4.3.3-p1 as well as dhcp-1
Currently dhcp-1 daemon is not running, dhcp-2 is running and giving out
leases just fine, but in "stand alone" mode, meaning failover is not
configured.
What i need to do is re-config dhcp-2 to be the secondary in a failover
mode, which would be just commentating the line in the dhcpd.conf file
that tells it that ir is the secondary, and then add dhcp-1 to the mix.
But when i tried this last night, after restarting dhcp-2, i saw many
lines in the log saying...
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from b8:44:d9:b8:1b:f4 via
10.51.168.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from cc:78:5f:6d:8a:73 via
10.33.169.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from c0:ce:cd:14:3f:d8 via
10.35.167.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from 90:8d:6c:96:a4:57 via
10.48.5.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from 10:1c:0c:40:5f:3a via
10.41.158.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from 34:12:98:76:5c:66 via
10.42.148.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from bc:4c:c4:ad:22:57 via
10.32.73.1: peer holds all free leases
Feb 10 05:46:44 dhcp-2 dhcpd: DHCPDISCOVER from 00:08:ca:70:76:81 via
10.51.22.1: peer holds all free leases
While this was going on dhcp-1 was not started yet...
So i started to panic a bit.... :)
I went over to dhcp-1 and started it and its log showed this...
Feb 10 05:46:56 dhcp-1 dhcpd: failover peer dhcp-failover: peer update
completed.
Feb 10 05:46:56 dhcp-1 dhcpd: failover peer dhcp-failover: I move from
recover to recover-wait
So i panicked once again, shut down dhcp-1 and went over to dhcp-2 and
told it that partner was down via omshell
and then it started to give out leases again.
To be safe i then stopped dhcp-2 and made it stand alone again restarted
and leases were being given out ok..
But now i was thinking , maybe i should have waited for mclt time to
expire??
Argg!! Maybe all was well and i jumped the gun to early???
Rob Morin
Gestionnaire des syst?mes | Senior Systems Administrator
Tel: 514 385-4448 #174
DATAVALET.COM
5275, chemin Queen-Mary, Montr?al (Qu?bec) H3W 1Y3 Canada
CE COURRIEL AINSI QUE CES DOCUMENTS JOINTS peuvent contenir des renseignements
confidentiels et privil?gi?s. Si vous n??tes pas le destinataire d?sign?,
veuillez nous en informer imm?diatement et effacer toute copie. Merci.
THIS EMAIL AND THE DOCUMENTS ATTACHED may contain privileged or confidential
information. If the reader of this message is not the intended recipient,
please notify the sender immediately and delete the original message. Thank you.
On 2016-02-10 10:52 AM, Simon Hobson wrote:
> Rob Morin <[email protected]> wrote:
>
>> What was done is the following?.
>>
>> I made both our dhcp-1(primary) and our dhcp-2(secondary) into stand alone
>> mode(no fail over) , I know this might have not been the correct way to do
>> this, but at the time it seemed practical.
>> We then configured our clients controllers to go half to dhcp-1 and half to
>> dhcp-2
>> This worked fine.
>> We then gradually moved, over the course of a couple days, all the client
>> controllers to go only to dhcp-2 server, so at that point all controllers
>> were going to dhcp-2 only.
>> This was working fine.
> What I would have suggested was :
> Just stop server 1 and put server 2 into partner down mode (or remove it's
> failover config. Clients with a lease from server 1 would try and renew
> directly for a while, then finally broadcast a request for the address in
> use. At this point, server2 would answer and the client would "switch
> servers" without changing address.
>
>> I then swapped out dhcp-1 server for a more updated one, with the above
>> mentioned specs.
> So server1 is now a newer version than server 2 ? I'm not really familiar
> with failover, but I suspect that there may well be some compatibility issues
> between different versions - especially if one of them is 4 years old.
>
> I would be inclined to suggest migrating clients to the new server, then
> upgrade server2. The quick and easy way to do this is to :
> Do not even start server 1 (or just nuke it's leases file), stop server 2,
> copy the leases file from server2 to server 1, start server 1 and make sure
> that server2 can't be accidentally started.
>
>
> If you don't want this big-bang change, then it can be done by (assuming you
> don't have the luxury of a huge address space) :
> Start up server 1 with a small pool that does not overlap with the pool in
> use by server 2. You need to reduce the lease length offered by server 2.
> Incrementally, decrease the size of the pool offered by server 2, and
> increase the size of the pool offered by server 1 - always allowing all
> leases in the freed up space on server2 to expire before adding the range to
> server 1. The more spare addresses you have, the faster you can do this.
> After a while, all clients are using server 1.
>
> You can avoid clients address churn by taking advantage of an undocumented
> behaviour in the code (warning: undocumented and not guaranteed to never
> change without warning). The ISC server allocated "never used" addresses from
> the top down - ie higher addresses first. This is just an artifact of the
> hashing process.
> So if you put the new range used by server1 higher (numerically) than server
> 2, any new clients looking for a lease will get addresses from this range.
> But if you remove addresses from the top of the range offered by server 2 and
> immediately add them to the bottom of the range offered by server1, clients
> will keep the same address as they switch servers. Because new clients will
> get addresses at the top of the range, there's a fairly good chance you'll
> avoid any conflicts.
>
>
> Finally, you can upgrade server2. When you've done that, add the failover
> config and let it sync the client data from server 1.
>
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Wed, 10 Feb 2016 11:56:22 -0500
From: Denis Laventure <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: RE: ISC-dhcp subnet limit?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Glad I could help!
Denis
De : [email protected] [mailto:[email protected]]
De la part de Rob Morin
Envoy? : 10 f?vrier 2016 08:07
? : Users of ISC DHCP <[email protected]>
Objet : Re: ISC-dhcp subnet limit?
Hey Denis, just wanted to let you know that all is well with that new dhcp
server now. Running 4.3.3-p1
I increased the lease_hash number and added the debug stuff.. Also i increased
some system defaults to the below..
net.core.rmem_max=33554432
net.core.wmem_max=33554432
net.core.rmem_default=33554432
net.core.wmem_default=33554432
net.ipv4.udp_rmem_min=16384
net.ipv4.udp_wmem_min=16384
net.core.netdev_max_backlog=2000
Memory use increased a bit , but still have 2.5 gigs left, and its not swapping
Throw in the ramdisk, and hopefully i will be good for a while...
Once i get up the new secondary server we will go back to the normal failover
config.
Thanks again for all your help!
Rob Morin
Montreal, Canada
On 2016-02-04 2:50 PM, Denis Laventure wrote:
It should be ok like that I think.
Denis
De : [email protected]<mailto:[email protected]>
[mailto:[email protected]] De la part de Rob Morin
Envoy? : 4 f?vrier 2016 14:04
? : Users of ISC DHCP
<[email protected]><mailto:[email protected]>
Objet : Re: ISC-dhcp subnet limit?
Thanks for the quick reply Denis..
So i found a number which seems to be ok, I have 8 gigs of ram on that dhcp
server... at its current full tilt it uses 4
Feb 4 13:59:05 localhost dhcpd: Lease IP hash: Contents/Size (%):
1664250/1800017 (92%). Min/max: 0/2
Feb 4 13:59:05 localhost dhcpd: Lease UID hash: Contents/Size (%): 0/1800017
(0%). Min/max: 0/0
Feb 4 13:59:05 localhost dhcpd: Lease HW hash: Contents/Size (%): 0/1800017
(0%). Min/max: 0/0
What do you think?
Rob Morin
Montreal, Canada
On 2016-02-04 1:50 PM, Denis Laventure wrote:
Hi Rob,
I don't remember having any problem with someone not getting a lease. If that
was the case, the stock apt-get version would have done the same thing with the
default value anyway.
I think you should have a number under 100% so yeah I would up that number
(find a prime number above 1664250). A value that high will probably impact the
memory used by the daemon.
Denis
De : [email protected]<mailto:[email protected]>
[mailto:[email protected]] De la part de Rob Morin
Envoy? : 4 f?vrier 2016 13:44
? : Users of ISC DHCP
<[email protected]><mailto:[email protected]>
Objet : Re: ISC-dhcp subnet limit?
Would a too low lease_hash prevent users from getting a lease or IP at a
certain point? I had this issue last night where i was running on stock apt-get
install and after we moved one more controller to that server , people started
not being able to get leases....
With the increase of lease_has after a restart i get this
Feb 4 13:41:49 localhost dhcpd: Lease IP hash: Contents/Size (%):
1664250/400009 (416%). Min/max: 3/5
Feb 4 13:41:49 localhost dhcpd: Lease UID hash: Contents/Size (%): 0/400009
(0%). Min/max: 0/0
Feb 4 13:41:49 localhost dhcpd: Lease HW hash: Contents/Size (%): 0/400009
(0%). Min/max: 0/0
Feb 4 13:41:49 localhost dhcpd: Server starting service.
So i should up it until i have space??
Rob Morin
Gestionnaire des syst?mes | Senior Systems Administrator
Tel: 514 385-4448 #174
DATAVALET.COM
5275, chemin Queen-Mary, Montr?al (Qu?bec) H3W 1Y3 Canada
CE COURRIEL AINSI QUE CES DOCUMENTS JOINTS peuvent contenir des renseignements
confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire d?sign?,
veuillez nous en informer imm?diatement et effacer toute copie. Merci.
THIS EMAIL AND THE DOCUMENTS ATTACHED may contain privileged or confidential
information. If the reader of this message is not the intended recipient,
please notify the sender immediately and delete the original message. Thank you.
On 2016-01-29 9:58 AM, Denis Laventure wrote:
Hi Rob,
I can't help for issue on your interface problem but I think I can help with
the performance.
I used to have performance problem with my failover setup and someone at ISC
told me to change some value in the code to get debug information about memory
usage.
Add this to the file "includes/dhcpd.h"
#if !defined (REPORT_HASH_PERFORMANCE)
# define REPORT_HASH_PERFORMANCE 1
#endif
Compile and start the daemon and you should get something like this on screen
and in the log:
dhcpd: DHCP name hash: Contents/Size (%): 106/401 (26%). Min/max: 0/2
dhcpd: DHCP code hash: Contents/Size (%): 106/254 (41%). Min/max: 0/1
dhcpd: NWIP name hash: Contents/Size (%): 11/17 (64%). Min/max: 0/2
dhcpd: NWIP code hash: Contents/Size (%): 11/17 (64%). Min/max: 0/1
dhcpd: FQDN name hash: Contents/Size (%): 8/13 (61%). Min/max: 0/2
dhcpd: FQDN code hash: Contents/Size (%): 8/13 (61%). Min/max: 0/1
dhcpd: VIVCO name hash: Contents/Size (%): 1/127 (0%). Min/max: 0/1
dhcpd: VIVCO code hash: Contents/Size (%): 1/127 (0%). Min/max: 0/1
dhcpd: VIVSO name hash: Contents/Size (%): 1/127 (0%). Min/max: 0/1
dhcpd: VIVSO code hash: Contents/Size (%): 1/127 (0%). Min/max: 0/1
dhcpd: ISC name hash: Contents/Size (%): 2/3 (66%). Min/max: 0/1
dhcpd: ISC code hash: Contents/Size (%): 2/3 (66%). Min/max: 0/1
dhcpd: Relay Agent name hash: Contents/Size (%): 5/11 (45%). Min/max: 0/1
dhcpd: Relay Agent code hash: Contents/Size (%): 5/11 (45%). Min/max: 0/1
dhcpd: Server-Config Option name hash: Contents/Size (%): 67/136 (49%).
Min/max: 0/4
dhcpd: Server-Config Option code hash: Contents/Size (%): 67/136 (49%).
Min/max: 0/1
dhcpd: data: hardware: no raw packet or lease is available
dhcpd: data: hardware: no raw packet or lease is available
dhcpd: data: hardware: no raw packet or lease is available
dhcpd: data: hardware: no raw packet or lease is available
dhcpd: data: hardware: no raw packet or lease is available
dhcpd: data: hardware: no raw packet or lease is available
dhcpd: Config file: /dhcpd/dhcpd.conf
dhcpd: Database file: /dhcpd/dhcpd.leases
dhcpd: PID file: /var/run/dhcpd.pid
dhcpd: Wrote 0 class decls to leases file.
dhcpd: Wrote 0 deleted host decls to leases file.
dhcpd: Wrote 0 new dynamic host decls to leases file.
dhcpd: Wrote 48578 leases to leases file.
dhcpd: Host HW hash: Contents/Size (%): 1420/22501 (6%). Min/max: 0/4
dhcpd: Host UID hash: No table.
dhcpd: Lease IP hash: Contents/Size (%): 70324/100003 (70%). Min/max: 0/5
dhcpd: Lease UID hash: Contents/Size (%): 8708/100003 (8%). Min/max: 0/3
dhcpd: Lease HW hash: Contents/Size (%): 9036/100003 (9%). Min/max: 0/3
"Lease IP hash" is where you should look.
By default the server use a lease hash size value of 100003. I had over 350000
leases so I was exceeding that value and the server was very slow to start.
To change the size you must edit the file "includes/dhcpd.h" and find
LEASE_HASH_SIZE and replace the value. This value must be a prime number (I
used 400009).
-# define LEASE_HASH_SIZE 100003
+# define LEASE_HASH_SIZE 400009
Compile and start again. That was the answer for me.
One other thing with the failover setup, the peer will always be in recover
state when starting for the duration of the "MCLT" (time in second) in your
failover definition (1800 in your case), so it will be in recover start for 30
minutes. I use 300 (5 minutes).
Le texte aurait ?t? plus facile ? ?crire en fran?ais mais comme la liste est en
anglais et que ?a peut aider d'autres personnes alors je me suis forc?. En
esp?rant que ce soit clair pour toi !
Denis Laventure
Universit? du Qu?bec ? Chicoutimi
De : [email protected]<mailto:[email protected]>
[mailto:[email protected]] De la part de Rob Morin
Envoy? : 27 janvier 2016 20:12
? : [email protected]<mailto:[email protected]>
Objet : ISC-dhcp subnet limit?
Hello all, my first post here, so please be gentle :)
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
Montreal Canada
_______________________________________________
dhcp-users mailing list
[email protected]<mailto:[email protected]>
https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160210/e6728ce1/attachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 88, Issue 15
******************************************
