mtu config audits

Cluster Network, User Defined

$\color{green}{\textsf{PASS}}$ Creating Cluster Network (non-mgmt) with uplink-mtu annotation and value of 1500 fails as expected $~~$

When attempting to create Cluster Network "testing", error of: admission webhook "validator.harvester-system.harvester-network-webhook" denied the request: Internal error occurred: can't create cluster network testing because annotation network.harvesterhci.io/uplink-mtu can't be added as expected

$\color{green}{\textsf{PASS}}$ Creating Cluster Network (non-mgmt) with uplink-mtu annotation and value of 1400 fails as expected when creating as yaml $~~$

When attempting to create Cluster Network new-testing with uplink-mtu: 1400 via editing as YAML on form fails as expected

$\color{red}{\textsf{FAIL}}$ Adding uplink-mtu annotation to Cluster Network when there are no valid vlanconfigs $~~$

When editing a Cluster Network with 0 cluster network configurations the annotation can be added with a value like 1400
When the a new network configuration is added we unfortunately do not see the network.harvesterhci.io/uplink-mtu there and present on the network configuration after it is added, it is not auto-populated as an annotation when building the resource in the UI nor is it present after the resource has been created when auditing the linkAttributes property
Additionally, it causes issues as when nc1 is built, it's building the MTU for nc1 as 0
Extra additionally, when the user goes back to view the uplink-mtu on the testing cluster network it has silently modified that value, shifting it surprisingly from 1400 -> 1500

$\color{green}{\textsf{PASS}}$ Attempting to change Cluster Network uplink-mtu to 1450 from 1400 when nc1 is using MTU of 1400 fails $~~$

When cluster network has uplink-mtu set to 1400
When cluster network configuration nc1 is built and 1400 is input as cluster network confgiuration manually
When user trys to change the uplink-mtu on the cluster network to 1450 from 1400, it fails as expected because nc1 is 1400

$\color{green}{\textsf{PASS}}$ Creating a Cluster Network with MTU of 1400, Network Configuration nc1 (target node a) w/ MTU of 1400, then trying to create Network Configuration nc2 (target node b) of MTU 1450 will fail $~~$

When Cluster network testing is built
testing, has mtu set to 1400
inside testing cluster network: nc1 is built targeting node a, w/ mtu 1400
inside testing cluster network: nc2 is built targeting node b, w/ mtu 1450, failure is observed as expected: admission webhook "validator.harvester-system.harvester-network-webhook" denied the request: Internal error occurred: can't create vlanConfig nc2 because the vlanconfig nc2 MTU 1450 is different with another vlanconfig nc1 MTU 1400, all vlanconfigs on one clusternetwork need to have same MTU

$\color{green}{\textsf{PASS}}$ Deleting a cluster network will fail with active network configurations $~~$

When a cluster network has one or more network configurations w/ configured MTUS
Attempting to delete the parent cluster network should fail

$\color{green}{\textsf{PASS}}$ Migrating a set MTU Network Configuration from one cluster network to the other will fail when VM is running $~~$

When vm is running using the network configuration, in a vm network
VM has one or more nics tied to vm network
MTU Network Configuration Migration will fail when trying to move to other Cluster Network

$\color{green}{\textsf{PASS}}$ Attempting to delete network configuration w/ set MTU that has a VM network and a VM using that VM Network will fail $~~$

When vm is running using the network configuration, in a vm network
VM has one or more nics tied to vm network
MTU Network Configuration will fail to delete as expected, you must stop the VM first before the vlanConfig can be deleted

$\color{green}{\textsf{PASS}}$ A VM Network (NAD) that was built using a specific Cluster Network w/ set MTU plus a Network Config on that Cluster Network w/ set MTU -> when that Network Config for the Cluster Network is removed, the Cluster Network should still fail to delete because the NAD (VM Network) is still existing $~~$

When a VM Network is built from a Cluster Network + Network Config (both with set MTU values)
The VM Network is used in a VM
The VM is powered off
The Cluster Network's Network Configuration is removed
The VM Network will be degraded
Then attempting to delete the Cluster Network with set MTU, will fail, because the VM Network (NAD) still exists

MGMT Network based, not user defined

$\color{green}{\textsf{PASS}}$ User can not build a VM Network (NAD) with a set MTU on MGMT Network, that is different than MGMT Network's MTU $~~$

When a mgmt nad is built like:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: mgmt-nad-1
  annotations:
    field.cattle.io/description: mgmt nad 1
    #  key: string
  labels:
    {}
    #  key: string
  namespace: default
spec:
  config: >-
    {"cniVersion":"0.3.1","name":"mgmt-nad-1","type":"bridge","bridge":"mgmt-br","promiscMode":true,"vlan":2011,"ipam":{}, "mtu":1500}
__clone: true

then gets modified from 1500 to 1480
Failure is to be expected if cluster network MTU is 1500

$\color{green}{\textsf{PASS}}$ VM Network (NAD) on MGMT Network, it's MTU can not be set to impproper values $~~$

$\color{green}{\textsf{PASS}}$ Modifying K9s/Kubectl (not from UI) the MGMT Network We Can Add MTU Annotation $~~$

when there is a VM Network built off of MGMT Network
w/ kubectl/k9s modifying the MGMT network adding the mtu annotation like:

Name:         mgmt                                                                                                                                          
Namespace:                                                                                                                                                  
Labels:       <none>                                                                                                                                        
Annotations:  network.harvesterhci.io/uplink-mtu: 1400                                                                                                      
API Version:  network.harvesterhci.io/v1beta1                                                                                                               
Kind:         ClusterNetwork                                                                                                                                
Metadata:                                                                                                                                                   
  Creation Timestamp:  2025-07-29T22:56:19Z                                                                                                                 
  Finalizers:                                                                                                                                               
    wrangler.cattle.io/harvester-network-manager-cn-controller                                                                                              
  Generation:        1                                                                                                                                      
  Resource Version:  2173805                                                                                                                                
  UID:               c5624bd7-45a6-4427-b3fe-b747f32876a1                                                                                                   
Status:                                                                                                                                                     
  Conditions:                                                                                                                                               
    Last Update Time:  2025-07-29T22:56:19Z                                                                                                                 
    Status:            True                                                                                                                                 
    Type:              ready                                                                                                                                
Events:                <none>