Ethernet Ring Protection Switching (ERPS) over a bridge domain is a network feature that allows the implementation of ring protection in Ethernet networks using bridge domains. ERPS, a protocol specified by ITU-T G.8032, is designed to provide fast and seamless protection switching in ring topologies to ensure network availability. Previously, all ERPS instances were mapped to a single bridge domain. It is now possible to map different flooding domains with ERPS instances.

Network Resilience: ERPS enhances network resiliency by creating a ring topology, where traffic can be rerouted in case of a link or node failure, ensuring uninterrupted connectivity.

Faster Traffic Switchover: In case of a link or node failure within the ring, ERPS ensures rapid traffic switchover to the backup path, minimizing service disruptions.

Before configuring ERPS over bridge-domains, ensure the following prerequisites are met:

The major ring is the primary ring in an ERPS configuration. It carries the traffic under normal operating conditions. When no failure occurs, traffic flows through the major ring.

Figure 1 illustrates a sample Ring Protection topology in which protection switching is configured using four bridges. The Ring Protection Link (RPL) owner is the link between Bridge 3 and Bridge 4 (xe16), with Bridge 4 explicitly defined as the RPL owner and Bridge 3 as the RPL neighbor on one side of the link. The other bridges are explicitly configured as RPL non-owners to enable Ethernet Ring Protection Switching (ERPS) within the ring.

In configuration mode, enable the following hardware-profile commands related to CFM and then reboot the nodes:

The following steps provide a detailed configuration of commands for setting up ERPS and CFM on Bridge1, Bridge2, Bridge3, and Bridge4 nodes. These commands enable the creation of rings, maintenance associations, Maintenance End Points (MEPs), and various parameters to ensure network reliability and protection against faults.

The following details provide validation for the G.8032 ERPS configuration on Bridge1, Bridge2, Bridge3, and Bridge4.

The associate-ring is a newly introduced command for supporting ERPS within a bridge-domain. This command is used when there is a need to establish a single ERPS instance that can manage multiple rings. It is essential that all rings associated with the associate-ring share the same parent interface as the primary ring linked to the ERPS instance. For more details, refer to the associate-ring command section.

Before using the associate-ring command, it is necessary to configure the major ring for Bridge1, Bridge2, Bridge3, and Bridge4 as described in the Major Ring Configuration section.

The following validation output displays data traffic details for ERP instances and provides details for the specified ERP instance using the show g8032 erp-instance data-traffic command on Bridge1, Bridge2, Bridge3, and Bridge4.

An Ethernet ring connects to a Major Ring at the interconnection nodes. The Sub-Ring, by itself, does not constitute a closed ring. It connects to the interconnection nodes on only one port, which is configured as the east-interface.

Figure 2 displays a sample Ring Protection topology with five bridges, consisting of one major ring (Bridge1, Bridge2, Bridge3, and Bridge4) and one sub-ring (Bridge5, Bridge1, and Bridge2). In the major ring, the RPL is enabled between Bridge 3 (owner node) and Bridge 4 (neighbor node) on the xe16 interface, while other devices are non-owner nodes for that ring. In the sub-ring, the RPL is enabled between Bridge 5 (neighbor node) and Bridge 4 (owner node) on link xe7, with other devices as non-owner nodes. A virtual channel is enabled for this Sub-Ring on interconnected nodes on VLAN 100, and TCN propagation is also enabled.

Before configuring the sub-ring with virtual channel, it is necessary to configure the major ring for Bridge1, Bridge2, Bridge3, and Bridge4 as described in the Major Ring Configuration section.

The following validation output displays details for the specified ERP instance using the show g8032 erp-instance command on Bridge5, Bridge1, and Bridge4. It describes the sub-ring type for Bridge1 and Bridge4 as virtual. Additionally, it specifies that Bridge1 is a non-owner node, while Bridge4 is the owner node for the specified ERPS ring, designating the east interface as the neighbor node in the ring.

The following section presents a sample Ring Protection topology, demonstrating the configuration of protection switching with five bridges.

Figure 3 illustrates a sample Ethernet Ring Protection Switching topology. This scenario consists of one major ring, which includes Bridge1, Bridge2, Bridge3, and Bridge4, and one sub-ring involving Bridge5, Bridge1, and Bridge2.

