In T1513#108669, @c-po wrote:

Hi @SIN3R6Y,

any idea about an alternative CLI? This is beta functionality in VyOS 1.4 and we can change it arround

rVYOSONEX47261d051759: bgp: evpn: T1513: VNI rt and rd are only supported under EVPN VRF.

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?

In T2630#68467, @thomas-mangin wrote:

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

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.

Thinking on this, should ("source-address" / "remote") and ("group" / "source-interface") be mutually exclusive? I cant think of any reason you would want both set to be setup on the same interface, I'm not even sure you can have both. Usually ("source-address" / "remote") would be used for unicast setups, and ("group" / "source-interface") for multicast. Seems like an either or, but not both, setup would be ideal.