Send dhcp-users mailing list submissions to
[email protected]
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.. :( (Shawn Routhier)
2. Re: Frustrated DHCP failover not working.. :( (Gregory Sloop)
3. Re: Frustrated DHCP failover not working.. :( (Shawn Routhier)
4. Re: dhcp-users Digest, Vol 88, Issue 11 (Klaus Vink Slott)
----------------------------------------------------------------------
Message: 1
Date: Wed, 10 Feb 2016 11:59:25 -0800
From: Shawn Routhier <[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=utf-8
> On Feb 10, 2016, at 11:37 AM, Attila Szalay <[email protected]> wrote:
>
> In the master node, you have this configuration option: split 128;
>
> This means, that half of the ip addresses are linked to the master and the
> secondary only own the other half.
This isn?t quite correct. The split option refers to how the two servers
handle incoming requests not how they allocate addresses between
them. 128 is splitting the hash buckets used to divide the clients
50 / 50.
>
> Of course time-to-time they rebalance the ip pools, but (if I remember
> correctly) it only happens after a timeout. So if the clients only reach one
> of the hosts, it is possible, that those host (temporally) run out of hosts.
The load balancing algorithm is used until the seconds field in the
request packet exceeds the value specified by ?load balance max seconds?
at which point either of the two servers will respond. As the seconds field
is the amount of time since the client started to request it will normally be
0 to start with and increment if there are time outs.
>
> This is because in normal operation (and with split 128, which means 50-50%)
> they run more likely as a load-balancing scenario than master-slave. (Also
> they split the mac address word to half too and the slave answer to one half
> of the macs and the master to the other))
On the original question. Setting your MCLT to 30 minutes while your default
lease time is 20 minutes
seems a bit strange to me.
Shawn
------------------------------
Message: 2
Date: Wed, 10 Feb 2016 12:35:39 -0800
From: Gregory Sloop <[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="utf-8"
SR> On the original question. Setting your MCLT to 30 minutes while
SR> your default lease time is 20 minutes
SR> seems a bit strange to me.
I certainly don't want to derail the search for a solution to the original
poster, but MCLT and it's proper setting isn't much discussed, and when I
brought it up some time back, Cathy Almond pointed at several FAQ's that were
not very useful. There was/is very little discussion about what a "reasonable"
forumla might be to determine what an optimal setting would be. [Cathy pointed
to FAQ's that _strongly_ suggested leaving it the default 30m. Which may be
where/why the OP left it at 30m. I believe this is quite wrong, but I'm
certainly no guru on dhcpd - so I hesitate to make authoritative pronouncements
about the subject. :) ]
In short, either here or in a new thread, I think a fuller discussion about
MCLT and fail-over operation. [Especially when a partner is down - either in
"communications-interrupted" mode, or in "partner-down mode."] I'd even perhaps
be willing to spend some time writing up a more informative FAQ on the issue -
provided I'm able to get a good understanding of how it works. If I've missed
some docs somewhere, I'd be more than glad to be pointed at them.
---
More to the point of this thread.
1) I don't recall my peer servers waiting the MCLT time to go from "waiting" to
"normal" - ever. [I could certainly be wrong about this - but I don't think
waiting the MCLT time would have made the servers go from waiting to normal.
I'd guess there's some kind of communication problem between the two. i.e.
Intermittant, too little bandwidth, etc. ]
2) In a fail-over situation, I'm not sure it's clear to Rob that both machines
will be splitting the pool and both will be responding to lease requests.
i.e. Fail-over isn't really a "fail-over" server. Which machine is primary and
which is secondary is, IMO, immaterial. [Other than one will have the "master"
config file, while the second will have the "peer."] Personally, I think it
ought to be called load-balancing with fail-over features. [Because in normal
operation, it's load balancing between the two servers, and when one is down,
it has features to continue operating on a single server with minimal
disruption (or if you're somewhat lucky, none).
My apologies if I'm wrong and #2 is clear to Rob.
-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160210/8fe186c4/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 10 Feb 2016 12:51:59 -0800
From: Shawn Routhier <[email protected]>
To: Greg Sloop <[email protected]>, Users of ISC DHCP
<[email protected]>
Subject: Re: Frustrated DHCP failover not working.. :(
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> On Feb 10, 2016, at 12:35 PM, Gregory Sloop <[email protected]> wrote:
>
>
>
> SR> On the original question. Setting your MCLT to 30 minutes while
> SR> your default lease time is 20 minutes
> SR> seems a bit strange to me.
>
> I certainly don't want to derail the search for a solution to the original
> poster, but MCLT and it's proper setting isn't much discussed, and when I
> brought it up some time back, Cathy Almond pointed at several FAQ's that were
> not very useful. There was/is very little discussion about what a
> "reasonable" forumla might be to determine what an optimal setting would be.
> [Cathy pointed to FAQ's that _strongly_ suggested leaving it the default 30m.
> Which may be where/why the OP left it at 30m. I believe this is quite wrong,
> but I'm certainly no guru on dhcpd - so I hesitate to make authoritative
> pronouncements about the subject. :) ]
>
> In short, either here or in a new thread, I think a fuller discussion about
> MCLT and fail-over operation. [Especially when a partner is down - either in
> "communications-interrupted" mode, or in "partner-down mode."] I'd even
> perhaps be willing to spend some time writing up a more informative FAQ on
> the issue - provided I'm able to get a good understanding of how it works. If
> I've missed some docs somewhere, I'd be more than glad to be pointed at them.
It?s difficult to try and cover all the different possibilities as people use
the servers in different ways.
I don?t think we have a great description on it.
>
> ---
> More to the point of this thread.
> 1) I don't recall my peer servers waiting the MCLT time to go from "waiting"
> to "normal" - ever. [I could certainly be wrong about this - but I don't
> think waiting the MCLT time would have made the servers go from waiting to
> normal. I'd guess there's some kind of communication problem between the two.
> i.e. Intermittant, too little bandwidth, etc. ]
There are some wait states that last for MCLT.
>
> 2) In a fail-over situation, I'm not sure it's clear to Rob that both
> machines will be splitting the pool and both will be responding to lease
> requests.
>
> i.e. Fail-over isn't really a "fail-over" server. Which machine is primary
> and which is secondary is, IMO, immaterial. [Other than one will have the
> "master" config file, while the second will have the "peer.?]
There is at least one major difference between primary and secondary. In the
transition
from active to free or backup. In normal operation only the primary can
transition the lease from active
to free (available on the primary) to backup (available on the secondary). The
rules change for partner-down
and we added an optimization for use in communications-interrupted.
> Personally, I think it ought to be called load-balancing with fail-over
> features. [Because in normal operation, it's load balancing between the two
> servers, and when one is down, it has features to continue operating on a
> single server with minimal disruption (or if you're somewhat lucky, none).
One can approximate failover by setting the split level to 0 or 256 in which
case one or the other server
will serve everything and the other will serve nothing until the load balance
max seconds value is
exceeded.
>
> My apologies if I'm wrong and #2 is clear to Rob.
>
> -Greg
>
> _______________________________________________
> dhcp-users mailing list
> [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/c861eb6d/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 Feb 2016 08:07:54 +0100
From: Klaus Vink Slott <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: dhcp-users Digest, Vol 88, Issue 11
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Hi
Just a brief note on you posting on the dhcp-users mailing list. Our
university uses some kind of Microsoft cloud service for spam filtering
and Your posting was caught as suspicious.
I have no knowledge on how MS filters work, but I would guess that
"miracles" followed with several ! is a trigger. You might want to
rephrase your tagline.
--
Regards
Klaus Vink Slott
HUMIT
University of Copenhagen
Den 10-02-2016 kl. 16:14 skrev David Elliott:
> Thanks Sten for the response.
> Client Id (option 61) is included in the DHCP Discover Packet and I
...
>
> -------------------------------------------------------------------------------------------------
> /God still works miracles!! We strive to provide you the best possible
> support./
> /If I have not provided you the excellent service you deserve, please
> contact my manager, Lynn Goolsby at [email protected] or
> 615-277-5892 <tel:615-277-5892>/
>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 88, Issue 17
******************************************
