EVPN VPWS
Load basic.evpn.vpws.init.cfg
Configure EVPN VPWS service between the following CEs:
CE1 & CE3
CE6 & CE8
Use BGP ASN 65000, with P1 and P2 as RRs.
Answer
Explanation
EVPN can replace tLDP as the control plane for VPWS. EVPN VPWS simply uses the type 1 route for autodiscovery of the peer PE. Using EVPN also allows us to easily provide a multihomed VPWS service, which we will explore in the next lab.
EVPN VPWS uses three separate values: an EVI, a source ID, and a target ID. The EVI is the instance number, and does not need to match between PEs. However, the RT is autogenerated based on the EVI, so you would need to manually change the RT if you wanted to use different EVI numbers. Practically speaking, you would usually just use the same EVI on both PEs.
The source ID and target ID identify the local and remote AC. You can either use the same value on both sides, or you can use different values on each end. For example, you can use source ID 101 on PE1 and source ID 201 on PE2. The router needs to be manually configured with the remote AC ID though; it cannot auto-discover this. So on PE1 you would specify remote id 201, and on PE2 you would specify remote id 101.
On IOS-XE, MTU is not signaled, and there does not appear to be a way to signal it. However, on IOS-XR, MTU is signaled. Whether MTU must match differs based on the OS version, but in my lab using XRv9000 7.2.2, the MTU does indeed need to match.
CSR1000v and XRv9000 do not interoperate with EVPN VPWS. This is because CSR1000v uses the CW but does not signal it, and XRv9000 does not use the CW. There is no way to toggle the CW on either platform for EVPN VPWS. However, IOS-XE and IOS-XR EVPN VPWS works just fine on real equipment. (For example beween an ASR920 and ASR9900).
Verification
Let’s examine the route that PE1 originated:
When we filter on the RD, we see both PE1’s route and PE2’s route. This is because PE2’s route had a matching RT value, so PE1 imported this into its local EVPN database, which results in it having the local RD value. The bottom route in the above screenshot is PE1’s locally originated route.
Notice that there is not all that much information here. The NLRI is in the following format:
[1] = Route type
[1.1.1.1:13] = RD, auto-generated in the format <Loopback>:<EVI>
[00000000000000000000] = ESI. This is not a multihomed service, so an all-zeros ESI is used by default.
[13] = The AC ID, or the Ethernet Tag ID
Each router will generate a route using the AC ID that is specified with the source command. The router will match remote routes that have the remote value as the AC ID to form the VPWS service.
Lastly, we see the RT and a local label. This is the service label.
On IOS-XR we see that the MTU is signaled as well. See PE5’s locally originated route:
For this reason, when we check the VPWS details on IOS-XE, we see nothing about MTU:
However if we check it on IOS-XR, we do see the MTU listed. Also notice that by default, this version of IOS-XR ensures that MTU matches to bring up the xconnect. (On XRd, the MTU is not signaled).
Verify that pings between CE1&CE3 and CE6&CE8 work. As you generate traffic, you should se the counters increase on the PEs. (On XRd, the pings will work, but the counters will not increment).
With both platforms, if the AC goes down, the type 1 route is withdrawn and the VPWS goes down.
On PE1 we bring down Gi3:
On PE2 the VPWS is down because the remote route was withdrawn:
The same happens on IOS-XR. Here we shutdown the AC on PE5:
PE6 now sees the xconnect as down:
Last updated
