Overview

Ethernet Virtual Private Network (EVPN) is a technology that allows Layer 2 traffic to be bridged across an IP network. EVPN instances configured on Provider Edge (PE) routers function as virtual bridges, transporting traffic between Customer Edge (CE) devices at separate locations.

At a basic level, the PE routers exchange information about reachability, encapsulate Layer 2 traffic from CE devices, and forward it across the Layer 3 network. EVPN is the de-facto standard technology in multi-tenant Data Centers (DCs).

VXLAN is a means for segmenting a LAN at a scale required by service providers. With the prevalent use of VXLAN in multi-tenant DCs, the EVPN control plane was adapted for VXLAN tunnels in RFC 8365.

The SR Linux EVPN-VXLAN solution supports using Layer 2 Broadcast Domains (BDs) in multi-tenant data centers using EVPN for the control plane and VXLAN as the data plane.

Layer 2 services refers to the infrastructure implemented on SR Linux to support tunneling of Layer 2 traffic across an IP network, overlaying the Layer 2 network on top of the IP network.

To do this, SR Linux uses a network-instance of type mac-vrf. The mac-vrf network-instance is associated with a network-instance of type default or ip-vrf via an Integrated Routing and Bridging (IRB) interface.

MAC-VRF, IRB interface, and IP-VRF shows the relationship between an IRB interface and mac-vrf, and ip-vrf network-instance types.

See Layer 2 services infrastructure for information about Layer 2 services on SR Linux, including configuring mac-vrfs, ip-vrfs, and IRB interfaces.

The primary usage for EVPN for VXLAN tunnels (Layer 2) is the extension of a BD in overlay multi-tenant DCs. This kind of topology is illustrated in BD extension in overlay DCs.

SR Linux features that support this topology fall into the following categories:

1. Bridged subinterface extensions, including:

   • Default subinterface, which captures untagged and non-explicitly configured VLAN-tagged frames on tagged subinterfaces.

   • Transparency of inner qtags not being used for service classification.

2. EVPN-VXLAN control and data plane extensions as described in RFC 8365:

   • EVPN routes type MAC/IP and IMET

   • VXLANv4 model for MAC-VRFs

3. Distributed security and protection, including:

   • An extension to the MAC duplication mechanism that can be applied to MACs received from EVPN

   • Protection of static MACs and learned-static MACs

4. EVPN L2 multi-homing, including:

   • The ES model definition for all-active and single-active multi-homing

   • Interface-level reload-delay timers to avoid service impact when links recover

   • Load-balancing and redundancy using aliasing

EVPN for VXLAN tunnels (Layer 2) describes the components of EVPN-VXLAN Layer 2 on SR Linux.

The primary usage for EVPN for VXLAN tunnels (Layer 3) is inter-subnet-forwarding for unicast traffic within the same tenant infrastructure. This kind of topology is illustrated in Inter-subnet forwarding with EVPN-VXLAN L3.

SR Linux features that support this topology fall into the following categories:

1. EVPN-VXLAN L3 control plane (RT5) and data plane as described in draft-ietf-bess-evpn-prefix-advertisement.

2. EVPN L3 multi-homing on MAC-VRFs with IRB interfaces that use anycast gateway IP and MAC addresses in all leafs attached to the same BD.

3. Host route mobility procedures to allow fast mobility of hosts between leaf nodes attached to the same BD.

Other supported features include:

• Interface-less (IFL) model interoperability with unnumbered interface-ful (IFF) model

• ECMP over EVPN

• Support for interface-level OAM (ping) in anycast deployments

EVPN for VXLAN tunnels (Layer 3) describes the components of EVPN-VXLAN Layer 3 on SR Linux.