Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
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
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Question (Leslie Rhorer)
2. Re: Question (Leslie Rhorer)
3. Re: Question (Leslie Rhorer)
4. Re: Question (Gregory Sloop)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Jun 2022 08:23:31 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <a2503d6a-4961-78a6-733c-fd7e4593c...@siliconventures.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 6/3/2022 5:03 AM, Glenn Satchell wrote:
> ok, now we are getting somewhere...
>
> Note startup error messages should be in syslog, or perhaps "systemctl
> status isc-dhcp-server" will show them.
??? I have it logging to /var/log/dhcp/dhcp.log with logrotate enabled
for the directory, but that doesn't really matter.
>
> So having the "wrong" network range would cause issues, the requests
> come in from a certain subnet, and the server tries to match the
> requests to a subnet definition, but of course on the secondary server
> it doesn't have 192.168.0.0 so it can't offer an address. That
> explains why there is no requests being served.
??? I think maybe you lost me.? Both are on the same /23 subnet, just
in one case not where I wanted them.? Both 192.168.0.200 - 240 and
192.168.1.220 - 240 are on 192.168.0/23.
>
> Next in the failover peer section, both config files have "primary".
> One of them needs to be "secondary"
??? How the heck did that happen?? I could swear one was set to
"secondary".
> , eg changing backup to be the back up server should have this as the
> failover peer setting. mclt is only specified on? primary. This would
> definitely be causing problems now as you have top primary failover
> peers for the same subnet. Before there were two different subnets, so
> no clashes as failover is done on a subnet by subnet basis. You could
> have different peers for each subnet for example.
??? Hmm, OK, maybe I follow.
> With this change I think it should work now... fingers crossed :)
>
??? Yeah.? What you said.
------------------------------
Message: 2
Date: Fri, 3 Jun 2022 08:48:32 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <ae3ba135-bba9-d9cf-9cd0-af6994774...@siliconventures.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
??? Phew! 'Much better.? I think.? I haven't seen any responses going
out from? the seconday, but then only 4 have gone out so far from the
primary.? It says the max mis-bal is 6, which I presume 6 means might go
out one interface before the other catches up?? We will let it run an
hour or so and see if the secondary catches up, and if the leases files
are updated.
On 6/3/2022 8:23 AM, Leslie Rhorer wrote:
>
> On 6/3/2022 5:03 AM, Glenn Satchell wrote:
>> ok, now we are getting somewhere...
>>
>> Note startup error messages should be in syslog, or perhaps
>> "systemctl status isc-dhcp-server" will show them.
> ??? I have it logging to /var/log/dhcp/dhcp.log with logrotate enabled
> for the directory, but that doesn't really matter.
>>
>> So having the "wrong" network range would cause issues, the requests
>> come in from a certain subnet, and the server tries to match the
>> requests to a subnet definition, but of course on the secondary
>> server it doesn't have 192.168.0.0 so it can't offer an address. That
>> explains why there is no requests being served.
> ??? I think maybe you lost me.? Both are on the same /23 subnet, just
> in one case not where I wanted them.? Both 192.168.0.200 - 240 and
> 192.168.1.220 - 240 are on 192.168.0/23.
>>
>> Next in the failover peer section, both config files have "primary".
>> One of them needs to be "secondary"
> ??? How the heck did that happen?? I could swear one was set to
> "secondary".
>> , eg changing backup to be the back up server should have this as the
>> failover peer setting. mclt is only specified on? primary. This would
>> definitely be causing problems now as you have top primary failover
>> peers for the same subnet. Before there were two different subnets,
>> so no clashes as failover is done on a subnet by subnet basis. You
>> could have different peers for each subnet for example.
> ??? Hmm, OK, maybe I follow.
>> With this change I think it should work now... fingers crossed :)
>>
> ??? Yeah.? What you said.
------------------------------
Message: 3
Date: Fri, 3 Jun 2022 09:03:37 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <c53b3e62-0cc7-e923-55ad-dcfc599e2...@siliconventures.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
??? Hmm.? I am not seeing any responses going out from the backup
server, but when I check, I don't see any incoming requests, either.?
Shouldn't the requests be broadcast packets?? With the primary shut
down, requests are coming in to the primary and no responses are going out.
On 6/3/2022 8:48 AM, Leslie Rhorer wrote:
> Phew! 'Much better.? I think.? I haven't seen any responses going out
> from? the seconday, but then only 4 have gone out so far from the
> primary.? It says the max mis-bal is 6, which I presume 6 means might
> go out one interface before the other catches up?? We will let it run
> an hour or so and see if the secondary catches up, and if the leases
> files are updated.
>
> On 6/3/2022 8:23 AM, Leslie Rhorer wrote:
>>
>> On 6/3/2022 5:03 AM, Glenn Satchell wrote:
>>> ok, now we are getting somewhere...
>>>
>>> Note startup error messages should be in syslog, or perhaps
>>> "systemctl status isc-dhcp-server" will show them.
>> ??? I have it logging to /var/log/dhcp/dhcp.log with logrotate
>> enabled for the directory, but that doesn't really matter.
>>>
>>> So having the "wrong" network range would cause issues, the requests
>>> come in from a certain subnet, and the server tries to match the
>>> requests to a subnet definition, but of course on the secondary
>>> server it doesn't have 192.168.0.0 so it can't offer an address.
>>> That explains why there is no requests being served.
>> ??? I think maybe you lost me.? Both are on the same /23 subnet, just
>> in one case not where I wanted them.? Both 192.168.0.200 - 240 and
>> 192.168.1.220 - 240 are on 192.168.0/23.
>>>
>>> Next in the failover peer section, both config files have "primary".
>>> One of them needs to be "secondary"
>> ??? How the heck did that happen?? I could swear one was set to
>> "secondary".
>>> , eg changing backup to be the back up server should have this as
>>> the failover peer setting. mclt is only specified on? primary. This
>>> would definitely be causing problems now as you have top primary
>>> failover peers for the same subnet. Before there were two different
>>> subnets, so no clashes as failover is done on a subnet by subnet
>>> basis. You could have different peers for each subnet for example.
>> ??? Hmm, OK, maybe I follow.
>>> With this change I think it should work now... fingers crossed :)
>>>
>> ??? Yeah.? What you said.
------------------------------
Message: 4
Date: Fri, 3 Jun 2022 08:39:12 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Question
Message-ID: <8759142.20220603083...@sloop.net>
Content-Type: text/plain; charset="utf-8"
Are you *sure* that both machines are on the same broadcast network??
(Or at least have a dhcp helper that will relay dhcp broadcasts?)
?
Just because the peers can talk to each other (finally) doesn't mean they're on
the same broadcast network.
?
(And, as far as packet capture. I doubt that you need 10G between the peers -
so you could always force the ports to something slower - 100Mbps would
probably be way more bandwidth than peer communication/leases really needs -
then a packet capture should be easy. (And once you've got it working, turn the
speed back up, if you really want/need it.)
?
Really short leases can help drive up traffic and allow you to see more lease
cycles more quickly - good for testing - probably not so great for production.
?
-Greg
??
> ???? Hmm.? I am not seeing any responses going out from the backup server,
> but when I check, I don't see any incoming requests, either.? Shouldn't the
> requests be broadcast packets?? With the primary shut down, requests are
> coming in to the primary and no responses are going out.
> On 6/3/2022 8:48 AM, Leslie Rhorer wrote:
>> Phew! 'Much better.? I think.? I haven't seen any responses going out >
>> from? the seconday, but then only 4 have gone out so far from the >
>> primary.? It says the max mis-bal is 6, which I presume 6 means might > go
>> out one interface before the other catches up?? We will let it run > an hour
>> or so and see if the secondary catches up, and if the leases > files are
>> updated.
>> On 6/3/2022 8:23 AM, Leslie Rhorer wrote:
>>> On 6/3/2022 5:03 AM, Glenn Satchell wrote:
>>>> ok, now we are getting somewhere...
>>>> Note startup error messages should be in syslog, or perhaps >>> "systemctl
>>>> status isc-dhcp-server" will show them.
>>> ??? I have it logging to /var/log/dhcp/dhcp.log with logrotate >> enabled
>>> for the directory, but that doesn't really matter.
>>>> So having the "wrong" network range would cause issues, the requests >>>
>>>> come in from a certain subnet, and the server tries to match the >>>
>>>> requests to a subnet definition, but of course on the secondary >>> server
>>>> it doesn't have 192.168.0.0 so it can't offer an address. >>> That
>>>> explains why there is no requests being served.
>>> ??? I think maybe you lost me.? Both are on the same /23 subnet, just >> in
>>> one case not where I wanted them.? Both 192.168.0.200 - 240 and >>
>>> 192.168.1.220 - 240 are on 192.168.0/23.
>>>> Next in the failover peer section, both config files have "primary". >>>
>>>> One of them needs to be "secondary"
>>> ??? How the heck did that happen?? I could swear one was set to >>
>>> "secondary".
>>>> , eg changing backup to be the back up server should have this as >>> the
>>>> failover peer setting. mclt is only specified on? primary. This >>> would
>>>> definitely be causing problems now as you have top primary >>> failover
>>>> peers for the same subnet. Before there were two different >>> subnets, so
>>>> no clashes as failover is done on a subnet by subnet >>> basis. You could
>>>> have different peers for each subnet for example.
>>> ??? Hmm, OK, maybe I follow.
>>>> With this change I think it should work now... fingers crossed :)
>>> ??? Yeah.? What you said.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/8d2b7c10/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 164, Issue 11
*******************************************
