Oversized DHCP option issues

Sun Jan 23 23:51:05 UTC 2022

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.chiang at 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.chiang at gmail.com
>> mailto:weihao.jiang at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
> 
> --
> eMail: mailto:rlhamil at 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 at 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-0001.htm>