Feat(eos_designs): Support default vrf in Network Services

[tgodaA]

Change Summary

Support default vrf in Network services. This shouldn't generate default vrf in vlan-aware-bundles, router_bgp, vlan-interfaces.

Related Issue(s)

Fixes #1203

Component(s) name

arista.avd.eos_designs

Proposed changes

How to test

Checklist

User Checklist

• N/A

Repository Checklist

• My code has been rebased from devel before I start
• I have read the CONTRIBUTING document.
• My change requires a change to the documentation and documentation have been updated accordingly.
• I have updated molecule CI testing accordingly. (check the box if not applicable)

[tgodaA]

Let me know if this is the correct way.

[xaviramon]

My concern here is that this implementation is limiting the networks in default VRF to only SVI defined. There is no possibility to import/export other sources into the EVPN table. Is this sufficient for the issue opened?

[tgodaA]

Could be @xaviramon . I don't have the core knowledge of using default vrf(I just read the docs on how to use it). Please share the doc/resource if you have any. So I can implement them in this PR or may be in another one.

[ClausHolbechArista]

@xaviramon @tgodaA
I don't think this feature should change our existing policy of only redistributing the loopbacks into default table and advertise to neighbors. Of course we also need to add the SVIs defined, but it should be easy to just add the SVI prefix-list to the existing redistribution route-map, so we permit the current loopbacks + the SVIs.
Since the feature will require not to advertise the SVIs, we could add an outbound route-map to underlay_peers specifically denying these, but allowing everything else.

[xaviramon]

My 5 euro-cents. I tested it in EVE-NG and it works.

[ClausHolbechArista]

My 5 euro-cents. I tested it in EVE-NG and it works.

Great. I will go through it, but at first glance, I think we need to find some better RM names. IMO the RM should be about where it is applied, and the PL about what it matches. So IMO the RM for underlay should be RM-BGP-UNDERLAY-PEERS-OUT or similar.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[xaviramon]

While pushing with AVD to testing environment I discovered a duplicate in iBGP for default VRF that was causing duplicated IPs. Since we are in default VRF, we will use default L3 peering and there is no need to create a new one.
Names changed, I hope it makes more sense now.

[emilarista]

LGTM aside from some unneeded blank lines.

[ClausHolbechArista]

LGTM