it's not a bug, this command are able in ospf :

@devon

after merge this ldp bug fixed , I saw that now it's already working . Could you check it ? I've tested on a lab and it seems to work :

I’m also seeing this error after the update to 1.3.4

That looks better:

        chain VZONE_LOCAL_OUT {
                oifname "lo" counter packets 387 bytes 33672 return
                oifname "bond0.40" counter packets 14 bytes 496 jump NAME_LOCAL_TO_ALL
                oifname "bond0.40" counter packets 0 bytes 0 return
                oifname "bond0.70" counter packets 0 bytes 0 jump NAME_LOCAL_TO_ALL
                oifname "bond0.70" counter packets 0 bytes 0 return
r packets 0 bytes 0 jump NAME_LOCAL_TO_ALL
                oifname { "bond0.7", "bond0.30", "bond0.90", "bond0.88" } counter packets 0 bytes 0 return
                oifname { "eth0", "pppoe0", "eth1.281" } counter packets 3 bytes 180 jump NAME_LOCAL_TO_ALL
                oifname { "eth0", "pppoe0", "eth1.281" } counter packets 0 bytes 0 return
                oifname "bond0.80" counter packets 2 bytes 80 jump NAME_LOCAL_TO_ALL
                oifname "bond0.80" counter packets 0 bytes 0 return
                oifname { "bond0.1", "podman-cntr-net" } counter packets 2 bytes 128 jump NAME_LOCAL_TO_ALL
                oifname { "bond0.1", "podman-cntr-net" } counter packets 0 bytes 0 return
                oifname { "wg0", "vti0", "vtun0", "podman-ts-net" } counter packets 0 bytes 0 jump NAME_LOCAL_TO_ALL
                oifname { "wg0", "vti0", "vtun0", "podman-ts-net" } counter packets 0 bytes 0 return
                counter packets 0 bytes 0 drop comment "zone_LOCAL default-action drop"
        }

tested /resolved

Does anyone knows real scenario where permanently storing/saving this logs are required?
Yes, this feature is not working on 1.4, neither on 1.5
But I can't think on a real case where this logs are needed. I know that keeping information of NAT for certain ISP is mandatory due lo legal requirements. But writing a log entry for every conntrack status change seems like it will flood logs, and may consume more resources than expected.
With usage of netflow/slflow, maybe this required information can be obtained in the netflow collector, and do not increase load on vyos router.

It seems to be the difference between the vyos version build in the Dockerfile of librtr-dev and the Debian librtr-dev version (which works).

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

Thanks, I'll wait for the merge and test the new iso ASAP.

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

If you add the librtr-dev to the docker build image and build FRR (with the docker build image) yourself it works:

$ git clone -b current --single-branch https://github.com/vyos/vyos-build.git
$ cd vyos-build
$ vi docker/Dockerfile
$ git diff
diff --git a/docker/Dockerfile b/docker/Dockerfile
index 953ea4c..baeb232 100644
--- a/docker/Dockerfile
+++ b/docker/Dockerfile
@@ -345,6 +345,9 @@ RUN apt-get update && apt-get install -y \
       libnl-genl-3-dev \
       libxtables-dev

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

Working on it! Thanks for the details!

Yup, VPN site to site authentication credentials are stored as "secret" hence the patch.

Do you have any example of in which context that exists?

In that PR, shouldnt also ifb* be included?

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

@n.fort Unfortunately, I'm hitting an issue with traffic sent from the router itself.
Running 1.4-rolling-202311021131.
Interfaces eth0 and pppoe0 are WAN. Interfaces bond0* are LAN.
For example, running dig google.nl @9.9.9.9 from the VyOS CLI will fail. The kernel log says:

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

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

set service snmp community public client '127.0.0.1'
set service snmp mib interface-max '25'
set service snmp mib interface 'eth'
set service snmp mib interface 'bond'

+1 for the other "virtual interfaces like lo, dummy, sstp. If such an interface is created - vyos.ifconfig library sets (or should set) all the appropriate sysctl stuff

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.

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

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.

Part of those is fixed with telegraf update in T5701

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