Perform this task to configure dynamic point-to-point cross-connects.

Note	For dynamic cross-connects, LDP must be up and running.

Router# configure 
Router(config)# l2vpn 
Router(config-l2vpn)# xconnect group vlan_grp_1
Router(config-l2vpn-xc)# p2p vlan1
Router(config-l2vpn-xc-p2p)# interface HunGigE 0/0/0/0.1
Router(config-l2vpn-xc-p2p)# neighbor 10.0.0.1 pw-id 1
Router(config-l2vpn-xc-p2p-pw)# commit

configure
  l2vpn
   xconnect group vlan_grp_1
    p2p vlan1
    interface HunGigE 0/0/0/0.1
    neighbor 10.0.0.1 pw-id 1
!

In Ethernet port mode, both ends of a pseudowire are connected to Ethernet ports. In this mode, the port is tunneled over the pseudowire. The ingress PE transports frames received on a main interface or after the subinterface tags are removed when the packet is received on a subinterface. The VLAN manipulation is transported over the type 5 PW, whether tagged or untagged.

This figure shows a sample ethernet port mode packet flow:

/* PE1 configuration */
Router# configure 
Router(config)# l2vpn 
Router(config-l2vpn)# xconnect group grp1
Router(config-l2vpn-xc)# p2p xc1
Router(config-l2vpn-xc-p2p)# interface HundredGigE0/0/0/1.2
Router(config-l2vpn-xc-p2p)# neighbor 10.0.0.11 pw-id 222
Router(config-l2vpn-xc-p2p-pw)# commit

/* PE2 configuration */
Router# configure 
Router(config)# l2vpn 
Router(config-l2vpn)# xconnect group grp1
Router(config-l2vpn-xc)# p2p xc1
Router(config-l2vpn-xc-p2p)# interface HundredGigE0/1/0/3.2
Router(config-l2vpn-xc-p2p)# neighbor 10.0.0.13 pw-id 222
Router(config-l2vpn-xc-p2p-pw)# commit

/* PE1 configuration */
l2vpn
 xconnect group grp1
  p2p xc1
   interface HundredGigE0/0/0/1.2
   neighbor 10.0.0.11 pw-id 222

/* PE2 configuration */
l2vpn
 xconnect group grp1
  p2p xc1
   interface HundredGigE0/1/0/3.2
   neighbor 10.0.0.13 pw-id 222

Router# show l2vpn xconnect group grp1 detail
Group grp1, XC xc1, state is up; Interworking none
  AC: HundredGigE0/0/0/1.2, state is up
    Type VLAN; Num Ranges: 1
    VLAN ranges: [2, 2]
    MTU 1504; XC ID 0x840006; interworking none
    Statistics:
      packets: received 186, sent 38448
      bytes: received 12644, sent 2614356
      drops: illegal VLAN 0, illegal length 0
  PW: neighbor 10.0.0.11, PW ID 222, state is up ( established )
    PW class not set, XC ID 0xc0000004
    Encapsulation MPLS, protocol LDP
    Source address 10.0.0.13
    PW type Ethernet, control word disabled, interworking none
    PW backup disable delay 0 sec
    Sequencing not set

    PW Status TLV in use
      MPLS         Local                          Remote
      ------------ ------------------------------ -----------------------------
      Label        16026                          16031
      Group ID     0x4000280                      0x6000180
      Interface    HundredGigE0/0/0/1.2           HundredGigE0/1/0/3.2
      MTU          1504                           1504
      Control word disabled                       disabled
      PW type      Ethernet                       Ethernet
      VCCV CV type 0x2                            0x2
                   (LSP ping verification)        (LSP ping verification)
      VCCV CC type 0x6                            0x6
                   (router alert label)           (router alert label)
                   (TTL expiry)                   (TTL expiry)
      ------------ ------------------------------ -----------------------------
    Incoming Status (PW Status TLV):
      Status code: 0x0 (Up) in Notification message
    Outgoing Status (PW Status TLV):
      Status code: 0x0 (Up) in Notification message
    MIB cpwVcIndex: 3221225476
    Create time: 30/03/2021 16:30:58 (21:31:00 ago)
    Last time status changed: 30/03/2021 16:36:42 (21:25:16 ago)
    Statistics:
      packets: received 38448, sent 186
      bytes: received 2614356, sent 12644

In VLAN mode, each VLAN on a customer-end to provider-end link can be configured as a separate L2VPN connection using virtual connection (VC) type 4. In VLAN mode, each VLAN on a customer-end to provider-end link can be configured as a separate L2VPN connection using virtual connection (VC) type 4. VLAN-based (VC Type 4) pseudowires ensure a VLAN tag is transported over the pseudowire by pushing a dummy tag at the attachment circuit ingress. If the rewrite rule pushes two or more tags, a dummy tag is not needed because these VLAN tags are transported over the pseudowire. On the remote router, the dummy tag, if added, is removed before egress.

