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:

The required patch is not included in builds and they have the same bug.

Version:          VyOS 1.3-stable-202303270442
Release train:    equuleus

PRs:

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

PR https://github.com/vyos/vyos-build/pull/323

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