In this article, we’re taking a look at EVPN E-LINE/VPWS Layer 2 (L2) point-to-point services offered by Internet service providers.
Traditionally, service providers offered L2 point-to-point services using LDP-signaled pseudowires. More and more service providers are migrating to EVPN-based solutions due to better scaling and ease of deployment.
EVPN E-line or virtual private wire service (VPWS) offers L2 point-to-point connections using EVPN signaling. This offers a highly scalable solution. Customer endpoints are identified on the PEs with VPWS-IDs. These IDs and hence the customer endpoints are discovered by other PEs using BGP.
In this lab we’re using a simple topology as shown below. We want to transport customer VLAN 512 across the service provider MPLS backbone.
![](https://www.nlogic.no/content/uploads/sites/3/2024/06/nLogic-EVPN-MPLS-backbone-Juniper-Arista-website-1024x640.png)
We are using one Arista PE and one Juniper PE to make it more interesting. The example configuration below is for a basic L2 point-to-point service. There are plenty of options to enable for more advanced deployments. Please reach out to us if you want to learn more.
In this lab we’re only configuring the PEs, we’re assuming that the core-facing interfaces on the PEs and the core routers have already been configured. We also assume a BGP full mesh with EVPN address family enabled. We’re running ISIS and segment-routing, this could be replaced with OSPF and/or LDP/RSVP.
Let’s take a look at the Arista PE configuration first.
// Customer interface
interface Ethernet2.512
description "Customer site 1"
encapsulation vlan
client dot1q 512 network client
!
In Arista, we also need a “patch panel”. This is where we are bridging the local interface with the pseudowire.
// Patch panel
patch panel
patch CustomerELINE
connector LOCAL interface Ethernet2.512
connector REMOTE pseudowire bgp vpws Customer1 pseudowire PW1
!
And then finally the BGP configuration:
router bgp 65550
// Customer VPWS configuration
vpws Customer1
rd 10.10.10.1:800
route-target import export evpn 65550:800
mpls control-word
!
pseudowire PW1
evpn vpws id local 100 remote 200
We need to configure the route-target 65550:800 on both PEs. We also need VPWS IDs, one local and one remote. We chose 100 as the local ID and 200 as the remote ID. The same IDs must be configured on the other PE but in reverse.
That’s it! Not a whole lot of configuration. Now let’s take a look at the Juniper PE:
// Customer interface
ge-0/0/1 {
description "Customer site 2";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 512 {
encapsulation vlan-ccc;
vlan-id 512;
}
}
The only other thing we need is a routing instance:
routing-instances {
Customer1 {
instance-type evpn-vpws;
protocols {
evpn {
interface ge-0/0/1.512 {
vpws-service-id {
local 200;
remote 100;
}
}
control-word;
}
}
interface ge-0/0/1.512;
route-distinguisher 10.10.10.3:800;
vrf-target target:65550L:800;
}
}
It’s a pretty straight forward configuration on the Juniper side too. Please note the route-target and the local and remote VPWS IDs.
Let’s verify the VPWS service by looking at the Arista PE:
R1#show patch panel CustomerELINE detail
PW Fault Legend:
ET-IN - Ethernet receive fault
ET-OUT - Ethernet transmit fault
TUN-IN - Tunnel receive fault
TUN-OUT - Tunnel transmit fault
NF - Pseudowire not forwarding (other reason)
Patch: CustomerELINE, Status: Up, Last change: 22:53:48 ago
Connector LOCAL: Ethernet2.512
Status: Up
Connector REMOTE: BGP VPWS Customer1 Pseudowire PW1
Status: Up
Local MPLS label: 100000
MTU: 0, Control word: Y
Neighbor 10.10.10.3, MPLS label: 19
Tunnel type: IS-IS SR IPv4, Tunnel index: 1
MTU: 0, Control word: Y
EVPN VPWS type: VLAN-based
Flow label used: no
As we can see, everything looks good. Both the local and remote side is up. We can see the remote Juniper PE IP 10.10.10.3 and that the remote PE has reserved label 19 and sent this to us.
We can also take a look at the EVPN prefixes:
R1#show bgp evpn
BGP routing table information for VRF default
Router identifier 10.10.10.1, local AS number 65550
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
c - Contributing to ECMP, % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > RD: 10.10.10.1:800 auto-discovery 100 0000:0000:0000:0000:0000
- - - 0 i
* > RD: 10.10.10.3:800 auto-discovery 200 0000:0000:0000:0000:0000
10.10.10.3 - 100 0 i
Looking good! Let’s check the Juniper PE:
olofk@R3> show evpn vpws-instance Customer1
Instance: Customer1, Instance type: EVPN VPWS
Route Distinguisher: 10.10.10.3:800
Number of local interfaces: 1 (1 up)
Interface name ESI Mode Role Status Control-Word Flow-Label-Tx Flow-Label-Rx
ge-0/0/1.512 00:00:00:00:00:00:00:00:00:00single-homed Primary Up Yes No No
Local SID: 200 Advertised Label: 19
Remote SID: 100
PE addr ESI Label Mode Role TS Status
10.10.10.1 00:00:00:00:00:00:00:00:00:00 100000 single-homed Primary 2024-06-12 09:39:36.919 Resolved
Number of protect interfaces: 0
Note the remote Arista PE IP 10.10.10.1 and the local and remote service IDs.
There is only one thing left to do – test the connection on the CEs. In our case, the CEs are a couple of Linux boxes. Let’s try with ping and traceroute:
// We have configured 2001:db8:5695::/64 on the CEs
user@ubuntu22-server:~$ ip address show dev ens4.512
4: ens4.512@ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 50:01:00:05:00:01 brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:5695::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5201:ff:fe05:1/64 scope link
valid_lft forever preferred_lft forever
// Ping
user@ubuntu22-server:~$ ping 2001:db8:5695::1 -c 5
PING 2001:db8:5695::1(2001:db8:5695::1) 56 data bytes
64 bytes from 2001:db8:5695::1: icmp_seq=1 ttl=64 time=27.0 ms
64 bytes from 2001:db8:5695::1: icmp_seq=2 ttl=64 time=28.3 ms
64 bytes from 2001:db8:5695::1: icmp_seq=3 ttl=64 time=29.4 ms
64 bytes from 2001:db8:5695::1: icmp_seq=4 ttl=64 time=28.3 ms
64 bytes from 2001:db8:5695::1: icmp_seq=5 ttl=64 time=28.2 ms
--- 2001:db8:5695::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 27.006/28.238/29.433/0.768 ms
// Traceroute
user@ubuntu22-server:~$ traceroute6 2001:db8:5695::1
traceroute to 2001:db8:5695::1 (2001:db8:5695::1) from 2001:db8:5695::2, port 33434, from port 56087, 30 hops max, 60 bytes packets
1 2001:db8:5695::1 (2001:db8:5695::1) 26.526 ms 22.753 ms 27.437 ms
Looking good, we can ping the remote CE and as expected, since this is a layer 2 service, traceroute only shows one hop.
Please note that there are a few extra configuration options that should be configured in a production network.
There you have it, a fully functioning L2 point-to-point service using EVPN. Don’t hesitate to contact us if you have any questions or want to learn more.
Har du nogle spørgsmål?
Kontakt os, hvis du har spørgsmål om EVPN E-LINE/VPWS med Juniper Networks og Arista Networks. Eller hvis du har andre spørgsmål om vores partnere.
Kontakt os direkte eller send os en besked nedenfor.
![Billede af Esben Dahl Nielsen.](https://www.nlogic.no/content/uploads/sites/2/2023/09/nlogic-esben-dahl-nielsen.png)