I decided to dig into this a little more and try to trace this out:

sudo nft add chain inet vrf_zones trace_chain { type filter hook prerouting priority -301\; }
sudo nft add rule inet vrf_zones trace_chain meta nftrace set 1

@dmbaturin, @sever
Would love your input regarding the lack of headers when using the -c option. I've created a PoC around "chronyc -c activity" as it was the most straight forward command to start with.

@dmbaturin , @Viacheslav - I use debian snapshot repository when building VyOS LTS on my own.

side note, if you flush ruleset, and only add:

Something I just figured out is that the minute I do:

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

The regression causing 'image cannot be found" was fixed in https://vyos.dev/T6186.

PR:
https://github.com/vyos/vyos-http-api-tools/pull/11

Status update:

• "Like for like" functionality between .sh script and .py script is complete and working (can be viewed in PR)
• Raw output capability -> in progress

@Viacheslav concur that it looks to be resolved. The last log entry was at 9:10 and nothing telegraph-related has been logged in almost 30 minutes since. I will close ticket. Thank your help and insight.

We'll close it if no response

A docker container usually has issues with loop devices:
Use the VM or attach dev

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

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

PR https://github.com/vyos/vyos-1x/pull/3313
Add onlink option

set interfaces ethernet eth0 vif 10 address '10.20.30.1/32'
set protocols static route 10.20.30.0/32 interface eth0.10

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

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

It is more of a feature request than a bug due to specific kernel routes.
Feature to add onlink option

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

I even commented on that issue…
It would seem my memory ages out after 3 years 🤣

Read the documentation for the 1.5

The same task https://vyos.dev/T3861

I probably can continue here in summer at first.

My system finally crashed again today. I found a workload that generates enough traffic over the VPN to reliably re-produce.

Seems like its either fixed or was a quirk in that specific version.

I don't see those logs:

set service monitoring telegraf influxdb authentication organization 'vyos'
set service monitoring telegraf influxdb authentication token 'lxxx='
set service monitoring telegraf influxdb bucket 'vyos'
set service monitoring telegraf influxdb url 'http://192.168.122.14'