Closed ineu closed 9 months ago
That's expected behavior. It doesn't create a second bridge at all, it creates an empty (dummy) ethernet device which is joined into the bridge to pin the MTU.
The MTU value when directly applied to the bridge isn't actually fixed, interfaces joining can cause it to go higher or lower. To avoid that effect, we purposefully create a network interface that we set the expected MTU to and then bridge into the bridge.
I see, thanks for the explanation. Should it be documented to avoid such questions in the future? For now the official documentation has been very helpful to me.
If we had an entry in the https://linuxcontainers.org/incus/docs/main/faq/ is that something you'd have noticed?
I think eventually when we port our network config table to the new way to handle configuration key descriptions, we could add a note directly to the bridge.mtu
key, but doing that today isn't easy due to how packed the table is.
is that something you'd have noticed?
I was thinking about something like an asterisk/footnote on the bridge.mtu
item here, that would be obvious to a reader (to me at least): https://linuxcontainers.org/incus/docs/main/reference/network_bridge/
But FAQ is also a good option.
Awesome, thank you!
Required information
Issue description
Setting bridge.mtu to an existing bridge creates a new interface named $NETWORK-mtu, enslaving it to the existing bridge.
Steps to reproduce
ip l l incusbr0
.incus network set incusbr0 bridge.mtu=1420
systemctl restart incus
Check the list of networks:
ip l l | grep -A 1 incusbr0
Actual result: it shows an additional interface
incusbr0-mtu
:Expect result: it should just set MTU to incusbr0, not create new interfaces.