The same bug as in T6283

Thanks for the heads up, first time reporting an issue, keep up the great work! Here is output of show configuration commands | strip-private

Upstream bug https://github.com/FRRouting/frr/issues/15912

something native would be more powerful

https://github.com/vyos/vyos-1x/pull/3403

also dsmark qdisc was removed

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

@natali-rs1985 Can you check and close it?

@e.pc.yuan Read please https://blog.vyos.io/feature-requests-and-bug-reports-guidelines

A sequence of configuration commands or a complete configuration file is required to recreate a setup where the bug occurs. Please avoid partial configs: a sequence of commands is easy to paste into the console, a complete config is easy to load in a VM, and a partial config is neither! At least not until we implement a "merge from the CLI" feature that allows pasting config file chunks into a session.

You can ask on the forum
Close the task as duplicate

Something like set policy route PBR rule 1 destination group network-group us such that PBR is able to route towards a GEOIP network group will be awesome. I believe it is available in firewall already.

https://github.com/vyos/vyos-1x/pull/3392

Tested as working in: VyOS 1.5-rolling-202405010020

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

Well looks like you hit a WireGuard limitation here (route-leaking the default nexthop to another VRF)

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

In T6281#185620, @c-po wrote:

You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)

Thanks for the hints, that makes sense. Let's see how that can be implemented :)

For added service when typing just:

You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)

You would still be limited to not be able to use " as part of your password.

There should also be migration scripts, as CLI will be changed.

Proposal:

set system config-management commit-archive uri "stor01z-cs.int.trae32566.org/cr01b-vyos"
set system config-management commit-archive scheme "sftp"
set system config-management commit-archive username "cr01b"
set system config-management commit-archive password "$T3$TP@$$W0^%"

We could improve it by breaking up configuration, having the user providing a URI, Protocol and optional username/password as separate values.
Then we can properly encode username/password. This would also give more flexibility how username/password are handled and passed on.

In both cases it is kind of an user error, the password would have to be properly url encoded if provided in one (@ should be %40 in an URI, a ! should be %21).

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

set service config-sync secondary address '192.168.122.11'
set service config-sync secondary port '8443'

Documentation does not require a task on the phabricator.
Thanks.

Migration needed for listen-address when upgrading from isc-dhcp to kea dhcp (1.4 to 1.5)

PR for 1.5: https://github.com/vyos/vyos-build/pull/579

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