one issue.
the migration scripts don't take into account older load balancing configs.

PR https://github.com/vyos/vyatta-wanloadbalance/pull/18

Fixed with rewriting to systemd unit vyos-wan-load-balance.service

In T5213#148346, @joshua.hanley wrote:

@Viacheslav Thanks for the prompt response. Not sure if the change will also cover L2TP as well. For example:

set vpn l2tp remote-access authentication radius accounting-interim-interval '60'

Sometimes it stuck for ~1.5 minutes after deleting.

vyos@r14# delete load-balancing 
[edit]
vyos@r14# commit

@Viacheslav Thanks for the prompt response. Not sure if the change will also cover L2TP as well. For example:

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

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

set service pppoe-server authentication mode 'radius'
set service pppoe-server authentication radius accounting-interim-interval '60'
set service pppoe-server authentication radius server 203.0.113.1 key '123'
set service pppoe-server client-ip-pool name POOL-01 gateway-address '192.0.2.1'
set service pppoe-server client-ip-pool name POOL-01 subnet '192.0.2.0/24'
set service pppoe-server interface eth1

https://github.com/vyos/vyos-1x/pull/1985

https://github.com/vyos/vyos-1x/pull/1985

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

set high-availability disable
set high-availability vrrp group GRP01 address 192.0.2.47/32
set high-availability vrrp group GRP01 interface 'eth1'
set high-availability vrrp group GRP01 vrid '10'

It doesn't like protocol tcp

vyos@r14# sudo tc filter replace dev eth1 parent 1: protocol all u32 match ip protocol tcp 0xff action police rate 300000000 burst 15k flowid 1:a
Illegal "match"
[edit]
vyos@r14#

But it works with protocol 6

vyos@r14# sudo tc filter replace dev eth1 parent 1: protocol all u32 match ip protocol 6 0xff action police rate 300000000 burst 15k flowid 1:a
[edit]
vyos@r14#

And next fail:

ardware UUID:    4d6f4d29-1ae8-446f-8d2b-3decd9da64c7

On 1.4-rolling-202305080742, speed limit and protocol detection still not worked out correctly too.

In T3655#143947, @fernando wrote:

it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .

In T5116#147654, @Viacheslav wrote:

I think the only solution is to use network namespaces
https://docs.strongswan.org/docs/5.9/howtos/nameSpaces.html

thanks for the contribution , I've done some test , it seems to work like a champ . @dmbaturin @c-po this script to do the steps necessary to compile the kernel module to use ovpn-dco . Could you check if it's correct or something needs to be improved :

Great, maybe we can use jool to build it!

Already fixed in https://github.com/vyos/vyos-1x/commit/aaa98de536cb1b9d6ab5a18341a56543b5b57ce1

Thanks! Setting a router-id fixed it for VPNv4 and VPNv6. It also works without creating a dummy interface.

In T5082#148096, @onedr0p wrote:

@c-po I know we're on rolling for 1.4 but is there any way to communicate breaking changes like this in the future? If this was mentioned in the PR or ticket I don't think there would have been any confusion.

As for this tickets status it can be closed.

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

PR https://github.com/vyos/vyos-1x/pull/1980
PR https://github.com/vyos/vyos-build/pull/347

@c-po I know we're on rolling for 1.4 but is there any way to communicate breaking changes like this in the future? If this was mentioned in the PR or ticket I don't think there would have been any confusion.

This can be implemented by multiple daemon instances in separate vrf's.

PRs:
1.3 - https://github.com/vyos/vyos-1x/pull/1979
1.4 - https://github.com/vyos/vyos-1x/pull/1978

@dcplaya yeah that was a transitional error/quirk as we renamed that one during the development cycle.

It might be a boot/slow DHCP lease issue.

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 failure

I've identified the root cause of the problem. It seems to be the control plane filter (local firewall) applied to the router that is preventing connections from the localhost to localhost:2004.

https://git.netfilter.org/conntrack-tools/tree/src/sync-mode.c#n620

Hi, the reason why the modem does not show up is because usb0 interfaces do not match the prefix we use to distinguish between interfaces.

Tested successfully! Modem showed up as usb0 in ip link, but not in show interfaces.

VPP 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'

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

Jool package was added to the vyos-build repo in https://github.com/vyos/vyos-build/commit/d9f711f500ea21288a50f54640dff833cd1da153