E-LAN (EVPN Single-Homed)
Last updated
Last updated
In this article we will use EVPN to create an E-LAN service. EVPN will replace VPLS that we configured in the first E-LAN article.
PEs will continue to learn MAC addresses in the data plane on the access circuits (ACs) but they will now learn remote MACs in the control plane via EVPN. This will reduce flooding of unknown unicast addresses, and prevents the need for PEs to age-out MACs located on other remote PEs.
We will keep this simple and use single-homing, so the ESI will be all zeros for every interface. This will let us focus on how EVPN and VPLS differ.
With EVPN E-LAN, we will see the type 2 route type, which in my opinion is the defining route type for EVPN overall. This route type advertises a single MAC address and optionally the IP associated with that MAC. When a PE learns the MAC of a CE that is connected to it, a type 2 route is created.
Route type 3 is also used in order to transport BUM traffic. An ingress PE needs to know which PEs to send BUM traffic to. Each PE advertises the fact that it participates in the EVI by using the type 3 route. This is similar to the auto-discovery function of Kompella circuits that we configured in the VPLS with BGP auto-discovery article.
To summarize, while EVPN VPWS used type 1 and type 4 (when multi-homing), E-LAN uses type 2 and type 3. If you were to use multi-homing with EVPN E-LAN you would see four total route types.
We will re-use the existing lab from the VPLS-based E-LAN using Martini circuits.
Here are the startup configs if you are building the lab from scratch:
First we will add BGP with the l2vpn/evpn address-family on all core routers. This closely resembles the EVPN VPWS configuration we did earlier, just with different neighbor IP addresses.
Now we’ll remove the existing l2vpn vfi, that was left over from the Maritini circuit based VPLS configuration.
First let’s enable EVPN on only PE1, and then take a look at the routes it advertises.
Those simple 5 lines are all we need to do to enable EVPN E-LAN (with all defaults). In line 2 and 3, we define the replication-type for BUM traffic. (The only option is ingress replication). When this PE receives a BUM frame from a directly connected CE, it will replicate the frame and send it to all PEs participating in the EVI. The PE knows which PEs are participating via the type 3 routes each PE advertises. This is also referred to as HER (Head End Replication).
In line 5 we define the EVPN instance as instance 1, and then associate it with bridge-domain 1 in lines 7 and 8.
The EVPN instance is defined as vlan-based, which is the simpliest type. There are three options:
VLAN-based
One EFP (one VLAN) is asssociated to a BD, and that BD is associated to an EVI
VLAN-bundle
Multiple EFPs (multiple VLANs) shared a single BD, which is associated to an EVI
VLAN-aware
Each EFP (VLAN) is associated with a single BD, but there can be multiple BDs per EVI
If you haven’t already from the previous lab, associate Gi2 with the bridge-domain
We can now confirm the EVPN EVI is up:
This output shows us that the RD and RTs have been autogenerated for us. We can see that the replication type is ingress, which we globally set in our configuration for all EVPN EVIs (lines 1 and 2). Encapsulation is mpls by default, and you can see the labels reserved for this EVI, and the state of the EVI (Established). The bottom of the output shows that there is a single MAC route. This is the MAC address of CE1 connected on Gi2. PE1 has already learned the MAC of CE1 due to it multicasting OSPF Hellos.
We can see that a type 2 route for CE1’s MAC has been advertised, as well as a type 3 route that advertises that PE1 is participating in the EVI. The type 3 route is used by other PEs to populate the BUM flood list.
Let’s enable EVPN on PE2 and PE3 and see if OSPF adjacencies come up.
Now each PE has 4 routes received from the RR. This is because each PE is advertising a single type 2 route and a single type 3 route.
OSPF comes up on all CEs
Let’s examine in the CAM table of PE1
The remote CEs’ MACs are learned statically, not dymaically. The locally attached CE’s MAC is the only MAC being learned dynamically and therefore being aged out.
What happens when CE1 sends a BUM frame?
PE1 does ingress replication, as we configured before. So PE1 replicates the frame for as many PEs as are participating in the EVI, and then sends each PE a copy. PE1 learns which PEs are participating in the EVI via the type 3 EVPN routes.
Remember earlier in the detailed EVI output, how there were two labels? Each PE reserves a BUM label and a per-BD label for the EVI. PE1 uses the PE’s advertised BUM label to send BUM traffic to the PE. Each PE advertised this label in the type 3 route. Remember, the type 3 route is all about BUM traffic replication. Each PE signals that it participates in the EVI and wants to receive BUM traffic, as well as the BUM label it has reserved for this EVI.
Let’s figure out what label stack PE1 will push on BUM traffic that it replicates and sends it to PE2 and PE3.
In the output above, we can see that the outgoing transport label for PE3’s loopback is 18, and for PE2 is 17. From the type 3 EVPN route that each PE originated, we can see the BUM label. Each PE advertised a BUM label of 31 in their type 3 routes. This just happened to be the same.
Taking a pcap on Gi1, we can see the labels PE1 imposes on broadcast frames that are originated from CE1, and then replicated to PE2 and PE3. The frame towards PE3 has 18/31 and towards PE2 has 17/31
We can also see OSPF hellos from CE2 and CE3 being multicasted to PE1 with PE1’s BUM label, which is 22. We can see that value in multiple places - the EVPN EVI detailed output, the LFIB, and the BGP route that PE1 generated.
This capture was taken at Gi1 on PE1. P4 already preformed PHP, removing the transport label and leaving only the service label (22).
To explore further on your own, you could try shutting down the AC of one PE to see what happens when it withdraws the MAC. Do other PEs immediately remove the MAC from their bridge tables? What mechanism causes the PEs to remove the MAC?
The instance ID is not actually signaled in the BGP Update. We configured instance 1 on all PEs, but this is not signaled in the NLRI. The instance ID only needs to match between PEs because it is used in the auto-generated RT value. The RT is <ASN>:<instance number>. Therefore you are free to change the EVPN instance number on each PE, but you would need to manually specify the RT values so that they match between all PEs.
The ethernet tag ID is a separate field which is used to signal the VLAN. In this lab we used a VLAN-based EVPN instance, in which a single VLAN maps to a single BD which maps to a single EVI. So the ethernet tag ID field is essentially unused. You can see the ethernet tag ID set to zero in all updates.
Also in VLAN-bundle, the ethernet tag ID is not used. There is still a one-to-one mapping of BD to EVI, but multiple EFPs can participate in a single BD. The downside to VLAN-bundle is that a single MAC address can only be present on a per-BD basis. If an EFP with VLAN 10 and an EFP with VLAN 20 learn the same MAC address, communication will be broken, because there is no differentiation between these vlans due to the fact that they both share a single BD.
The ethernet tag ID is used in VLAN-aware. This is because multiple BDs map to a single EVI, so you need to differentiate between each BD. When you add the vlan-aware EVI to the BD, it forces you to choose an ethernet tag ID.
EVPN is an elegant solution to providing VPLS services without targeted LDP. EVPN E-LAN uses type 2 and type 3 routes to signal MAC addresses and create BUM replication lists.
The benefit of EVPN is that a single PE only learns MAC addresses locally. Remote MAC addresses are signaled via the control plane, they are not learned via the data plane. You saw that the remote MAC addresses are present in the BD table as a static entry, which is created due to received type 2 routes.
We also saw the difference between vlan-based, vlan-bundle, and vlan-aware EVPN instances.
VLAN-based = one EFP → one BD → one EVI
VLAN-bundle = multiple EFPs → one BD → one EVI
VLAN-aware = multiple EFPs → multiple BDs (one to one basis of VLAN to BD) → one EVI
Requires an ethernet tag ID
This concludes the series on EVPN. I hope that this has been useful!
