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.
#PE1
hostname PE1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet2
ip address 10.1.2.1 255.255.255.0
ip ospf network point-to-point
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
#P2
hostname P2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet1
ip address 10.1.2.2 255.255.255.0
ip ospf network point-to-point
mpls ip
!
interface GigabitEthernet2
ip address 10.2.3.2 255.255.255.0
ip ospf network point-to-point
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
#PE3
hostname PE3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet2
ip address 10.2.3.3 255.255.255.0
ip ospf network point-to-point
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0Let’s configure BGP, with PE1 and PE3 as RR clients and P2 as the RR. We need to activate the l2vpn/evpn address family.
PE1,3#
router bgp 65000
neighbor 2.2.2.2 remote-as 65000
neighbor 2.2.2.2 update-source lo0
address-family l2vpn evpn
neighbor 2.2.2.2 activate
P2#
router bgp 65000
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source lo0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source lo0
address-family l2vpn evpn
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-reflector-client
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 route-reflector-clientYou should see the BGP session come up, but no routes received yet:
P2#show bgp l2vpn evpn sum
BGP router identifier 2.2.2.2, local AS number 65000
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 65000 4 2 1 0 0 00:00:12 0
3.3.3.3 4 65000 2 2 1 0 0 00:00:04 0Next we will remove the existing xconnect configuration, if it still exists from your E-Line lab.
PE1,3#
int gi1
service instance 1 ethernet
no xconnectYou will see the targeted LDP neighborship go down.
Now we configure the EVPN VPWS service on the two PEs.
PE1#
l2vpn evpn instance 1 point-to-point
vpws context CUSTOMER_P2P
service target 301 source 101
member Gi1 service-instance 1
PE3#
l2vpn evpn instance 1 point-to-point
vpws context CUSTOMER_P2P
service target 101 source 301
member Gi1 service-instance 1Once 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
l2vpn evpn instance number point-to-point
vpws context name
service target X source Y
member interface service-instance numberLine 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
l2vpn evpn instance 10 point-to-point
route-target export 65000:1
route-target import 65000:1
vpws context CUSTOMER_P2P
service target 101 source 301
member GigabitEthernet1 service-instance 1PE3 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
CE1#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 00:00:33 10.1.1.2 GigabitEthernet0/0Here are some show commands you can explore on the PE routers
show l2vpn evpn sum
show l2vpn evpn vpws evi 1 detail
show l2vpn evpn vc all
!Most verbose
show l2vpn evpn vpws vc all detailAs 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.
PE1#show mpls ldp nei br
Peer LDP id Uptime NSR GR Discovery Address Labels
----------- ------ --- -- --------- ------- ------
2.2.2.2:0 6d21h N N 1 3 5You can see which label the PE router allocated for its local AC like this:
PE1#show bgp l2vpn evpn all detail
Route Distinguisher: 1.1.1.1:1
BGP routing table entry for [1][1.1.1.1:1][00000000000000000000][101]/23, version 2
Paths: (1 available, best #1, table evi_1)
Advertised to update-groups:
2
Refresh Epoch 1
Local
:: (via default) from 0.0.0.0 (1.1.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Rcvd Label: None, Local Label: 20
Extended Community: RT:65000:1
rx pathid: 0, tx pathid: 0x0
Updated on Jul 3 2022 14:39:47 UTC
BGP routing table entry for [1][1.1.1.1:1][00000000000000000000][301]/23, version 4
Paths: (1 available, best #1, table evi_1)
Not advertised to any peer
Refresh Epoch 2
Local, imported path from [1][3.3.3.3:1][00000000000000000000][301]/23 (global)
3.3.3.3 (metric 3) (via default) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Rcvd Label: 19, Local Label: None
Extended Community: RT:65000:1
Originator: 3.3.3.3, Cluster list: 2.2.2.2
rx pathid: 0, tx pathid: 0x0
Updated on Jul 3 2022 14:40:46 UTC
Route Distinguisher: 3.3.3.3:1
BGP routing table entry for [1][3.3.3.3:1][00000000000000000000][301]/23, version 3
Paths: (1 available, best #1, table EVPN-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
3.3.3.3 (metric 3) (via default) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Rcvd Label: 19, Local Label: None
Extended Community: RT:65000:1
Originator: 3.3.3.3, Cluster list: 2.2.2.2
rx pathid: 0, tx pathid: 0x0
Updated on Jul 3 2022 14:39:48 UTCFirst, let’s break down the full BGP update entry so it doesn’t look so confusing:
[1][1.1.1.1:1][00000000000000000000][101]/23The 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
PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 2.2.2.2/32 0 Gi2 10.1.2.2
17 Pop Label 10.2.3.0/24 0 Gi2 10.1.2.2
18 17 3.3.3.3/32 0 Gi2 10.1.2.2
20 No Label l2ckt(3) 8596 Gi1 point2pointThis 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?
PE3#
int Gi1
mtu 9126
CE1#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms,
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:
CE1#ping 10.1.1.2 size 1474 df
Type escape sequence to abort.
Sending 5, 1474-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms
CE1#ping 10.1.1.2 size 1475 df
Type escape sequence to abort.
Sending 5, 1475-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)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