As illustrated in the following figure, the Ethernet PE associates an internal VLAN tag to the Ethernet port for switching the traffic internally from the ingress port to the pseudowire; however, before moving traffic into the pseudowire, it removes the internal VLAN tag.

At the egress VLAN PE, the PE associates a VLAN tag to the frames coming out of the pseudowire, and after switching the traffic internally, it sends out the traffic on an Ethernet trunk port.

Note	Because the port is in trunk mode, the VLAN PE doesn't remove the VLAN tag and forwards the frames through the port with the added tag.

Router# configure
Router(config)# l2vpn
Router(config-l2vpn)# pw-class VLAN
Router(config-l2vpn-pwc)# encapsulation mpls
Router(config-l2vpn-pwc-mpls)# transport-mode vlan
Router(config-l2vpn-pwc-mpls)# exit
Router(config-l2vpn-pwc)# exit
Router(config-l2vpn)# xconnect group grp1
Router(config-l2vpn-xc)# p2p xc1
Router(config-l2vpn-xc-p2p)# neighbor 10.0.0.11 pw-id 222
Router(config-l2vpn-xc-p2p-pw)# pw-class VLAN
Router(config-l2vpn-xc-p2p-pw)# commit

l2vpn
 pw-class VLAN
  encapsulation mpls
   transport-mode vlan
  !
 !
 xconnect group grp1
  p2p xc1
   neighbor 10.0.0.11 pw-id 222
    pw-class VLAN
   !
  !
 !
!

Router# show l2vpn xconnect group grp1 detail | i " PW type"
PW type Ethernet VLAN, control word disabled, interworking none
      PW type      Ethernet VLAN                  Ethernet VLAN

Configure the transport mode vlan passthrough command under the pw-class to negotiate a virtual connection (VC)-type 4 (Ethernet VLAN) PW, which transports whatever comes out of the AC after the VLAN tag manipulation specified by the rewrite command.The VLAN tag manipulation on the EFP ensures that there is at least one VLAN tag left on the frame because you need a VLAN tag on the frame if there are VC-type 4 PWs. No dummy tag 0 is added to the frame when you use the transport mode vlan passthrough command.

The Pseudowire Redundancy feature allows you to configure a redundant pseudowire that backs up the primary pseudowire. When the primary pseudowire fails, the PE router switches to the redundant pseudowire. You can elect to have the primary pseudowire resume operation after it becomes functional. The primary pseudowire fails when the PE router fails or when there is a network outage.

An autonomous system (AS) is a single network or group of networks that is controlled by a common system administration group and uses a single, clearly defined routing protocol.

As VPNs grow, their requirements expand. In some cases, VPNs need to reside on different autonomous systems in different geographic areas. In addition, some VPNs need to extend across multiple service providers (overlapping VPNs). Regardless of the complexity and location of the VPNs, the connection between autonomous systems must be seamless.

EoMPLS supports a single AS topology where the pseudowire connecting the PE routers at the two ends of the point-to-point EoMPLS cross-connects resides in the same autonomous system; or multiple AS topologies in which PE routers can reside on two different ASs using iBGP and eBGP peering.

The following figure illustrates MPLS over Inter-AS with a basic double AS topology with iBGP/LDP in each AS.

There are two types of traffic flow involved in the PWHE interfaces.

• PWHE Decapsulation/Disposition Flow: On traffic flowing from access side to core, PWHE ingress features would be executed on the PWHE Access facing Line card.

• PWHE Encapsulation/Imposition Flow: On traffic flowing from core to access side, PWHE egress features would be executed on the PWHE Access facing Line card.

A generic interface list (GIL) is a list of physical or bundle interfaces used in a PWHE connection.

The GIL supports only main interfaces, and not subinterfaces. The GIL is bi-directional and restricts both receive and transmit interfaces on access-facing line cards. The GIL has no impact on the core-facing side.

A GIL is used to limit the resources allocated for a PWHE interface to the set of interfaces specified in the list.

Only the S-PE is aware of the GIL and expects that the PWHE packets arrive on only line cards with GIL members on it. If packets arrive at the line card without GIL members on it, they are dropped.

• The following are not supported on PWHE

  • ISIS as IGP for access core

  • PW classVC label 4

  • Segment Routing Traffic Engineering (SR-TE) in the access core for Layer 2 VPN

  • TE tunnel as preferred path in access core for Layer 2 VPN

  • Traffic with Internet Mix (IMIX)

  • The commands load-balancing flow src-dst-ip and flow-label both

  • PWHE load balancing by VC label or by Flow-Aware Transport (FAT)

  • EVPN mulithoming mode

  • PWHE MTU

• The load balancing hashing is done only by PWHE link numbers.

