Seen in time to pull back the RIPE Labs article on automating V4LESS-AS with VyOS and spending my end-year holidays re-building my automation on another stack. -.-'

I prepared a service to log some network events including changing link status.
to configure service:

conf
set service monitoring network-event event addr
set service monitoring network-event event link
set service monitoring network-event event neigh
set service monitoring network-event event route
set service monitoring network-event event rule
commit

to check change status:

vyos@vyos:~$ sudo ip link set down dev eth1
vyos@vyos:~$ sudo ip link set up dev eth1
vyos@vyos:~$ show interfaces ethernet eth1 event-log link 
Dec 03 09:30:09 vyos-network-event-logger[21158]: [LINK]   3: eth1:  <BROADCAST,MULTICAST>  mtu 1500  qdisc fq_codel  state DOWN  group 0  link/ether 0c:89:0a:2e:00:01  brd ff:ff:ff:ff:ff:ff  [altname enp0s4] [altname ens4]
Dec 03 09:30:14 vyos-network-event-logger[21158]: [LINK]   3: eth1:  <BROADCAST,MULTICAST,UP,LOWER_UP>  mtu 1500  qdisc fq_codel  state UP  group 0  link/ether 0c:89:0a:2e:00:01  brd ff:ff:ff:ff:ff:ff  [altname enp0s4] [altname ens4]

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

Investigating a little bit show big time diff here

LTS release package repositories are permanently closed for public access.
https://forum.vyos.io/t/lts-release-package-repositories-permanently-closed-for-public-access/

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

I came up with a possible solution:

Here are some config commands I used with my ubnt plugin

Code committed.

Implemented for the next 1.4.1
@a.apostoliuk recheck please and close if works as expected

Implemented in T6045

Dear Apachez
I observed a big load and time spent in 4 unionfs procs.
So probably you're point in hte right direction

I would insist only not adding endpoint, let peer be ready if they have configured with hostname endpoint.

If it does not block commit that's fine for me

Wouldnt be surprised if it turns out to be the same root cause as this is related to:

"blackhole" is a common term in regards of dropping traffic.

Here is how to get the latest-handshakes in seconds:

You are right with the naming we should consider this.
Regarding differentiation between network and address lists:
The current sources are returning mixed lists containing addresses and prefixes so I would not consider having both.

In T4930#208881, @c-po wrote:

@runar @sskaje

In general I like the idea and it's a very useful addition. Given the current implementation and design of wireguard to be easy, lightweight and not messed with 1000 of config options the design choice is to move everything requiring brain out of the WG core code.

In general I like the idea and it's a very useful addition. Given the current implementation and design of wireguard to be easy, lightweight and not messed with 1000 of config options the design choice is to move everything requiring brain out of the WG core code.

In T4930#182050, @Fr0stedD0nut wrote:

Does anyone have any thoughts on the best place to start adding this functionality / design ideas for this feature?

@c-po I'm curious, does using a hub like you suggest mean all data gets proxied through the hub, or is the hub enough to facilitate the connections and then the clients talk directly to each other?