tested on 1.4-rolling-202311080309

I'm marking this one as resolved since ZBF was already re-introduced.

Can we mark this one as resolved for 1.5? Seems it wasn't back-ported yet to Saggita @sdev

@c-po It seems you only implement the "type bridge_slave neigh_suppress on"
And "type bridge_slave learning on" is not implemented in this PR.
Will you add this also?
Thank you

set protocols static neighbor-proxy arp 192.0.2.1 interface eth1

check

vyos@r4# sudo ip nei show proxy
192.0.2.1 dev eth1 proxy 
[edit]
vyos@r4#

According to firewall-version.xml.i, the firewall config version was not updated to 12. Was this intentional?

@Viacheslav My addition of the onlink option is really brute-force, applied blindly to everything just to see if that was a solution and give you more information. I do not think my "fix" is really ready for a PR.

@giuavo I didn't test "default route", only regular routes for some prefixes, and it worked.
Could you create a PR?

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

Tested in 1.3. Everything works

Tested in 1.5

Backport to 1.4 https://github.com/vyos/vyos-1x/pull/2449

It's fixed in 1.5-rolling-202311060023 but the bug is still present in 1.4.

I would mainly want to log new conntrack entries for various reasons.

@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 :

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.

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

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

Working on it! Thanks for the details!

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.

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