It will be easy to add; you need to generate a new CLI like with "prometheus-client" for example https://github.com/vyos/vyos-1x/blob/03d8c16a12d182a2fb2ab9f7acec5d8cb83937ba/interface-definitions/service_monitoring_telegraf.xml.in#L188-L250
And add template changes https://github.com/vyos/vyos-1x/blob/03d8c16a12d182a2fb2ab9f7acec5d8cb83937ba/data/templates/telegraf/telegraf.j2#L45-L58

@lclements0 Add a simple set of commands to reproduce.

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

set nat cgnat log-allocation
set nat cgnat pool external ext-01 external-port-range '1024-65535'
set nat cgnat pool external ext-01 per-user-limit port '2000'
set nat cgnat pool external ext-01 range 192.168.122.222/32
set nat cgnat pool internal int-01 range '100.64.0.0/28'
set nat cgnat rule 10 source pool 'int-01'
set nat cgnat rule 10 translation pool 'ext-01'

check logs:

Jun 10 14:10:02 r4 sudo[9057]:     vyos : TTY=pts/0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/bin/sh -c ' /usr/libexec/vyos/conf_mode/nat_cgnat.py'
Jun 10 14:10:02 r4 sudo[9057]: pam_unix(sudo:session): session opened for user root(uid=0) by vyos(uid=1003)
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.0, external host: 192.168.122.222, Port range: 1024-3023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.1, external host: 192.168.122.222, Port range: 3024-5023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.2, external host: 192.168.122.222, Port range: 5024-7023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.3, external host: 192.168.122.222, Port range: 7024-9023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.4, external host: 192.168.122.222, Port range: 9024-11023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.5, external host: 192.168.122.222, Port range: 11024-13023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.6, external host: 192.168.122.222, Port range: 13024-15023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.7, external host: 192.168.122.222, Port range: 15024-17023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.8, external host: 192.168.122.222, Port range: 17024-19023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.9, external host: 192.168.122.222, Port range: 19024-21023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.10, external host: 192.168.122.222, Port range: 21024-23023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.11, external host: 192.168.122.222, Port range: 23024-25023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.12, external host: 192.168.122.222, Port range: 25024-27023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.13, external host: 192.168.122.222, Port range: 27024-29023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.14, external host: 192.168.122.222, Port range: 29024-31023
Jun 10 14:10:03 r4 cgnat[9059]: Internal host: 100.64.0.15, external host: 192.168.122.222, Port range: 31024-33023
Jun 10 14:10:03 r4 sudo[9057]: pam_unix(sudo:session): session closed for user root

Accel-ppp does not work with VPP

At the meeting, we concluded that tables should not intersect with protocols static table x
This PR was just to make this use case when they intersect and have a more flexible configuration.
Without using the same tables, it makes no sense in this PR.
That's why it was closed

In T6448#191156, @HappyShr00m wrote:

I have not used it since I thought it would delete even running instances or stop them. if it doesn't, then may I suggest adding a description to the command to indicate that it will not impact the running containers. thanks

In T6445#191083, @Apachez wrote:

Yes but this is what the peer would do on its own - if the opposite device is lost in connectivity it can rollback to previous config which is enabled by default (that is history of configs).

It will delete all unused images
Did you try this command, as the command does not work?

@talmakion Good catch! Thanks for contributing!

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

In T6445#191034, @Apachez wrote:

This can be handled just like "how others does it" as in if the peer is lost after a sync then the peer will automatically return to previous config.

Swap/change/hide config entries are not implemented.
It is not a bug but a feature request.

The config-sync is not a HA.
I don't think config-sync should save, reboot, or do something else.
Imagine if, due to config-sync, you lose access to the secondary node and if it was saved by config-sync.

If you add this config after the server is configured, it works as it requires a restart of the service

sudo systemctl restart accel-ppp@pppoe.service

Or reconfigure the service again

@L0crian Some TC combinations are affected by locks, so they are impossible to use with, for example, /16 networks.

Add the set of commands to reproduce.

Should be fixed in T6373

Duplicate

We do not need add tasks for the documentation. There are a lot of things that are not documented or require improvements.
Just create a PR to the documentation repo.

This is a new feature that was added after EPA-3 release
It was added 3 days ago https://github.com/vyos/vyos-1x/pull/3535

Provide the full (minimal) set of commands to reproduce.

Need a general place to store accounts for VPN; whether it is a local radius server or chap-secrets file(this option seems simpler and more correct) is not so important.
A separate radius server is another point of failure and a separate infrastructure object. Wants to have a boxed solution where everything is available at once

The similar task T6409

It is not clear why it should be ignored? If they should be ignored they must not be in the CLI at all.
Why not use RADIUS authentication for it?

It probably cannot be a universal solution due to specific per-user options.
For example, for opencoonect, you can add otp if you want on a per-user basis and not do it for other users.

vyos@r4# set vpn openconnect authentication local-users username foo 
Possible completions:
   disable              Disable instance
 > otp                  2FA OTP authentication parameters
   password             Password used for authentication

More a feature request than a bug

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

Can you provide set of commands instead? Bug-report-guidelines

The charon identifier also shows IKE name of the SA; this way, we can identify peers in the logs https://github.com/vyos/vyos-build/blob/b809886538eaad66b8756be8f5e758584f88e6a6/data/live-build-config/hooks/live/30-strongswan-configs.chroot#L41-L54
The current show log vpn does https://github.com/vyos/vyos-1x/blob/48e5266e2bca8d1d7a2ee4bacbe0e6628de3fa66/op-mode-definitions/show-log.xml.in#L710

The dependency allowed for 386/amd64 only https://github.com/vyos/vyos-build/blob/b809886538eaad66b8756be8f5e758584f88e6a6/docker/Dockerfile#L281
Though the package is available for ARM

As several CA were allowed some time ago it is a bug with op-mode generator.
There is a list of CA's https://github.com/vyos/vyos-1x/blob/48e5266e2bca8d1d7a2ee4bacbe0e6628de3fa66/src/op_mode/ikev2_profile_generator.py#L147
The template https://github.com/vyos/vyos-1x/blob/current/data/templates/ipsec/windows_profile.j2

Probably the best way will be moving the config to the vrf section (not implemented)
For example:

set vrf name foo service dhcp-server shared-network-name eth1 option default-router '192.168.1.1'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 lease '300'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default start '192.168.1.10'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default stop '192.168.1.100'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 subnet-id '1'

And start several instances, each with its configuration.

The similar task for redirect T260