Page MenuHomeVyOS Platform

Move EVPN VRF up in FRR config
On hold, NormalPublicBUG

Description

Hey there,

It seems there is currently a bug in FRR that causes issues when trying to enable BGP EVPN in a different VRF than the default one.

There is however a workaround for this, if you first add the router bgp 1 vrf stuff statement to the config and then router bgp 1 it should actually work, the FRR bug has to do with the order in which they get configured.

If you first define router bgp 1 and then router bgp 1 vrf stuff (which is what VyOS does) then you get a Please unconfigure EVPN in VRF (null) error.

The FRR developers are working on a solution (there is no issue on GitHub yet as far as I know) however this might take a while to get released.

Update: I opened https://github.com/FRRouting/frr/issues/9405 for the FRR issue.

Details

Difficulty level
Unknown (require assessment)
Version
1.4
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Related Objects

Event Timeline

c-po changed the task status from Open to Confirmed.Aug 12 2021, 8:01 AM
c-po claimed this task.
c-po triaged this task as Normal priority.

Very cool this has apparently been fixed already, I was reading through the vyos-1x commints and didn't see anything that looked related. What was the implemented change for this?

Nvm I just noticed that the task number was mentioned in a commit, I have a feeling this won't solve the issue as this is related to the router bgp 123 vrf something rather than vrf something statements.

They are all intermixed ;) - maybe I also missinterpreted the issue. Maybe you can retest the latest rolling which will be available by tomorrow? Image is currently build: https://ci.vyos.net/job/vyos-build/job/current/2195

If it does not work, please throw me some VyOS CLI commands so I can reproduce the issue.

Well test it tomorrow once it becomes available :)

Just checked, the behaviour for this bug is still the same.

I think you can replicate it by doing something like:

set protocols bgp local-as 12345
set vrf name underlay table 100
set vrf name underlay protocols bgp local-as 64535
set vrf name underlay protocols bgp address-family l2vpn-evpn advertise-all-vni

Thank's for opening an upstream bug

Might be good to have a workaround in VyOS in the mean time

c-po set Issue type to Unspecified (please specify).