<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 11:42 PM, Gregory Sloop
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:502986313.20220603214249@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">See inline</p>
<p class="norm"> <br>
</p>
<p class="norm"><br>
</p>
<blockquote class="rt">
<p><br>
</p>
<div class="moz-cite-prefix">On 6/3/2022 10:39 AM, Gregory Sloop
wrote:<br>
</div>
<blockquote cite="mid:8759142.20220603083912@sloop.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<style title="rt_noDelete" type="text/css">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). </blockquote>
<p> </p>
<p>Well, then it's *really* odd that you're pretty sure that one
of the servers isn't seeing the broadcasts when a new discovery
occurs.</p>
</blockquote>
No, that is not what I said. I said there were no broadcast
packets. All the requests were unicast packets. 'Tons of them, at
the time all sent to the primary server.<br>
<blockquote type="cite"
cite="mid:502986313.20220603214249@sloop.net">
<p> (IMO, either there aren't any discoveries happening, or
they're not on the same broadcast domain.) Just because they're
on the same switch doesn't mean the same broadcast domain - two
different VLANS will mean two different broadcast domains.</p>
</blockquote>
<p> No, I don't have any VLANs set up on that particular switch.
You are of course correct any VLAN will be segregated at Layer 2
(and of course subsequently Later 3), and any interface not
configured with a VLAN will not see any traffic from another, but
that is not what was happening. When I think about it, it does
make sense once a host has obtained an IP assignment by sending
broadcast packets, thereafter it assumes it will find a server at
the same IP as sent the original ACK, and thus send an update
request over unicast, rather than broadcast.</p>
<p><br>
</p>
<p> Over the last several hours, lots of packets have dome in to
both servers, just not in the first couple of hours.</p>
<p><br>
</p>
<p> Just FYI, I am not new to any of this. I have been a network
engineer for nearly 40 years. I just have not looked deeply into
the DHCP protocol or the ISC server before now. (And obviously, I
do make plenty of mistakes.)<br>
</p>
<blockquote type="cite"
cite="mid:502986313.20220603214249@sloop.net">
<p> </p>
<p>I'd packet capture from each server to ensure they're *both*
seeing the discovers from clients.</p>
<p>If they're not, then tearing into the switch configuration or
perhaps the eth interface config on each server is in order.
(i.e. It's not a dhcpd problem.)</p>
</blockquote>
<br>
That was the first thing I did, and they weren't. All the
packets were unicast packets coming in to the Primary. It wasn't a
problem, at all - certainly not for DHCPD. It can't respond to
requests it never sees. It just struck me as odd, at first.<br>
<blockquote type="cite"
cite="mid:502986313.20220603214249@sloop.net">
<p> </p>
<p>If both servers ARE seeing all the discovers, then you likely
still have something mis-configured in the DHCPD configs. (It
probably is a dhcpd problem, and is likely misconfigured.)</p>
</blockquote>
No, I never said either server was not responding to requests,
just that for the first hour or two, no requests were coming down
the wire to the Secondary.<br>
<blockquote type="cite"
cite="mid:502986313.20220603214249@sloop.net">
<p> </p>
<p>But narrowing down the scope here is first priority.</p>
<p> </p>
<blockquote class="rt"><br>
<blockquote cite="mid:8759142.20220603083912@sloop.net"
type="cite">
<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.</blockquote>
<p> </p>
<p>I assume you're talking about dhcp renewals? Yeah, if you look
at the protocol, only the discover is broadcast.</p>
<p>A client renewal asks the server it got the lease from for the
"renewal," directly. Only after not getting a renewal, will it
then try a discover/broadcast again.</p>
<p> </p>
<p>Which might be impacting your not seeing broadcast traffic. If
all your machines have leases, they'll continue to unicast
extension requests to the server that initially granted the
lease. (And get them, if things are working right.) Thus no
broadcasts - at least until a lease expires (or gets old
enough.)</p>
<p> </p>
<blockquote class="rt"><br>
</blockquote>
<div class="email-signature"><br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>