Shouldnt dummy* and some others be excluded aswell?

To fix it

sudo nano -c /lib/udev/rules.d/99-systemd.rules

Find sysctl line

# Apply sysctl variables to network devices (and only to those) as they appear.
ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"

Replace to:

# Apply sysctl variables to network devices (and only to those) as they appear.
ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo|ppp*|ipoe*", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name"

Tested with 1.5-rolling-202311030022 and working as expected.

PR for VyOS 1.4 https://github.com/vyos/vyos-1x/pull/2433

I think we may be talking about different things. The situation I am testing has the pair of QFX switches. An end server has a pair of interfaces in a bond with each interface going to one QFX. VyOS is configured with an interface to each QFX but not in a bond (just two different VLANs). The designated forwarder election for the segment to the end server is handled by the QFXs.

@shthead: Im talking about features in VyOS. I dont care what others such as Juniper does or doesnt do.

In T5698#163675, @Apachez wrote:

@shthead: Yes but when it comes to multihoming there are some additional settings that should exist aswell:

https://www.arista.com/en/um-eos/eos-vxlan-configuration#topic_ckc_dh4_ynb

redundancy single-active
vs.
redundancy all-active

The migration scripts still have an issue @n.fort I sent you the issues with loading a 1.4 rolling to 1.5 in slack

Good to know it worked @marc_s . Thanks for letting us know!

@shthead: Yes but when it comes to multihoming there are some additional settings that should exist aswell:

PR for VyOS 1.5 https://github.com/vyos/vyos-1x/pull/2431

@Viacheslav @n.fort Regarding https://github.com/vyos/vyos-1x/pull/2388: I just tested on 1.4-rolling-202311021131: ZBF config from 1.4-rolling-202304120317 loaded without a hitch.
This is a 8 zone, 959 line config.

PR https://github.com/vyos/vyos-1x/pull/2427

I understand (and accept) the risks of running rolling.

In T5681#163634, @JeffWDH wrote:

When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.

Snippet from vyos-migrate.log:

List of executed migration scripts:
List of executed migration scripts:
List of executed migration scripts:
/opt/vyatta/etc/config-migrate/migrate/cluster/1-to-2
/opt/vyatta/etc/config-migrate/migrate/interfaces/31-to-32
/opt/vyatta/etc/config-migrate/migrate/nat/5-to-6
- op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface']
- op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name'] value: vtun0 replace: True
- op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface']
- op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name'] value: vtun1 replace: True
<omitted a bunch of NAT rules>
/opt/vyatta/etc/config-migrate/migrate/nat/6-to-7
- op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name']
- op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'name'] value: vtun0 replace: True
- op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name']
- op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'name'] value: vtun1 replace: True
<omitted a bunch of NAT rules>
/opt/vyatta/etc/config-migrate/migrate/nat66/1-to-2

After readding them with the new syntax all is good, but it looks like for some reason the migration script didn't run on my system.

When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.

PR: https://github.com/vyos/vyos-1x/pull/2424

PR https://github.com/vyos/vyos-1x/pull/2423

There is a bug when we use lowercase "cisco"

set service pppoe-server authentication radius rate-limit vendor 'cisco'

It doesn't work as vendor is Cisco not cisco

vyos@vyos-lns# sudo cat  /usr/share/accel-ppp/radius/dictionary.cisco | grep -i vendor
VENDOR		Cisco

PR for 1.4 https://github.com/vyos/vyos-build/pull/451

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

PR for 1.5 which will be backported to 1.4 https://github.com/vyos/vyos-1x/pull/2416

I don't see this fix having been backported to Equuleus.

I'm building 1.4 rolling with the ixgbe out-of-tree driver if anyone cares.

This has been implemented in 1.5 and 1.4.

@Apachez this request stems from this issue: https://forum.vyos.io/t/evpn-vxlan-esi-lag-duplicate-packets/12581

Both single-active and all-active should be supported when it comes to EVPN Multihoming.

This functionality has also been backported to 1.4 so it will be in the next LTS release.

@Viacheslav yes, I already did last month, but there were lots of errors when veryfing the fix.
I figured it came due to the changes performed by task https://vyos.dev/T5048.

PR created: https://github.com/vyos/vyatta-op/pull/79

One way however to make the variable more robust in case there are for whatever reason more than one squashfs mounted object available is to select the one who is "loop0".

Looking through https://vyos.dev/T5457 I now get what you meant by "re-broke it".

But before the revert by T5690 today T5440 worked perfectly fine so what was "re-broken"?

Nope, it works fine, now; your revision to the change re-broke it.

So in short https://vyos.dev/T5440 will be broken again?

It was fixed in a keepalived project.
https://github.com/acassen/keepalived/commit/9ca8688c7fe591e1face259f19ee6169e20a3438

Should be fixed in https://vyos.dev/T5232
needs to re-check

For the record.

Oops, wrong task.

I would just expose these 3 options as-is.