Comment 12 for bug 1988069

I'd like to clarify several things:

1) I cannot confirm a "broken kernel" suggestion. I tried with several 5.4 kernels from Ubuntu 20.04, including the versions stated earlier as well as older and newer versions, and they all behaved exactly the same. Thus far it seems to me that an interface with MTU<1280 cannot get IPv6 configuration because IPv6 requires MTU>=1280 by design. I'm not sure about this, but it may be an expected kernel behavior. I will try kernel 5.15 today and see whether anything changes.

2) I am not a Python developer or a Neutron developer in particular, but I managed to find the relevant part in ml2 plugin code and prevent it from creating networks with MTU<1280 similarly to how it prevents creating networks with MTU>MAX_MTU. It was a rather ugly hack with a hardcoded minimum value though, so I'm wondering whether there's a better way.

3) The "blast radius" is not limited to a single user/tenant or a single project, but is system-wide. A non-admin user, for example a member of a tenant, is able to cause a denial of service by creating an internal DHCP-enabled network with MTU<1280. In our deployment with 3 infra nodes and redundant DHCP agents, within a few seconds of creating such network neutron-dhcp-agent instances fail on all infra nodes, enter an error-loop and are unable to process configuration changes. Everything that relies on DHCP configuration changes, including attachments of new ports in/to other DHCP-enabled networks of all other tenants, including the service networks of a service tenant such as for example LBaaS management, stops working in this scenario until the user's network is removed or adjusted to have MTU>1280. This seems like a rather high-priority issue to me.