@Viacheslav Yes, I will test it once it is included in the next rolling release.

Both kernel and user-space support are needed. On the kernel side, you must enable vDPA-related options (e.g., CONFIG_VDPA and/or CONFIG_VHOST_VDPA) to provide the necessary infrastructure. On the user-space side, binaries that interact with VirtIO devices must be updated to take advantage of this support. For example, QEMU needs to be built with vDPA support so that virtual machines can offload packet processing to the hardware accelerator. Additionally, tools like libvirt or other management utilities might require adjustments to properly configure and utilize vDPA-enabled devices.

@n.fort I have upgraded following the path 1.2.6-S1 --> 1.3-S1 --> 1.4 Following the tips of not using port names for bootps and ssmtp and not using "set system ipv6 disable" and everything went fine.

@n.fort the config i would like to upload to this ticket has 43727 lines.. Its a text file of 1.3 Mbps. Its it possible to attach the file instead of paste it on the comments?

Hi, I'm sorry for the confusion but the configuration I uploaded is not from a production machine. It's just an example of a small configuration of a pre-production vyos that I was having trouble upgrading.
Tomorrow if I will upload one of the ones that take 25-30 minutes to boot on modern CPUs (xeon gold).

@n.fort Sorry yes this AC-1 vyos was on 1.2.1 I will a test tomorrow with a version 1.2.6-S1 to have the path i was mention..

@n.fort yes . This is an example os our AC-1 enviroment (the one i have used for the first test)

tried also with vyos-1.4-rolling-202203070319-amd64.iso and same issue with the migration

Hi @Viacheslav I have tried this morning upgrading from vyos 1.2.6-S1 to vyos-1.4-rolling-202204060217-amd64.iso but something went wrong with the firewall config load and all the firewall rules and objets were removed from config so impossible to test.. :(

Do we have any news when this feature (-n option) will be included? We have lot of vyos on 1.2.X with booting times between 20 and 40 minutes and commits about 3-5 minutes.

I think all Chaos stater after this message:

More detail :

I happened today in 17 vyos clusters after a switch failure. Same logs and no bgp process running:

In T1019#26665, @runar wrote:

Hmm, please enligthen me. Google BBR is a new way to handle congesition instead of the traditional way tcp deals with it. This functionallity needs to be enabled in the end host systems starting the tcp session to have any impact on troughput and congestion control.. as vyos is a router and are not responsible to start tcp sessions on behalf of any end system, what is the benefit of adding this functionallity?

@syncer Already tested with latest version.

Ok @syncer We are going to update and we will let you know.