• When a packet arrives at PWHE Layer 3 subinterface, the software aggregate count is done on PWHE main interface.

• It is recommended not to use mixed-mode Egress Traffic Management (ETM), a combination of ETM and non-ETM members in a GIL.

• It is recommended not to use the ECMP path list as a superset of GIL interfaces.

• If you have configured other features like QoS and ACL on GIL, they are applicable as follows:

  • For PWHE traffic received on GIL, all the features configured on the PWHE interface are applicable.

  • For other traffic received on GIL, all the features configured on the GIL interface are applicable.

• You can attach ACL in PWHE interface for both ingress and egress, for IPv4 and IPv6.

• You can attach hybrid-ACL (Level 2) in PWHE interface for only ingress, for IPv4 and IPv6.

Prerequisites

Consider the following guidelines while configuring PWHE:

• The generic interface list members must be the superset of the ECMP path list to the Access Provider Edge (A-PE).

• Only eight generic interface lists are supported per A-PE neighbor address.

• Eight Layer 3 links per generic interface list are supported.

• Only PW-Ether interfaces can be configured as PWHE L2 or L3 subinterfaces.

• Cross-connects that contain PW-Ether main interfaces can be configured as VC-type 5.

• PW-Ether interfaces and subinterfaces can be configured with both IPv4 and IPv6. To encapsulate and transport IPv4 or IPv6 frames over a pseudowire, the packet-switched network must be capable of routing IPv4 and IPv6 packets.

• Pseudowire redundancy, preferred path, local switching or L2TP are not supported for cross-connects configured with PWHE.

• The TE and LDP applications work on physical interfaces and therefore do not allow PWHE configuration.

• Address family, CDP, and MPLS configurations are not allowed on PWHE interfaces.

• For PWHE, eBGP, static routes, OSPF, and ISIS are supported with both IPv4 and IPv6. Routing Information Protocol (RIP) is only supported with IPv4 and not with IPv6.

• You must attach a different generic interface list for PW-Ether interfaces with different remote neighbors. Hence, you must create a separate and dedicated generic interface list for each remote neighbor or peer whose remote neighbors are different routers or devices. For example, a unique generic interface list needs to be configured for each Access Provider Edge that the Access Provider Edge peers with. The generic interface list may have the same set of outgoing interfaces.

/* Configure L2 interface */
Router(config)# interface hundredGigE 0/1/0/3
Router(config-if)# l2transport
Router(config-if-l2)# root

/* Configure PWHE cross-connect */

Router(config)# l2vpn
Router(config-l2vpn)# pw-class pwhe_port_vc5
Router(config-l2vpn-pwc)# encapsulation mpls
Router(config-l2vpn-pwc-mpls)# exit
Router(config-l2vpn-pwc)# exit
Router(config-l2vpn)# xconnect group pw-he
Router(config-l2vpn-xc)# p2p pw-ether1
Router(config-l2vpn-xc-p2p)# interface hundredGigE 0/1/0/3
Router(config-l2vpn-xc-p2p-pw)# neighbor ipv4 10.1.1.1 pw-id 6
Router(config-l2vpn-xc-p2p-pw)# pw-class pwhe_port_vc5
Router(config-l2vpn-xc-p2p-pw)# commit
 

/* Create GIL */
Router(config)# generic-interface-list txlist
Router(config-gen-if-list)# interface hundredGigE 0/1/0/1
Router(config-gen-if-list)# interface hundredGigE 0/1/0/2
Router(config-gen-if-list)# commit

/* Configure pw-ether interface and attach GIL */
Router(config)# interface pw-ether1
Router(config-if)# ipv4 address 10.1.1.1/24
Router(config-if)# ipv6 address 5000::2/64
Router(config-if)# attach generic-interface-list txlist
Router(config-if)# commit
 

/* Configure cross-connect to include pw-ether interface */
Router(config)# l2vpn
Router(config-l2vpn)# pw-class pwhe_port_vc5
Router(config-l2vpn-pwc)# encapsulation mpls
Router(config-l2vpn-pwc-mpls)# transport-mode ethernet
Router(config-l2vpn-pwc-mpls)# exit      
Router(config-l2vpn-pwc)# exit
Router(config-l2vpn)# xconnect group pw-he
Router(config-l2vpn-xc)# p2p pw-ether1
Router(config-l2vpn-xc-p2p)# interface pw-ether1
Router(config-l2vpn-xc-p2p)# neighbor ipv4 10.2.2.2 pw-id 6
Router(config-l2vpn-xc-p2p-pw)# pw-class pwhe_port_vc5
Router(config-l2vpn-xc-p2p-pw)# commit

L2 Subinterface Configuration

The following example shows how to configure PWHE on L2 subinterface.

A-PE Configuration

Configure L2 subinterface.

