@higebu that box works well!

@ssasso You can test the fixed box with https://app.vagrantup.com/vyos/boxes/current/versions/20221227.20.48

@ssasso Thank you for creating the PR. I confirmed the issue with the latest box. I will check your PR today.

it looks good, maybe @zsdc could you help us ?

Any update on this PR merge? :(

Any update on the PR merge? thanks

I reproduced this configuration. Version VyOS 1.4-rolling-202212270317 - BFD works fine.

For 1.4 resolved in the https://github.com/vyos/vyos-cloud-init/commit/d385e3655e9eed77397136f5e27325a93719332d
Waiting several days for tests before doing a backport.

It copies the images between updates, but it can't properly clean up the old data/garbage, even when the old VyOS images were deleted.

PR for VyOS 1.3 (equuleus) https://github.com/vyos/vyos-build/pull/290

1.4 shipps

@m1nus FRR used in VyOS gets updated frequently. Can you please try a more recent rolling release?

This manual step just got removed by f3956a5358a71 which simply exports active images as oci-image and re-imports the image after the filesystem got migrated. No manual interaction by the user required.

In T4891#139596, @Viacheslav wrote:

Which version?

Which version?

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

@rob Thanks

Hello everyone,

The "incompatibility" can be resolved by running the following script prior to upgrading to a new image:

I don't think the commit comment adequately justifies why we can't pull the image from the internet when starting the container if it does not exist within the on-disk store shared between VyOS images.

the change worked for my example.

I did some extra test , I've missed a command , this solution works as expected . FRR backport 8.4.1

At first look, at least it works, but it requires more tests and improvements

set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 check target '192.168.122.1'
set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 check timeout '5'
set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 check type 'icmp'
set protocols failover route 203.0.113.1/32 next-hop 192.168.122.1 interface 'eth0'

Fix pushed for schema generation.

using 8.5-dev ....it doesn't work ...even is worgs than the initial case, it's not able to show any local prefix on l3vpn bgp :

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

Backport for this PR. I am not running 1.3 so YMMV.

Had a quick look at the 1.3 implementation and it seems the bug isn't present there. So no back-porting needed @c-po

After screwin up the previous PR:
https://github.com/vyos/vyos-1x/pull/1712

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

FRR fixed it , it seems the issues were associate with next-hop tracking protocol when a prefix is imported using network command (if we used redistributed connected next-hop tracking will not be done):

yes, it's already configured , share here my full configuration on FRR :

Certbot (specifically certbot/dns-cloudflare container) is another situation where a command & argument is required. Currently, I get around it by running a task-schedule to run the podman command directly (its a task because the container runs to completion). But having a way to do this via VyOS CLI would be extra helpful.