EVPN-VPWS PW headend functionality

EVPN-VPWS is often used as an aggregation technology to connect access devices to the residential or business PE in the service provider network. The PE receives tagged traffic inside EVPN-VPWS circuits and maps each tag to a different service in the core, such as ESM services, Epipe services, or VPRN services.

SR OS implements this PW headend functionality by using PW ports that use multihomed Ethernet Segments (ESs) for redundancy. ESs can be associated with PW ports in two different modes of operation.

PW port-based ESes with multihoming procedures on PW SAPs

PW ports in ESs and virtual ESs (vESs) are supported for EVPN-VPWS MPLS services. In addition to LAG, port, and SDP objects, PW port ID can be configured in an Ethernet Segment. In this mode of operation, PW port-based ESs only support all-active configuration mode, and not single-active configuration mode.

The following requirements apply:

For all the preceeding scenarios, fault-propagation to the access CE only works in the case of physical failures. Administrative shutdown of individual Epipes, PW SAPs, ESs or BGP-EVPN may result in traffic black holes.

The following figure shows the use of PW ports in ESs. In this example, an FPE-based PW port is associated with the ES, where the stitching service itself also uses EVPN-VPWS.

Figure: ES FPE-based PW port access using EVPN-VPWS

In this example, the following conditions apply:

PW port-based ESes with multihoming on stitching Epipe

The solution described in PW port-based ESes with multihoming procedures on PW SAPs provides PW-headend redundancy where the access PE selects one of the PW-headend PE devices based on BGP best path selection, and the traffic from the core to the access may follow an asymmetric path. This is because the multihoming procedures are actually run on the PW SAPs of the core services, and the AD per-EVI routes advertised in the context of the stitching Epipe use an ESI=0.

SR OS also supports a different mode of operation called pw-port headend which allows running the multihoming procedures in the stitching Epipe and, therefore, use regular EVPN-VPWS primary or backup signaling to the access PE. The mode of operation is supported in a single-active mode shown in the following figure.

Figure: ES FPE-based pw-port headend

The following configuration triggers the needed behavior:

// ES and stitching Epipe config

PE-1/2>config>service# info
  system
    bgp-evpn
      ethernet-segment “ES-1” create
        esi 00:12:12:12:12:12:12:12:12:12
        multi-homing single-active
        pw-port 1 pw-headend
        no shutdown

  epipe 300 name ”stitching-300" customer 1 create
    pw-port 1 fpe 1 create
      no shutdown
    bgp-evpn
      local-attachment-circuit ac-23 eth-tag 23
      remote-attachment-circuit ac-1 eth-tag 1
      mpls bgp 1
        auto-bind-tunnel resolution any


// Services config

epipe 10
  sap pw-1:10 create
  bgp-evpn
    mpls bgp 1

epipe 11
  sap pw-1:10 create
  bgp-evpn
    mpls bgp 1

The configuration and functionality are divided in four aspects.

Configuration of single-active multihoming on ESs associated with PW ports of type pw-headend

In this mode, PW Ports are associated with single-active non-virtual Ethernet Segments. The pw-headend keyword is needed when associating the PW port.

PE-1/2>config>service# info
  system
    bgp-evpn
      ethernet-segment “ES-1” create
        esi 00:12:12:12:12:12:12:12:12:12
        multi-homing single-active
        pw-port 1 pw-headend
        no shutdown

The pw-port id pw-headend command indicates to the system that the multihoming procedures are run in the PW port stitching Epipe and the routes advertised in the context of the stitching Epipe contains the ESI of the ES.

Configuration of the PW port stitching Epipe

A configuration example of the stitching Epipe follows.

epipe 300 name ”stitching-300" customer 1 create
    pw-port 1 fpe 1 create
      no shutdown
    bgp-evpn
      local-attachment-circuit ac-23 eth-tag 23
      remote-attachment-circuit ac-1 eth-tag 1
      mpls bgp 1
        auto-bind-tunnel resolution any

When the ES is configured with a PW port in pw-headend mode, the stitching Epipe associated with the PW port is now running the ES and DF election procedures. Therefore, the following actions apply:

Configuration of the PW port-contained PW SAPs and edge services

The edge services that contain the PW SAPs of the pw-headend pw-port command are configured without any other additional commands. These PW SAPs can be configured on Epipes, VPRN interfaces, or subscriber interfaces, VPLS (capture SAPs). As an example, if the PW SAP is configured on an Epipe EVPN-VPWS service:

epipe 10
  sap pw-1:10 create
  bgp-evpn
    mpls bgp 1
The behavior of the PW SAPs when the PW port is configured with the pw-headend keyword follows:
  • The PW SAP is brought operationally down if the PW port is down. The PW port goes down with the reason MHStandby if the PE is a non-DF, or with reason stitching-svc-down if the EVPN-MPLS destination is removed from the stitching Epipe.
  • If the PW SAP is configured in an EVPN-VPWS edge service as in the preceeding example, the following actions are performed:
    • An AD per ES route is advertised for the EVPN-VPWS service with the RD or RT of the service Epipe, the configured ESI of the ES associated with the PW port, and the ESI-label extended community with the multihomed mode indication of the ES and ESI label (label is the same value as in the AD per ES for the stitching Epipe). If the PW port is only down because of the MHStandby flag, the AD per ES route for the Epipe service is still advertised.
    • In addition, an AD per EVI route is advertised with the RD or RT of the service Epipe, the configured ESI of the ES associated with the PW port, and the P/B flags of the ES:
      • P=1/B=0 on the DF
      • P=0/B=1 on backup
      • P=0/B=0 on non-DFs and non-backup
    • If the PW port is down only because of MHStandby, the AD per EVI route for the service Epipe is still advertised.

Some considerations and dependencies between the PW port and the service Epipe PW SAPs

The PW SAP can also be configured on VPRN services (under regular interfaces or subscriber interfaces) and works without any special consideration, other than that a PW port in non-DF state brings down the PW SAP and, therefore, the interface. Similarly, VPLS services with capture PW SAPs support this mode of operation too.