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

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?

Personally I thing there should be a difference between setting PKI manually like set pki certificate and set pki ca vs whatever the command is to utilize letsencrypt or acme or whatever they might be called automatically through VyOS (lets say set pki letsencrypt and set pki acme etc).

documentation : https://github.com/vyos/vyos-documentation/pull/1479

Documenting what I've found regarding Bug #2:

confirmed working

I would have put it on my list. @Fabse if you get stuck or need some support just slack me.

Sure @Viacheslav! I'll try to add the PR. Also thanks for the documentation @nvollmar :)

@nvollmar Do you want to claim the task?

Relevant telegraf documentation: https://github.com/influxdata/telegraf/blob/release-1.31/plugins/outputs/loki/README.md

PR for 1.5: https://github.com/vyos/vyos-build/pull/654

It will be easy to add; you need to generate a new CLI like with "prometheus-client" for example https://github.com/vyos/vyos-1x/blob/03d8c16a12d182a2fb2ab9f7acec5d8cb83937ba/interface-definitions/service_monitoring_telegraf.xml.in#L188-L250
And add template changes https://github.com/vyos/vyos-1x/blob/03d8c16a12d182a2fb2ab9f7acec5d8cb83937ba/data/templates/telegraf/telegraf.j2#L45-L58

@a.apostoliuk

For 1.5-rolling-202406120020 it doesnt work even without having a vrf:

vyos@vyos-a# run update geoip 
Downloaded GeoIP database
Error: GeoIP failed to update firewall
[edit]
vyos@vyos-a#

Unfortunately there is no explaining logging (at least I didn't found any).

Looking into this a bit more. This request is to enable VyOS as a LAC - l2tp v2 client support against an LNS server, for which VyOS already has support. Most LAC's are presented to LNSs as PPPoE connections they are authenticated as LAC clients to an LNS. But there are cases such Andrews & Arnold who allow the l2tp tunnel to come from anywhere.

Upstream bug https://github.com/FRRouting/frr/issues/16013 fixed in https://github.com/FRRouting/frr/pull/16023

There are 2 usecases of option82 when it comes to DHCP:

@aidan-gibson You can build current with the microcode packages included by passing the following to the build script:

In upgrade process

Happened across this one while trying to find support for defining client classes in Kea in order to pass different PXE boot files depending on client architecture. The following has an example of how this is achieved in kea.

Can you please retest with the latest ISO as additional fixes got added to the code.

Just to notice: This task focuses on container part of multi arch support. I can take a look at multiarch pieces outside docker support, but it will demand a deeper knowledge of vyos build system and the vyos goal on multiarch (Or for now, arm) support.

Hey, is this feature currently being worked on? If not then I wouldn't mind working on support for it (I've also created a basic wpa2-enterprise option for client mode)

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

@a.apostoliuk this one should be resolved in the current rolling release, if you're able to check it out?

I have https://github.com/vyos/vyos-1x/pull/3616 and https://github.com/vyos/vyos-1x/pull/3637 as works in progress.

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

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