/* Configure L2 subinterface */
Router(config)# interface hundredGigE 0/1/0/3.2 l2transport 
Router(config-subif)# encapsulation dot1q 2
Router(config-subif)# rewrite ingress tag pop 1 symmetric

Note	There is no need to configure cross-connect for the subinterface, as the main PWHE interface configuration is applied to the subinterface.

S-PE Configuration

Configure the L2 subinterface and add the subinterface.

/* Configure L2 subinterface */
Router(config)# interface PW-Ether1.2 l2transport
Router(config-subif)# encapsulation dot1q 1
Router(config-subif)# rewrite ingress tag pop 1 symmetric

/* Configure cross-connect and assign the L2 subinterface  */
Router(config)# l2vpn
Router(config-l2vpn)# pw-class pwhe_port_vc5
Router(config-l2vpn-pwc)# encapsulation mpls
Router(config-l2vpn-pwc-mpls)# transport-mode vlan
Router(config-l2vpn-pwc-mpls)# exit
Router(config-l2vpn-pwc)# exit
Router(config-l2vpn)# xconnect group pw-he
Router(config-l2vpn-xc)# p2p pw-ether1
Router(config-l2vpn-xc-p2p)# interface pw-ether1.2
Router(config-l2vpn-xc-p2p)# neighbor ipv4 10.2.2.2 pw-id 6
Router(config-l2vpn-xc-p2p-pw)# pw-class pwhe_port_vc5
Router(config-l2vpn-xc-p2p-pw)# commit

L3 Subinterface Configuration

The following example shows how to configure PWHE on L3 subinterface. Except the A-PE, repeat the other configurations as described for L2 interface.

A-PE Configuration

/* Configure L3 subinterface */
Router(config)# interface pw-ether 1.1
Router(config-subif)# encapsulation dot1q 1
Router(config-subif)# ipv4 address 10.1.1.1/24
Router(config-subif)# commit

Note	There is no need to configure cross-connect for the subinterface, as the main PWHE interface configuration is applied to the subinterface.

/* A-PE Configuration */
interface hundredGigE 0/1/0/3
  l2transport
!
l2vpn
   pw-class pwhe_port_vc5
   encapsulation mpls
  xconnect group pw-he
p2p pw-ether1
interface hundredGigE 0/1/0/3
neighbor ipv4 10.1.1.1 pw-id 6
pw-class pwhe_port_vc5

/* S-PE Configuration */
generic-interface-list txlist
  interface hundredGigE 0/1/0/1
  interface hundredGigE 0/1/0/2
!
interface PW-Ether1
  ipv4 address 10.1.1.1/24
  ipv6 address 5000::2/64
  attach generic-interface-list txlist
!
l2vpn
  pw-class pwhe_port_vc5
     encapsulation mpls
      transport-mode ethernet
  xconnect group pw-he
     p2p pw-ether1
       interface PW-Ether1
       neighbor ipv4 10.2.2.2 pw-id 6
         pw-class pwhe_port_vc5

/* A-PE Configuration for L2 Subinterface */
interface hundredGigE 0/1/0/3.2 l2transport
   encapsulation dot1q 2
   rewrite ingress tag pop 1 symmetric 

/* S-PE Configuration for L2 Subinterface */
l2vpn
    pw-class pwhe_port_vc5
        encapsulation mpls
        transport-mode vlan
    !
    xconnect group pw-he
        p2p pw-ether1
            interface pw-ether1.2
            neighbor ipv4 10.2.2.2 pw-id 6    
            pw-class pwhe_port_vc5
    

/* A-PE Configuration for L3 subinterface */
interface pw-ether 1.1
    encapsulation dot1q 1
    ipv4 address 10.1.1.1/24

Router# show generic-interface-list idb name txlist

GIL name: txlist, ifhandle: 0xf000014
  State: Down Immediate
  Members:
    HundredGigE0/1/0/2
    HundredGigE0/1/0/1

Router# show l2vpn xconnect group pw-he xc-name pw-ether1
Mon Mar 11 21:26:48.281 EDT
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed,
LU = Local Up, RU = Remote Up, CO = Connected, (SI) = Seamless Inactive

XConnect                  Segment 1       Segment 2
Group     Name        ST  Description ST Description              ST
------------------------ ----------------------------- -----------------------------
pw-he pw-ether1       UP PE1          UP EVPN 1,1,102.102.102.102 UP
----------------------------------------------------------------------------------------

Router# show l2vpn pwhe interface pw-ether 1 detail

Interface: PW-Ether1 Interface State: Up, Admin state: Up
Interface handle 0xf000054
MTU: 1514
BW: 10000 Kbit
Interface MAC addresses: 1859.f57d.0008
Label: 24041
Internal ID: None
L2-overhead: 0
VC-type: 5
CW: Y
Hash: 0xf5f5 [Success]

The Cisco 8000 load balances traffic when it is either not VLAN tagged or tagged with VLAN in supported formats.

