EVPN E-LAN Ethernet Tag
Load evpn.eth.tag.init.cfg
Configure EVPN for CE1, CE3 and CE4. The CEs are already preconfigured with IP addresses and VLANs:
CE1 (untagged) = 192.168.10.1/24
CE3 (untagged) = 192.168.20.3/24
CE4 VLAN 10 = 192.168.10.4/24
CE4 VLAN 20 = 192.168.20.4/24
BGP is already preconfigured in the core.
Configure EVPN so that each VLAN has its own separate bridge-domain, but only one EVI is consumed. For example, only use EVI 100, but use bridge-domains 10 and 20. Traffic for VLAN 10 and VLAN 20 must be kept separate.
Answer
Explanation
EVPN allows for four different instance types:
vlan-based
This is typically the “default” type. We saw this in the previous single-homed lab.
Each VLAN (BD) has its own EVI. No ethernet tag is used.
vlan-aware
Each VLAN has its own BD, but multiple BDs can map to an EVI
This allows you to conserve EVI numbers. Each BD is kept separate using an ethernet tag. So each BD pretty much operates as if it had its own unique EVI. The ethernet tag is used for uniqueness instead of the EVI.
vlan-bundle
Multiple VLANs share a single BD, which is associated with an EVI.
You cannot manipulate the tags, because the tags are used to keep L2 domains separate within the single BD.
This is similar to how an 802.1q trunk operates on a switch. The tag must be preserved end-to-end, because that identifies the bridge-domain/l2 domain.
I don’t believe this type would be used very often in an SP network, as tag manipulation is commonplace at the SP edge.
point-to-point (VPWS)
In this lab we are asked to use one EVI but keep each VLAN separate. CE1 and CE2 are untagged, and CE4 has two dot1q subinterfaces, so we must use a vlan-aware EVI.
When we configure a vlan-aware EVI, we must pick an ethernet-tag when we map the EVI to a bridge domain. You are allowed to map the EVI to multiple BDs only when using vlan-aware. When using vlan-based or vlan-bundle the parser will give you an error if you try to associate the EVI with multiple BDs.
Typically you will just match the VLAN ID with the EVPN ethernet tag, however these values are unrelated. The VLAN ID is in the data plane, while the ethernet tag is a control plane identifier.
Verification
Let’s first explore the type 3 routes that are generated before the CEs generate traffic. On PE1 we see that the ethernet tag field (highlighted on the first route) is now populated with a value of 10. In previous labs when using vlan-based, this field was zero.
Also notice that because the EVI RTs match, PE1 imports PE2’s type 3 route. However, PE1 realizes that it does not have a BD with EVI=100 and eth tag=20, so it does not list PE2 in its peers for EVI 100. (Keep in mind these outputs were from CSR1000v with version 17, and version 16 has a bug that does not list the EVI peers).
Likewise on PE2, we will only see PE3 as a neighbor.
On PE3 we see both PE1 and PE2 as peers, but they are kept separate based on the bridge-domain. We also see that each BD gets its own BUM label and per-BD label. For this reason, the BDs basically operate as if they had their own separate EVI.
Let’s now generate traffic from CE1. PE1 will generate a type 2 route. This will have the ethernet tag=10, so only PE3 will import it into BD10.
The ethernet tag is highlighted in the NLRI. Otherwise the type 2 route looks the same as with vlan-based.
PE3 imports this into BD10:
If we generate traffic from CE3, likewise PE3 will import this into BD20:
The ethernet tag of 20 prevents PE1 from importing CE3’s MAC into its BD, even though it is imported into PE1’s local EVPN BGP table with PE1’s own RID:
In summary, the ethernet tag is a control plane identifier that keeps domains separate with the same EVI. The only advantage to this appears to be the conservation of EVI numbers. The ethernet tag is not present in the data plane (on the MPLS label). The ethernet tag essentially just creates a “sub EVI” within the main EVI.
Last updated
