confirm, it's working :

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

I would like to make some question. this prefix 10.0.0.0/24 on PE2 is a connected network or learned from another routing protocol (static or BGP)

We can use patches dir https://github.com/vyos/vyos-build/blob/c3f11ba39c50a3bd1c69e61c38f1c82960a15ee7/packages/frr/build-frr.sh#L18

There also additional bugs relates iptables-nft as chain WANLOADBALANCE_OUT is not exist
https://github.com/vyos/vyatta-wanloadbalance/blob/70ee1319c20e083ab407d8a11faa44c74d05f084/src/lbdecision.cc#L312

vyos@r14# sudo nft list table ip mangle
# Warning: table ip mangle is managed by iptables-nft, do not touch!
table ip mangle {
	chain PREROUTING {
		type filter hook prerouting priority mangle; policy accept;
		counter packets 851 bytes 179376 jump WANLOADBALANCE_PRE
	}

In T5123#145898, @fernando wrote:

cool , it could be useful.

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

Starting in hsflowd version 2.0.50-3, the mod_dbus module can be asked for the current sFlow agent-address along with other stats, and the example "telemetry" and "telemetry.py" scripts in the repo under src/Linux/scripts/ have both been updated. So if you wanted to offer a "show sflow" CLI command then you might adapt one or other of those scripts to extract the information from the running hsflowd process. The steps would be:

PR for VyOS 1.3 https://github.com/vyos/vyos-1x/pull/1919

PRl https://github.com/vyos/vyatta-wanloadbalance/pull/15

cool , it could be useful.

In T5123#145870, @fernando wrote:

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

vyos@cust-pe2:~$ show ip ospf database

       OSPF Router with ID (1.1.1.1)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
1.1.1.1        1.1.1.1          696 0x80000007 0xd2d4 2
10.255.254.2   10.255.254.2     630 0x80000008 0x682a 3

                Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
10.180.3.2     10.255.254.2     640 0x80000004 0x6f0a

vyos@cust-pe2:~$
vyos@cust-pe2:~$
vyos@cust-pe2:~$ show ip ospf database router

       OSPF Router with ID (1.1.1.1)

                Router Link States (Area 0.0.0.0)

  LS age: 703
  Options: 0x2  : *|-|-|-|-|-|E|-
  LS Flags: 0x3
  Flags: 0x0
  LS Type: router-LSA
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000007
  Checksum: 0xd2d4
  Length: 48

   Number of Links: 2

    Link connected to: Stub Network
     (Link ID) Net: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metric: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.180.3.2
     (Link Data) Router Interface address: 10.180.3.3
      Number of TOS metrics: 0
       TOS 0 Metric: 1

  LS age: 637
  Options: 0x2  : *|-|-|-|-|-|E|-
  LS Flags: 0x6
  Flags: 0x0
  LS Type: router-LSA
  Link State ID: 10.255.254.2
  Advertising Router: 10.255.254.2
  LS Seq Number: 80000008
  Checksum: 0x682a
  Length: 60

   Number of Links: 3

    Link connected to: Stub Network
     (Link ID) Net: 10.255.254.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metric: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.180.3.2
     (Link Data) Router Interface address: 10.180.3.2
      Number of TOS metrics: 0
       TOS 0 Metric: 1

    Link connected to: Stub Network
     (Link ID) Net: 172.16.50.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metric: 1

also FRR doesn't show the information on that way , so you should use those commands or enable the log .

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.