Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Adjust MTU for VXLAN tenant networks¶

Incorrect MTU settings can lead to packet fragmentation, dropped packets, or even complete connectivity loss. To avoid these issues, you must ensure that the MTU is properly configured across all VXLAN tenant networks before migrating.

In OpenStack, the DHCP service distributes migration-sensitive information, such as IP addresses, MTU size, and routes to metadata services. If some of your networks have subnets with enable_dhcp = False, you must manually configure each instance in those subnets before migration.

Note

Not all operating systems allow the MTU size and DHCP renewal interval (T1) to be dynamically updated through DHCP. Ensure that the operating systems used in your instances can update MTU and T1 values upon DHCP lease renewal.

To adjust MTU for VXLAN tenant networks:

Decrease the DHCP renewal interval (T1).

This parameter sets the IP address renewal period in seconds. It also corresponds to the maximum potential network downtime during MTU size change. By default, T1 is set to half of the value of Neutron dhcp_lease_duration option. The default value of dhcp_lease_duration is 24 hours. You must significantly reduce the T1 value before changing MTU size on Neutron networks.

To set a new value for T1, edit the OpenStackDeployment object as follows:
```
spec:
  services:
    networking:
      neutron:
        values:
          conf:
            dhcp_agent:
              DEFAULT:
                dhcp_renewal_time: 60
```
In this example, T1 is set to 60 seconds. Setting this value too low increases the load on the DHCP server, as all instances will request IP renewals more often. After applying the new value, wait at least 24 hours before proceeding.
Ensure that the new DHCP settings are applied to all instances, for example, by running tcpdump inside an instance to verify the frequency of DHCP requests and replies:
```
tcpdump -nei <INTERFACE> udp port 67 or udp port 68
```

If some instances in VXLAN subnets have statically assigned IP addresses (DHCP is disabled for those subnets), manually decrease the MTU by updating the network interface configuration inside each affected instance.

Calculate the new MTU value, use the following formula:

NEW_MTU_SIZE = min(global_physnet_mtu, path_mtu)
               - tunnel_ip_header_size
               - geneve_overhead_size

Where:

tunnel_ip_header_size equals to 20 for IPv4 tunnels
geneve_overhead_size equals to 38

To obtain global_physnet_mtu:

kubectl -n openstack get osdpl osh-dev \
  -o jsonpath='{.spec.services.networking.neutron.values.conf.neutron.DEFAULT.global_physnet_mtu}'

Note

If global_physnet_mtu is not defined, use the default value of 1500.

To obtain path_mtu:

kubectl -n openstack get osdpl osh-dev \
  -o jsonpath='{.spec.services.networking.neutron.values.conf.neutron.ml2.path_mtu}'

Note

If path_mtu is not defined, ignore it.

For example, if global_physnet_mtu = 1500 and path_mtu = 0, the new MTU value should be 1442:

NEW_MTU_SIZE = 1500 - 20 - 38 = 1442

Update the MTU on Neutron VXLAN networks by copying the list of affected networks from the pre-migration check results and running the following commands inside the keystone-client pod:

IFS=',';
networks=$(cat /tmp/preflight_checks.json | jq -c .networks_mtu_size_check.violations | tr -d [] | tr -d \")
for net in $networks; do openstack network set --mtu <NEW_MTU_SIZE> ${net} ; done

Verify that the new MTU value is applied by logging in to instances and running:

ip link show <INTERFACE>

Example output:

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
   link/ether fa:16:3e:fb:a3:88 brd ff:ff:ff:ff:ff:ff

After completing these steps, all VXLAN tenant networks will use the correct MTU size. Instances will receive updated MTU settings, reducing the risk of packet loss or downtime during the migration to OVN.