The router performs load balancing on outgoing interfaces and bundle members in these scenarios:

1. Ethernet frames entering from a L2 main or sub interface may be

   • switched out to another L2 interface that is part of a bundle, or

   • routed out to L3 interfaces with MPLS encapsulation.

2. MPLS labeled PW and EVPN traffic entering from an L3 interface. After label disposition, the customer Ethernet frames may be

   • switched out to an L2 main or sub interface that is part of a bundle, or

   • routed out to L3 interfaces with MPLS encapsulation.

The router parses packets to identify the required headers for generating a load balance hash, which determines the path to route the traffic across the network. The hashing process varies based on whether the traffic is received on L2 or L3 interfaces.

For load balance hash on traffic received from L2 interfaces, refer to Hash for Traffic Received on L2 Interface.

For load balance hash on traffic received from L3 interfaces, refer to Hash for Traffic Received on L3 Interface.

The router performs BUM Traffic load balancing on outgoing interfaces and bundle members in these scenarios:

• Sending Traffic to an L2 Interface on bundle

• Sending Traffic over an MPLS PW

• Sending Traffic to EVPN MPLS Network

Sending Traffic to an L2 Interface on Bundle

When sending traffic to a L2 interface, the router does not perform load balancing over bundle members. Instead, it pins all traffic sent to an L2 main or sub-interface to a single bundle member. The selection of the bundle member is based on the main or sub-interface ID.

Sending Traffic over an MPLS PW

When BUM traffic is routed to an MPLS PW, the traffic is routed out to L3 interfaces. The router performs ECMP and bundle load balancing on the PW traffic. The hashing for load balancing is based on:

• PW VC label and flow label

• The 12 bytes of the PW payload. If control word (CW) is enabled, this includes a combination of 4 bytes of CW and 8 bytes of inner Ethernet MAC address.

Sending Traffic to EVPN MPLS Network

When BUM traffic is routed to an EVPN MPLS network, the traffic is encapsulated with:

• EVPN label

• ETREE leaf label or Ethernet Segment split horizon label

The MPLS encapsulated traffic is routed out to L3 interfaces. ECMP and bundle load balancing are performed on the EVPN MPLS encapsulated traffic. The hashing for load balancing is based on:

• EVPN label

• ETREE leaf label or Ethernet Segment split horizon label

• The 12 bytes of the PW payload. If CW is enabled, this includes a combination of 4 bytes of CW and 8 bytes of inner Ethernet MAC address.

In certain configurations, you may choose to disable the non-IP hash mode. When non-IP hash mode is disabled, the Ethernet MAC address of BUM traffic isn’t used to perform load balance hashing. This can impact how BUM traffic is distributed across the network, as the router relies on other available headers for hashing.

For traffic received on a L2 interface, hashing depends on the headers present in the packet stack. The router generates the load balance hash using the designated fields based on the packet stack headers.

When ethernet frames entering a L2 main or sub interface, the router identifies the IP header within the packet based on the packet stack headers. The router uses these packet stack headers to generate the hash for traffic received on the L2 interface.

IP Traffic on L2 Interface

An ethernet frame is classified as IP traffic if it meets the following requirements:

• The ethernet header contains no more than two VLAN tags.

• The ethernet header either has no VLAN tag or has VLAN tags in a supported format as listed in Supported VLAN Tag Formats for Load Balancing.

• No more than ten MPLS labels are placed in front of the IP header.

Non-IP Traffic on L2 Interface

All traffic that does not meet the description of IP traffic on L2 Interface is classified as non-IP traffic on L2 interface.

L2 Hash Fields

The L2 hash fields include the source and destination MAC addresses and the outer VLAN ID.

L3 Hash Fields

The L3 hash fields include the source and destination IP addresses and the source and destination ports of the layer 4 header.

IP Traffic Load Balancing

1. On Q100 and Q200 based Silicon One ASIC:

   Before Release 24.2.1, L2 hash fields were used in hashing. L3 hash fields were also included for limited traffic types.

   Starting from the Release 24.2.1, both L2 and L3 fields are used in hashing for all IP traffic.

2. On P100 and A100 based Silicon One ASIC:

   L2 hash fields are used in hashing. L3 hash fields are also included for limited traffic types.

Non-IP Traffic Load Balancing

Non-IP traffic on the L2 interface is load balanced using L2 hash fields.

If any of the designated fields are missing, the router replaces those field values with zeros.

For traffic received on a L3 interface hashing depends on several criteria, including the headers present in the packet stack and whether the Control Word (CW) and Flow Label (FL) are enabled on the pseudowire (PW).

When ethernet frames entering a L3 interface, the router identifies the IP header within the packet based on the packet stack headers.

IP over PW Traffic

An ethernet frame is classified as IP over PW traffic if it meets the following criteria:

• The frame contains an outer ethernet header and an inner ethernet header.

