all work!
Thank you

@pavel-altair can you please re-test with VyOS 1.5-rolling-202406170021

@zsdc if that completed, please close this task

@c-po, can you see if it's still actual, and if not, close it
Thanks!

@dmbaturin can you take a look and close if it's obsolete?

Forum thread with a nice workaround by giuppo77: https://forum.vyos.io/t/wan-failover-with-dhcp/
Not a generic solution but maybe an inspiration for implementation.

Forum thread with a nice workaround by giuppo77: https://forum.vyos.io/t/wan-failover-with-dhcp/
Not a generic solution but maybe an inspiration for implementation.

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

Closing this. Further shrinking is not priority now
we can comeback to this later if there will be proper business case

I've created a PR for this: https://github.com/vyos/vyos-1x/pull/3655

I've created a PR with a very simple fix: https://github.com/vyos/vyos-1x/pull/3654

In T915#73587, @Cheeze_It wrote:

One thing I did notice that did not work (and I think this would more or less be due to other options that can be enabled that FRR currently doesn't have yet) was that LSP pings from the Junipers directly connected to the Vyos VM failed but that's due to a specific corner case. FRR currently doesn't support explicit null in LDP, and Vyos doesn't have it implemented. However that shouldn't cause a problem in the current role that Vyos has. As an MPLS P Vyos works absolutely how it needs to. This seems to have a fix in FRR 7.4 as well per note "Ingress packets coming through broken LSP are no longer dropped." 

I would say that for what it's worth....I think we're good here. I think that the new additions are working as expected. So I am unsure if the ordered label allocation will be added later when things are moved to FRR 7.4, or if you'll put in that now @Viacheslav. But for what it is, MPLS support with LDP is verifiably working as it should be per the implementation in FRR 7.3.1. Thank you sir :)

I sure hope this custom waagent build will be removed once the upstream (debian packages) have been updated with this fix.

You are right @blueish, better to spend time on something more meaningful

@syncer I could try. I'm just not sure what the motivation/use-case would be? I can think only of very specific cases where someone would want to do mirror thus I'm not sure if it justifies the existence in the docs. Someone may want to have local mirror if they do a lot of reruns of the image build process but that's seems like very much edge-case.