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.

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

I can now reproduce the issue. The reason I was unable to reproduce this was I missed out that you use an ACME certificate

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

There is another incompatibility:

The first step in support this is to build the kernel modules thunderbolt and thunderbolt-net.

While I think the mismatch between PBR-addressable RTs and VRF RTs is a bit odd, the PR's been rejected and could be addressed differently in any case. In the meantime, VRFs with RTs 100-200 are targetable by PBR.

here we can add some prevention to raise error, to avoid that someone uses in EBGP a profile to IBGP, because, the problem is under FRR which syntax brakes the frr-cli.

You are correct, it was a misconfiguration, but there is no way to remove the error.
You need to remove the whole BGP in order to correct the mistake.
How did you manage to revert the error?

This is not the latest image. Please use 1.5-rolling-202406130020

There is no need for set pki letsencrypt or set pki acme as a PEM wil always be provided and we have a common PEM framework.

I've tested it, the problem here is because you change a wrong local role , in your configuration is a rs-client ( IBGP relationship) but when you move to rs-server ( only works with EBGP , this attribute reflect EBGP routes to bgp router clients ) , so, that it's reason why you are not allowed to change :
VyOS :

vyos@vyos# run show configuration commands | match bgp
set protocols bgp neighbor 10.88.88.255 address-family ipv4-unicast
set protocols bgp neighbor 10.88.88.255 peer-group 'FAST'
set protocols bgp peer-group FAST capability dynamic
set protocols bgp peer-group FAST graceful-restart 'enable'
set protocols bgp peer-group FAST local-role rs-client
set protocols bgp peer-group FAST password 'F@st123!'
set protocols bgp peer-group FAST remote-as '211186'
set protocols bgp peer-group FAST update-source '10.88.88.2'
set protocols bgp system-as '211186'
[edit]
vyos@vyos# delete protocols bgp peer-group FAST local-role rs-client
[edit]
vyos@vyos# commit
[edit]

Have to pospone it untill upgrade FRRouting to version 10.1

The only reason I see why this can happen is that the config.boot format can be unexpected. But this should not happen anymore, because now Cloud-init always runs migrations before doing any work, which should always add required metadata if the original file is a valid VyOS config.

I tend to say that this is not necessary and very dangerous. These modules can easily destroy the VyOS filesystem when used improperly.

I think this one would be fixed by my PR for https://vyos.dev/T6045

@bernhardschmidt Are you able to share the relevant pieces of your VXLAN and VRF config as well?