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

Added requested config option to Kernel for 1.4

• https://github.com/vyos/vyos-build/commit/88be901bc103d1c47adbbc874d02e8ec5cde3397

If I pre-load my zone firewall with the new interface format (pod-$containerName) and upgrade to vyos-1.4-rolling-202304290647, it seems to upgrade seamlessly

@carazzim0 good find, I updated that and now everything appears to be working again!

Wouldn't it make sense to add iptables as a direct dependency then? Looking back at Debian Bullseye, iptables was still a direct dependency to the podman package. But as of Debian Bookworm, iptables is just a suggested package to podman.

root@bullseye:/# apt-cache depends podman | grep iptables
  Depends: iptables

In either case when trying to PING or TRACEROUTE from a device on my LAN network I can PING and TRACEROUTE 192.168.254.2.

No iptables installed, and also no vyos-1x-smoketest package.

I was able to reproduce the issue in the lab. In order to avoid an automatic assignment of RD after the interface flap, you could add a dummy or loopback interface to the vrf and define it as router-id in your existing configuration, For example:

I want to describe my issues but I am not able to do so very easily since I don't have ipmi on my router.

I updated one of my servers to the latest rolling:

[email protected]:~$ show version
Version:          VyOS 1.4-rolling-202304280615           <-- 28.04.2023
Release train:    current

can you add some more detials? I just used your above container config and upgraded from a VyOS version that came with CNI to a version with netavark and I do not see that error.
netavark was added 2023-04-02.