proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-13 21:10:28 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: add docs for EVPN MAC-VRF Site-of-Origin

Browse Source 
Adds user documentation for the new EVPN MAC-VRF Site-of-Origin feature.

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
This commit is contained in:
Trey Aspelund 2023-05-08 17:22:04 +00:00
parent 3579225830
commit 9b55b559db
1 changed files with 71 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
doc/user/bgp.rst
View File

@ -3223,6 +3223,77 @@ Example configuration:
exit-address-family
!
.. _bgp-evpn-mac-vrf-site-of-origin:
EVPN MAC-VRF Site-of-Origin
^^^^^^^^^^^^^^^^^^^^^^^^^^^
In some EVPN deployments it is useful to associate a logical VTEP's Layer 2
domain (MAC-VRF) with a Site-of-Origin "site" identifier. This provides a
BGP topology-independent means of marking and import-filtering EVPN routes
originated from a particular L2 domain. One situation where this is valuable
is when deploying EVPN using anycast VTEPs, i.e. Active/Active MLAG, as it
can be used to avoid ownership conflicts between the two control planes
(EVPN vs MLAG).
Example Use Case (MLAG Anycast VTEPs):
During normal operation, an MLAG VTEP will advertise EVPN routes for attached
hosts using a shared anycast IP as the BGP next-hop. It is expected for its
MLAG peer to drop routes originated by the MLAG Peer since they have a Martian
(self) next-hop. However, prior to the anycast IP being assigned to the local
system, the anycast BGP next-hop will not be considered a Martian (self) IP.
This results in a timing window where hosts that are locally attached to the
MLAG pair's L2 domain can be learned both as "local" (via MLAG) or "remote"
(via an EVPN route with a non-local next-hop). This can trigger erroneous MAC
Mobility events, as the host "moves" between one MLAG Peer's Unique VTEP-IP
and the shared anycast VTEP-IP, which causes unnecessary control plane and
data plane events to propagate throughout the EVPN domain.
By associating the MAC-VRF of both MLAG VTEPs with the same site identifier,
EVPN routes originated by one MLAG VTEP will ignored by its MLAG peer, ensuring
that only the MLAG control plane attempts to take ownership of local hosts.
The EVPN MAC-VRF Site-of-Origin feature works by influencing two behaviors:
1. All EVPN routes originating from the local MAC-VRF will have a
Site-of-Origin extended community added to the route, matching the
configured value.
2. EVPN routes will be subjected to a "self SoO" check during MAC-VRF
or IP-VRF import processing. If the EVPN route is found to carry a
Site-of-Origin extended community whose value matches the locally
configured MAC-VRF Site-of-Origin, the route will be maintained in
the global EVPN RIB ("show bgp l2vpn evpn route") but will not be
imported into the corresponding MAC-VRF ("show bgp vni") or IP-VRF
("show bgp [vrf <vrfname>] [ipv4 | ipv6 [unicast]]").
The import filtering described in item (2) is constrained just to Type-2
(MAC-IP) and Type-3 (IMET) EVPN routes.
The EVPN MAC-VRF Site-of-Origin can be configured using a single CLI command
under ``address-family l2vpn evpn`` of the EVPN underlay BGP instance.
.. clicmd:: [no] mac-vrf soo <site-of-origin-string>
Example configuration:
.. code-block:: frr
router bgp 100
neighbor 192.168.0.1 remote-as 101
!
address-family ipv4 l2vpn evpn
neighbor 192.168.0.1 activate
advertise-all-vni
mac-vrf soo 100.64.0.0:777
exit-address-family
This configuration ensures:
1. EVPN routes originated from a local L2VNI will have a Site-of-Origin
extended community with the value ``100.64.0.0:777``
2. Received EVPN routes carrying a Site-of-Origin extended community with the
value ``100.64.0.0:777`` will not be imported into a local MAC-VRF (L2VNI)
or IP-VRF (L3VNI).
.. _bgp-evpn-mh:
EVPN Multihoming