Introduction to EVPN

EVPN (Ethernet VPN) is a layer 2 VPN technology, used to extend Ethernet circuits over a routed underlay.

EVPN is commonly used today in Service Provider environments to offer E-Line and E-LAN services, and it is perhaps even more commonly used in data center environments to stretch a layer 2 domain between multiple data centers, without needing to run spanning-tree, etc. at the data center interconnect.

EVPN is a control plane protocol. It relys on a data plane in order to actually transport the layer 2 frames across a routed layer 3 network. The most popular data plane protocols you will see are MPLS and VXLAN.

So in other words, EVPN is how devices learn where hosts in the layer 2 domain are. Once a device learns that a host is in a part of the network that is separated by layer 3 boundaries, it needs to tranport the layer 2 frame across the layer 3 network. MPLS is used by putting labels on the frame, or VXLAN is used by encapsulating the frame in a UDP header and sending it to the PE on the other end.

Why do we need EVPN? What problems does it solve?

Multihoming

Let’s say you have a customer that wants redudant circuits to their CE that is participating in a VPLS service. The customer wants this CE to run a LAG with two different PEs which use two diverse-path fibers.

Currently, achieveing this with VPLS is not really possible if you want both links to be active. But EVPN was built with this setup in mind. It creates a method to support these type of multihoming situations with ease.

BUM traffic

VPLS requires data plane “flood and learn,” just like a “traditional” switch. If a PE receives a frame with a DST MAC that is not in the CAM table, it has to flood it to all other PEs and local ACs. Only once it sees a return frame with that MAC in the SRC MAC field, can the PE then add the MAC to its CAM table. It now has to start a timer to age out that MAC. This entire process is done in the data plane, and is called “flood and learn.”

EVPN optimizes this by having the ingress PE advertise the MAC address of the CE to all other PEs. Now when that same PE receives the unknown unicast frame, it does not need to flood it. It has already learned where the MAC is located through the control plane. It did not have to rely on data plane learning.

In addition to the optimization at a micro-level, the VPLS flood and learn method is problematic at scale as well. If you have thousands of MACs in a VPLS domain, you have to have an aging timer for every single one. BGP was built to handle very large numbers of routes, and also fail them over between PEs very quickly. (Think of BGP PIC).

Configuration Complexity

In the E-LAN (VPLS) series, we configured every remote PE pariticipating in the VPLS manually. This was obviously not scalable, so we used Kompella circuits in the “VPLS with BGP Autodiscovery” section.

However, if you look back to that section, there was still some limitations to that configuration. We had to specify a range of VEs, up to a max of 100, and the way that labels were chosen was a bit complex.

EVPN aims to also simply the configuration process for E-LAN services.

E-Tree

E-Tree configuration is a major problem in VPLS. As you saw in the “E-Tree” series, our basic configuration left us in a position where we could not have multiple CEs connected to the same PE. EVPN has built-in support for E-Tree servies.

BGP and route types

EVPN uses a new address family in BGP, called l2vpn/evpn.

The problem that EVPN ran into, is that unlike other services such as VPNv4 and l2vpn/vpls, there are multiple types of information EVPN needs to share via BGP. This leads to route types. Because you can’t create a “subsequent subsequent” address family (i.e. l2vpn/evpn/mac), EVPN uses route types to distinguish different types of information.

Route Type	Name	Use
Type 1	Ethernet Auto-Discovery (A-D) route	Allows a PE to advertise an Ethernet Segment ID or Tag ID along with an MPLS label. Used in E-Line (VPWS) to advertise the AC ID, and used in VPWS/E-LAN when a CE is dual connected to two PEs
Type 2	MAC/IP advertisement route	Allows a PE to advertise a MAC address and/or IP address with an MPLS label. Used in E-LAN.
Type 3	Inclusive Multicast route	Advertises that a PE participates in an EVI, so that an ingress PE knows where to deliver BUM traffic.
Type 4	Ethernet Segment route	Advertises a Segment ID along with the originating router’s IP. This is used when a CE is dual-homed to two PEs, and elects one of the peers as the designated forwarder for BUM traffic.
Type 5	IP Prefix route	Allows EVPN to advertise IP prefixes that are not /32. You can replace L3VPN with EVPN by using this. This is used in symmetric IRB which is frequently seen in the data center but not in the service provider MPLS core.

This table contains terms you might not have seen yet, so don’t worry if you don’t quite understand it. This table is here for you to reference back to whenever you need it.

Futher Reading

RFC 7209 https://datatracker.ietf.org/doc/html/rfc7209

RFC 7432 https://www.rfc-editor.org/rfc/rfc7432.html

https://resource.nvidia.com/en-us-evpn-datacenter/evpn-datacenter