Fix(eos_designs): Remove EVPN related config if VRF 'default' is not EVPN enabled #2888
+260
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change Summary
Remove EVPN related config if VRF 'default' is not EVPN enabled
Related Issue(s)
For EVPN networks carrying VRF 'default' the best practice is to use the overlay (EVPN l3vni) for services, but keep loopbacks in the underlay. To avoid the services from being routed in the underlay, AVD implements route-maps and prefix-lists when VRF 'default' is defined on an EVPN VTEP.
It is possible to disable EVPN under the VRF configuration by setting
address_families:[]
in which case the VRF should not be added to EVPN configuration, and the route-maps and prefix-lists should not be created at all.Before this fix, the route-maps and prefix-lists were still configured even if the VRF was not configured for EVPN. The VRF was also configured with a VNI under the VXLAN interface.
Component(s) name
arista.avd.eos_designs
Proposed changes
evpn
address-family enabled (true by default)How to test
Added a molecule test case for this corner case.
No other changes to molecule outputs.
Checklist
User Checklist
Repository Checklist