Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring VPWS with EVPN Signaling Mechanisms

 

This example shows how to implement Virtual Private Wire Service (VPWS) with Ethernet Virtual Private Network (EVPN) signaling. The use of EVPN signaling provides single-active or all-active multihoming capabilities for BGP-signaled VPNs.

Requirements

This example uses the following hardware and software components:

  • Four MX Series routers acting as provider edge (PE) devices, running Junos OS Release 17.1 or later

  • Two customer edge (CE) devices (MX Series routers are used in this example)

Overview and Topology

VPWS employs Layer 2 VPN services over MPLS to build a topology of point-to-point connections that connect end customer sites. EVPN enables you to connect dispersed customer sites using a Layer 2 virtual bridge. Starting with Junos OS Release 17.1, these two elements can be combined to provide an EVPN-signaled VPWS.

The vpws-service-id statement identifies the endpoints of the EVPN-VPWS based on local and remote service identifiers configured on the PE routers in the network. These endpoints are autodiscovered using BGP-based EVPN signaling to exchange the service identifier labels.

Topology

This example uses the topology shown in Figure 1, consisting of four PE routers and two CE routers. Router CE1 is multihomed to Routers PE1 and PE2; Router CE2 is multhomed to Routers PE3 and PE4.

Figure 1: VPWS with EVPN Signaling
 VPWS with EVPN Signaling

The following configuration elements are used in this scenario:

  • CE devices:

    • Aggregated Ethernet (AE) interface towards related PE devices

  • PE devices:

    • AE interface, with EVPN segment identifier (ESI), towards related CE device

    • OSPF and IBGP in the core

    • MPLS LSPs using RSVP in the core

    • Per-packet load balancing

    • Routing instance using instance type evpn-vpws, and the vpws-service-id statement to define the local and remote endpoints.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level.

CE1

CE2

PE1

PE2

PE3

PE4

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

Note

Only Router PE1 is shown here. Repeat this procedure for all other PE devices, using the appropriate interface names, addresses, and other parameters for each device.

The step-by-step procedure for CE devices is not shown.

To configure Router PE1:

  1. Configure the CE-facing interface to be part of the ae0 bundle.

    The second interface for the AE bundle will be configured on the other local PE device.

  2. Configure the core-facing interfaces toward Routers PE3 and PE4.

    Be sure to include the MPLS protocol family.

  3. Configure the loopback interface.
  4. Define the number of aggregated Ethernet interfaces to be supported on the device.
  5. Configure the ae0 interface.

    Alternate VLAN tagging and encapsulation options can be used, depending on your needs.

  6. Assign an Ethernet segment identifier (ESI) value to the ae0 interface and enable EVPN active-active multihoming.
  7. Configure link aggregation control protocol (LACP) for the ae0 interface.

    The system ID used here must be the same on both local PE devices.

  8. Enable OSPF on the core-facing (and loopback) interfaces.
  9. Configure an IBGP mesh with the other PE devices, using EVPN for signaling.
  10. Enable RSVP on the core-facing interfaces.
  11. Enable MPLS on the core-facing interfaces, and configure LSPs to the remote PE devices.

    For this example, be sure to disable CSPF.

  12. Configure load balancing.
  13. Configure a routing instance using the evpn-vpws instance type. Add the AE (CE-facing) interface configured earlier, as well as a route distinguisher and VRF target.

    In EVPN terms, this is an EVPN instance (EVI).

  14. In the routing instance, enable EVPN and add the AE interface. Then associate local and remote VPWS identifiers to the interface.

Results

From configuration mode, confirm your configuration. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from the configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying Agregated Ethernet Interfaces and LACP

Purpose

Verify that the AE interfaces are up and properly.

Action

Verify that the AE interfaces are up, and LACP connections are established between the PE devices and their related CE device..

user@CE1> show lacp interfaces extensive
user@PE1> show lacp interfaces extensive
user@PE2> show lacp interfaces extensive

Meaning

The AE interface on each device is up, and there are active LACP connections between the CE device and its local PE devices. Note also that the system ID configured on the PE devices, 00:00:00:00:00:01 (and shown on the PE device outputs as the Actor), matches the Partner system ID value on the CE device.

Verifying OSPF

Purpose

Verify that OSPF is working properly.

Action

Verify that OSPF has adjacencies established with its remote neighbors.

user@PE1> show ospf neighbor
user@PE3> show ospf neighbor

Meaning

Adjacencies have been established with remote neighbors.

Verifying BGP

Purpose

Verify that BGP is working properly.

Action

Verify that IBGP has peerings established with its neighbors using EVPN signaling.

user@PE1> show bgp summary
user@PE3> show bgp summary

Meaning

EVPN-signaled IBGP peerings have been established with all neighbors.

Verifying MPLS

Purpose

Verify that MPLS is working properly.

Action

Verify that MPLS LSPs are established with remote neighbors.

user@PE1> show mpls lsp
user@PE3> show mpls lsp

Meaning

LSPs have been established with remote neighbors.

Verifying the VPWS

Purpose

Verify that the VPWS is established.

Action

Verify that the PE devices have exchanged and learned service identifiers, and established the VPWS.

user@PE1> show evpn vpws-instance
user@PE3> show evpn vpws-instance

Meaning

The PE devices on each side of the network have advertised their service identifiers, and received the identifiers from their remote neighbors. The VPWS is established.

Verifying Route Exchange and ESI Autodiscovery

Purpose

Verify that EVPN signaling is working properly.

Action

Verify that autodiscovery information is being shared across the VPWS.

user@PE1> show route table bgp.evpn.0
user@PE3> show route table bgp.evpn.0

Meaning

The outputs show the ESI routes being shared across the VPWS to the remote PE devices.

The routes beginning with 1:198.51.100.x:0:: are the per-Ethernet-segment autodiscovery Type 1 EVPN routes originating from the remote PE devices. The route distinguishers (RDs) are derived at the global level of the devices.

The routes beginning with 1:198.51.100.x:11:: are the per-EVI autodiscovery Type 1 EVPN routes from the remote PE devices. The RDs are taken from the remote PE devices’ routing instances.

Verifying Local EVPN Table Route Information

Purpose

Verify that the local EVPN routing tables are being populated.

Action

Verify that both local and remote reachability information is being added into the EVPN table.

user@PE1> show route table EVPN-VPWS.evpn.0
user@PE3> show route table EVPN-VPWS.evpn.0

Meaning

In addition to the remote ESI routes being shared across the VPWS, as explained in the previous section, the EVPN table on each PE device also includes a local ESI route. This Type 1 route represents the locally configured Ethernet segment, and is derived from the locally configured RD and ESI values.