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: Oversized DHCP option issues (Richard L. Hamilton)
2. Re: Oversized DHCP option issues (Glenn Satchell)
----------------------------------------------------------------------
Message: 1
Date: Sun, 23 Jan 2022 08:28:41 -0500
From: "Richard L. Hamilton" <rlha...@smart.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Oversized DHCP option issues
Message-ID: <9bee001a-2c37-41c7-845a-10cfcb98e...@smart.net>
Content-Type: text/plain; charset="utf-8"
I see no way to specifically configure option concatenation, but I think the
server will do it automatically as required.
As for size, I think the packet size may still be a limitation. Rather than
live with the minimum 576 MTU, assuming everything can handle at least MTU 1500,
option dhcp-max-message-size 1236;
(the rest of 1500 is overhead)
As far as I can tell, isc-dhcp does not presently support MTU larger than 1500
even if large packets are enabled for all involved hosts, so this is the
largest useful value at this time. If the client specifies that option, that
will take precedence over the server configuration, so that's one more thing
that could go wrong.
Remember that per https://datatracker.ietf.org/doc/html/rfc3442 the netmasks
are VARIABLE LENGTH. You specify the number of significant bits first, then the
number of octets needed to hold that many bits. One example I saw:
option classless-routes code 121 = array of uint8;
option classless-routes 32, 1,1,1,1, 5,5,5,1,
24, 2,2,2, 5,5,5,1,
24, 3,3,3, 5,5,5,1;
(for ease of reading, formatted with each line being bits, subnet mask,
destination; note that the ones with 24 significant bits only have 3 octets for
the subnet mask)
WARNING: I am NOT a DHCP expert by any means, although I run a fairly trivial
home server (actually two, with failover, given gadgets that like short leases
and become useless without a functioning DHCP server), because the DHCP built
in to a home router doesn't give me enough control to assign lots of fixed
addresses (which make troubleshooting and monitoring easier) and other
information - but my routing is trivial indeed, just one default route for
everything, so I've never before looked at sending multiple classless routes.
This is also only about the 2nd time I've looked at the server code, so I may
be misinterpreting what I saw. In other words, it's the best I can come up with
given minutes rather than hours of research, but I may be horribly wrong about
any or all of it.
> On Jan 23, 2022, at 05:43, ??? <weihau.chi...@gmail.com> wrote:
>
> Hello everyone,
>
> I'm configuring a DHCP server over a network that has multiple
> gateways. One of the gateways has limited bandwidth, so I'm thinking
> of using the classless static route defined in RFC3442 to
> automatically configure it.
>
> However, our routing tables are large, exceeding the DHCP 255 bytes
> limit. I observed that only packets within 255 bytes can be sent out
> successfully while exceeding the limit by a little bit will cause a
> malformed DHCP packet shown in Wireshark, and the DHCP server doesn't
> send out the option while using the whole table.
>
> In RFC3396 it specifies that the options should be concatenated when
> they exceeded the 255-byte limit, while I didn't find how to configure
> that in `dhcpd.conf`.
>
> I've tried to add multiple options that share the same DHCP code, and
> dhcpd just ignore the previous settings and only takes the last one.
>
> The question is, how can I send out the large table successfully? I
> think this problem could be practical, as the 255-byte option limit
> can only store 23 CIDR-255.255.255.0 table entries.
>
> --
> Weihao Jiang
> mailto:weihau.chi...@gmail.com
> mailto:weihao.ji...@sjtu.edu.cn
> _______________________________________________
> 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
>
--
eMail: mailto:rlha...@smart.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220123/3a088fdb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2814 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220123/3a088fdb/attachment-0001.bin>
------------------------------
Message: 2
Date: Mon, 24 Jan 2022 10:51:05 +1100
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Oversized DHCP option issues
Message-ID: <7befc71c4e92c0cef93013e243bfa...@uniq.com.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
in the dhcp-options man page there is also this possibility:
option routers ip-address [, ip-address... ];
The routers option specifies a list of IP addresses for routers on
the client's subnet. Routers should be listed in order of preference.
which might allow you to specify your low-bandwidth router as the last
lowest preference - this looks like it would mean the clients only use
that low bandwidth router if the others are not contactable? To me this
looks like something that would depend on client behaviour - so it might
work as you want for some clients and not others.
For the classless routes option, the second group is the destination
network - you only include the non-zero part of the network address:
option classless-routes code 121 = array of uint8;
option classless-routes 32, 1,1,1,1, 5,5,5,1,
24, 2,2,2, 5,5,5,1,
24, 3,3,3, 5,5,5,1;
So 2,2,2 is the destination network 2.2.2.0/24 and 5.5.5.1 is the
router's address.
A third option could be to aggregate the routes, eg if your subnets are
192.168.1.0/24, 192.168.2.0/24 and so on you could try adding a route
for the superset such as 192.168.0.0/16 and the router's address. This
would of course depend on how your networks are laid out.
Be careful with changing the maximum packet size - clients may or may
not know how to handle the larger packet so you will need to test this.
regards,
Glenn
On 2022-01-24 00:28, Richard L. Hamilton wrote:
> I see no way to specifically configure option concatenation, but I
> think the server will do it automatically as required.
>
> As for size, I think the packet size may still be a limitation. Rather
> than live with the minimum 576 MTU, assuming everything can handle at
> least MTU 1500,
>
> option dhcp-max-message-size 1236;
>
> (the rest of 1500 is overhead)
>
> As far as I can tell, isc-dhcp does not presently support MTU larger
> than 1500 even if large packets are enabled for all involved hosts, so
> this is the largest useful value at this time. If the client specifies
> that option, that will take precedence over the server configuration,
> so that's one more thing that could go wrong.
>
> Remember that per https://datatracker.ietf.org/doc/html/rfc3442 the
> netmasks are VARIABLE LENGTH. You specify the number of significant
> bits first, then the number of octets needed to hold that many bits.
> One example I saw:
>
> option classless-routes code 121 = array of uint8;
>
> option classless-routes 32, 1,1,1,1, 5,5,5,1,
> 24, 2,2,2, 5,5,5,1,
> 24, 3,3,3, 5,5,5,1;
>
> (for ease of reading, formatted with each line being bits, subnet mask,
> destination; note that the ones with 24 significant bits only have 3
> octets for the subnet mask)
>
> WARNING: I am NOT a DHCP expert by any means, although I run a fairly
> trivial home server (actually two, with failover, given gadgets that
> like short leases and become useless without a functioning DHCP
> server), because the DHCP built in to a home router doesn't give me
> enough control to assign lots of fixed addresses (which make
> troubleshooting and monitoring easier) and other information - but my
> routing is trivial indeed, just one default route for everything, so
> I've never before looked at sending multiple classless routes. This is
> also only about the 2nd time I've looked at the server code, so I may
> be misinterpreting what I saw. In other words, it's the best I can come
> up with given minutes rather than hours of research, but I may be
> horribly wrong about any or all of it.
>
>> On Jan 23, 2022, at 05:43, ??? <weihau.chi...@gmail.com> wrote:
>>
>> Hello everyone,
>>
>> I'm configuring a DHCP server over a network that has multiple
>> gateways. One of the gateways has limited bandwidth, so I'm thinking
>> of using the classless static route defined in RFC3442 to
>> automatically configure it.
>>
>> However, our routing tables are large, exceeding the DHCP 255 bytes
>> limit. I observed that only packets within 255 bytes can be sent out
>> successfully while exceeding the limit by a little bit will cause a
>> malformed DHCP packet shown in Wireshark, and the DHCP server doesn't
>> send out the option while using the whole table.
>>
>> In RFC3396 it specifies that the options should be concatenated when
>> they exceeded the 255-byte limit, while I didn't find how to configure
>> that in `dhcpd.conf`.
>>
>> I've tried to add multiple options that share the same DHCP code, and
>> dhcpd just ignore the previous settings and only takes the last one.
>>
>> The question is, how can I send out the large table successfully? I
>> think this problem could be practical, as the 255-byte option limit
>> can only store 23 CIDR-255.255.255.0 table entries.
>>
>> --
>> Weihao Jiang
>> mailto:weihau.chi...@gmail.com
>> mailto:weihao.ji...@sjtu.edu.cn
>> _______________________________________________
>> 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
>
> --
> eMail: mailto:rlha...@smart.net
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220124/516f51a8/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 159, Issue 3
******************************************
