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

The following adds support into the XML generation but I have no clue about vyatta-cfg how those files get executed.

Presumably a val_help line in the op-mode node.def, too

Tested good - migrating traceroute now

On boot, the existing config file is committed.

Right. In my opinion it would be necessary to change that.

Definition of effective is here:

Enhancement created.
Question to ISC submitted (https://gitlab.isc.org/isc-projects/dhcp/-/issues/104)

@ddiguru
I confirm all the issues that you have observed. I was able to reproduce them in the both our LTS and currect rolling releases.

1. Issue with a wrong giaddr address. This sounds like a bug in the isc-dhp-relay package. Fortunately, those extra packets with a wrong giaddr address could be eliminated in newer versions by using "-id" and "-iu" instead of muliple "-i" options. isc-dhcp-relay allows for this since v4.3.5. I will create a Feature Request to modify the VyOS config syntax and isc-dhcp-relay config file accordingly. In the meantime I will try to confirm with ISC people that this indeed is a bug.
2. Issue with duplicate packets. isc-dhp-relay seems to unnecessarily relay unicast packets (I have no idea why it does so). That's why you see all unicast packets doubled. Looks like another bug :) The good news is that it is more cosmetic issue. I already submitted the ticket for it (https://gitlab.isc.org/isc-projects/dhcp/-/issues/102)

https://github.com/vyos/vyos-cloud-init/pull/10