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

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

The documentation part should be covered now by https://github.com/vyos/vyos-documentation/pull/1680

It was also desided to add auto calculation for min buffers-per-numa parameter as default

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

While technically this is not a VPP config validation error, I think something needs improvement.

At least 2 CPUs should be for the system processes (Not VPP)
So the error looks handled correctly if you have 8 cores and are trying to use 7 cores.
So, max-number-cores - 2, you can use for VPP even if you isolate 7.

Needs the correction of the error message to be clearer.

@Viacheslav yes, you are rigth... it's a feature request.

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

Have just checked it with AWS 4 vCPU vm and the behavior is the same as with Azure

https://github.com/vyos/vyos-documentation/pull/1678

In T6563#234214, @marvin wrote:

Thanks @Viacheslav.

FWIW, it looks like Jool's official documentation site is now https://nicmx.github.io/Jool/en/index.html (not jool.mx anymore).

The last word is up to @zsdc

It's already disallowed. Vpp is not started with proper error message

Should we disallow starting VPP on such instances?

It's already disallowed. Vpp is not started with proper error message

Thread(s) per core:      2
Core(s) per socket:      2
Socket(s):               1

The calculation is okay for me: 1 socket, 2 cores. Threads or virtual cores will do more harm than good to performance. Should we disallow starting VPP on such instances?

I found a companion issue to this and created a task for it:
https://vyos.dev/T7781

@c-po

! In T7760#233813, @L0crian wrote:
Quick note on this. It'll maintain the existing AS-Path in the advertisements, but it COULD change the behavior of route rejection on received routes.

The temporary fix is to disable the pre-build tests until this issue is not fixed by vendor.

Changing the base template controlling dhcp6c config generation seems to do the trick.
Folowing basic pppoe example provided on Vyos main website :

// config
interfaces {
    ...
    pppoe pppoe0 {
        ...
        dhcpv6-options {
            pd 0 {
                interface eth0 {
                    address "1"
                    sla-id "0"
                }
                length "56"
            }
            rapid-commit
        }
        ipv6 {
            address {
                autoconf
            }
        }
    }
}

FWIW, it looks like Jool's official documentation site is now https://nicmx.github.io/Jool/en/index.html (not jool.mx anymore).

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

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

@guerralucasdaniel7 Could you please share the topology map with all interfaces and networks included?

In T7761#234119, @Fabse wrote:

aggregation — ipt-netflow allows rewriting IP prefixes and ports. Do we want that?

This feature is crucial for our use case. We are using a custom build for ipt_NETFLOW since 2024 in order to --enable-aggregation for being able to account all flows (sampling rate 1) while keeping flow cardinality manageable. --enable-direction would be great as well.

Looks like a feature

In T7769#234133, @Viacheslav wrote:

What about option priority?

set container name c1 priority 1
set container name c2 priority 2

Do you mean to manipulate the start order of the containers? If so, I don’t think it’d solve the issue. On a suitably fast system, all of the containers would start within a fraction of a second of each other. So it’d be a race condition that would almost always fail.

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

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

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