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. IPv6 DHCP Routing (spaceman)
2. Re: failover, partner-down state, MCLT and rewind binding
(Glenn Satchell)
3. Re: failover, partner-down state, MCLT and rewind binding
(Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Nov 2015 21:07:15 +0000
From: spaceman <[email protected]>
To: [email protected]
Subject: IPv6 DHCP Routing
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
I have the following IPv6 subnet 2001:470:1f09:800::/64 and these addresses
are handed out correctly by dhcpd. However a single windows machine I have
insists on send all traffic destined for a 2001:470:1f09:800::/64 address to
the gateway when it should be sent straight to the device on the network.
For example it should be:
2001:470:1f09:800::10 --> 2001:470:1f09:800::5
but with this machine its:
2001:470:1f09:800::10 --> 2001:470:1f09:800::1 --> 2001:470:1f09:800::5
The IP of the gateway is 2001:470:1f09:800::1.
How do I avoid this?
Regards,
spaceman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151116/4e2b44d7/attachment-0001.bin>
------------------------------
Message: 2
Date: Tue, 17 Nov 2015 16:28:16 +1100
From: "Glenn Satchell" <[email protected]>
To: "Users of ISC DHCP" <[email protected]>
Subject: Re: failover, partner-down state, MCLT and rewind binding
Message-ID:
<[email protected]>
Content-Type: text/plain;charset=iso-8859-1
Yes, a small ratio of MCLT to lease time is right. I use 30 min for MCLT
and 24 hours for lease time.
I have seen discussion about really short lease times (< 1 min) doing
crazy things with some clients, ie the client has not settled and the
lease expires, so I wouldn't make your MCLT too short. You need to balance
this with how many clients you have and expect them all to try to renew
during the MCLT period. So really work out how many renews per second one
of your servers can cope with, multiply that by the number of clients and
it will give you the minimum MCLT that your server can handle.
On the other hand MCLT only affects new leases, and partner-down
situations. Normal operations will handle out default length leases.
Don't know about the last two points.
regards,
-glenn
On Tue, November 17, 2015 4:52 am, Gregory Sloop wrote:
> Top posting.
>
> So there wasn't a lot of follow-up. Let me bump this and I'll summarize
> and clarify. [In order of importance to me.]
>
> 1) MCLT time. Is there any benefit, other than performance/load on the
> server, to pick longer MCLT times vs shorter?
>
> 1A) It seems to me that in a tight lease situation, having the MCLT time
> be some fairly small fraction of the DHCP lease time makes sense.
> Anecdotally, something like 10-20% seems about right. [Again, assuming
> your DHCP servers can handle the load.] Is there any comment or
> observation that might illuminate that thinking from anyone?
>
> 2) How does the newish lease rewind feature work? Does rewind work only in
> communications interrupted mode? [vs partner down mode]
>
> 3) Is there a way, other than examining the leases file, to see if a lease
> was "rewound" - say be reviewing the log files?
>
> Thanks again.
>
>
>
>
>
>
> CA> On 10/11/2015 01:43, Gregory Sloop wrote:
>>> So, I'm looking for a little more understanding. I had an outage last
>>> week that didn't work out so well.
>>> I've had sort-of-similar problems in the past with this setup, and I
>>> *think* I know some of what happened this time, but wanting
>>> confirmation.
>
>>> After the last similar outage, I knew we needed to put the surviving
>>> peer in "partner-down" mode, and this, along with the new "rewind state
>
> CA> Hi Greg,
>
> CA> I've just (belatedly, remembering that they had been written, but not
> CA> able to find them readily), made the two KB articles below
> published/public.
>
> CA> Hoping that they help - particularly around tweaking the default
> CA> failover settings and why a very small MCLT is not necessarily a good
> idea.
>
> CA>
> https://kb.isc.org/article/AA-00268/31/DHCP-Failover-and-MCLT-configuration-implications.html
>
> CA>
> https://kb.isc.org/article/AA-00327/31/Why-are-the-lease-times-short-and-random-during-communication-interrupted-state.html
>
> CA> Cathy
>
> Thanks Cathy. But those documents don't add a lot of light to the
> discussion.
>
> In specific:
>
> 1) I understand why the lease extensions are different times and not just
> the MCLT time. BUT - the lease extensions should *NEVER* be shorter than
> the MCLT time, right? [They'll be of varying lengths, because there
> will/may be varying time left on the original leases - from before the
> fail-over pair went down. But once all the "original" leases have expired,
> all the remaining leases should be MCLT time, right?]
>
> 2) I *think* what I read essentially verifies what I said about MCLT
> times. If you use really short MCLT times, it's going to put extra load on
> the environment [network and servers] in even regular mode. [This is
> because the initial lease, even when running in "communication-normal"
> mode is for the MCLT time. _After that initial lease_, however, clients
> will get the regular DHCP lease time. So, I realize that _really_ short
> MCLT times can adversely impact the performance of your servers both in
> communications-normal mode, as well as in interrupted mode [as well as
> other recovery or failure modes]. However, I don't see any indications,
> _other than performance_, to select longer MCLT times. Do I understand
> that correctly?
>
> So, is there some reason/benefit, other than performance [load on network,
> clients and servers] to select longer MCLT times?
>
> And as a corollary, I think MCLT times, provided your server can handle
> the load, should be some small fraction of the DHCP lease time. My initial
> thought - which wasn't encumbered by a lot of deep thought - is around
> 20-25% of the regular DHCP lease time. That would mean that the
> server/network should be able to sustain about four-five times the regular
> load in a failure situation.
>
> Other than answers to the above direct questions - I'm happy for any wider
> ranging discussion on the thread.
>
> -Greg
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Tue, 17 Nov 2015 08:05:03 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: failover, partner-down state, MCLT and rewind binding
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Glenn Satchell <[email protected]> wrote:
> So really work out how many renews per second one of your servers can cope
> with, multiply that by the number of clients and it will give you the minimum
> MCLT that your server can handle.
I think you meant divide there - easy mistake to make when manually rearranging
a formula in your head.
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 85, Issue 18
******************************************