• No more than two MPLS labels are placed between the outer ethernet header and the inner ethernet header.

• There is no control word in front of the inner ethernet header.

• The inner ethernet header contains no more than two VLAN tags.

• The inner ethernet header has no VLAN tag or has VLAN tags in supported format as listed in Supported VLAN Tag Formats for Load Balancing.

• Behind the inner ethernet header, there are no more than ten MPLS labels placed in front of the IP header.

Non-IP over PW Traffic

All traffic that does not meet the IP over PW traffic criteria is classified as non-IP over PW traffic.

Inner Ethernet L2 Hash Fields

The inner ethernet L2 hash fields include the source and destination MAC addresses, and the first VLAN tag of the inner ethernet frame.

Inner Ethernet L3 Hash Fields

The inner ethernet L3 hash fields include L3 and L4 headers in the inner ethernet frame. They are source and destination IP addresses, the source and destination ports of the layer 4 header.

Control Word Presence L2 Hash Fields

The 12 bytes of the PW payload, which include 4 bytes of CW followed by the 8 bytes of inner ethernet frame MAC address.

MPLS Hash Fields of Outer Ethernet Frame

All MPLS labels in front of inner ethernet header.

PW Disposition Traffic Load Balancing

1. PW disposition traffic load balance when control word and flow label are both disabled.

   IP over PW Traffic Load Balancing

   1. On Q100 and Q200 based Silicon One ASIC:

      IP over PW traffic load balance hash uses the inner ethernet L2 hash fields.

      Before Release 24.2.1, inner ethernet L3 hash fields are also added in the hashing for limited types of traffic.

      Starting from Release 24.2.1, both inner ethernet L2 hash fields and inner ethernet L3 hash fields are used in hashing.

   2. On P100 and A100 based Silicon One ASIC:

      IP over PW traffic load balance hash uses the inner ethernet L2 hash fields. Inner ethernet L3 hash fields are also added in the hashing for limited types of traffic.

   Non-IP over PW Traffic Load Balancing

   Non-IP over PW traffic load balance hash always uses the inner ethernet L2 hash fields.

2. PW disposition traffic load balance when control word is enabled and flow label disabled.

   In this case, all PW traffic is non-IP over PW traffic. Load balance hash uses control word presence L2 hash fields.

3. PW disposition traffic load balance when control word is disabled and flow label enabled.

   1. On Q100 and Q200 based Silicon One ASIC:

      IP over PW Traffic Load Balancing

      IP over PW traffic load balancing hash uses the following fields:

      • Before Release 24.2.1, hash uses the inner ethernet L2 hash fields. Inner ethernet L3 hash fields are also added in the hashing for limited types of traffic.

      • In Release 24.2.1, inner ethernet L2 hash fields and inner ethernet L3 hash fields are both used in hashing.

      • Starting from Release 24.3.1, inner ethernet L3 hash fields and MPLS hash fields of outer ethernet frame are used in hashing.

      Non-IP over PW Traffic Load Balancing

      Before Release 24.3.1, Non-IP over PW traffic load balance hash uses the inner ethernet L2 hash fields.

      Starting from Release 24.3.1 release, MPLS hash fields of outer ethernet frame are used in hashing.

   2. On P100 and A100 based Silicon One ASIC:

      IP over PW Traffic Load Balancing

      IP over PW traffic load balance hash uses the following fields:

      • Before Release 24.3.1, hash uses the inner ethernet L2 hash fields. Inner ethernet L3 hash fields are also added in the hashing for limited types of traffic.

      • Starting from Release 24.3.1, hash uses MPLS hash fields of outer ethernet frame. Inner ethernet L3 hash fields are also added in the hashing for limited types of traffic.

      Non-IP over PW Traffic Load Balancing

      Before Release 24.3.1, Non-IP over PW traffic load balance hash uses the inner ethernet L2 hash fields.

      Starting from Release 24.3.1 release, MPLS hash fields of outer ethernet frame are used in hashing.

4. PW disposition traffic load balance when control word and flow label are both enabled.

   In this case, all PW traffic is Non-IP over PW traffic.

   Before Release 24.3.1, Non-IP over PW traffic load balance hash uses the control word presence L2 hash fields.

   Starting from Release 24.3.1, MPLS hash fields of outer ethernet frame are used in hashing.

Each Ethernet ring node is connected to adjacent Ethernet ring nodes participating in the Ethernet ring using two independent links. A ring link never allows the formation of loops that affect the network. The Ethernet ring uses a specific link to protect the entire Ethernet ring. This specific link is called the ring protection link (RPL). A ring link is bound by two adjacent Ethernet ring nodes and a port for a ring link (also known as a ring port).

Note	The minimum number of Ethernet ring nodes in an Ethernet ring is two.

The fundamentals of ring protection switching are:

• The principle of loop avoidance

