BGP in the EVPN model

When it comes to LAN emulation services, the Virtual Private LAN Service (VPLS) model has many defects that prevent its use in advanced scenarios of major interest, such as the interconnection of data centres (a service often called Data Centre Interconnection (DCI)). This is why a new model for LAN emulation services — known as Ethernet VPN (EVPN) has been developed, and its purpose is to make service implementation more suitable to meet the DCI’s needs.

The EVPN model was standardized by RFC 7432 ‘BGP MPLS-Based Ethernet’ VPN, February 2015. The title of the RFC already indicates the main idea — using BGP to advertise MAC addresses, with the same operating model as Layer 3 VPNs (L3VPNs). In other words, MAC learning does not occur only on the data plane, as in the VPLS model, but partially on the data plane (local MAC learning) and partially on the control plane, using BGP. Do not be misled by the fact that even the VPLS model can use BGP for its operation; the EVPN model uses BGP in a very different way (similar, for the auto-discovery portion, and completely different for the signalling one).

And this is not the only new aspect introduced by the EVPN model. The standard focuses particularly on the implementation of multihoming connections, load balancing, loop prevention and other aspects we will not cover here. All these aspects are not treated (or only marginally treated) in the VPLS model, while RFC 7432 introduced many clever solutions for them.

The importance of the EVPN model is due to two reasons. First, that it is a very well-designed standard, and second, thanks to the complete separation between the control plane and the data plane, it can be used as the control plane for several kinds of data plane. There are currently three standards with the EVPN control plane:

• RFC 7432 (mentioned above): MPLS data plane.
• RFC 7623: ‘Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)’, September 2015 — MAC-in-MAC data plane, also known as PBB (Provider Backbone Bridge), defined by IEEE standard 802.1ah.
• RFC 8365: ‘A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)’, March 2018 — general data plane used in the Overlay Virtual Networks in a data centre environment. In particular, the document deals with EVPN integration with the two most used standards — VXLAN and NVGRE (between the two, it is the first one that became a de facto standard in the latest-generation data centres).

The EVPN control plane is based on the BGP MAC routing concept. The idea is similar to the control plane in the L3VPN service, with the difference that, instead of the IP prefixes of VPN sites, the MAC addresses learned locally by provider edges (PEs) (and, optionally, also the IP addresses of the hosts with that MAC address) are the ones advertised via MP-iBGP. Since MAC addresses, different from IP addresses, cannot be aggregated, a BGP advertisement for each MAC address is required.

Another idea similar to L3VPNs is the auto-discovery mode, which occurs through the standard route target filtering mechanism, also used in the VPLS model, with auto-discovery via BGP.

What makes EVPN and VPLS models very different is the MAC learning mode. Just like in the VPLS model (and in L3VPN for IP prefixes), in EVPN, MAC learning is achieved in two steps — one local and one remote. The local phase is identical to VPLS. Through it, a PE learns about the existence of MAC addresses, and, optionally, with a few tricks (for example, GARP, Gratuitous ARP) and also about the corresponding IP addresses associated with them.

Then it creates, in its own MAC table, indicated in the EVPN model as MAC-VRF, a <MAC; local port> association. However, the remote learning phase is quite different. After learning a MAC address, it is communicated to all the other PEs within the same EVPN instance, via MP-iBGP advertisements. The process is summarized in Figure 1, where we assumed — as it almost always occurs in practical applications — to use route reflectors to minimize the number of MP-iBGP sessions.

NOTE: In the EVPN standard, the set of connections between customer edges (CEs) and PEs is called an Ethernet Segment (ES). In the case of a multi-homed connection of one CE to several PEs, it represents the set of connections. In the case of a single-homed connection to a single PE, it represents the only connection. Each ES is identified by an Ethernet Segment Identifier (ESI), which, in the case of multi-homed PE-CE connections, is a non-null identifier (10 bytes long) and in the case of single-homed PE-CE connections, ESI=0.

What happens when BGP is used in the control plane when a MAC address learned from a PE is removed from the MAC-VRF table because the MAC aging timer has expired (or the table has been cleared)? One of the advantages of using BGP is that, through a BGP UPDATE message, the advertisement previously sent is withdrawn. This causes the cancellation of the remote PEs of the entry related to the MAC address on the MAC-VRFs, thus allowing an automatic synchronization of the MAC-VRF tables on all the PEs. The advertisement and withdrawal of a MAC address are particularly important in the case of MAC mobility, that is, when a MAC address moves from one ES to another.

MP-iBGP advertisements are very peculiar, and, similarly to what occurred for other services, the new BGP EVPN address family has been defined, with new Network Layer Reachability Information (NLRI) within them. Then, new BGP Extended Community attributes, specific to the EVPN model, have also been defined. For the new BGP EVPN address family, IANA defined the AFI code equal to 25 (identical to the VPLS model) — and the SAFI code equal to 70.

The BGP EVPN address family is activated through the following configuration commands.

OS XE:

PE(config)# router bgp AS-number
PE(config-router)# address-family l2vpn evpn 
PE(config-router-af)# neighbor neighbor-IP-address activate

IOS XR:

RP/0/RP0/CPU0:PE(config)# router bgp AS-ISP
RP/0/RP0/CPU0:PE(config-bgp)# address-family l2vpn evpn
RP/0/RP0/CPU0:PE(config-bgp)# neighbor neighbor-IP-address
RP/0/RP0/CPU0:PE(config-bgp-nbr)# address-family l2vpn evpn

JUNOS:

[edit protocols bgp group group-name]
family evpn {
      signaling;
 }

The general NLRI format is the standard Type-Length-Value (TLV) type shown below, with the ‘Route Type’ field representing the type of coding in the ‘Route Type Specific’ field, the ‘Length’ field representing the length of the following field in byte, and the ‘Route Type Specific’ field the actual coding of the NLRI.

+-----------------------------------+
|       Route Type (1 octet)        |
+-----------------------------------+
|          Length (1 octet)         |
+-----------------------------------+
|   Route Type specific (variable)  |
+-----------------------------------+

RFC 7432 defined four different types of NLRIs (Types 1 – 4). Subsequently, Type 5 has also been defined (see: RFC 9136 ‘IP Prefix Advertisement in EVPN’). The following table shows the most important fields and their use. Moreover, in all NLRI types, there is a Route Distinguisher (RD) value, whose format and meaning are the same as those of the L3VPNs, that is, they are values used to distinguish any possible identical NLRIs, generated by different EVPN instances.

So, we can conclude that the use of the different NLRI types depends on the type of PE-CE connections. For instance, if all connections were single-homed, we would only need types 2 and 3. Types 1 and 4 are used (along with types 2 and 3) only in multi-homed connections, while type 5 is used both within an EVPN domain and in the interconnection with external IP/MPLS networks.