T5493 is merged

https://github.com/vyos/vyos-vpp/pull/24

Yes - this has been included in the nightly builds for a few weeks now.

Is this resolved on the latest nightly, now that T7177 has been resolved?

Decided to not replace the functionality for all methods, only where I found a problem. This means the information in this issue isn't relevant. I'll make a new issue to fix the test case above.

The version of lego in the Debian repositories is very old, and this will likely mean it is broken for various DNS providers since things change rapidly out there on the Internet. As an example, Porkbun DNS provider has recently changed the URL for their DNS API, which has been updated in the newest LEGO, but the old version in the debian repos no longer works for Porkbun. I believe updating LEGO in the debian repos is hard due to needing to bring each go dependency into the repos also - which means the LEGO version is even old in the debian unstable repos.

A key decision in implementing this dns-01 acme authentication feature is whether or not to change the upstream tool used to obtain let's encrypt certificates (currently certbot).

Will this be backported to 1.4 ahead of the 1.4.2 release?

I am tired of Network Management complacation, I am tired to change different management cli command if switch diffrent brand router, I need automation, so I switch to netconf to config, I ask chatgpt, what router support, It said VyOS, But VyOS not support NetConf infact, I hope someday it could.

Related PR from GitHub: PR #4414

Thanks for reporting this! At least we know people actually use the signatures. ;)

*-update flavors are no longer used in LTS releases — there is no need to, and it's much simpler for users when they can just use openstack or whatever ISO flavor for upgrade.

If I use 1M in the command, everything works well for 3 hours

I reproduced this issue in my lab.
Network MAP
HOST1(debian)---VyOS1----(GREoverIPSEC)-----VyOS-2-- HOST2(debian)

Another possible solution https://github.com/vyos/vyos-build/pull/935

Fixed in https://github.com/vyos/vyos-vpp-patches/pull/4

Im also getting a 404 for the commit link posted at 2025-03-23 11:50.

Thanks @Viacheslav, but no need to patch anything in FRR. The commit has made it into the FRR 10.3 release, it will be better to just wait until you guys bump to the latest FRR release. I can rebase and submit a PR at that point fairly quickly.

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

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

In T7239#219113, @evgbondarenko wrote:

https://github.com/VyOS-Networks/vyos-nightly-build/commit/7e4efc05a48dc10324464889afb45dff3a0bd581

https://github.com/VyOS-Networks/vyos-nightly-build/commit/7e4efc05a48dc10324464889afb45dff3a0bd581

We can add patches for FRR build https://github.com/vyos/vyos-build/tree/current/scripts/package-build/frr/patches/frr

You do not need task on phorge for docs

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

I built a lab and generated traffic as the customer did. However, I could not reproduce this issue. Maybe it is a problem with the packets generated by the switch (192.168.10.10).
There are periodic messages in the log file

Dependent FRR commit has made it to the 10.3 release. Waiting for VyOS to update and then I will create a PR.

Both dependent FRR commits have made it to the 10.3 release. Waiting for VyOS to update and then I will create a PR.

Well, it could go something like this:

Which option do you propose for CLI to configure it?

At the moment, it's not configurable in the CLI or if it is, it's not documented or it's buried somewhere that my question marking through the whole thing hasn't revealed it.

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

@woodsb02 Would you like to create a PR fix?

How do you see it in the CLI?
In my opinion each option should be configurable from the proper CLI if such option does not exist, it should be added.