EVPN VPWS Multihomed
Load basic.evpn.multihomed.vpws.init.cfg
BGP l2vpn/evpn is already preconfigured in the core.
Configure EVPN VPWS multihomed service between CE7 & CE9.
LACP does not appear to work with CSR1000v, so use static port-channels. The CEs are already preconfigured with port-channels, but you may need to add this config:
Answer
Explanation
Multihoming requires the use of an ESI. Previously, we saw an ESI of all-zeros. The ESI is how two separate PEs know their Bunde/Po interface connects to the same CE. This allows multihoming to work at layer 2 without the PEs running some type of MC-LAG control protocol.
In this lab we’re only using IOS-XR, as VPWS multhoming doesn’t work correctly on CSR1000v with 16.9.8.
Multihoming on IOS-XR
First, on IOS-XR the ESI is defined under the EVPN configuration. The ESI must be manually specified as a type 0 ESI.
If we were running LACP, we would need to manually set the LACP sys ID to be the same on each PE, in order to “trick” the CE into thinking it is connected to the same LACP system on both links. This would be done as follows:
The router generates two BGP routes with RD <loopback>:0. This represents the global EVPN table instead of a specific EVI. The ESI functionality seems to exist outside of a specific EVI.
We see a route type 1 per-ESI route for the ESI. This advertises the SH label and the ESI mode (0x0 = all-active, 0x1=single-active). The SH label isn’t used with VPWS, but this seems to be advertised whether using EVPN or just VPWS.
We also see a type 4 DF election route for the ESI:
We also see routes with RD <loopback>:<EVI>. These are similar to what we saw in single-homed VPWS. The AC ID is placed in the NLRI. Additionally we see a per-EVI type 1 route that doesn’t appear to be used with VPWS. This route is used with EVPN for aliasing with type 2 routes (MAC advertisements).
Because the ESI is specified in the route, the router knows that the VPWS endpoint is dual-connected to PE7 and PE8. As a result, the VPWS neighbor is not one particular PE, but instead a label binding which represents both PEs. We can see this looking at the xconnect detail and then inspecting the LFIB:
We can see information about the ethernet segments using the following command. PE5 tracks the nexthops for the remote ESI in order to do load sharing to all PEs connected to that ESI for the VPWS.
The source and target AC IDs can be the same as with the single-homing lab. The routers keep track of the ESIs and which PEs are connected to which ESIs, to determine the remote endpoints.
Note that the DF election does not appear to actually take place. Both PEs are active forwarders, because with EVPN-VPWS there is no notion of BUM traffic.
Multihoming VPWS on IOS-XE
On CSR1000v, the multihoming appears to only be supported for bridged EVPN. However, this is still a good opprotunity to explain how it works.
On IOS-XE, we configure the ESI directly under the Port-channel. On v16.9.8, only type 3 ESIs are supported. On newer v17 code, we can use either type 0 or type 3. Type 3 is a bit easier, because you just specify a MAC and the router will auto-generate the full 10 byte ESI. You also must specify redundancy all-active even though it is the only option.
If we were using LACP, we could match the LACP sysID on each PE using the following command:
Further Reading
Last updated
