Use same MTU as uplink for bridge port #6577
Conversation
There was a problem hiding this comment.
@wenyingd do you think something like this would make sense for the bridge port on Windows? I am not sure it is needed as on Windows are always use "bridging mode", and this is not something that is configuration-dependent.
| if mtu > 0 { | ||
| if err := bridge.SetInterfaceMTU(ifaceName, mtu); err != nil { | ||
| return "", false, fmt.Errorf("failed to set bridge interface MTU: %w", err) | ||
| } | ||
| } |
There was a problem hiding this comment.
This is not enforced if the port already exists (as determined by the call to bridge.GetOFPort at the beginning of the function). My take is that this is consistent with how we handle other configurations at the moment (e.g., we don't call SetLinkUp unconditionally).
antoninbas
force-pushed
the
use-same-mtu-as-uplink-for-bridge-port
branch
from
4f0ae28
to
71374be
Compare
I don't think it is necessary for Windows. This is because the host local interface is automatically created by Windows OS when we create the HNSNetwork (VMSwitch) , what antrea-agent does is to rename the vNIC (host local interface) and to attach it on OVS bridge. Windows OS has ensured the configurations on the vNIC is the same as the uplink (physical interface). Besides, setting mtu values on OVSDB on Windows doesn't really take effect on the network adapter, we shall modify the network adapter directly. |
| // We request the same MTU for the bridge interface as for the uplink adapter. If we don't, | ||
| // OVS will default to the lowest MTU among all existing bridge ports, including container | ||
| // ports. There may be some existing workloads with a lower MTU, and using that lower value | ||
| // may impact host connectivity. |
There was a problem hiding this comment.
Shall we add additional comment that big packet will be fragmented when it passthrough lower MTU interfaces (e.g. old antrea-gw0)?
There was a problem hiding this comment.
We always update the MTU of antrea-gw0 to the correct value:
Line 698 in e9990f8
Do you have another case in mind?
|
/test-all |
|
/test-flexible-ipam-e2e |
In bridging mode (on Linux), when moving the physical adapter to the bridge, we explictly set the MTU for the bridge port to the same value as for the physical adapter. Without this change, the MTU may default to a different (lower) value if some existing container ports have a lower MTU value. For example, this occurs when first installing Antrea in encap mode, then re-installing Antrea in noEncap mode with bridging mode enabled. We also do some minor documentation updates to indicate to users that they should consider restarting existing workloads when updating the Antrea datapath configuration. Fixes antrea-io#6456 Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
antoninbas
force-pushed
the
use-same-mtu-as-uplink-for-bridge-port
branch
from
71374be
to
7c844cc
Compare
|
/test-all |
antoninbas
added
kind/bug
In bridging mode (on Linux), when moving the physical adapter to the bridge, we explictly set the MTU for the bridge port to the same value as for the physical adapter. Without this change, the MTU may default to a different (lower) value if some existing container ports have a lower MTU value. For example, this occurs when first installing Antrea in encap mode, then re-installing Antrea in noEncap mode with bridging mode enabled.
We also do some minor documentation updates to indicate to users that they should consider restarting existing workloads when updating the Antrea datapath configuration.
Fixes #6456