Its good for traceability to get a snmp trap sent when the firewall config has been altered/changed/(re-)applied.

Yeah, no worries.

Im biased but here are my testresults using modified VyOS 1.4-rolling-202308060317:

@Apachez thank you for your response 🙏
Sorry, I really have attached screenshots but didn't grant access to them. Fixed.

Some internal test where done, using integration between:

• Traffic shaper. Currently supported in vyos cli
• Bridge firewall. Currently not supported in vyos cli.

According to https://www.kernel.org/doc/html/v6.1/admin-guide/serial-console.html

There were no screenshots included with this task?

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

It seems to exist for current Debian 12.1 (bookworm) so I think it should be a relativily simple task to add that if not already existing:

Sounds almost related to this longrunning shitshow between FRR and the Linux kernel:

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

I admit my setup isn't really the most common for production, but for the home lab crowd it might be ok. Realtek makes many network chip models I assume and their implementation might also vary from board manufacturer to another.
About not using VMware - that's a tougher ask :)

As stated, building libvyosconfig outside of the Docker image may not be desirable. However, as a compromise solution, we can consider moving the vyos1x-config pin/build into the libvyosconfig build script. Suggested PR to follow, and update to task description.

Not only affects, smoketest.. nat66 got broken

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

set service monitoring zabbix-agent directory '/config/zabbix/'
set service monitoring zabbix-agent limits buffer-send '8'
set service monitoring zabbix-agent limits buffer-size '120'
set service monitoring zabbix-agent log debug-level 'warning'
set service monitoring zabbix-agent log size '1'
set service monitoring zabbix-agent server '192.0.2.5'
set service  monitoring zabbix-agent server-active 192.0.2.5 port '10051'
set service monitoring zabbix-agent server-active 2001:db8::123

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

Nope, now i had to do

@aalmenar could you test this patch?

information that can be useful for this feature request :

If that was pppoe i'd have thought of arp, but here with fixed number of l2tp tunnels (22 tunnels from LACs) i don't think arp cache oversizes the table.
Some more information which i can't think of as a failure reason yet, but it looks strange, - just before the issue we see that LAC drops l2tp tunnel for some reason and starts to send SCCRQ with tid=0 as if it just started working. After a while accel-ppp daemon drops the old tunnels and starts the new ones for few LACs. This definitely cause massive (thousands) route updates between zebra and kernel i guess. Sometimes the system can stand this, sometimes it cant.

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

I tried digging through google if somebody else have encountered the same but I couldnt find any obvious hints (except for the zebra nexthop-group keep 1 already mentioned).

I checked the FRR version in the recent rolling release - it is release candidate still. Does it worth upgrading from 8.5.2? As for the possibility - yes, sure we can build latest image.

I added a comment to https://github.com/FRRouting/frr/issues/12239 so hopefully there might be some other commands or stuff to do other than the debug-commands to hunt this thing down.

And the logs looks the same as in your original post?

After 19 hours of production run since yesterday the failure occurred again despite the workaround applied. Routes are cleared from kernel for some reason. During the run we observed few l2tp tunnels drops followed by 600 to 6000 sessions drop. The reason is not clear for now but i'm not sure this should kill zebra functionality this way.

Fixed

set qos interface eth1 egress 'VyOS-HTB'
set qos policy shaper VyOS-HTB bandwidth '100mbit'
set qos policy shaper VyOS-HTB class 10 bandwidth '40%'
set qos policy shaper VyOS-HTB class 10 description 'dscp_EF_ipprec_5_GETS'
set qos policy shaper VyOS-HTB class 10 match AF11 ip dscp 'AF11'
set qos policy shaper VyOS-HTB class 10 priority '1'
set qos policy shaper VyOS-HTB class 10 queue-type 'fair-queue'
set qos policy shaper VyOS-HTB class 20 bandwidth '30%'
set qos policy shaper VyOS-HTB class 20 description 'dscp_AF4x_ipprec_4'
set qos policy shaper VyOS-HTB class 20 match ef ip dscp 'EF'
set qos policy shaper VyOS-HTB class 20 priority '2'
set qos policy shaper VyOS-HTB class 20 queue-type 'fair-queue'
set qos policy shaper VyOS-HTB default bandwidth '20%'
set qos policy shaper VyOS-HTB default queue-type 'fq-codel'

There is template for it https://github.com/vyos/vyos-1x/blob/710dac553fac93d8a205c9bc7e6b116753ac0b34/data/templates/frr/bgpd.frr.j2#L483-L485

@c-po Tried with latest rolling 1.4-rolling-202308060317, rpki doesn't start automatically, one must do:

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

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

Latest rolling uses FRR 9.0. - could you re-test it please?