It should work for 1.4
set policy route foo interface eth1v1
It should work for 1.4
set policy route foo interface eth1v1
Load-balancing op-mode output generated by https://github.com/vyos/vyatta-wanloadbalance/blob/current/src/lboutput.cc
Works in my test
set protocols static table 200 route 192.0.2.35/32 dhcp-interface 'eth4'
Show ip route
vyos@vyos2:~$ vtysh -c "show ip route table 200"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failureVPP 23.02 failing on Debian 12 (bookworm) https://jira.fd.io/browse/VPP-2075
PR https://github.com/vyos/vyos-1x/pull/1975
set policy route-map foo rule 10 action 'permit' set policy route-map foo rule 10 match protocol 'connected' set policy route-map foo rule 20 action 'permit' set policy route-map foo rule 20 match protocol 'bgp'
I think the only solution is to use network namespaces
https://docs.strongswan.org/docs/5.9/howtos/nameSpaces.html
Do you have users/passwords with specsymbols or not utf-8 or some ascii symbols?
Could you provide l2tp configuration? show conf com | match l2tp
I cannot reproduce it
vyos@r14:~$ vyos@r14:~$ show l2tp-server sessions ifname | username | ip | ip6 | ip6-dp | calling-sid | rate-limit | state | uptime | rx-bytes | tx-bytes --------+----------+--------------+-----+--------+---------------+------------+--------+----------+----------+---------- l2tp0 | alice | 100.64.203.0 | | | 192.168.122.1 | | active | 00:00:10 | 246 B | 208 B vyos@r14:~$ vyos@r14:~$ vyos@r14:~$ show version Version: VyOS 1.4-rolling-202304261027 Release train: current
@joshua.hanley Could you provide the output of the next command?
sudo accel-cmd -p 2004 show sessions
Incorrect modify modify_section: starting search for '^vrf protocols' until '^exit-vrf'
vyos@r14# delete vrf name red vni
[edit]
vyos@r14# commit
[ vrf name red vni 3000 ]
{'name': {'protocols': {'bgp': {'address_family': {'ipv4_unicast': {'redistribute': {'connected': {}}},
'l2vpn_evpn': {'advertise': {'ipv4': {'unicast': {}}}}},
'system_as': '65001'}},
'table': '3000'}}
load_configuration: Configuration loaded from FRR daemon zebra
load_configuration: loaded 0 !
load_configuration: loaded 1 frr version 8.5
load_configuration: loaded 2 frr defaults traditional
load_configuration: loaded 3 hostname debian
load_configuration: loaded 4 log syslog
load_configuration: loaded 5 log facility local7
load_configuration: loaded 6 hostname r14
load_configuration: loaded 7 service integrated-vtysh-config
load_configuration: loaded 8 !
load_configuration: loaded 9 vrf red
load_configuration: loaded 10 vni 3000
load_configuration: loaded 11 exit-vrf
load_configuration: loaded 12 !
load_configuration: loaded 13 end
modify_section: starting search for '^vrf protocols' until '^exit-vrf'@Harliff Could you check it? Available in the latest rolling release
vyos@r14# set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy Possible completions: all-available All targets must be alive any-available Any target must be alive (default)
PR https://github.com/vyos/vyos-1x/pull/1966
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 'any-available' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.1' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.11' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check timeout '3' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 interface 'eth0'
Don't have any idea how to integrate this logic to XML https://github.com/vyos/vyatta-wanloadbalance/blob/973421035568810e2583187c48d14054970b9806/templates/load-balancing/wan/node.def#L2-L5
In T1237#147125, @Harliff wrote:Sorry, missed some messages.
In T1237#146586, @Viacheslav wrote:We have targets-checks 203.0.113.1, 192.0.2.1, and if any of these targets are unreachable, we delete this route.
Is it correct?It is not correct. I think it would be better to remove the route if ALL of corresponding targets are unreachable.
A target may become unreachable due to a problem of its own rather than an uplink failure. This is the reason why I asked to add multiple targets per uplink.
Provide your configuration
It is difficult to say without it
It uses other names in the newest versions, not cni-xxx
The firewall for ocserv is handled by https://gitlab.com/openconnect/ocserv/-/blob/master/src/ocserv-fw and uses iptables by default
@Harliff Could you re-check?
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1954