Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Question (Gregory Sloop)
2. Re: Question (Leslie Rhorer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Jun 2022 21:42:49 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Question
Message-ID: <502986313.20220603214...@sloop.net>
Content-Type: text/plain; charset="utf-8"
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. (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.
?
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.)
?
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.)
?
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/20220603/8cd23041/attachment-0001.htm>
------------------------------
Message: 2
Date: Sat, 4 Jun 2022 00:35:08 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <e9bbfbba-5b5d-84b1-595d-1e7d049ad...@siliconventures.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 164, Issue 13
*******************************************
