<div dir="auto">Hello Jeremy, thanks for your help.<div dir="auto">Indeed when more subnet of a provider vlan are created, instance on one of the subnet receives the static routes of all subnets.</div><div dir="auto">Is it correct?</div><div dir="auto">Ignazio</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il Mer 11 Dic 2019, 16:29 Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" rel="noreferrer noreferrer" target="_blank">fungi@yuggoth.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-12-11 10:10:17 +0100 (+0100), Ignazio Cassano wrote:<br>
[...]<br>
> Dec 11 09:49:06 podto2-osctrl01 dnsmasq-dhcp[70093]: cannot send<br>
>     DHCP/BOOTP option 121: no space left in packet<br>
[...]<br>
<br>
This error is fairly straightforward. DHCP replies are limited to<br>
what you can fit in a single UDP packet and how large of a datagram<br>
the client agrees to accept. The number of routes you're trying to<br>
include in via option 121 could be the problem (is it a bunch?) but<br>
also the other fields and their lengths can also contribute, as can<br>
the MTU on that network segment:<br>
<br>
    <a href="https://tools.ietf.org/html/rfc2131" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc2131</a><br>
<br>
According to IETF RFC 2131 you should be able to assume clients will<br>
accept a datagram of up to 576 octets in length (which implies your<br>
entire options field can use at least 312 octets). Anything over<br>
this requires negotiation of a maximum DHCP message size with the<br>
client.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div>