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?

There is current work that will be replacing the legacy show command, removing this bottleneck; related tasks will link here to keep track of progress.

In addiction we experiment problem even with api and graphql

Hello from Grafana,

Nov 27 21:47:20 kernel: [STATE-POLICY-INV-A]IN= OUT=eth3 MAC=01:80:c2:00:00:00:60:be:b4:10:7a:6d:00:26
Nov 27 21:47:20 kernel: [STATE-POLICY-INV-A]IN= OUT=eth2 MAC=01:80:c2:00:00:00:60:be:b4:10:7a:6c:00:26

21:35:57.958675 60:be:b4:10:7a:6a > 01:80:c2:00:00:00, 802.3, length 38: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.52:37:9c:d2:22:eb.8001, length 35

this isthe invalid stp traffic log

Can you share logs for those entries?

Hi @n.fort
the error messages disappeared after manual add your command. there still has few stp traffic with same error

Can you check manually adding next rule?

I think it being called and centered around blacklisting is too specific. I'd be more inclined to see it as a firewall group, perhaps like the functionality of domain groups:

Example vyos config:

A lot of work was lost in mid of the year when my not pushed changes got lost due to a hardware failure.
So I had to do the work again.

Personally I would still prefer the later that is with DebianBanner no.

Had a look at this since it seems an easy task, but adding DebianBanner no only removes the Debian packages version string. As far as I can tell there is no way to remove the SSHd versiond used.

@daniil Any idea for CLI and what it should generate to strongswan.conf?
Which plugin should it use?
https://docs.strongswan.org/docs/5.9/plugins/plugins.html

eap-dynamic Plugin
eap-gtc Plugin
eap-radius Plugin
eap-simaka-sql Plugin
eap-tls Plugin

Nov 17, 2024

In T4930#208556, @Viacheslav wrote:

@runar btw, we have python script for the priority /usr/libexec/vyos/priority.py

@runar btw, we have python script for the priority /usr/libexec/vyos/priority.py

I don't agree with the 'refresh peer' idea in this script, it would ruin connections with peers with ddns. Also the $IP by digging, it's stupid and it can't handle any CNAMEs.

This script is handed over as an example for how it potentially can be done and not a "this is how you should do it", and yea there are potentials for improvement. but to call digging stupid is not correct in my mind, as it does exactly what its set to do.
as for the issue you noted that can be fixed by using tail -1 instead of head -1, that way you get the last element in the list, eg. the address that the cname points to.

In T4930#208505, @runar wrote:

Hi!

I do not like the concept that this should be done inline while in the middle of a commit.
As this will halt the commit phase for potentially a long time (relative) if dns is not up'n'running.
This in itself is not that critical, but if this is done the same on multiple sub-systems you potentially can have an exponentionall increase of boot time because of this.
And in a time where we are optimising milliseconds of code to get shorter boot and commit times in other subsystems i feel this is not the correct way to do it.

This task can remain closed - I have created a new task instead:

The new package exists at: https://github.com/vyos/vyos-build/tree/current/scripts/package-build/xen-guest-agent

I do not like the concept that this should be done inline while in the middle of a commit.
As this will halt the commit phase for potentially a long time (relative) if dns is not up'n'running.
This in itself is not that critical, but if this is done the same on multiple sub-systems you potentially can have an exponentionall increase of boot time because of this.
And in a time where we are optimising milliseconds of code to get shorter boot and commit times in other subsystems i feel this is not the correct way to do it.

Sounds reasonable! I'm not going to worry about it any more, unless I see any further symptoms. Thanks a lot for the fix and taking the time to respond here!

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

@gadams it may well have been the case that the fragile synchronization before the fix was in fact a cause of the problem, at least in some (all ?) cases. I expected however, that any other config error on boot could also trigger the complaint in vyos-configd, which would consequently drop any useful output. With the original change in T6326 and the fix in T6899, any output (error or otherwise) should now be robust and generally available (notably, through the http-api, which was the motivation to finally fix the output workaround for T6326).

To be clear, the clean-config boot hangs I was seeing were prior to this fix. Since the fix, I have yet to see the hang.