• The utilization of learning, forwarding, and Filtering Database (FDB) mechanisms

Loop avoidance in an Ethernet ring is achieved by ensuring that, at any time, traffic flows on all but one of the ring links which is the RPL. Multiple nodes are used to form a ring:

• RPL owner - It’s responsible for blocking traffic over the RPL so that no loops are formed in the Ethernet traffic. There can be only one RPL owner in a ring.

• RPL neighbor node - The RPL neighbor node is an Ethernet ring node next to the RPL. It's responsible for blocking its end of the RPL under normal conditions. This node type is optional and prevents RPL usage when protected.

• RPL next-neighbor node - The RPL next-neighbor node is an Ethernet ring node next to the RPL owner node or RPL neighbor node. It's used for FDB flush optimization on the ring. This node is also optional.

The following figure illustrates the G.8032 Ethernet ring.

Nodes on the ring use control messages called RAPS to coordinate the activities of switching on or off the RPL link. Any failure along the ring triggers a RAPS signal fail (RAPS SF) message along both directions, from the nodes next to the failed link, after the nodes have blocked the port facing the failed link. On obtaining this message, the RPL owner unblocks the RPL port.

Note	A single link failure in the ring ensures a loop-free topology.

Line status and Connectivity Fault Management protocols are used to detect ring link and node failure. During the recovery phase, when the failed link is restored, the nodes next to the restored link send RAPS no request (RAPS NR) messages. On obtaining this message, the RPL owner blocks the RPL port and sends RAPS no request, root blocked (RAPS NR, RB) messages. This causes all other nodes, other than the RPL owner in the ring, to unblock all blocked ports. The ERPS protocol is robust enough to work for both unidirectional failure and multiple link failure scenarios in a ring topology.

A G.8032 ring supports these basic operator administrative commands:

• Force switch (FS) - Allows the operator to forcefully block a particular ring-port.

  • Effective even if there’s an existing SF condition.

  • Multiple FS commands for ring supported.

  • May be used to allow immediate maintenance operations.

• Manual switch (MS) - Allows the operator to manually block a particular ring-port.

  • Ineffective in an existing FS or SF condition.

  • Overridden by new FS or SF conditions.

  • Multiple MS commands cancel all MS commands.

• Clear - Cancels an existing FS or MS command on the ring-port.

  • Used (at RPL Owner) to clear non-revertive mode.

A G.8032 ring can support multiple instances. An instance is a logical ring running over a physical ring. Such instances are used for various reasons, such as load balancing VLANs over a ring. For example, odd VLANs may go in one direction of the ring, and even VLANs may go in the other direction. Specific VLANs can be configured under only one instance. They cannot overlap multiple instances. Otherwise, data traffic or RAPS packets can cross logical rings, and that isn't desirable.

G.8032 ERPS provides a new technology that relies on line status and Connectivity Fault Management (CFM) to detect link failure. By running CFM Continuity Check Messages (CCM) messages at an interval of 100ms, it's possible to achieve SONET-like switching time performance and loop free traffic.

For more information about Ethernet Connectivity Fault Management (CFM) and Ethernet Fault Detection (EFD) configuration, refer to the Configuring Ethernet OAM on the Cisco 8000 Series Router module in the Cisco 8000 Series Router Component Configuration Guide.

Protection Switching during Single Link Failure

The following example describes the protection switching process during a single link failure:

For example, consider the Protection Switching during G.8032 Single Link Failure figure with the following configuration:

• An ethernet ring is composed of seven ethernet ring nodes (A to G) with node ID (81, 26, 89, 62, 71, 31, and 75) and port ID (0 and 1).

• The ethernet ring node A is the RPL neighbor node.

• The ethernet ring node G is the RPL owner node.

• The RPL is the ring link between ethernet ring nodes A and G.

• Traffic is blocked at both ends of the RPL.

The ERPS performs the following protection switching steps during a single link failure:

1. The link operates in the normal condition.

2. A failure occurs between ring nodes C and D.

3. Ethernet ring nodes C and D detect a local signal failure (SF) condition and after the holdoff time interval, block the failed ring port and perform the forwarding database (FDB) flush.

4. Ethernet ring nodes C and D start sending ring automatic protection switching (RAPS) (SF) messages periodically along with the node ID and Blocked Port Ring (BPR) pair on both ring ports, while the SF condition persists.

   For example, ring node C sends the SF(89,1) message, which consists of node ID 89 and BPR 1.

5. All Ethernet ring nodes receiving an RAPS (SF) message perform FDB flush. When the RPL owner node G and RPL neighbor node A receive an RAPS (SF) message, the Ethernet ring node unblocks its end of the RPL and performs the FDB flush.

6. All Ethernet ring nodes receiving a second RAPS (SF) message perform the FDB flush again; this is because of the Node ID and BPR-based mechanism.

