<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">See inline</p><p class="norm"> <br/>
</p><p class="norm"><br/></p><p class="norm"></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;"/>
<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. (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><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><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><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></body>