<html><head> <style type="text/css" title="rt_noDelete">
blockquote.rt {
margin: 0 0 15px;
border-left: 4px solid #81c784;
padding: 0 0 0 12px;
display: block;
}
p { margin: 0 0 0 0 }
.email-signature {font-family:"Arial"; font-size: 8pt; font-style: italic; font-weight: normal; text-decoration: none; }
</style></head><body><p class="norm">Are you *sure* that both machines are on the same broadcast network? </p><p class="norm">(Or at least have a dhcp helper that will relay dhcp broadcasts?)</p><p class="norm"> </p><p>Just because the peers can talk to each other (finally) doesn't mean they're on the same broadcast network.</p><p> </p><p>(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.)</p><p class="norm"> </p><p>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.</p><p> </p><p>-Greg</p><p class="norm"> <br/>
</p><p class="norm"><br/></p><blockquote class="Odd QOdd rt" prefix="LR> "> 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.<br/>
</blockquote><p class="norm"><br/></p><blockquote class="Odd QOdd rt" prefix="LR> ">On 6/3/2022 8:48 AM, Leslie Rhorer wrote:<br/>
<blockquote class="Even QEven rt" prefix=">> ">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.<br/>
</blockquote><blockquote class="Even QEven rt" prefix=">>"><br/>
</blockquote><blockquote class="Even QEven rt" prefix=">> ">On 6/3/2022 8:23 AM, Leslie Rhorer wrote:<br/>
<blockquote class="Odd QOdd rt" prefix=">>>"><br/>
</blockquote><blockquote class="Odd QOdd rt" prefix=">>> ">On 6/3/2022 5:03 AM, Glenn Satchell wrote:<br/>
<blockquote class="Even QEven rt" prefix=">>>> ">ok, now we are getting somewhere...<br/>
</blockquote><blockquote class="Even QEven rt" prefix=">>>>"><br/>
</blockquote><blockquote class="Even QEven rt" prefix=">>>> ">Note startup error messages should be in syslog, or perhaps >>> "systemctl status isc-dhcp-server" will show them.<br/>
</blockquote></blockquote><blockquote class="Odd QOdd rt" prefix=">>> "> I have it logging to /var/log/dhcp/dhcp.log with logrotate >> enabled for the directory, but that doesn't really matter.<br/>
<blockquote class="Even QEven rt" prefix=">>>>"><br/>
</blockquote><blockquote class="Even QEven rt" prefix=">>>> ">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.<br/>
</blockquote></blockquote><blockquote class="Odd QOdd rt" prefix=">>> "> 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.<br/>
<blockquote class="Even QEven rt" prefix=">>>>"><br/>
</blockquote><blockquote class="Even QEven rt" prefix=">>>> ">Next in the failover peer section, both config files have "primary". >>> One of them needs to be "secondary"<br/>
</blockquote></blockquote><blockquote class="Odd QOdd rt" prefix=">>> "> How the heck did that happen? I could swear one was set to >> "secondary".<br/>
<blockquote class="Even QEven rt" prefix=">>>> ">, 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.<br/>
</blockquote></blockquote><blockquote class="Odd QOdd rt" prefix=">>> "> Hmm, OK, maybe I follow.<br/>
<blockquote class="Even QEven rt" prefix=">>>> ">With this change I think it should work now... fingers crossed :)<br/>
</blockquote><blockquote class="Even QEven rt" prefix=">>>>"><br/>
</blockquote></blockquote><blockquote class="Odd QOdd rt" prefix=">>> "> Yeah. What you said.<br/>
</blockquote></blockquote></blockquote><p class="norm"></p><div class="email-signature"><br/>
</div></body>