The EVPN standard, in the context of an NVO environment, defines the functionality for delivering multi-tenant Layer 2/3 VPN services using either VXLAN, NVGRE, or MPLS over GRE encapsulation across a common physical IP infrastructure. The standard introduces new terminology specific to a NVO environment, which is summarized below in relation to VXLAN encapsulation.

The new EVPN Network Layer Reachability Information (NLRI) is carried in BGP using Multi-protocol BGP Extensions with a newly defined Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI).

To provide multi-tenancy, the standard uses the above traditional VPN methods to control the import and export of routes and provide support for overlapping IP address between tenants.

The format of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute, holding the new EVPN NLRI is illustrated below, where the next-hop address within the NLRI is the IP address of the VTEP advertising the EVPN route.

As illustrated, the original MPLS RFC (7348) and subsequent IP prefix draft (EVPN Terminology), introduce five unique EVPN route types.

Type-5 route: IP-prefix route advertisement

The type-5 route is used to advertise IP prefixes rather the MAC and IP hosts addresses of the type-2 route. This advertisement of prefixes into the EVPN domain provides the ability to build classic Layer 3 VPN topologies.

A detailed understanding of the function of each of these route types in the operation of EVPN to provide multi-tenant Layer 2 and 3 VPN services, is defined in section 4 of this document.

While this guide focuses on EVPN with VXLAN data-plane encapsulation, it’s important to note that, in addition to the new routes type, a BGP encapsulated extended community is included in all advertisements to determine the data-plane encapsulation.

The Encapsulation extended community is defined in RFC 5512. The different IANA registered tunnel types for an NVO environment are summarized in the table below.

An EVPN Instance (EVI), can contain, one or more Layer 2 broadcast domains (VLANs).

Three EVPN service models—VLAN-based, VLAN bundle, and VLAN aware bundle—define the association of VLAN IDs to a specific EVI instance and how a VLAN tag can be transported within the EVI if required.

When VXLAN Control Services (VCS) is enabled on a CloudVision eXchange (CVX) of a Data Center (DC), each VXLAN Tunnel End Point (VTEP) connects to the corresponding CVX to share the Layer 2 bridging information of its attached hosts. In turn, CVX advertises this information to all VTEPs within the DC.

The following graphic illustrates the federation of CVX across multiple DCs.

Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: Layer 2 VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to exchange overlay MAC and IP address reachability information between BGP peers using type-2 routes. Additionally, EVPN supports the exchange of layer 3 IP overlay routes through the extensions described in (type 5 EVPN routes).

An IP VRF is used on a PE router for each Layer 3 overlay. VRF IP routes are exported into the EVPN BGP table and advertised to remote VTEPs as type 5 routes. The exported EVPN routes carry the route-Target (RT) extended communities that are configured as export route-targets on the IP VRF from which they were exported.

The RTs carried by the EVPN type 5 routes received by a PE are matched against the VRF import route-target configuration. When a received route carries an RT that is configured as an import route-target on an IP VRF, the route is imported into the IP table for that VRF.

PE routers allocate per-VRF and address family Labels that are advertised as part of the Layer 3 (type 5) EVPN route NLRI. Forwarding of overlay packets between PEs across the underlay requires underlay MPLS connectivity provided by an IP backbone.

The type-5 routes allows you to decouple the advertisement of an IP prefix from any specific MAC address, support floating IP addresses, optimize the mechanism for advertising external IP prefixes, and reduce the churn when withdrawing IP prefixes.

The format of the new type-5 IP-prefix route is illustrated in the figure below. Unlike VXLAN, whichis used as a transport, BGP route update for MPLS does not specify the router-mac extended community and sets the tunnel encapsulation to MPLS. Unlike with VXLAN encapsulation, which uses the VNI as the overlay index, the MPLS Type-5 route uses the MPLS label.

The following example offers a more detailed view of the route as displayed on a PE router.

As shown in the example, the route contains the VPN route (prefix and RD), the next-hop for the route and the advertising router ID, along with the extended communities of tunnel type (MPLS), MPLS Label value and route-target.

Beginning with eos Release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPv6 host to another IPv6 host on a stretched VXLAN VLAN.

eos supports iBGP as the Provider Edge (PE) - Customer Edge (CE) as an extension to BGP EVPN Layer 3 (L3) VPNs. The feature provides a method to isolate your network BGP attributes from a Service Provider (SP) backbone attributes by saving the your network BGP attributes into a special attribute called ATTR_SET, code 128. This separation introduces a route server model that allows your BGP attributes to be stored in the SP backbone along with the VPN IPv4 and IPv6 paths.

The configuration requires the Autonomous Systems (AS) numbers of the PE Virtual router Forwarding (VRF) and the CE to match regardless of the VPN AS number on the default VPN. This causes the exported paths by the PE to carry your original attributes through the SP backbone in a new attribute, ATTR_SET, code 128. Any CE at a different site sees only your attributes except the next-hop. For better loop prevention and detection, eos requires any iBGP-configured CE to be configured as a route-reflector client of the PE.

eos does not restrict exporting and importing VRFs from different sites to sharing the same AS number. When configuring iBGP on the CE, this means that each CE has the same AS number as the VRF in the respective PE, and the AS numbers may be different. To address this issue, a peering relationship exists between exporting and importing VRFs in the SP network. The ATTR_SET, code 128 carries the AS number of the VRF that exported the paths and the relationship between the origin AS number and the AS number assigned to the VRF importing the paths controls the restoration of the original CE attributes. If the AS numbers do not match, eos removes the iBGP-specific attributes and prepends the AS-path with the origin AS number, just as eBGP peering does.