Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks
Extracted elements (30)
EVPN routes on GWs are never reflected between DC and WAN but are consumed and re-advertised with the GW's own RD, the I-ESI in the ESI field, and appropriate encapsulation extended communities. This decouples encapsulation types, route targets, and label spaces between domains.
The decoupled interconnect solution targets deployments where EVPN-Overlay and WAN are operated by different entities, providing a clean demarcation for QoS/security enforcement. The integrated solution is used when both are under the same administrative entity, combining GW and WAN PE in the same router to save CAPEX/OPEX.
The EVPN-MPLS GW interconnect offers key advantages over 'DCI using ASBRs': it supports local ACs on GWs, allows different encapsulations in DC and WAN, provides independent multicast trees, enables MPLS label aggregation (one label per GW MAC-VRF instead of per NVE), and localizes intra-DC MAC mobility handling.
The UMR solves transient packet duplication in all-active multihoming: without UMR, an NVE flooding an unknown unicast sends it to both GWs, which both forward it since VXLAN carries no BUM indicator. With UMR, the NVE unicasts to one GW, eliminating the duplication.
The UMR usage in this document differs from RFC 7543: RFC 7543 uses UMR to route V-spoke-to-V-spoke traffic through a Default MAC Gateway until direct MAC addresses are learned. Here, leaf-to-leaf communication within the same DC is always direct; the UMR only directs unknown unicast destined for remote DCs toward the GW.
EVPN routes sent to the WAN SHOULD carry a different RD than those sent to the DC, and separate route targets are expected for the same EVI in WAN versus DC, to facilitate independent BGP processes and distinct RFC 9012 BGP encapsulation extended community values.
In PBB-VPLS interconnect, if both a B-component PW and an I-component EVPN-Overlay binding exist to the same far-end, the EVPN binding is kept down operationally while the B-component PW is active. The EVPN binding is only activated when no corresponding B-component PW exists to that far end.
If BGP Auto-discovery and FEC129-based PWs are used between the GW MAC-VRF and WAN Edge VSI, provisioning of the VPLS-ID MUST be supported on the MAC-VRF and MUST match the VPLS-ID used in the WAN Edge VSI.
If different EVPN-Overlay networks are connected to the same group of GWs in an EVPN-MPLS interconnect scenario, each EVPN-Overlay network MUST be assigned a different I-ESI.
In all-active multihoming, the DF GW MUST add the I-ESI label when forwarding BUM traffic received on EVPN-Overlay bindings associated to an I-ES to the peer GW over EVPN-MPLS, for split-horizon purposes.
In EVPN-MPLS interconnect, GWs MUST establish separate BGP sessions for EVPN routes to/from the DC and to/from the WAN, typically one session per RR (or two if redundant).
In EVPN-VXLAN interconnect with downstream-assigned VNIs, GWs and PEs MUST use proper RTs to import/export EVPN routes. GWs SHOULD support multiple VNI spaces per EVI, one per interconnect network to which they are connected.
In EVPN-VXLAN interconnect with globally unique VNIs, GWs MUST be configured to map the local DC VNI to the agreed-upon interconnect VNI in BGP EVPN updates and in the data plane in both directions.
In PBB-VPLS interconnect, the non-DF GW MUST NOT advertise EVPN MAC/IP routes to DC peers for MACs learned from the WAN.
In single-active multihoming, the non-DF GW MUST block ingress and egress forwarding on all EVPN-Overlay bindings associated to the I-ES; the EVPN-MPLS bindings to remote PEs and GWs remain active.
In single-active multihoming, the non-DF MUST NOT reoriginate MAC/IP routes received from the WAN to the DC, nor from the DC to the WAN. This lets remote PE/NVEs identify the primary GW via MAC/IP route origin.
In single-active multihoming, when the DF GW receives BUM traffic on EVPN-Overlay bindings associated to an I-ES, it SHOULD add the I-ESI label when forwarding to the peer GW over EVPN-MPLS for split-horizon filtering.
In the PW-based handoff, the GW MUST support an interworking function in each MAC-VRF requiring WAN extension. If a FEC128-based PW is used, the VCID MUST be provisioned on the MAC-VRF and MUST match the VCID used at the peer WAN Edge VSI.
The DF GW MUST NOT forward BUM or unicast traffic received from a given split-horizon group to a member of its own split-horizon group; forwarding to other split-horizon groups and local ACs is allowed.
The GW solution MUST follow the single-active multihoming procedures described in RFC 8365 for the provisioned I-ESI, advertising Ethernet A-D routes per ES and per EVI to DC NVEs and ES routes for DF election.
The sticky-bit indication in the MAC Mobility extended community MUST be propagated between EVPN domains whenever a MAC moves across DC or WAN boundaries.
The use of ESI Type 0 for the I-ESI is RECOMMENDED. The administratively configured I-ESI uniquely identifies the Interconnect Ethernet Segment associated with the set of virtual tunnels (PWs or overlays) to WAN Edge routers.
Within the same MAC-VRF, a GW is not allowed to simultaneously have both an EVPN binding and a PW to the same far-end PE. If both can be established, the EVPN binding prevails and the PW MUST be brought down operationally.
In EVPN-MPLS interconnect, each GW MAC-VRF maintains two independent flooding lists: an EVPN-Overlay flooding list (bindings to remote NVEs or multicast tunnels) and an EVPN-MPLS flooding list (MP2P or LSM tunnels to remote PEs). Each constitutes a separate split-horizon group (DC or WAN).
In the VPLS Interconnect model, each GW MAC-VRF uses two split-horizon groups: a WAN split-horizon group (VPLS PWs) and a DC split-horizon group (EVPN-Overlay bindings). Traffic received from a binding in one group is never forwarded to any member of the same group, preventing loops.
The Interconnect Ethernet Segment (I-ES) and its identifier (I-ESI) are defined on GWs for multihoming to/from the WAN. Unlike a standard ES per RFC 7432 (associated with physical Ethernet links), the I-ES is associated with a set of virtual tunnels such as PWs, referred to as a vES.
GWs provide superior per-tenant security compared to ASBRs: GWs perform MAC lookups on frames received from the WAN and apply filtering (undesired frames, source MAC matching protected DC MACs, MAC-duplication from RFC 7432). ASBRs forward based on a label or VNI swap with no visibility into encapsulated frames, which can carry malicious traffic.
The decoupled interconnect solution is inherently easier to protect since each GW has a single logical link to one WAN PE; in the integrated solution, the GW has logical links to all WAN PEs for the tenant. In either model, proper control and data plane policies must be applied on the GWs to protect the DC from potential WAN-originated attacks.
The MAC-address advertisement control and UMR (Section 3.5.1) protect DC NVEs from being overwhelmed with excessive MAC/IP routes learned on GWs from the WAN. The ARP/ND flooding control (Section 3.5.2) can reduce or suppress broadcast storms injected from the WAN into the DC.
The Unknown MAC Route (UMR) is encoded as a regular EVPN MAC/IP Advertisement route with MAC Address Length set to 48, MAC address set to all zeros, and the ESI field set to the DC GW's I-ESI. It is defined in RFC 7543.