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: INFORM getting different values for the same option than
REQUEST (Friesen, Don MTIC:EX)
2. Re: Failover : Balancing a one-ip pool (!) (Chris Buxton)
3. Different NTP options on peers ([email protected])
4. Re: Failover : Balancing a one-ip pool (!) (Nicolas Ecarnot)
5. RE: Different NTP options on peers (Stier, Matthew)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Feb 2016 14:12:25 +0000
From: "Friesen, Don MTIC:EX" <[email protected]>
To: "'Users of ISC DHCP'" <[email protected]>
Subject: RE: INFORM getting different values for the same option than
REQUEST
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Yes, that's what we determined. That it was the Windows client's fault for
updating network information when requesting additional browser related data.
Don Friesen
-----Original Message-----
Glenn Satchell <[email protected]> wrote:
> I'm pretty sure this is expected behaviour. The INFORM request doesn't
> have enough information for the server to work out pool memberships.
I vaguely recall from past discussions that this is considered wrong but
mandated by the RFCs. Specifically, the server is not allowed to look at any
lease the client has been given when responding to an Inform message - and
given that the client may not send all the same information, this means the
server may respond with different answers.
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 2
Date: Tue, 16 Feb 2016 06:28:38 -0800
From: Chris Buxton <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Failover : Balancing a one-ip pool (!)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Nicolas,
I have a couple of thoughts about this.
1. When using a hub-and-spoke architecture, I find its better to let the spokes
be primary and the hub be secondary for all its peers.
2. Singleton pools like you're describing don't really work for the failover
protocol. Only the primary server will ever be able to answer. You won't see
any benefit in terms of load balancing or even fault tolerance. You're better
off configuring these without failover; if you really can't use reservations
(host declarations with fixed addresses), then just define each singleton pool
identically on each server, without failover (as long as you're certain there
will never be two clients asking for that one address).
Regards,
Chris
> On Feb 16, 2016, at 12:05 AM, Nicolas Ecarnot <[email protected]> wrote:
>
> Hello,
>
> This message is less a question than a discussion, because we're happy with
> our setup for years and maybe won't change soon, unless you answer with a
> nice new idea.
>
> We have 7 DHCP servers in a star pattern : one central and 6 around.
> The center is the primary peer for the others, for around 400 pools and lots
> of subnets.
>
> Around 30 pools are classical ones, and balancing fine.
> The numerous other ones are one-ip pools.
>
> These one-ip pools are made this way in order to :
> - benefit from failover setup. There seems to be no other way, failover can
> only be setup on pools
> - apply classID rules by pool, working only on one machine by subnet. We
> don't want to use static reservations for that.
>
> All this is working like a charm, but a small concern of mine is the periodic
> balancing (60 seconds by default, we raised it to 120) where I see that the
> servers are trying and obviously failing to balance the only one ip between
> peers.
> This is not very bad, except it is eating CPU and flooding the logs.
>
> But I post here this message in hope someone could advice a better way to do.
> Because I read lots of doc about balancing and the way ISC DHCPD is managing
> this sounds clever and I'd be happy to use it in a proper way.
>
> Of course, external constraints exist forcing me to use this weird one-ip
> pools setup. But I'll fight to change them if someone replies with nice hints
> I may have missed.
>
> Regards,
>
> --
> Nicolas ECARNOT
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
------------------------------
Message: 3
Date: Tue, 16 Feb 2016 10:41:24 -0500
From: "[email protected]" <[email protected]>
To: [email protected]
Subject: Different NTP options on peers
Message-ID:
<cacyag3m94gyptpiunij6u5uxyjl+fp34eqbo-duak7mo17g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have a pair of DHCP servers that specify 2 NTP servers for each pool. The
pool definitions are exactly the same on each peer, and they are set to
split 128. We have recently set up 2 additional NTP servers. I know the
order of the NTP servers listed is in order of preference. Is there a
recommended practice in order for load balancing the clients usage of the
NTP servers? All of the NTP servers are the same strata. Does it make sense
to define different NTP server options on each DHCP server? For example on
DHCP1 use NTP1 and NTP2 and on DHCP2 use NTP3 and NTP4. Or does it make
more sense to set the NTP servers in a round-robin fashion in pool
definitions? For example pool1 defines NTP1, NTP2, NTP3, NTP4, then pool2
defines NTP2, NTP3, NTP4, NTP1, etc...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160216/ef24f1ee/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 16 Feb 2016 16:46:45 +0100
From: Nicolas Ecarnot <[email protected]>
To: [email protected]
Subject: Re: Failover : Balancing a one-ip pool (!)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Thank you Chris for your answers.
See below some comments.
Le 16/02/2016 15:28, Chris Buxton a ?crit :
> Nicolas,
>
> I have a couple of thoughts about this.
>
> 1. When using a hub-and-spoke architecture, I find its better to let
> the spokes be primary and the hub be secondary for all its peers.
We lived this way (spokes primary and hub secondary) for 6 years.
Actually, we saw no real difference, neither in term of reliability not
performance.
> 2. Singleton pools like you're describing don't really work for the
> failover protocol. Only the primary server will ever be able to
> answer. You won't see any benefit in terms of load balancing or even
> fault tolerance.
Though I understand your answer about load balancing, I counldn't agree
about fault tolerance benefit:
On every remote site, we configure its router to relay the queries
towards 2 servers. When one of the server is down, the other correctly
replies, even to one-ip pools queries.
> You're better off configuring these without
> failover; if you really can't use reservations (host declarations
> with fixed addresses), then just define each singleton pool
> identically on each server, without failover (as long as you're
> certain there will never be two clients asking for that one
> address).
I agree, that could make complete sense, and would be cleaner.
>
> Regards, Chris
>
>> On Feb 16, 2016, at 12:05 AM, Nicolas Ecarnot <[email protected]>
>> wrote:
>>
>> Hello,
>>
>> This message is less a question than a discussion, because we're
>> happy with our setup for years and maybe won't change soon, unless
>> you answer with a nice new idea.
>>
>> We have 7 DHCP servers in a star pattern : one central and 6
>> around. The center is the primary peer for the others, for around
>> 400 pools and lots of subnets.
>>
>> Around 30 pools are classical ones, and balancing fine. The
>> numerous other ones are one-ip pools.
>>
>> These one-ip pools are made this way in order to : - benefit from
>> failover setup. There seems to be no other way, failover can only
>> be setup on pools - apply classID rules by pool, working only on
>> one machine by subnet. We don't want to use static reservations for
>> that.
>>
>> All this is working like a charm, but a small concern of mine is
>> the periodic balancing (60 seconds by default, we raised it to 120)
>> where I see that the servers are trying and obviously failing to
>> balance the only one ip between peers. This is not very bad, except
>> it is eating CPU and flooding the logs.
>>
>> But I post here this message in hope someone could advice a better
>> way to do. Because I read lots of doc about balancing and the way
>> ISC DHCPD is managing this sounds clever and I'd be happy to use it
>> in a proper way.
>>
>> Of course, external constraints exist forcing me to use this weird
>> one-ip pools setup. But I'll fight to change them if someone
>> replies with nice hints I may have missed.
>>
>> Regards,
>>
>> -- Nicolas ECARNOT _______________________________________________
>> dhcp-users mailing list [email protected]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
> _______________________________________________ dhcp-users mailing
> list [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
--
Nicolas ECARNOT
------------------------------
Message: 5
Date: Tue, 16 Feb 2016 16:15:36 +0000
From: "Stier, Matthew" <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: RE: Different NTP options on peers
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
No need. The NTP client will query all available NTP services and choose one
to follow. This query/choose continues as long as the client is running, so it
knows it is getting the best time source available. As the time service
stabilize, the NTP client will slowly increase the time period between queries,
to reduce the load on the NTP servers. If there is a disruption, the client
will simply reset to a short time period, and when thing settle down again, it
will again, slowly increase the time period between queries.
Run ?ntpq ?p? on your NTP client. The ?poll? column is the time period between
polling (On my systems, it is 1024 seconds). The ?when? column is the number
of seconds since the last poll of the system in the ?remote? column. The
asterisk in the first column, signifies the selected server. A plus signifies
a selected server. A minus signifies a discarded server (good, but outside the
balance of the selected servers) and a space signifies a system discarded for
high stratum level.
From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Tuesday, February 16, 2016 9:41 AM
To: [email protected]
Subject: Different NTP options on peers
I have a pair of DHCP servers that specify 2 NTP servers for each pool. The
pool definitions are exactly the same on each peer, and they are set to split
128. We have recently set up 2 additional NTP servers. I know the order of the
NTP servers listed is in order of preference. Is there a recommended practice
in order for load balancing the clients usage of the NTP servers? All of the
NTP servers are the same strata. Does it make sense to define different NTP
server options on each DHCP server? For example on DHCP1 use NTP1 and NTP2 and
on DHCP2 use NTP3 and NTP4. Or does it make more sense to set the NTP servers
in a round-robin fashion in pool definitions? For example pool1 defines NTP1,
NTP2, NTP3, NTP4, then pool2 defines NTP2, NTP3, NTP4, NTP1, etc...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160216/ffd4a515/attachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 88, Issue 20
******************************************
