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: failover, partner-down state, MCLT and rewind binding
(Gregory Sloop)
2. Re: failover, partner-down state, MCLT and rewind binding
(Gregory Sloop)
3. server with two NICs and relayed to (lejeczek)
4. Re: server with two NICs and relayed to (Simon Hobson)
5. Re: server with two NICs and relayed to (lejeczek)
6. Re: server with two NICs and relayed to (Niall O'Reilly)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Nov 2015 07:50:05 -0800
From: Gregory Sloop <[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-15"
SH> Gregory Sloop <[email protected]> wrote:
>> Fairly quickly, got the secondary back up.
>> It handled all it's assigned leases fine, as far as I can tell. It then
>> handed out all the remaining pool leases it had. Then it ran out of leases.
>> I expected it to start recovering the leases from the peer [primary] at this
>> point, and extend [rewind] the leases the primary had already issued.
>> While I'm not sure how the "rewind" provision worked - we were getting "peer
>> holds all free leases" messages for quite a while.
>> I didn't think this should be happening - but then I looked at the MCLT time
>> and it was set to 1800 [30m]
SH> It is not clear, did you set that server into "partner down" mode ?
I did set the "still up" server in partner-down mode. I verified it was in
partner down mode via the OMAPI tool too.
But given what I read in the docs, about MCLT, I think it was operating
normally - at least as far as the free address pool, and reclaiming addresses
from the "down" server. [i.e. It still has to wait the MCLT time before
reclaiming them. Since my MCLT time was as long as my lease time, leases were
expiring and the clients unable to get another address for 30m+ because the
partner-down server couldn't reclaim the split pool for 30 minutes after going
into partner down mode. (And we didn't get the secondary server up and into
partner down mode until after most all of the active leases had actually
expired. And yes, it is probably an indication that a longer DHCP lease time
would be helpful, in addition to shortening the MCLT.)]
I still need/want more information about how the rewind process works, if
anyone has it.
[Is there a way, in the log files, to determine if and/or what clients got a
"rewind" lease extension? I don't have a copy of the leases file at the time of
the problem, so I can't look there for any data. So, I'm hoping there's
evidence of "rewind" activity in the log files, which I can retrospectively
review.]
TIA
-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151110/00f8eafe/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 10 Nov 2015 08:23:00 -0800
From: Gregory Sloop <[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-15"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20151110/ca3c96ad/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 10 Nov 2015 16:59:17 +0000
From: lejeczek <[email protected]>
To: "[email protected]" <[email protected]>
Subject: server with two NICs and relayed to
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
hi everybody
I'm looking at my setup and got stuck
I have a box with two NICs on the same subnet, and another
box similar, also two NICs on one subnet, all four NICs are
on the same subnet.
Now, that second box has also a virtual NIC (libvirtd's
bridge) and VMs guests are using it, traffic is routed via
1st NIC to that virtual net. This second box dhcrelays to
the first box(dhcpd).
I see box-dhcrelay forwards to box-dhcpd, I see box-dhcpd
receives and offers a lease but that VM guest does not get it.
I have policy routing manually set in place so both boxes
can pings each other all NICs. (including virtual NIC on the
box-dhcrelay)
Moreover that VM guest can ping both boxes' all NICs when
set to manual.
It's RHEL7 and I'm only trying IPv4.
I'm hoping some can rule out (or suggest what might be
broken in) DHCP config.
I see those offers box-dhcpd makes are exactly for the
subnet of box-dhcrelay's virtual subnet.
It's a pickle. An expert's thought would be great to hear.
------------------------------
Message: 4
Date: Tue, 10 Nov 2015 17:29:27 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: server with two NICs and relayed to
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
lejeczek <[email protected]> wrote:
> hi everybody
> Now, that second box has also a virtual NIC (libvirtd's bridge) and VMs
> guests are using it, traffic is routed via 1st NIC to that virtual net. This
> second box dhcrelays to the first box(dhcpd).
>
> I see box-dhcrelay forwards to box-dhcpd, I see box-dhcpd receives and offers
> a lease but that VM guest does not get it.
Follow the packets. Use your preferred packet sniffing tool to see where the
packet gets lost. Does it leave the DHCP server ? Does it reach the other
server ? Is there a firewall that might block it ? Does the relay log that it's
received it ? Does it leave the (virtual) nic from the relay ? Does it reach
the (virtual) nic on the client ?
All you know at the moment is "it doesn't work". Follow the trail, and then
you'll know that it fails at a specific location and you can then try and work
out why.
BTW - I don't like the sound of "policy routing", for almost every non-broken
network it is not required.
------------------------------
Message: 5
Date: Tue, 10 Nov 2015 17:55:30 +0000
From: lejeczek <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: server with two NICs and relayed to
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 10/11/15 17:29, Simon Hobson wrote:
> BTW - I don't like the sound of "policy routing", for almost every non-broken
> network it is not required.
but after looking it up I understand that if one wants to -
have a box two(or more) NICs on same one subnet and be able
to pass traffic from another subnet to such a box then one
must use/setup policy based routes, no?
what would you recommend to sniff the packets?
many thanks.
------------------------------
Message: 6
Date: Tue, 10 Nov 2015 18:31:19 +0000
From: "Niall O'Reilly" <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: server with two NICs and relayed to
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On Tue, 10 Nov 2015 17:55:30 +0000,
lejeczek wrote:
>
> what would you recommend to sniff the packets?
tcpdump
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 85, Issue 11
******************************************
