On 12/11/19 12:36 PM, Ignazio Cassano wrote:
Hello Jeremy, thanks for your help. Indeed when more subnet of a provider vlan are created, instance on one of the subnet receives the static routes of all subnets. Is it correct?
Yes, this behavior is correct, the dhcp-agent will add host routes for all subnets in a network. I looks like in your case you had a network with 12 subnets? I wonder whether it's worth checking either the number of subnets is below some threshold (10?) and just stop supplying the routes, or if there is some other way to determine the packet size. The only issue with limiting the packet size in the reply is the admin wouldn't know we did it, since adding the subnet is asynchronous from the dhcp-agent adding it's option logic, and things might fail in random ways, but I guess having a running dnsmasq is better than not. I guess at worst we should document that adding too many subnets, or extra dhcp options for that matter, could cause issues. -Brian
Il Mer 11 Dic 2019, 16:29 Jeremy Stanley <fungi@yuggoth.org <mailto:fungi@yuggoth.org>> ha scritto:
On 2019-12-11 10:10:17 +0100 (+0100), Ignazio Cassano wrote: [...] > Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send > DHCP/BOOTP option 121: no space left in packet [...]
This error is fairly straightforward. DHCP replies are limited to what you can fit in a single UDP packet and how large of a datagram the client agrees to accept. The number of routes you're trying to include in via option 121 could be the problem (is it a bunch?) but also the other fields and their lengths can also contribute, as can the MTU on that network segment:
https://tools.ietf.org/html/rfc2131
According to IETF RFC 2131 you should be able to assume clients will accept a datagram of up to 576 octets in length (which implies your entire options field can use at least 312 octets). Anything over this requires negotiation of a maximum DHCP message size with the client. -- Jeremy Stanley