EVPN E-LAN Multihomed
Load evpn.multihomed.init.cfg
Configure EVPN E-LAN for CE1, CE2, CE3, and CE5. The CEs are already preconfigured with IP addresses. BGP is already preconfigured in the core.
CE2 and CE5 should be multihomed to each PE using a static LAG.
Answer
Explanation
Most of EVPN’s complexity comes from multihoming support. There are several route types used to support multihoming:
Type 1 per-ESI
Used for mass MAC withdraw, to advertise a SH label, and to advertise the redundancy mode (all-active or port-active)
Type 1 per-EVI
Used to advertise an aliasing label
Type 4
Used to elect a DF on the ES
The configuration is fairly simple. You configure an ESI under the port-channel. The only available redundancy mode option on IOS-XE is all-active but you must specify it anyways.
In this CSR1000v version, you can only specifiy a type 3 ESI, in which the ESI is generated from a specified MAC address. This gives you an ESI in the format 03.xx.xx.xx.xx.xx.xx.00.00.0Y, where Y is the ethernet-segment number.
In newer versions, the ESI type can also be type 0, in which all 9 bytes are manually specified, leaving you with an ESI in the format 00.xx.xx.xx.xx.xx.xx.xx.xx.xx.
In general, MAC learning in the control plane and BUM flooding works as we saw previously in the single-homed lab. So in this lab we will walkthrough how multi-homing prevents duplicate frames from being sent to the CE, how a DF is elected, and how remote PEs can load balance traffic to all PEs connected to the ES.
Multi-homing Control Plane Walkthrough
When PE1 is first configured by itself, it generates four BGP routes:
A per-ESI type 1 route
This route can be identified because the RD is in the format <loopback>:<random number> as opposed to <loopback>:<EVI> which is used for the per-EVI type 1 route. Additionally, the ethernet tag is all Fs (4294967295). The per-ESI type 1 route advertises a split horizon label and is used for mass MAC withdraw. This route also advertises the type of ES, either all-active or port-active. 0x0 is all-active (which is our only choice) and 0x1 is port-active. Note that the label value of 272 appears to be a bug, as the SH label is not this value, it is actually 17.
A per-EVI type 1 route
This route advertises the aliasing label for the EVI. This is the per-BD label for the EVI. A remote PE will use this label to load balance traffic to the PE for MACs behind the ES, but for which this local PE did not generate a type 2 route. Simply put, this is how a remote PE can load balance traffic to MACs behind an ES to all participating PEs. The remote PE knows the ESI from the type 2 route and can lookup the attached PEs to that ESI using the type 1 per-ESI routes.
A type 3 route which advertises a BUM label. This is no different than in the single-homing case.
A type 4 route used for DF election
The type 4 route contains the ESI in the NLRI as well as the PE’s loopback. The ES-Import value ensures that only PEs attached to this ESI import the route. This route is used to elect the DF for the ES.
We’ll now configure PE2. This will prompt a DF election. We can see the DF election results using the following show command:
In the above screenshot, we also see PE2’s BUM label, which is 40. Traffic received on PE2 with this label is not forwarded onto the ES.
Because the EVI is even, when you do 100%2 you get 0. (100%2 means divide 100 by 2 and return the remainder, which is 0). This elects the lowest RID as the DF, which in this case is PE1. We can see the oridinal values using the following show command:
This tells us that when the remainder is 0, PE1 is the DF. When the remainder is 1, PE2 is the DF.
The above output also shows us the split horizon label for the ESI. When either PE1 or PE2 receive BUM traffic from the CE on the ES and flood it to a remote PE that is also on the ES, they will include both the BUM label and the SH label. The SH label ensures that the PE will not flood the traffic back onto the ES. Below we see a pcap taken at PE1. 24012 is the transport label for PE2’s loopback, 40 is the BUM label PE2 advertised in the type 3 route, and 17 is the SH label PE2 advertised in the per-ESI type 1 route.
We’ll now configure PE3 and PE4. We should see all PEs as peers for the EVI:
Let’s now generate one frame on CE1 to observe how the aliasing label works. PE1 generates a type 2 route, but PE2 does not:
This route contains the ESI. Using this, PE4 can lookup the ESI via the per-ESI type 1 routes that PE1 and PE2 generated. PE4 knows that PE2 is attached and that the ES is all-active. Therefore, PE4 can load balance traffic for the MAC to PE2 as well, even though PE2 did not advertise this MAC. However, PE4 needs to put a service label that PE2 will understand. It uses PE2’s per-EVI type 1 route as the service label. This is the aliasing label:
The aliasing label is the same as the per-BD label. Note that I do not see a way to confirm on PE4 that it is actually load balancing traffic to PE1 and PE2.
Finally we’ll observe how mass MAC withdraw works. We’ll simulate an AC failure on PE1 by shutting down Gi4. This will bring down Po1 and prompt PE1 to first withdraw its per-ESI type 1 route. This tells all remote PEs to stop using PE1 as a nexthop for any MACs associated with the ESI that was withdrawn. This is called a mass withdraw because it effectively withdraws n type 2 routes with a single type 1 route withdraw.
As an optimization, PE1 immediately withdraws the per-ESI type 1 route and the type 4 route. It then begins withdrawing individual per-EVI routes and type 2 routes.
Last updated
