EVPN E-LAN on XRv
Last updated
Last updated
This lab does not have an associated topology. It uses the EVE-NG topology provided in Ovi's EVPN course. I have left this lab in this workbook in case you want to use this for refrence, or you have the associated EVE-NG topology and want to use this as a challenge.
Startup the Ping Factory - EVPN MPLS XR - day 1 topology in EVE-NG.
Configure EVPN for dual-homed CE1 and single-homed CE2. PE1 and PE2 will use the physical interface only, not a bundle. They should use single-active mode for the ESI.
BGP is not preconfigured.
On IOS-XR, you must configure advertise-mac for a bridged EVPN service. This happens automatically on IOS-XE. Without this command on IOS-XR, the router will not generate type 2 routes.
You then place the EVI inside the BD, which is very similar to placing a VFI inside a BD.
On IOS-XR you configure the ESI under the global evpn config. On IOS-XR the only option is to use a type 0 ESI in which you manually specify 9 bytes.
When using a standalone interface for an ESI, the only available option is single-active. This is not configurable. However, when using a Bundle-Ether interface, it will by default be all-active. You can change this using the following command:
XRv allows you to commit and view EVPN control plane operations, but the data plane does not work. Nevertheless we can verify EVPN operation and multi-homing operation.
Using the following show command we can see details about the ESI. We see that the default for a single interface is single-active. We also see the ESI value, ES import RT (which was auto-generated from the ESI value), the peers, DF election results, and the SH labels (local and remote):
The DF election results are displayed using the Elected and Not Elected fields. A value of 1 means true, and a value of 0 means false.
The BGP route types work the same as seen with IOS-XE. To view the details of a route you can use show bgp l2vpn evpn rd <rd> <full NLRI>. The below route is the local per-ESI route that PE1 generated. We can see that the ESI type is single active (0x01). The SH label appears to be properly parsed in IOS-XR. In IOS-XE this seems to be a bug - the SH label seen in the update in the CLI is not the correct value. Notice below that the SH label is 24012, which matches the SH seen in the output above.
The following command shows us details of the EVI. We can see the unicast and BUM labels, and that MACs are being advertised. The multicast label is the BUM label.
To see the auto-discovered PEs participating in the EVI, we can use the following command:
The following command shows us the details about the ingress replication list. This was built from the type 3 routes, hence the keyword inclusive-multicast.
To test the control plane for MAC addresses, we can manually inject a MAC into the control plane. This will allow us to verify MAC learning via BGP type 2 routes:
PE5 advertises the MAC with the EVI unicast label. We can see this MAC is learned on remote PEs:
We can also test single-active MAC advertisement. Because PE2 is not the DF, and we are operating in single-active mode, it should never advertise a MAC address into EVPN. Inject a local MAC ending in 1s on PE1 and ending in 2s on PE2. Notice that PE5 only sees the MAC ending in all 1s from PE1.
IOS-XR will properly load balance traffic to multiple PEs connected to an ES. Because we are using single-active, the router can only use PE2 as a FRR backup. It cannot actively load balance to PE2 while PE1 is still connected to the ES. We can see the details of this using the detail keyword:
PE5 found that there are multiple paths to the MAC due to the ESI included on the type 2 route. PE5 locally allocated label 24012 for this forwarding behavior. If we look at the details of this local label, we see that PE2 is used purely as a FRR backup path.
Above, 24011 is the aliasing label that PE2 has advertised in its per-EVI type 1 route. It is also the label that PE1 included in the type 2 route. These happen to be the same value in this lab.
