I don't see it as bug , this information can be obtained from OSPF database using LSA or summary:

frr 8.5 LSP is working as expected:

The possible reason https://github.com/vyos/vyatta-wanloadbalance/blob/02f9e8fbee873f9ca1111a69761546c758001b24/src/lbdecision.cc#L116

this fix was added 8.5 :

vyos@cust-pe2:~$ show bgp ipv4 vpn 172.16.80.0/24
BGP routing table entry for 1:2:172.16.80.0/24, version 0
not allocated
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    0.0.0.0 from 0.0.0.0 (1.1.1.1) vrf customer(6) announce-nh-self
      Origin IGP, metric 0, weight 32768, invalid, sourced, local
      Extended Community: RT:1:2
      Originator: 1.1.1.1
      Remote label: 80
      Last update: Wed Mar 29 13:17:24 202

Re Opening this task, since same error is present again

bump hsflowd version to v2.0.50-3

I've made some changes but not sure if the logic is what VyOS team accept.

Code changed, to override all settings in build_config instead of args from cli only.

@stepler Thanks
PR https://github.com/vyos/vyos-1x/pull/1918

Fixed in https://github.com/vyos/vyos-1x/commit/4a44d8bbd328b99582d8079fd086a7239bfc2121

In T4516#145664, @Viacheslav wrote:

@diodep There is the task for it T3001

@n.fort In that case then this functionality does seem to be working as designed, even if the pkttype matcher isn't behaving exactly as I expected it to for "host".

@SrividyaA i have to disagree the ipsec shell script command is depreciated, refer to below...

PR's:
https://github.com/vyos/vyatta-op/pull/59
https://github.com/vyos/vyos-1x/pull/1916

ipsec statusall will not show any details in the latest rolling release as the ipsec.conf backend is deprecated, and swanctl.conf is being used now. Strongswan 5.9.8-5 package is installed and also charon daemon is replaced with the charon-systemd in this version.

Looks like a PAM configuration issue:

@diodep There is the task for it T3001

I think it is good to implement a append kernel boot parameter in configuration file. Like mitigations=off to help old platforms to perform well.

Fix pushed to current:
f8522f323
and updated on test server.

Looks good on 1.4-rolling-202303271007:

The site-to-site mode shows that tunnel not configured
Config:

set interfaces openvpn vtun52 description 'Site-to-Site'
set interfaces openvpn vtun52 local-address xxx.xxx.0.1
set interfaces openvpn vtun52 local-port '1152'
set interfaces openvpn vtun52 mode 'site-to-site'
set interfaces openvpn vtun52 persistent-tunnel
set interfaces openvpn vtun52 protocol 'udp'
set interfaces openvpn vtun52 remote-address 'xxx.xxx.0.2'
set interfaces openvpn vtun52 remote-host 'xxx.xxx.41.117'
set interfaces openvpn vtun52 remote-port '1152'
set interfaces openvpn vtun52 shared-secret-key 's2s'

interface:

vyos@vyos:~$ show int openvpn 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
vtun52           10.52.0.1/32                      u/u  Site-to-Site

Output show openvpn

vyos@vyos:~$ show openvpn site-to-site 
No OpenVPN interfaces configured
vyos@vyos:~$

Most of the match rules results in:

PRs:

• https://github.com/vyos/vyos-1x/pull/1914
• https://github.com/vyos/vyos-documentation/pull/976

PRs:
https://github.com/vyos/vyos-1x/pull/1913
https://github.com/vyos/vyos-documentation/pull/971

This sort of config should absolutely persist across both reboots and upgrades!.

it will be option b) it will be persistent accross reboots but not accross upgrades as only files in /config will be migrated to the new image version.
We could also alter the path to /config/user-data/ or make /etc/keepalived/conf.d/ a symlink to /config/user-data/ so that those files will be migrated during an upgrade.

PR for 1.4:
https://github.com/vyos/vyos-1x/pull/1911
PR for 1.3:
https://github.com/vyos/vyos-1x/pull/1912