Question

[Gregory Sloop]

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-0001.htm>