Proposed fix in - https://github.com/vyos/vyos-build/pull/299

Fixed in commit: https://github.com/vyos/vyos-1x/commit/6eea12512e59cc28f5c2e5ca5ec7e9e7b21731da

Error reporting: PR's
https://github.com/vyos/vyos-1x/pull/1789
https://github.com/vyos/vyos1x-config/pull/12 (merged)
https://github.com/vyos/libvyosconfig/pull/6 (merged)

Backport PR https://github.com/vyos/vyos-cloud-init/pull/60

Fixed in the https://github.com/vyos/vyos-cloud-init/pull/58

Fix for 1.4: https://github.com/vyos/vyos-cloud-init/pull/59
It must be backported to 1.3 now.

If I don't use advertise-all-vni I get an error

This command is only supported under EVPN VRF

Please use

advertise-all-vni

My full bgp config:

Ok I'll re-check with the latest rolling.

r14# show version 
FRRouting 8.4.2 (r14) on Linux(6.1.6-amd64-vyos).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

hmm, very strange.

The Original FRR log
This command is only supported under EVPN VRF

r14# conf t
r14(config)# router bgp 65000
r14(config-router)# address-family l2vpn evpn 
r14(config-router-af)# 
r14(config-router-af)# vni 100
r14(config-router-af-vni)# 
r14(config-router-af-vni)# route-target import 65000:100
This command is only supported under EVPN VRF
r14(config-router-af-vni)#

In testing this I found that ocserv validates its config on startup and using radius accounting without radius authentication fails to validate and the service will not start. As a result i'm not treating OpenConnect accounting as dependant on the radius as the authentication mode.

migration script modified in current; lower task priority to test error reporting from libvyoconfig.

Yeah, in my case as well, NPTv6 is mostly only useful if it it works with a dynamic (from DHCPv6-PD) prefix, since that's how my ISP provides addresses (AFAIK I'd have to pay for a business connection to get a static prefix, though I haven't actually called and asked myself). I'm tempted to play with hacking something together by building from source myself with some tweaks to auto-update the nat rules when it gets a new PD prefix.

I've created a pull request which add support for this, and yes, it does use raw command.
I know that here we want to avoid "raw options" but I think this is one of the most needed feature and I don't see any other way else to do this. Until a better option is found, I think my PR should do just fine.

Tested in a server/client setup:

I can confirm that with VyOS 1.4-rolling-202301250317 the issue is gone.
At least based on my setup and configuration
Thx for fixing quickly

Please test with latest rolling