7. Stable SF condition—RAPS (SF) messages on the Ethernet Ring. Further RAPS (SF) messages trigger no further action.

Recovery from Single Link Failure

The following example describes the single link failure recovery process:

For example, consider the Single link failure Recovery (Revertive operation) figure with the following configuration:

• An ethernet ring is composed of seven ethernet ring nodes (A to G) with node ID (81, 26, 89, 62, 71, 31, and 75) and port ID (0 and 1).

• The ethernet ring node A is the RPL neighbor node.

• The ethernet ring node G is the RPL owner node.

• The RPL is the ring link between ethernet ring nodes A and G.

• Traffic is blocked at both ends of the RPL.

The ERPS performs the following reversion steps to revertive the link during a single link failure:

1. A failure occurs between ring nodes C and D.

2. Recovery of link failure occurs between ring nodes C and D.

3. Ethernet ring nodes C and D detect clearing of SF condition, start the guard timer and initiate periodical transmission of RAPS No Request (NR) messages on both ring ports.

   Note	The guard timer prevents the reception of RAPS messages.

4. When the Ethernet ring nodes receive an RAPS (NR) message, the node ID and BPR pair of a receiving ring port is deleted and the RPL owner node starts the WTR timer.

5. When the guard timer expires on ethernet ring nodes C and D, they may accept the new RAPS messages that they receive. Ethernet ring node D receives an RAPS (NR) message with higher Node ID from ethernet ring node C, and unblocks its non-failed ring port.

6. When the WTR timer expires, the RPL owner node blocks its end of the RPL, sends the RAPS (NR, RB) message with the node ID and BPR pair, and performs the FDB flush.

7. When Ethernet ring node C receives an RAPS (NR, RB) message, it removes the block on its blocked ring ports, and stops sending RAPS (NR) messages. On the other hand, when the RPL neighbor node A receives an RAPS (NR, RB) message, it blocks its end of the RPL. In addition to this, Ethernet ring nodes A to F perform the FDB flush when receiving an RAPS (NR, RB) message, due to the existence of the Node ID and BPR based mechanism.

8. Link operates in the stable SF condition.

• You must not configure G.8032 ERPS and CFM down-mep on the same sub-interface. If you enable it, then the router displays a syslog message, as shown in the following example:

  Router# configure
  Router(config)# l2vpn
  Router(config-l2vpn)# ethernet ring g8032 test
  Router(config-l2vpn-erp)# port0 interface FourHundredGigE0/0/0/6
  Router(config-l2vpn-erp)# port1 interface FourHundredGigE0/0/0/10
  Router(config-l2vpn-erp)# instance 1
  Router(config-l2vpn-erp-inst)# profile test
  Router(config-l2vpn-erp-inst)# rpl port0 owner
  Router(config-l2vpn-erp-inst)# inclusion-list vlan-ids 1,100
  Router(config-l2vpn-erp-inst)# aps-channel
  Router(config-l2vpn-erp-inst-aps)# port0 interface FourHundredGigE0/0/0/6.1
  Router(config-l2vpn-erp-inst-aps)# port1 interface FourHundredGigE0/0/0/10.1
  
  Router(config)# interface FourHundredGigE0/0/0/6.1 l2transport
  Router(config-if)# encapsulation dot1q 1
  Router(config-if)# ethernet cfm
  Router(config-if-cfm)# mep domain domain1 service link1 mep-id 2
  
  %PLATFORM-SPITFIRE_CFM-3-G8032_VIOLATION : G8032 has been configured for interface FourHundredGigE0/0/0/6.1
  where CFM configuration exists. G8032 config is disabled.

  Instead configure the CFM down-mep on the main interface and configure the G.8032 ERPS on the sub-interface.

• Linecards and fixed routers with Q100 and Q200 based Silicon One ASICs don't support G.8032 Ethernet Ring Protection Switching.

To configure the G.8032 operation, you have to configure ERPS and CFM separately as follows:

• Configure the ERPS profile, ERPS instance, ERPS paramenters, and TCN propagation by including the following requirements:

  • Designate a (sub)interface which is used as the APS channel.

  • Designate a (sub)interface which is monitored by CFM.

  • Verify whether the interface is an RPL link, and, if it is a RPL link then indicate the RPL node type.

  For more information, see the following sections:

  • Configuring ERPS Profile

  • Configuring an ERPS Instance

  • Configuring ERPS Parameters

  • Configuring TCN Propagation

• Configure CFM with EFD to monitor the ring links. For more information, see the Configuring CFM MEP.

Note	MEP for each monitor link needs to be configured with different Maintenance Association.

• The bridge domains to create the Layer 2 topology. The RAPS channel is configured in a dedicated management bridge domain separated from the data bridge domains.

• Behavior characteristics, that apply to ERPS instance, if different from default values. This is optional.

This section provides information on: