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.

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

I made an attempt at integrating openvpn-dco into the build here https://github.com/spion06/vyos-build/tree/ovpn-dco. This works fine for me in my testing so far. The kernel module loaded, verified in the logs that it detected and used the dco tunnel. I'm not super familiar with the build system or what else would need to be done for contributing this. I'm just and end-user who would like to see this feature :)

Your CLI config is valid in general but FRR will refuse it with the error message: This command is only supported under EVPN VRF

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

Dear Jestabro,
i built an updated docker image and a new ISO, i do confirm now IPv6 is working correctly.

PR: https://github.com/vyos/vyos-build/pull/343

Ok, if we merge the patch (backported to frr v8.5), this task can be close.

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

Usernames usually take the following format: abc-1234-12
Passwords are a combination of alphanumeric characters.

In T5116#147640, @c-po wrote:

Do you know how to tell Linux to use nameservers within a VRF?
What you mean IPSec/OpenVPN "punch a tunnel through a VRF" ? So the underlay should run via a VRF? source-interface binding does not work?

Thanks for opening the task; note that Viacheslav had opened
https://vyos.dev/T5185
as well, and the updates on the now fixed issue can be found there. This task can be merged into that one and closed.

Merged and repos updated, so this will be in the next nightly build. Note that for a local build, one will need an updated Docker image for the update to vyos1x-config.

Do you know how to tell Linux to use nameservers within a VRF?
What you mean IPSec/OpenVPN "punch a tunnel through a VRF" ? So the underlay should run via a VRF? source-interface binding does not work?

This is a simple bug in the recently introduced configtree node name comparison function; fixed and should be in next rolling.

Do you have users/passwords with specsymbols or not utf-8 or some ascii symbols?

hmmm very strange.... here is my configuration (IP addresses removed):

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

@Viacheslav It hangs for a while and then eventually the following output:

@joshua.hanley Could you provide the output of the next command?

sudo accel-cmd -p 2004 show sessions

PR with dependencies: https://github.com/vyos/vyos-build/pull/341

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

PR (for build): https://github.com/vyos/vyos-build/pull/340

PR: https://github.com/vyos/vyos-build/pull/339

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'

Two cents from the fields. It will be nice to see vrf aware cg-nat solution, when subscribers from a number of "inside" vrfs NAT'ed into one outside vrf. Of course if that's possible.

Test case above produces:

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