In the major ring, RPL is enabled between Bridge 3 (the owner node) and Bridge 4 (the neighbor node) through interface xe16. The remaining devices within this major ring are non-owner nodes. For the sub-ring, RPL is enabled between Bridge 5 (the neighbor node) and Bridge 4 (the owner node) using link xe7, while the other devices in this sub-ring function as non-owner nodes.

The following validation output displays details for the specified ERP instance using the show g8032 erp-instance command on Bridge5, Bridge1, and Bridge4. It describes the sub-ring type for Bridge1 and Bridge4 as non-virtual. Additionally, it specifies that Bridge1 is a non-owner node, while Bridge4 is the owner node for the specified ERPS ring, designating the east interface as the neighbor node in the ring.

We explore deploying Ethernet LAN (ELAN) services using a bridge domain and leveraging ERPS to enhance network resilience and accelerate traffic switchover.

ELAN services find common applications in data centers and enterprise networks, facilitating connectivity among multiple endpoints. A bridge domain serves as a logical segment where these services are extended and managed.

In a data center network, multiple access switches are connected to aggregation switches forming a ring topology using bridge domains. The data center operator wants to implement fast protection switching to ensure uninterrupted connectivity for critical services in case of link or node failures.

Use Case: The data center network can achieve network resiliency by configuring ERPS over the bridge domains. In the event of a link failure on one of the ring ports, ERPS will automatically redirect traffic through the backup path, maintaining service continuity and minimizing downtime.

A campus LAN network is designed with redundant links between distribution switches using bridge domains. The network administrators want to implement ring protection to ensure reliable communication between buildings and minimize service disruptions in case of link failures.

Use Case: The campus LAN network can achieve seamless switchover during link failures by deploying ERPS over the bridge domains connecting the distribution switches. ERPS will detect the failure and swiftly switch traffic to the backup link, ensuring continuous connectivity for users and devices.

An industrial automation network uses a redundant ring topology with bridge domains to connect various industrial devices and controllers. The network operator requires a solution to achieve rapid network recovery in case of link or node failures.

Use Case: The network operator can achieve seamless switchover during link or node failures by configuring ERPS over the bridge domains in the industrial automation network. ERPS will provide fast protection switching, reducing downtime and ensuring continuous operation of critical industrial processes.

The ERPS with CFM Down-MEP over Bridge-Domain introduces the following configuration commands.

Use this command to configure a single ERPS instance to monitor multiple rings. All the rings associated with the associate-ring command must share the same parent interface as the primary ring mapped to the ERPS instance.

None

G.8032 configure switch mode

This command was introduced in OcNOS version 6.4.1.

Here is a sample example of configuring a G.8032 ERP instance and associate ring in OcNOS device.

Use this command to enable failover for the logical interface (LIF) resources, optimizing ERPS hardware failover ID.

Use the no parameter of this command to disable failover for the LIF resources.

None

None

Configure mode.

This command was introduced in OcNOS version 6.4.1.

Below are examples of configuring hardware profiles for ACL interface (aclif) with and without failover in OcNOS device.

Use this command to enable failover for the logical interface (LIF) resources, enhancing the LIFs hardware profile for ERPS.

Use the no parameter of this command to disable failover for the LIF resources, providing control over individual LIFs.

None

None

Interface mode.

This command was introduced in OcNOS version 6.4.1.

Below are sample examples of configuring ACL interface (aclif) with and without failover on interface xe2 in OcNOS device.

Below is the revised command for configuring ERPS with Bridge-Domain. For more details, refer G.8032 ERPS Version 2 Commands chapter in the Carrier Ethernet Guide, Release 6.4.1.

In some scenarios, ERPS may encounter conflicts with VXLAN configurations, leading to issues with traffic forwarding. These conflicts primarily arise due to resource conflicts in the hardware for wide LIF data. This section provides insights into identifying and resolving such conflicts.

When VXLAN is used in conjunction with ERPS, traffic forwarding for xConnects configured in specific scenarios, such as Qumran2 series platform, may fail.

ERPS optimizations, particularly those related to hardware failover IDs (hw-failover-id), can conflict with VXLAN bridge configurations and VXLAN xConnects, causing VXLAN-related functionalities to stop working as expected. The conflict arises due to resource contention in the hardware, particularly when dealing with wide LIFs data.

To address these conflicts and provide granular control over resource usage, a new CLI commands hardware-profile aclif failover and aclif failover has been introduced. This command allows users to enable or disable the hardware-aclif-failover feature for failover on LIFs.

The following are some key abbreviations and their meanings relevant to this document:

The following provides definitions for key terms used throughout this document.