This has been completely rewritte in Python/XML. Please reopen if this is still a problem - and if so what do you think should be the "real" rendered configuration.

I suggest adding a "validate" function to vyos.validate. We should determine the hypervisor used and if a setting is allowed on that hypervisor or not. Thus we can throw an appropriate erorr message by raise ConfigError() in the Python file changing the interface setting. This would be the cleanest way then the "false" setting never reaches the configuration backend at all.

So the minimum MTU for IPv6 is 1280. Setting ipv6 address no-default-link-local will probably fix this.

@jjakob I don't set any ip address on eth1

@Viacheslav do you have IPv6 disabled per chance? What's the output of ip addr dev eth1 after the failed commits? What's the full eth1 config?
The odd thing to me here is that it shouldn't ever be adding just fe80::/64, it should get the mac (using self.get_mac()) and create a single EUI64 address. The longer fe80:: address looks as it should be.

Confirmed with the simplest 'login as vyos; set interfaces ... description; login as other; delete interfaces .. description; login as vyos; set ...". T2203 is likely a result of this issue. Will reassign to me.

Fix path to mac-address node. PR https://github.com/vyos/vyos-1x/pull/392

In T1230#62672, @Viacheslav wrote:

@csalcedo maybe you use large port-ranges https://phabricator.vyos.net/T2189

We don't do any firewalling — we have lots of prefix-lists for filtering eBGP sessions. Right now we're looking at a router that's taken more than 1h20minutes to boot up — and it is still not finished — on modern Xeon CPUs. That's doubled in length since adding a prefix-list of around 5000 entries (roughly double the total number of prefix-list entries as before).

I definitely am not using large port-ranges. A pretty standard setup using a zone-based firewall.

@csalcedo maybe you use large port-ranges https://phabricator.vyos.net/T2189

All works on the rolling 1.3-rolling-202005030117

vyos@vyos:~$ ping 100.64.0.1 flood count 300
PING 100.64.0.1 (100.64.0.1) 56(84) bytes of data.

Another affected by this! Several devices with more than 20K config lines cause our automation scripts to take really really long to complete, and also the devices take much time to boot.
It would be great having this fixed in 1.3 :-)

PR https://github.com/vyos/vyos-build/pull/104

Also affected by this. Reboots take almost 10 minutes before the device is usable. Commits take a long time as well.

This issue seems to still be reproducing on static mappings with 1.2.5. I have noticed that the issue is fixed for non static mapping DHCP clients but all my clients who are getting assigned their IPs via static mappings are still getting their hostnames prefixed with LAN_ (LAN being my shared network name).

I think not setting the MTU at all if the user doesn't configure it is the right way to do it. It would be nice if we could detect an interface's max MTU but I couldn't find a way to do it either (I didn't really search that hard other than looking under /sys/net/{ifname} and /proc/sys/net).
@thomas-mangin Which other dependent interfaces do you mean? All other interfaces that depend on the ethernet interface should leave the MTU untouched too, let the OS choose the defaults.

My suggestion:

• if someone set a higher MTU than OS support, commit fail will be ok and that's OK, each vyos admin should know his OS limitations

Some code should also be added to detect the parent MTU size and make sure a clan MTU is smaller than the parent

Other ubuntu servers inside same openstack max mtu OS leave at 1450 too

In T2404#62637, @robertoberto wrote:

I tried to google to find out how to discover max mtu an interface accept but not found.

I guess limitation is because we are using OpenStack KVM or the other guy is using VMware and they use some bytes to their SDN

I tried to google to find out how to discover max mtu an interface accept but not found.

The mtu provided are reasonable and should not fail IMHO. I need to understand why Linux does not want to honour it.. hw limitation or other. If it is a limitation then we should detect it and report it to the user

That would only hide the problem. The MTU bug would still be here.

This should probably be:

if eth['mtu']:
    e.set_mtu(eth['mtu'])

