E-Line (EVPN VPWS)
In this article we will configure a single-homed EPL service. This will achieve the same functionality as the E-Line service we configured using Martini circuits. However, instead of using targeted LDP, we will use EVPN which uses BGP to signal the EPL service.
EVPN VPWS uses only the type 1 EVPN route type. This route advertises an ESI and Ethernet Tag ID. Since this is a single-homed setup, and not multi-homed, the ESI will be zeros. The ESI is only used to identify a multi-homed CE.
When configuring EVPN VPWS, we will need three things:
EVI — EVPN Instance ID (or VPN ID)
This keeps multiple EVPN VPWS on the same PE separate from each other
This is analogous to a VRF in L3VPN. Each EVI has a RD and RT but these are auto-configured for you by the router when you create the EVI
Local AC tag ID
This identifies the local AC.
The remote PE “looks” for a BGP route that contains this tag ID.
This is not configured under the interface, rather under the EVI itself. This is also called a service instanced ID
Remote AC tag ID
This identifies the remote PE’s AC.
This local router will “look” for a BGP route that contains this tag ID. When it sees an EVPN Type 1 route that has this tag ID, it will use the MPLS label in that route. More on this later.
The local router tags the route with the local tag, and the remote router tags the route with its local tag. Each router then matches the route using the configured remote tag.
The tag ID can seem a little confusing at first, because you will see multiple names for the same thing. This can be called an “Ethernet Tag ID” which you will see in the pcap. It can also be called a Service Instance ID, and it can be called a Service Target. In the config you will see reference to the service target. These all mean the same thing. It’s simply a number that identifies this particular VPWS service.
Note: The tag ID is the VNI in EVPN/VXLAN if you preformed the lab in the previous article! If you capture the BGP Updates in your Arista lab, you’ll see that the VNI is in two fields, the Ethernet Tag ID and the VNI field. In this lab, the VNI field is replaced with an MPLS label, and the tag ID and MPLS label are two separate things.
Lab
OSPF, MPLS/LDP, and IP addressing has already been configured on the MPLS core, just like in the E-Line (LDP) section.
Let’s configure BGP, with PE1 and PE3 as RR clients and P2 as the RR. We need to activate the l2vpn/evpn address family.
You should see the BGP session come up, but no routes received yet:
Next we will remove the existing xconnect configuration, if it still exists from your E-Line lab.
You will see the targeted LDP neighborship go down.
Now we configure the EVPN VPWS service on the two PEs.
Once you exit from configuration mode, the PE will generate a l2vpn evpn update in BGP.
Let’s look at the NLRI for the Update generated by PE1, and then walk through the configuration line-by-line.
Configuration Explanation
Line 1 - Instead of simply configuring the xconnect on the interface, or using l2vpn vfi like we did previously, we use l2vpn evpn configuration mode. We create an instance, which is the EVI. We chose point-to-point for this VPWS service. The other options are vlan based services, but we won’t worry about those for now.
Line 2 - We are configuring vpws, so we create a vpws context and give it a name
Line 3 - All iBGP peers will receive this update, so we need to be able to differentiate this point-to-point service from other point-to-point services. We use a tag ID on each PE. The target is the remote PE’s ID, and the source is the local tag ID for this PE. In the real world you might use a formula to keep this organized. In this lab I used <PE #> 0 <EVI #>, which gives me 101 for PE1 and 301 for PE3. You could also use the same tag ID on each end and track the tag IDs in your IPAM similarily to tracking VPN RT values.
Line 4 - Since we did not configure this directly under the interface, we need to associate our AC (Gi1 service 1) with this vpws
Notice how the source ethernet tag ID is listed in the Update, but not the target tag ID is not. The target is only used to match received Updates. The local PE will “accept” the learned Update from the remote PE if the tag ID matches the configured target.
Also notice that the MPLS label is signaled, which makes sense - BGP is distributing the service label. There is also a RT, and since we did not specify one in the evpn instance configuration, a value of <ASN>:<instance number> was auto-generated. Because the instance number is used as the import/export RT, these must match on each PE. Or you could use a non-matching instance number but specify the RT:
PE3 uses instance 10 instead of instance 1. So you must specify the import/export RT since the auto-generated RTs on each end will not match. If you are confused about RTs, I highly recommend you go through the series “An In-Depth Look at RD and RT” under L3VPN on this website.
The ESI is all zeros, because this is not a multi-homed setup.
The RD is also auto-generated, in the format <Lo0>:<instance number>
The EVPN route type is type 1, Ethernet Auto-Discovery route. As mentioned earlier, VPWS uses only a single route type - type 1. The routers do not need to preform MAC learning and bridging, so there is no need for a type 2 route.
Do you notice anything missing here that you saw with the xconnects with targeted LDP? I do not see the MTU signaled here.
Let’s verify that the service is up, and then change MTU on one side to see what happens.
Verifcation
The OSPF adjancency came up between CE1 and CE2
Here are some show commands you can explore on the PE routers
As you know, there is no LDP session between PE1 and PE3. To prove it let’s check LDP neighbors on PE1. The only neighbor is P2 which is directly connected. If this used LDP you would see a neighborship with PE3.
You can see which label the PE router allocated for its local AC like this:
First, let’s break down the full BGP update entry so it doesn’t look so confusing:
The first [1] is the EVPN route type, which is type 1.
Next, [1.1.1.1:1] is the auto-generated RD. Just like with L3VPN, the RD is prepended to the route.
Next is the ESI, which is all zeros. Since we are single-homed, this is “blank.”
Next, [101] is the local Ethernet Tag, or service instance ID.
/23 is a bit misleading. The length of the EVPN route type 1 update has a length of 25. BGP interprets this as a mask. You can essentially ignore this.
Back to the detail of the first route. It shows a local label of 20. The subsequent two routes are from PE3, and show a received label of 19.
The second route is not actually in the BGP table, but in the EVI table. Notice that it says “imported from …. (global).” Because the received route in the global table matches the target ethernet ID for the VPWS, PE1 imported this route into its EVI table. The difference between the two routes is that the imported route has 1.1.1.1:1 as the RD instead of PE3’s original RD. (Why exactly does the router copy and import this into the EVI table, instead of simply using the information from BGP? I’m not sure).
Let’s look at PE1’s LFIB
This matches PE1’s advertised BGP route. Frames with a label of 20 will be forwarded out Gi1 (the AC).
What happens if we set PE3’s AC to jumbo frames, but leave PE1 at the default 1500?
,
We still have reachability. Since MTU is not signaled in EVPN VPWS like it is with xconnect using targeted LDP, the MTU does not need to match on either end in order for the service to be up. This is more like L3VPN in this sense. BGP is simply used to advertise the route and label. It is not concerned with MTU settings, etc.
MTU Considerations in the Core
If core links are left at 1500 MTU, only up to 1474 byte frames from the CEs will pass:
This is exactly what we saw with xconnect using targeted LDP in E-Line. 1500 - 14 (ethernet) - 8 (two MPLS labels) - 4 (control word) = 1474. See that section for more details.
Conclusion
Using EVPN VPWS allows you to use BGP to signal a point-to-point (EPL) service. The MTU of each AC does not need to match in order for the service to be up, which could be useful in certain circumstances.
The major benefit of using EVPN VPWS is the ability to multi-home the CE to multiple PEs and removing targeted LDP sessions. The targeted LDP sessions create additional state in your core, and also prevent full migration to Segment Routing, due to the necessity to keep LDP up for the targeted LDP sessions for your xconnects.
Even if you’re not multihoming, EVPN allows you to remove LDP and migrate to SR, where you can use SR-TE policies based on the color extcommunity value of a BGP route. See the Segment Routing series for more on that!
Next we’ll explore how a customer can have redundant multi-homed connectivity for a single p2p service using EVPN VPWS.
Further Reading
EVPN VPWS on IOS-XE: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-3s/asr903/mp-l2-vpns-xe-3s-asr903-book/epvn_vpws_single_homed.html
Last updated
