The network manager dispatcher script found in mtu-migration-dispatcher.yaml does not currently support IPv6 routes, but it should. MTU migration should support both IPv4 and IPv6 clusters.
@@rravaiol Can you provide a reproducer for the problem?
Hi Mike, the problem was that the bash function set_mtu_on_dev_routes only applied to ipv4 routes: https://github.com/openshift/machine-config-operator/blob/283df7393b2218903e7ddbee692d836d1f08a03b/templates/common/_base/files/mtu-migration-dispatcher.yaml#L55-L70 ... so in an IPv6 single-stack cluster the dispatcher script above would do absolutely nothing. In order to see this happening, the whole MTU migration procedure should be triggered on an IPv6 cluster. For instance, following the accepted proposal (https://github.com/openshift/enhancements/pull/963), we can *decrease* the cluster (and host) MTU as in the example in https://github.com/openshift/enhancements/blob/master/enhancements/network/allow-mtu-changes.md#mtu-decrease-example. After the first rolling reboot, we should see a change in host routes (on each node) that go through br-ex or the physical interface on the host(this is for ovn-k, while for sdn we only consider routes going through the default gateway interface): these routes should now have an MTU value equal to `MTU.Machine.To` that the user specified when triggering the MTU migration. Prior to the fix for this BZ, if we did the MTU migration on an IPv6 cluster, after the first rolling reboot we would see no MTU at all on these host routes.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056