Then if the user doesn't set a mtu, we don't try to change it. If the config set mtu is wrong the commit should fail, but it should get verified in the verify section by a max mtu read from the interface (if that's possible), or leaving it as it is now. It shouldn't silently (or even loudly) continue as that would make the failure undetectable at boot.

In T2404#62624, @thomas-mangin wrote:

An issue to change the MTU should not fail the whole interface change but just this one but the code does not not allow this easily. I will try to work on this.

An issue to change the MTU should not fail the whole interface change but just this one but the code does not not allow this easily. I will try to work on this.

vyos@vyos:~$ show version
Version: VyOS 1.3-rolling-202004230117
Release Train: equuleus

In T2404#62621, @robertoberto wrote:

Here:

root@vyos:~# cat /sys/class/net/eth0/mtu
1450
root@vyos:~# echo 1500 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1460 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1440 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1441 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1442 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1443 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1449 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1450 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1460 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1455 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1453 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1452 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1451 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~#

root@vyos:~# cat /sys/class/net/eth0/mtu
1450
root@vyos:~# echo 1500 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1460 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1440 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1441 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1442 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1443 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1449 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1450 > /sys/class/net/eth0/mtu
root@vyos:~# echo 1460 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1455 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1453 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1452 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~# echo 1451 > /sys/class/net/eth0/mtu
-bash: echo: write error: Invalid argument
root@vyos:~#

Sure it can (was in the initial ifconfig.py rewrite IIRC)

The reason seems to be that when the kernel can not change the MTU when writing to the sysfs, it will raise a OSError with the reason why.

Scratch the above comment - I'll write a simple utility function that parses the STP config from the bridge, and some utility functions to remove duplication for adding the bridge members and setting STP on them, that should be good enough.

This isn't as important as I thought initially as the interface scripts verify function will prevent adding interfaces with addresses to a bridge or bond - thus a simple 'ip addr flush dev x' will suffice to flush the remaining (should be just the fe80 link-local), as there should be no dhclients running.

In T2404#62515, @jjakob wrote:

@robertoberto issue (cannot change udp fragmentation-offload) is not the same as the original post (changing MTU out of range) so please create a separate task for it.

On a dual-core Pentium E5300: 2.2s, time for completion 5s.

vyos@rt-home# time /usr/libexec/vyos/completion/list_interfaces.py --help
usage: list_interfaces.py [-h] [-t TYPE | -b | -br | -bo]

It takes 2s even with just --help. I can't explain why it takes 2s by itself, but the completion takes 4s. 2s must be added elsewhere.

vyos@vyos# time /usr/libexec/vyos/completion/list_interfaces.py --help
usage: list_interfaces.py [-h] [-t TYPE | -b | -br | -bo]

https://github.com/vyos/vyos-1x/pull/388

@robertoberto issue (cannot change udp fragmentation-offload) is not the same as the original post (changing MTU out of range) so please create a separate task for it.

same here
root@vyos:~# ls -la /tmp/vyos.log.debug
-rw-r--r-- 1 vyos users 0 May 1 18:03 /tmp/vyos.log.debug
root@vyos:~# /sbin/ethtool -K eth0 ufo off
Cannot change udp-fragmentation-offload

We must be able to call klass('eth0.1.2', create=False).add_addr to add an address on the vif-c and also klass('eth0.1', create=False).add_addrto add an address on the vif-s. I'm adding functions on Interfaces class to purge/restore addresses which will be used when adding/removing bridge/bond members, T2367.

Same symptoms in T1889.

https://github.com/vyos/vyos-1x/pull/384 is the initial fix for this.

Reopen if needed, but considered resolved.

The immediate issue was resolved above. As far as changing the backend code, this will only be done if there emerges another annoyance; for now, we will consider the preamble 'path' when calling print in a config session a 'feature'.

A list of all related tasks from a search: T1999 T1877 T538 T970 T99 T1095

Must have this feature
https://phabricator.vyos.net/T1083

vyos@vyos:~$ monitor traceroute vrf red 1.1.1.1