I see no issue with the proposed solution.

Need to add max MTU to operational mode and create a new validator using it and applying it to the xml. The only question being if the information is always available.

This was discussed already in T2404. The problem is that NICs that expose their min/max MTU are rare. None of the NICs I have expose it, neither through sysfs nor through 'ip -d link show'. If I recap the discussion from T2404, there are 2 main ways to solve this:
a) not have any limitations regarding MTU at all and then detect an error when trying to apply the new MTU. This means no way to verify if the new mtu is correct beforehand so it doesn't comply with the verify/apply separation that's prescribed in the developer docs. I described a possible workaround using revert code in T2404.
b) have a mtu detection script that would be ran by udev on every new NIC detection (to support hotplugging NICs) that would determine the min/max mtu with a bruteforce binary search algorythm (try to set a mtu and see if it errors), then record the results in some temporary file that would get read by the config script. The idea was proposed by @thomas-mangin.

a) not have any limitations regarding MTU at all and then detect an error when trying to apply the new MTU. This means no way to verify if the new mtu is correct beforehand so it doesn't comply with the verify/apply separation that's prescribed in the developer docs. I described a possible workaround using revert code in T2404.

My point of view on this would be, if a nic does not support this feature, then actually verifying the configuration before applying it is impossible. Right now we are just obeying arbitrary limits that are likely to be safe in most cases, i don't know if i would call that verification.

b) have a mtu detection script that would be ran by udev on every new NIC detection (to support hotplugging NICs) that would determine the min/max mtu with a bruteforce binary search algorythm (try to set a mtu and see if it errors), then record the results in some temporary file that would get read by the config script. The idea was proposed by @thomas-mangin.

Personally, if the driver does not return max/min mtu, i think a warning message upon setting mtu along the lines of...

"could not verify supported mtu range for interface <interface name>, make sure the set mtu is supported before commit"

would suffice just fine. If a driver isn't going to expose that information, it's a bit unreasonable to brute force it in my opinion. And on the contrary all of the nics i have expose this information.

@SIN3R6Y The solution of @SIN3R6Y is worth considering

I have a PR for this (not changing the XML limiting range) for review ATM.

https://github.com/vyos/vyos-1x/pull/473 was merged so now need to agree sane limits for the XML.

could have the range 68-65536 but it may be a bit on the extreme side.

In T2630#68467, @thomas-mangin wrote:

could have the range 68-65536 but it may be a bit on the extreme side.

it might seem extreme now, but perhaps not later in time? As of today i know some intel nics support of to 16K, those are some of the highest i'm aware of.

Also, potentially a separate issue (if it hasn't been addressed) dummy interfaces (which you currently cant set an MTU on, but i plan to send a PR), have a max / min mtu of 0 (they have no limits). To me that pull request looks like it will break in that case. Probably need a case for handling no limits and just do 68-65K or similar.

There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.

Maybe warn on over 9000 but not block it? Also, what are NVMeoF/RoCE NIC's saying these days? Still, since path MTU discovery isn't reliable, direct testing the interface seems like a good fallback, but while udev running it might be okay, again for VM nics, the host changing the underlying hardware could cause changes while running, so rescan on every commit?

In T2630#68490, @Asteroza wrote:

There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.

Maybe warn on over 9000 but not block it? Also, what are NVMeoF/RoCE NIC's saying these days? Still, since path MTU discovery isn't reliable, direct testing the interface seems like a good fallback, but while udev running it might be okay, again for VM nics, the host changing the underlying hardware could cause changes while running, so rescan on every commit?

VM nics don't usually report the host's supported mtu, so if the host mtu support changed while the vm is running, you would have no idea, and a rescan would tell you the same thing. In the case of virtio 68-65k always.