<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 6/3/2022 10:39 AM, Gregory Sloop
wrote:<br>
</div>
<blockquote type="cite" cite="mid:8759142.20220603083912@sloop.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<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>
</blockquote>
Yes, I am sure. The servers are plugged into the same switch,
and they have adjacent IP addresses (192.168.1.50/23 and
192.168.1.51/23). <br>
<blockquote type="cite" cite="mid:8759142.20220603083912@sloop.net">
<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>
</blockquote>
Not necessary. Over time, now, they have both served numerous
IP addresses. I was just mildly surprised the hosts were sending
unicast requests, but I suppose it makes sense. It cuts down a
little - not much - on broadcast traffic, making the network more
efficient.<br>
<blockquote type="cite" cite="mid:8759142.20220603083912@sloop.net">
<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>
<div class="email-signature"><br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>