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. dhclient leases decode vendor options (Colin McInnes)
2. Re: Question (Glenn Satchell)
3. Re: Question (Leslie Rhorer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Jun 2022 11:05:12 -0600
From: Colin McInnes <jabrwo...@gmail.com>
To: dhcp-users@lists.isc.org
Subject: dhclient leases decode vendor options
Message-ID:
<CALq_2D3OavRc1k9zyWxE=rrmg6zn08prb3sdrzo29xyzjo7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhclientconf#lease-declarations
Ref says I can add "vendor option space "spacename";" to the leases section
to enable using that defined space to decode incoming leases.
Here is a snippet of dhclient.conf
option space docsis;
option docsis.device-type code 2 = string;
option docsis.server-list code 61 = array of ip-address;
option local-encapsulation code 43 = encapsulate docsis;
request ... , docsis.server-list;
lease {
vendor option space "docsis";
}
But the client is saying it's expecting a lease.
/etc/dhcp/dhclient.conf line 48: expecting lease declaration.
vendor
Am I using the vendor option space lease option incorrectly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/5f46cde1/attachment-0001.htm>
------------------------------
Message: 2
Date: Sat, 04 Jun 2022 11:53:08 +1000
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Question
Message-ID: <944738d7-e6a0-4a4e-a096-0fb93d697...@email.android.com>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220604/82cfaeb7/attachment-0001.htm>
------------------------------
Message: 3
Date: Fri, 3 Jun 2022 21:19:22 -0500
From: Leslie Rhorer <lesrho...@siliconventures.net>
To: dhcp-users@lists.isc.org
Subject: Re: Question
Message-ID: <6f1d3781-1857-723d-4f2c-84e83001b...@siliconventures.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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).
>
> (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.
>
> 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.
>
> -Greg
>
>
>
> ???? 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.
>
>
> On 6/3/2022 8:48 AM, Leslie Rhorer wrote:
>
> 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.
>
>
> On 6/3/2022 8:23 AM, Leslie Rhorer wrote:
>
>
> On 6/3/2022 5:03 AM, Glenn Satchell wrote:
>
> ok, now we are getting somewhere...
>
>
> Note startup error messages should be in syslog, or
> perhaps >>> "systemctl status isc-dhcp-server" will
> show them.
>
> ??? I have it logging to /var/log/dhcp/dhcp.log with
> logrotate >> enabled for the directory, but that doesn't
> really matter.
>
>
> 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.
>
> ??? 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.
>
>
> Next in the failover peer section, both config files
> have "primary". >>> One of them needs to be "secondary"
>
> ??? How the heck did that happen?? I could swear one was
> set to >> "secondary".
>
> , 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.
>
> Hmm, OK, maybe I follow.
>
> With this change I think it should work now... fingers
> crossed :)
>
>
> Yeah.? What you said.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220603/e8a9e539/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 12
*******************************************
