Question

[Leslie Rhorer]

On 6/3/2022 11:42 PM, Gregory Sloop wrote:
>
> See inline
>
>
>
>
>     On 6/3/2022 10:39 AM, Gregory Sloop wrote:
>>
>>     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.
>>
>             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). 
>
> 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.
>
     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.
>
> (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.
>
     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.


     Over the last several hours, lots of packets have dome in to both 
servers, just not in the first couple of hours.


     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.)

> I'd packet capture from each server to ensure they're *both* seeing 
> the discovers from clients.
>
> 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.)
>

     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.
>
> 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.)
>
     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.
>
> But narrowing down the scope here is first priority.
>
>
>>     (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.)
>>
>             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.
>
> I assume you're talking about dhcp renewals? Yeah, if you look at the 
> protocol, only the discover is broadcast.
>
> 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.
>
> 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.)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220604/941ff779/attachment-0001.htm>