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
}Should we revive this consideration again? See https://github.com/ddclient/ddclient/issues/528.
In T5123#145898, @fernando wrote:cool , it could be useful.
Management Commands
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
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: 1also 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:
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 202Re 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.
In T4516#145664, @Viacheslav wrote:
@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...
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:
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:~$