EVPN E-LINE/VPWS using Juniper and Arista

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.

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.