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:

sfinke@gw-vpn.bap.rhr.de:~$ 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.

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