Basic Single-homed EVPN E-LAN
Load basic.evpn.singlehomed.init.cfg
Configure EVPN E-LAN service for CE1, CE3 and CE4. The CEs are already preconfigured with IP addresses. BGP is already preconfigured in the core.
Answer
Explanation
EVPN replaces VPLS as an E-LAN control plane. In EVPN, we can achieve the same E-LAN service but without flood & learn in the data plane. Instead, MAC addresses are learned via BGP routes. This also means we don’t need a full mesh of pseudowires. Instead, service labels are advertised with MAC address BGP routes, similar to a service label advertised with a VPNv4 prefix.
In this lab, there is no multi-homing. A lot of the complexity of EVPN comes from supporting multi-homing scenarios. When we only have single homing everywhere, EVPN is not all that complex.
We will see two route types: type 2 routes which advertise MACs, and type 3 routes which advertise interest in receiving BUM traffic for the EVI. We will look at these in detail throughout this lab.
This lab uses only IOS-XE as PEs. XRv9000 and XRd do not support local MAC learning/bridging, so we cannot use them in EVPN. XRv9000 and XRd only support VPWS in which MACs are not learned in the data plane at all.
Configuration
EVPN configuration on a PE is fairly simple. Because we don’t have to choose a unique VE ID value for each PE, we can just reuse the EVPN configuration on all PEs.
First we must specify the ingress replication type. The only available option is ingress-replication. This can be set globally or per EVI:
As a good measure, the lab solution sets the RID statically as well. If this wasn’t specified, the loopback would have been automatically chosen as RID anyways.
Lastly we just associate the EVI with the bridge-domain, which is very similar to associating a VFI with a BD.
The router will handle automatically advertising the type 3 route, generating type 2 routes for locally learned MACs, and importing type 2 routes from BGP into the CAM table.
Control Plane Walkthrough and Verification
Before the CEs begin sending traffic, all PEs advertise interest in receiving BUM traffic for the EVI using a type 3 route:
We can see the detail of one of these routes. The NLRI includes the ethernet tag (not used in vlan-based) and the loopback of the advertising PE. The route details includes the PMSI attribute which is the same PMSI attribute used in mVPN. This shows us the replication type (IR, for ingress replication) and the label.
Based on these type 3 routes, each PE builds a IR list. We can see this using the below show command. (This was from a CSRv1000 running version 17).
We can also see this information using the following show command, which adds the time since the peer has been discovered:
Let’s send customer traffic to generate type 2 routes. From CE1 we’ll ping CE3. This will generate an unknown unicast frame which needs to be flooded. PE1 will flood this to both PE2 and PE3 using each of their BUM labels, which were learned via the type 3 routes. Additionally, PE1 will advertise CE1’s MAC address using a type 2 route, as seen below:
The type 2 route NLRI is in the format:
In our case we are not using ethernet tags, nor are we learning IP addresses, so those values are zero. Additionally, the type 2 route contains an ESI value which is used for aliasing in multi-homed setups. But we are not doing multihoming in this lab, so the ESI is all zeros as well.
When PE2 receives the BUM frame, it does not learn CE1’s MAC in the data plane. It only adds CE1’s MAC to the CAM table based on the BGP route. On PE2 we can see that CE1’s MAC is tagged as static in the CAM table. The advantage of this is that MACs are not aged out. They are simply added and removed from the CAM table in response to BGP type 2 routes.
We can see a list of known MACs in the EVI using the following command. It shows us the remote PE and the service label:
We can see the local type 2 label that each PE is using with the following command:
Each PE generates two labels per EVI by default: a per-BD label (used for unicast traffic) and a BUM label (for BUM traffic). All type 2 routes will have the same per-BD label.
Above we also see that the RD and import/export RTs were automatically generated.
Summary
Basic EVPN uses two route types:
Type 3 routes to advertise the BUM label and build an IR list for an EVI
Type 2 routes to advertise a MAC address in the EVI, and an associated service label
EVPN learns MACs only in the control plane. Type 2 routes are populated into the CAM table as static entries and are not aged out. This is much more scalable than VPLS in which remote MACs are learned in the data plane.
EVPN control plane and data plane operation looks much more like VPNv4 now. MAC addresses are advertised as “routes” with an associated service label. In the data plane we see two labels: a transport label and a service label. MAC address “routes” are added to the “VRF” which for EVPN is a bridge-domain. You can think of a BD sort of like an L2 VRF, or MAC VRF. MAC address “routes” are removed and added to this L2 VRF in response to BGP routes, just like in VPNv4.
The big difference between EVPN and VPNv4 is BUM flooding. This is necessary in layer 2 VPN, so there is a separate route type for auto-discovery of all participating PEs. Ingress replication is the only available choice for BUM flooding on IOS-XR, although underlay multicast is seen in data centers with VXLAN. Underlay multicast optimizes bandwidth by not sending n copies of a BUM frame out, where n is the number of PEs. Instead one copy would be sent out and that copy is destined to a multicast group address. The network would replicate it via multicast in the underlay to all interested receivers (PEs participating in the EVI which have joined the multicast group in the underlay).
Last updated
