SVC Tech MB Tech Guide - ERPSv1 (G.8032v1) v1

Services Technology Office

Mobile Backhaul
Ethernet Rings
Technology Guide:
Ethernet Ring Protection Switching (G.8032v1) with ExtremeXOS
Author: Chad Smith

Abstract

The Ethernet Ring Protection Switching (ERPS) protocol is an industry standard
(G.8032/Y.1344), vendor-‐agnostic ring protection protocol. There are currently two
versions of the ERPS protocol available – ERPSv1 and ERPSv2.

ERPSv1 is limited to a single Ethernet ring topology. ERPSv2 introduces many new
features such as support for multiple rings, a “revertive” failover mode, and support for
multiple ERPS instances on the same physical ring. This document will introduce ERPS in
its simplest form – the ERPSv1 single ring format.

The goal of ERPS is to establish an Ethernet ring topology that provides both redundancy
and fast failover times in the event of a ring failure. Since ERPS (also referred to by its
ITU-‐T standard names G.8032/Y.1344) is a vendor-‐agnostic protocol, it’s supported by a
large ecosystem of Ethernet networking vendors; therefore, it is well suited for mixed-‐
vendor environments.

This document will provide both a brief overview of the ERPS protocol and a detailed
building-‐block example of how to configure it within ExtremeXOS. More specifically, the
example will demonstrate how to configure the most basic ERPS ring (i.e. no sub-‐rings,
and no CFM Connectivity Check Messages) using only ExtremeXOS switches.

Author: Chad Smith Ethernet Ring Protection Switching version 1

(G.8032v1) with ExtremeXOS

Effective Date: 11/1/2012 Page 1 of 56

© 2012 Extreme Networks, Inc. All rights reserved.

REVISION HISTORY

Date Version Revision Description Author
10/22/2012 00.00.01 Initial Draft Chad Smith
10/26/2012 00.00.02 Initial Review Ryan Mathews
10/30/2012 00.01.02 Approve Edits Chad Smith
10/31/2012 00.02.02 Grammatical/Technical Review Denis Korobov
10/31/2012 1 Approve v1 Chad Smith

Extreme Networks, Inc.
AccessAdapt, Alpine, Altitude, BlackDiamond, Direct Attach, EPICenter, ExtremeWorks Essentials, Ethernet
Everywhere, Extreme Enabled, Extreme Ethernet Everywhere, Extreme Networks, Extreme Standby Router
Protocol, Extreme Turbodrive, Extreme Velocity, ExtremeWare, ExtremeWorks, ExtremeXOS, Go Purple Extreme
Solution, ExtremeXOS ScreenPlay, ReachNXT, Ridgeline, Sentriant, ServiceWatch, Summit, SummitStack, Triumph,
Unified Access Architecture, Unified Access RF Manager, UniStack, XNV, the Extreme Networks logo, the Alpine
logo, the BlackDiamond logo, the Extreme Turbodrive logo, the Summit logos, and the Powered by ExtremeXOS
logo are trademarks or registered trademarks of Extreme Networks, Inc. or its subsidiaries in the United States
and/or other countries.
sFlow is the property of InMon Corporation.

Specifications are subject to change without notice.
All other registered trademarks, trademarks, and service marks are property of their respective owners.




TABLE OF CONTENTS

Table of Contents

1. Introduction .................................................................................................................... 4
2. ERPS Overview ................................................................................................................. 6
2.1 ERPS Terminology ................................................................................................................... 7
2.2 General Operation and Example Scenario ............................................................................... 8
2.3 ERPS R-‐APS Message Frames ................................................................................................ 12
2.4 ERPS R-‐APS Messaging ......................................................................................................... 14
2.4.1 No Request (NR) RPL Blocked ............................................................................................... 15
2.4.2 Signal Fail (SF) ....................................................................................................................... 17
2.5 ERPSv1 Timers ...................................................................................................................... 18
2.6 Summary .............................................................................................................................. 19
3. Hardware Requirements ................................................................................................ 20
4. Software Requirements ................................................................................................. 20
5. Network Topology ......................................................................................................... 21
6. General Approach .......................................................................................................... 22
7. ExtremeXOS Configuration ............................................................................................ 23
7.1 670_1 Configuration ............................................................................................................. 24
7.2 E4G_400 Configuration ......................................................................................................... 29
7.3 E4G_200 Configuration ......................................................................................................... 32
7.4 X670_2 Configuration ........................................................................................................... 33
8. Solution Validation ........................................................................................................ 34
8.1 IXIA Setup ............................................................................................................................ 35
8.2 Link Failure Simulation ......................................................................................................... 36
9. Summary ....................................................................................................................... 51
10. References .................................................................................................................. 52
11. Appendix A: Switch Configurations .............................................................................. 53





1. Introduction

This technology guide will provide a brief overview of the Ethernet Ring Protection Switching
(ERPS) protocol and an example of how to configure it within ExtremeXOS. More specifically,
the example will demonstrate how to configure a single ERPSv1 ring without CFM Connectivity
Check Messages (CCM). Its ring features a Layer-‐2 Ethernet topology comprised of only
ExtremeXOS switches.

What is ERPS? “Ethernet Ring Protection Switching, or ERPS, is an effort at ITU-‐T under G.8032
Recommendation to provide sub-‐50ms protection and recovery switching for Ethernet traffic in
a ring topology and at the same time ensuring that there are no loops formed at the Ethernet
layer. G.8032v1 supported a single ring topology and G.8032v2 supports multiple rings/ladder
topology.”1

Extreme Networks has been championing Ethernet rings since 2003 with the advent of Ethernet
Automatic Protection Switching or EAPS (RFC 36192). A word of caution is required here
regarding EAPS vs. ERPS comparisons: the two technologies are not the same. Beyond their
basic Ethernet ring topology, EAPS and ERPS should be considered separate and distinct. Their
building blocks, terminology, and ExtremeXOS implementations are entirely distinct. This is
analogous to comparing OSPF and IS-‐IS. Both are link-‐state routing protocols, but are unique
solutions. Due diligence should be applied when selecting your ring protection mechanism for
future deployments. From this point forward, the focus of this document will be exclusively on
ERPS.

The goal of ERPS is to establish an Ethernet topology that provides both redundancy and fast
failover times. Since ERPS is a vendor-‐agnostic protocol, it is supported by a large ecosystem of
Ethernet networking vendors; therefore, it is well suited for mixed-‐vendor environments.

1
http://en.wikipedia.org/wiki/Ethernet_Ring_Protection_Switching
2
http://tools.ietf.org/html/rfc3619



The ERPS protocol uses “CFM R-‐APS” messages to transmit information to the ring nodes and
alert node members of link failures, etc. ERPS (both v1 and v2) can also be integrated with CFM
Connectivity Check Messages (CCM) to speed detection of link failures and improve ring failover
times. This guide will use only R-‐APS messaging. ERPS with CFM CCM is beyond the scope of
this document.

There are currently two versions of the ERPS protocol available – ERPSv1 and ERPSv2. ERPSv1 is
limited to a single ring. ERPSv2 introduces many new features, such as support for multiple
rings, a “revertive” failover mode, and support for multiple ERPS instances on the same physical
ring. This document will introduce ERPS in its simplest form – the ERPSv1 single ring format.




2. ERPS Overview

ERPS (G.8032) is a standardized ring protection switching protocol. The ultimate goal is to
provide Layer-‐2 redundancy and resiliency via a ring-‐based networking architecture. The ring
offers designers fast recovery during failure scenarios. Ring protection protocols usually have
some common components. Those include:

1) Master node: controls the ring and blocks/unblocks one of its ports based on ring status
2) Control messaging system: transports link and ring status throughout the ring
3) Timers: measures status of devices on ring and triggers actions

ERPS has all of these components.

1) ERPS Master node: Remote Protection Link (RPL) Owner
2) ERPS Control messaging system: the R-‐APS frame transports ERPS control messages
3) ERPS Timers: multiple timers that can be customized to improve performance and
influence ERPS behavior during ring failure conditions

Each of these components will be explained in further detail below. First, some general ERPS
terms must be introduced and defined.





2.1 ERPS Terminology

To orient the terminology discussion, please refer to the simple Ethernet ring below:

Ring Name: The name of the ERPS ring (i.e. “Ring1”).

ERPS Node: Network device in the physical ring participating in the ERPS operation.

Remote Protection Link (RPL): The link that under normal operation is blocked to
prevent a network loop across the ERPS ring.

RPL Owner: The ERPS Node containing the RPL. This node acts as the master of the
ring, blocking/unblocking the RPL port based on the status of the ring.

East Port: One of two ports on an ERPS node that are participating in the ring. East
ports should be connected to the west port of the adjacent ERPS node.

West Port: One of two ports on an ERPS node that are participating in the ring. West
ports should be connected to the East port of the adjacent ERPS node.





Control VLAN: The VLAN that transports the R-‐APS control messages across the ring.
This Control VLAN should be dedicated to this purpose.

Protected/Data VLAN: A data/user VLAN on the ring.

Ring Automatic Protection Switching (R-‐APS) Frame: The frame used to transmit
control messages around the ring.

2.2 General Operation and Example Scenario

In ERPSv1, there are three possible ring states: Idle, Pending, and Protection.

When a ring is in the Idle state there are no signal failure (SF) conditions present and the
RPL is blocked. When a ring is in the Protection state there has been a signal failure
condition (link failure) and the RPL port has been unblocked. When the ERPS ring is in
the Pending state, the signal failure condition has been cleared and the RPL Owner is
waiting for the wait-‐to-‐restore timer to expire.

The following section will walk through the actions performed by the ERPS ring during a
link failure and restoration. In terms of ERPS states the ring will go from Idle to
Protection to Pending to Idle.





Observe the following ERPS ring. Under normal operation (no signal failures present)
the RPL will be blocked and the RPL Owner will send out a periodic R-‐APS No Request
(NR) message. This NR message would indicate the RPL is blocked. The normal
operating state is referred to as the Idle state:

If a link failure were to occur between Node 3 and Node 4, both nodes would block their
failed ports and send out an R-‐APS Signal Fail (SF) message out of their operational port:





Upon reception of the R-‐APS (SF) each node flushes its forwarding database (FDB).
Once the RPL Owner receives the Signal Fail, it unblocks the RPL. Node 3 and 4 would
continue to send out SF messages. The state of the ring would transition into the
Protection state:





Once Node 3 and Node 4 detect that the link has been restored, they begin sending R-‐
APS NR messages. When the RPL Owner receives these messages it waits the period of
the wait-‐to-‐restore timer and then blocks the RPL. Once blocked, the RPL Owner starts
sending out R-‐APS NR messages indicating that the RPL is blocked. When Node 3 and 4
receive these messages they unblock their ports. All nodes flush their forwarding
databases and the ring again enters the Idle state:

With the ring entering the Idle state, the ring is up and functioning normally again.

When looking at the graphics above this may seem like a time consuming process.
However, when a change in the ring is detected, an R-‐APS frame is sent out very quickly
(~3.3ms). This results in fast recovery times. Ideally, the ring should enter the
Protection state in less than 50ms. Similarly, the transition from Protection to Idle
should also occur in less than 50ms.

(Note: Many factors contribute to the recovery time of the actual traffic on a
ring. Some limiting factors include transport medium (fiber is faster than
copper), routing protocols, and network architecture.)

This was a very simple example, but it highlights the operational behaviors of Ethernet
Ring Protection Switching. Now we’ll dig in a little deeper into the mechanics of the
control messaging system from an Ethernet frame perspective.




2.3 ERPS R-‐APS Message Frames

In the operational example above, it is clear that R-‐APS messages play a key role in the
G.8032 protocol. After all, R-‐APS messages are the communication medium for all ERPS
control traffic.

It is important (especially in troubleshooting scenarios) to be able to recognize the
different types of R-‐APS messages sent across the ERPS ring and understand why they
are sent.





First, let’s observe the R-‐APS Frame itself (captured from Wireshark):

Without even looking inside the CFM PDU there are four key things to make note of:

1. Destination Address: All ERPS R-‐APS frames have a multicast destination address of
01:19:A7:00:00:01.
2. Frame Type: R-‐APS messages are a subtype of CFM (Connectivity Fault Management)
Frames.
3. CFM Operation Code: The CFM Operation Code of R-‐APS frames is 40 (decimal). This is
useful when filtering captures that contain multiple types of CFM traffic.
4. CFM PDU: The CFM PDU contains all messaging and status information about the ERPS
ring. The internals of the PDU will be explored below.




2.4 ERPS R-‐APS Messaging

There are two ERPSv1 R-‐APS messages: No Request and Signal Fail.

Each of these will be explained below.




2.4.1 No Request (NR) RPL Blocked

The image below is a Wireshark capture of an R-‐APS No Request message.

There are two major things to notice in this capture.

1. Request/State Field: This field in the CFM PDU is where the Message type is
determined. In this capture it can be seen that the type is No Request.
2. RPL Blocked Field: This field indicates whether or not the RPL should be blocked. In
this case it is blocked.




In this frame the source MAC address is the RPL Owner. Knowing that, it could be
inferred that this ring is in the Idle state, as there is currently no signal failure and the
RPL is blocked.

No Request frames can also be sent by non-‐RPL owners to indicate that a signal failure
condition has been cleared. In this case the RPL would not be blocked.





2.4.2 Signal Fail (SF)

The image below is a Wireshark capture of an R-‐APS Signal Failure message.

Again, there are two major things to notice in this capture.

1. Request/State Field: This field in the CFM PDU is where the Message type is
determined. In this capture it can be seen that the type is Signal Failure.
2. RPL Blocked Field: This field indicates whether or not the RPL should be blocked. In
this case it is not blocked.




In this frame, the source MAC address is a non-‐RPL Owner ERPS node. Knowing this, it
could be inferred that this ring is in the Protection state as there is currently a signal failure
being reported by this node and the RPL is not blocked.

2.5 ERPSv1 Timers

There are four timers that are important to ERPSv1 operation.

Brief explanations of each of these timers are listed below.

Wait-‐To-‐Restore Timer: This timer specifies the amount of time the RPL Owner will
wait before blocking the RPL after a signal failure has been restored. Shifting the ring
back to its normal topology after a failure is a disruptive task, as the FDB of each node in
the ring has to be flushed. Therefore, it may sometimes be wise to wait a period of time
to either ensure that the link failure has been fully resolved or to simply stagger the
disruptions. This timer starts when the RPL Owner receives an R-‐APS No Request
message from an ERPS node that has just restored a Signal Failure. When this timer
expires the RPL owner blocks the RPL and sends an R-‐APS No Request message. When
the nodes that experienced the signal failure receive this message, they unblock their
ports and the ring resumes normal Idle operation.

Guard Timer: R-‐APS messages, like all other frames, are not sent instantaneously
around the ring. Therefore, it is possible that an ERPS node could receive outdated R-‐
APS messages. The guard timer specifies the amount of time a node waits after
receiving an R-‐APS before taking an action. This timer should always be greater than the
amount of time it takes for an R-‐APS message to traverse the entire ring.

Periodic Timer: The periodic timer is the frequency that R-‐APS messages, such as No
Request and Signal Failure, are re-‐sent around the ring.

Hold-‐off Timer: The hold-‐off timer is the amount of time a node waits before
determining there is a fault. In some situations the device itself may be able to correct
the fault in a timely enough fashion that a ring state change isn’t necessary. In
ExtremeXOS the hold-‐off timer is set to zero by default. Faults are reported to the ring
immediately.





2.6 Summary

ERPS (G.8032) is a standardized ring protection switching protocol. It is important to
understand the concepts, standard operational behavior, terminology, and calibration of
the ERPS’ master node, control messaging system and timers before deploying it. These are
the key building blocks of the solution.

In this brief overview, each ERPS solution components were outlined and key take away(s)
presented as follows:

1) ERPS Master node: Remote Protection Link (RPL) Owner
2) ERPS Control messaging system: the R-‐APS frame transports ERPS control messages
3) ERPS Timers: multiple timers that can be customized to improve performance and
influence ERPS behavior during ring failure conditions

Now it’s time for a simple ERPSv1 deployment scenario to bring home the discussion.




3. Hardware Requirements

Ethernet Ring Protection Switching is supported on all ExtremeXOS hardware platforms except
BlackDiamond 10800 switches, BlackDiamond 12800 series switches, and BlackDiamond 20800
series switches.

Hardware equipment used in this Technology Guide are as follows:

• Two X670-‐48x ExtremeXOS Switches
• One E4G-‐200 ExtremeXOS Switch
• One E4G-‐400 ExtremeXOS Switch
• Ixia or other Traffic Generator (for Validation)

4. Software Requirements

Ethernet Ring Protection Switching was introduced in to ExtremeXOS during the 15.1 release.

ExtremeXOS 15.2.1.5 is used in this guide.





5. Network Topology

Four ExtremeXOS-‐powered switches (i.e. named respectively: X670_1, X670_2, E4G_200, and
E4G_400) are connected and arranged in a ring topology.

Each of the switches will be configured with two VLANs. Those VLANs are ERPS_C – the ERPS
control VLAN, and ERPS_P – the ERPS protected VLAN.

ERPS_C will be added tagged to all ERPS ring ports. ERPS_P will be added tagged to all ring
ports and untagged to port 2 of X670_2 and port 1 of E4G_400. These ports are connected to
an IXIA that will be used in the validation segment.

The RPL and East and West ring ports are as specified in the diagram above. The X670s are
connected by an 8 port 10GbE link aggregation group. All other ports are 1G.





6. General Approach

1) ExtremeXOS Configuration

a) Physical Setup & Assumptions
i) Cabling has been arranged as specified in the network topology
ii) All ports have been deleted from the Default VLAN
iii) All 1GbE ports on the Summit X670s have been set correctly (i.e. auto
negotiation, port speed, and duplex) and ports are enabled and active.
iv) Port sharing has been enabled for the link aggregation port group between
X670_1 and X670_2.
b) X670_1 Configuration
i) VLAN Configuration
ii) ERPS Configuration (Ring Port & Control/Protected VLAN designation)
iii) ERPS Ring Timers Configuration
c) E4G_400 Configuration
d) E4G_200 Configuration
e) X670_2 Configuration

2) Solution Validation

a) Traffic Generator (IXIA) Setup
b) Link Failure Simulation





7. ExtremeXOS Configuration

The ExtremeXOS ERPSv1 configuration can be broken down into three major steps.

1) VLAN Configuration
2) ERPS Configuration (Ring Port & Control/Protected VLAN designation)
3) ERPS Ring Timers Configuration

The configuration procedure for each of the four switches participating in the ERPS ring will be
provided in the sections below. Some basic configuration assumptions are made:

• All physical cabling has been arranged as specified in the network topology
• All ports have been deleted from the Default VLAN
• All 1GbE ports on the Summit X670s have been set correctly (i.e. auto negotiation,
port speed, and duplex) and ports are enabled and active.
• Port sharing has been enabled for the link aggregation port group between X670_1
and X670_2.





7.1 670_1 Configuration

Each ERPSv1 Ring has a node that contains the Ring Protection Link (RPL). (NOTE: This
node is similar to an EAPS master node.) The RPL is the link that is blocked under
normal operation.

In this guide X670_1 contains the RPL. Therefore, this switch will be configured first.
7.1.1 VLAN Configuration

Before the ring can be deployed, the VLANs that are participating in the ring must exist.
The G.8032v1 protocol requires a control VLAN to transport the ERPS messages around
the ring. Along with the control VLAN, protected VLANs must be provisioned to carry
the user traffic.

In this example there will only be two VLANs – a control VLAN and a protected VLAN.
Each VLAN is named ERPS_C and ERPS_P respectively.

An explanation of basic VLAN configuration is beyond the scope of this document.
However, the required commands for X670_1 are provided below:

# ERPS_C VLAN Configuration
create vlan ERPS_C tag 11
configure vlan ERPS_C add ports 1, 17 tagged
# ERPS_P VLAN Configuration

create vlan ERPS_P tag 10
configure vlan ERPS_P add ports 1, 17 tagged





7.1.2 ERPS Configuration (Ring Port & Control/Protected VLAN designation)
When configuring ERPS, the first step is to create the ring (in this example, Ring1)

The ring is created with the create erps <Ring Name> command:

create erps Ring1
Next, the ERPS control VLAN must be configured. This is provisioned by issuing the
command configure erps <Ring Name> add control vlan <Control
VLAN> command. In this example the control VLAN is ERPS_C:
configure erps Ring1 add control vlan ERPS_C

Now, all protected VLANs must be added to the ring. This is done via the configure
erps <Ring Name> add protected vlan <Protected VLAN> command.
In this example there is only one protected VLAN (ERPS_P), thus making the command:
configure erps Ring1 add protected vlan ERPS_P
Each ERPS node in a ring contains two ring ports. These ring ports must be specified in
the ExtremeXOS configuration. The ERPS protocol also differentiates the two ports by
designating one port as the “East” port and the other as the “West” port.

To define the East port the command configure erps <Ring Name> ring-
port east <Port Number> command is used. In this example the east port on
X670_1 will be defined as port 1:
configure erps Ring1 ring-port east 1

To define the west port, the command configure erps <Ring Name> ring-
port west <Port Number> command is used. In this example port 17 will be
defined as the west port:
configure erps Ring1 ring-port west 17




Next, since X670_1 contains the Remote Protection Link (RPL), the RPL port must be
configured. This is performed using the configure erps <Ring Name>
protection-port <Port Number> command. Port 1 will be configured as the
RPL:
configure erps Ring1 protection-port 1

Finally, with the configuration of this node completed, ERPS must be enabled both
globally and on Ring1. The command to enable ERPS globally is simply enable erps.
To enable a specific ERPS ring, the command is enable erps <Ring Name>.
These two commands should be issued on the switch:
enable erps
enable erps Ring1
This completes the basic ERPS configuration on X670_1.




7.1.3 ERPS Ring Timers Configuration
ERPS has many timers that can be configured to improve/customize failover
performance. In this example, some of the timers have been changed from their default
values for learning purposes.

The first timer that was changed was the wait-‐to-‐restore timer. Once a ring failure
condition has been corrected, this timer determines how long to wait before restoring
the ring back to its normal operation (RPL blocked). Real world values for this timer
depend on many factors. The timer may be set to a large value to prevent frequent
transitions in the ring. Alternatively, it could be set to a short time period because the
RPL link may be a less preferential path for traffic across the ring (lower bandwidth etc.)

By default, the wait-‐to-‐restore timer is set to 300,000ms (i.e. 5 minutes). This timer was
changed to 5,000ms (i.e. 5 s) to speed up the validation section of this document. The
command to set the wait-‐to-‐restore timer is configure erps <Ring Name>
timer wait-to-restore <Time in ms>.

To set Ring1 to a 5,000ms timer the following command is issued:
configure erps Ring1 timer wait-to-restore 5000
The periodic timer was also customized for this demonstration. The default value for
this timer is 5,000ms (i.e. 5 s). The value was changed to 2,000ms (i.e. 2s) to speed up
viewing of ERPS behavior in packet captures. This change was simply for illustrative
purposes.

The command to change this timer is configure erps <Ring Name> timer
periodic <Time in ms>. Using the value of 2,000 makes the command:

configure erps Ring1 timer periodic 2000




The final timer that was changed was the guard timer. The guard timer prevents nodes
from taking action on R-‐APS messages that may be erroneous or out of date. The guard
timer should be set just above the maximum expected time required for an R-‐APS
message to traverse the entire ring. In this example, it will be set to 100ms. The default
value is 500ms.

To change the guard timer the command configure erps <Ring Name>
timer guard <Time in ms> is used. Using the value of 100ms the command
entered on X670_1 is:

configure erps Ring1 timer guard 100

This completes X670_1’s configuration: VLAN, ERPS and ERPS timers.




7.2 E4G_400 Configuration

In this example, there are two groups of switches on the ERPS ring: the RPL and any
switch that is not the RPL. This may not sound like a lot, but it is the difference between
the configuration for X670_1 and the other ExtremeXOS switches.

Since the E4G_400 is not a Root Protection Link Owner, there is no RPL port
configuration. Additionally, the wait-‐to-‐restore timer need not be configured on non-‐
RPL nodes. All other configuration parameters are very similar. The only other
exception being that the E4G_400 uses different Ethernet ports.

The E4G_400 configuration is captured below.

Again, the ERPS_C and ERPS_P VLANs must be created and configured. Ports 25 and 26
need to be added as tagged to both VLANs. Port 1 (connected to the IXIA) should be
added as untagged to ERPS_P. These VLAN configurations commands are provided.

create vlan "ERPS_C" tag 11
configure vlan ERPS_C add ports 25-26 tagged

create vlan "ERPS_P" tag 10
configure vlan ERPS_P add ports 25-26 tagged
configure vlan ERPS_P add ports 1 untagged





As with the X670_1, the first step is to create the ERPS Ring.

create erps Ring1

Next, the control and protected VLANs must be added.


Finally, the east and west ring ports must be set and the ERPS ring enabled. With an
ERPS ring, a port is set as east/west based on the configuration of the port it is
connected to on the adjacent ERPS node. If a port is connected to an east port on the
adjacent node, it should be configured as a west port and vice versa. E4G_400 is
connected to X670_1 port 1 via port 25. Since X670_1 port 1 is an east port, port 25 of
E4G_400 should be a west port. That makes port 26 the east port.

The configuration is as follows:

enable erps
enable erps Ring1





On E4G_400, the periodic and guard timers need to be configured the same as X670_1.
(again, the wait-‐to-‐restore timer is only used by the RPL owner). Since the guard timer
is based off of the time required for an R-‐APS packet to traverse the ring, it should be
the same value on all nodes.

As with X670_1 the guard timer will be set to 100ms. The periodic timer was changed
on X670_1 to speed up the time between R-‐APS messages. The same will be done on
E4G_400 so that signal failure messages are seen more frequently.


This completes the E4G_400 ERPS configuration.




7.3 E4G_200 Configuration

The E4G_200 configuration procedure is nearly identical to the E4G_400 configuration.
Only the port numbers and east/west ring port configuration change. For E4G_200 the
ring ports are 11 and 12. Since Port 12 is connected to port 26 of E4G_400 (east port), it
will be configured as a west port. Port 11 will be an east port.

The E4G_200 commands are listed below.


create erps Ring1

enable erps
enable erps Ring1





7.4 X670_2 Configuration

The X670_2 configuration procedure is also very similar to the E4G_400 setup. Only the
port numbers and east/west ring port configuration change.

For X670_2, the ring ports are 1 and 17. Since port 1 is connected to port 11 of E4G_200
(east port), it will be configured as a west port. Port 17 will be an east port.

The E4G_200 commands are listed below. Additionally, an IXIA is connected to port 2
and will be added as untagged to ERPS_P.

configure vlan ERPS_C add ports 1,17 tagged

configure vlan ERPS_P add ports 1,17 tagged
create erps Ring1

enable erps
enable erps Ring1


This completes the ERPS ring configuration.




8. Solution Validation

Once deployed, the ERPS protocol can easily go unnoticed – running in the background,
seemingly doing very little. It’s when disaster strikes (link failure occurs) that the value of an
ERPS solution can truly be illustrated.

To validate this ERPSv1 setup, a link failure and restoration will be simulated. As a result, the
ERPS solution will transition from an Idle state to Protected to Pending and back again to Idle.
An IXIA traffic generator will be used to send a constant flow of traffic across the ring and
measure the packet loss during both the link failure and restoration.

During this process, a series of show commands will also be issued on the ring nodes to assess
the status of the ERPS ring during the test.





8.1 IXIA Setup

The two IXIA ports are configured and connected to the network.

Port 4:3 has an IxNetwork protocol interface configured with MAC address
00:00:C0:04:03:02 and IP address 10.0.0.10.

Port 4:10 has an IxNetwork protocol interface configured with MAC address
00:00:C0:04:0A:02 and IP address 10.0.0.11.

The two ports have been configured to send a 1,000 packet-‐per-‐second stream to the IP
address of the other port. They have also been configured in the IXIA as a port statistics
group. The port statistics group will allow transmit and receive traffic statistics for both
ports to be viewed side-‐by-‐side.





8.2 Link Failure Simulation

Once the IXIA ports are transmitting 1,000 pkt/s streams, the link failure test can begin.

To simulate a link failure, the connection between X670_2 an E4G_200 will be physically
disconnected, preceded by the operational status validation of the ERPS ring using a
series of show commands on X670_1 (RPL Owner), starting with the show erps
command:

X670_1.2 # show erps
ERPS Enabled: Yes

ERPS Display Config Warnings: On
ERPS Multicast Add Ring Ports: Off
ERPS Multicast Send IGMP and MLD Query: On
ERPS Multicast Temporary Flooding: Off
ERPS Multicast Temporary Flooding Duration: 15 sec
Number of ERPS instances: 1
# ERPS ring configuration :
-------------------------------------------------------------------------------
-
Ring State Type East West Control-Vlan VID
-------------------------------------------------------------------------------
-
Ring1 Idle R r +1 17 ERPS_C (11 )
-------------------------------------------------------------------------------
-
where State: Init/Idle/Protection/Manual-Switch/Force-Switch/Pending
Type: (I) Interconnected node, (N) RPL Neighbor,
(R) RPL Owner, (X) Ring node
Flags: (n) Non-revertive, (r) Revertive,
(+) RPL Protection Port, (^) RPL Neighbor Port
(f) Force Switch Port, (m) Manual Switch Port

From this output it can be seen that the ERPS ring is enabled (as expected) and is in the
Idle state. Also, the “R” flag in the type field indicates this node is the RPL Owner and
the “+” symbol beside port 1 indicates the RPL port.





Next, the show erps “Ring1” command is issued to gather some additional details
about this specific ring:

X670_1.3 # show erps "Ring1"
Name: Ring1
Operational State: Idle Node Type: RPL Owner, Revertive
Configured State : Enabled
East Ring Port : +1 MepId: 0 Remote MepId: 0 Status: Blocked

West Ring Port : 17 MepId: 0 Remote MepId: 0 Status: Unblocked
Periodic timer interval: 2000 millisec (Enabled)

Hold-off timer interval: 0 millisec (Enabled)
Guard timer interval : 100 millisec (Enabled)
WTB timer interval : 5500 millisec (Enabled)
WTR timer interval : 5000 millisec (Enabled)
Ring MD Level : ----

CCM Interval East : 1000 millisec
CCM Interval West : 1000 millisec
Notify Topology Change : -------
Subring Mode : Virtual Channel
ERPS Control Vlan: ERPS_C VID:11

Topology Change Propogation List: None
Topology Change Propogation : Disabled
ERPS Ring's Sub-Ring(s): None
ERPS Ring has following Protected Vlan(s):
Vlan Name VID
ERPS_P 10
Number of Protected Vlans: 1

The ring state (Idle) is again seen in this output. More importantly, this command lists
the status of each of the ERPS ring ports. Since the ring is in the Idle state, port 1 (RPL)
is blocked and port 17 is unblocked. The ERPS timers can also be validated from this
command. All are as configured.

(Note: The WTB timer or wait-‐to-‐block timer is an ERPSv2 feature and can be
disregarded for the purposes of this setup.)





Next, the show erps “Ring1” statistics command is issued to obtain ring
specific statistics:

(Note: counters were recently cleared to remove any confusion on the statistics
based on previous ERPS transitions.)

X670_1.7 # show erps "Ring1" statistics
Ring RAPS RAPS RAPS
Port Sent Received Discarded Blocked Unblocked Failed Recovered
====================================================================================
1 9 9 0 0 0 0 0
17 9 9 0 0 0 0 0
====================================================================================

For the purposes of this test, the key statistics to observe are the Blocked/Unblocked
and Failed/Recovered counters. Currently, they are at 0. These counters should
increment after the link failure.





As expected, the ERPS ring is operational in the Idle state with no current link failures.
The IXIA port statistics group counters are now cleared:

With the counters cleared, the link between X670_2 and E4G_200 is physically
disconnected.





Shortly after disconnecting the link the port statistics are viewed again:

The key in this test is to compare the frames transmitted by one IXIA port with the
frames received by the other IXIA port. Port 4:3 sent 89,971 frames and 4:10 received
89,926 frames for a difference of 45 frames. Port 4:10 sent 89,965 frames and 4:3
received 89,940 frames for a difference of 25 frames. From these results it can be
inferred that the ERPS failover occurred in the time it took IXIA port 4:3 to send 25
frames and IXIA port 4:10 to send 45 frames. Not too bad!





Now, the status of the ERPS ring must be verified from a network perspective starting
with the show erps command on X670_1:

ERPS Enabled: Yes

-------------------------------------------------------------------------------
-
-------------------------------------------------------------------------------
-
Ring1 Protection R r +1 17 ERPS_C (11 )
-------------------------------------------------------------------------------
-

As expected, this command indicates the ring has transitioned to the Protection state.
When in the Protection state the RPL should be unblocked.





This is verified by issuing the show erps “ring1” command:

Name: Ring1
Operational State: Protection Node Type: RPL Owner, Revertive
East Ring Port : +1 MepId: 0 Remote MepId: 0 Status: Unblocked




Vlan Name VID
ERPS_P 10

The command output indicates that the port is unblocked. The show erps
“Ring1” statistics command should also indicate that port 1 has been
unblocked once.

X670_1.9 # show erps “Ring1” statistics
Ring RAPS RAPS RAPS
====================================================================================
1 714 1174 0 0 1 0 0
17 714 1174 0 0 0 0 0
====================================================================================





When a link failure is detected by ERPS, the nodes identifying the failure block their
ports to prevent a potential loop when the RPL is unblocked. Since the link between
X670_2 and E4G_200 has failed each of their ports should be blocked by ERPS.

The show erps “Ring1” command is now issued on both switches to validate this
behavior.

E4G_200.6 # show erps "Ring1"
Name: Ring1
Operational State: Protection Node Type: Non-RPL Owner
East Ring Port : 11 MepId: 0 Remote MepId: 0 Status: Blocked




Vlan Name VID
ERPS_P 10





Name: Ring1
Operational State: Protection Node Type: Non-RPL Owner
East Ring Port : 17 MepId: 0 Remote MepId: 0 Status: Unblocked

West Ring Port : 1 MepId: 0 Remote MepId: 0 Status: Blocked



Vlan Name VID
ERPS_P 10

Both E4G_400 and X670_2 will also indicate a port failure and port block in the show
erps “Ring1” statistics command.

X670_2.9 # show erps “Ring1” statistics
Ring RAPS RAPS RAPS
====================================================================================
11 717 1177 0 1 0 1 0
12 717 1177 0 0 0 0 0
====================================================================================

E4G_200.10 # show erps “Ring1” statistics
Ring RAPS RAPS RAPS
====================================================================================
17 735 1185 0 0 0 0 0
1 735 1185 0 1 0 1 0
====================================================================================





Conclusion? The ERPS ring has successfully entered the protection state.

The physical link is now reconnected. Remember, that the wait-‐to-‐restore timer is set
to 5 seconds. This means that after the link is restored, the ERPS ring will wait 5 seconds
before reverting back to Idle state. During this 5 second period, the ring will be in the
Pending state. This is validated with the show erps command on X670_1.

ERPS Enabled: Yes

-------------------------------------------------------------------------------
-
-------------------------------------------------------------------------------
-
Ring1 Pending R r +1 17 ERPS_C (11 )
-------------------------------------------------------------------------------
-

As seen above, the ring is in Pending state.





After a 5 second wait time, the show erps command is issued again.

ERPS Enabled: Yes

-------------------------------------------------------------------------------
-
-------------------------------------------------------------------------------
-
Ring1 Idle R r +1 17 ERPS_C (11 )
-------------------------------------------------------------------------------
-

The state has now reverted back to Idle.





The RPL port should now be blocked:

Name: Ring1
Operational State: Idle Node Type: RPL Owner, Revertive
East Ring Port : +1 MepId: 0 Remote MepId: 0 Status: Blocked




ERPS Ring's Protected Vlan(s): Unassigned

Also, the ring statistics Blocked counter for port 1 should have incremented. The RPL
Owner did not experience any link failures so the Failed and Recovered counters should
still be zero:

X670_1.12 # show erps "Ring1" statistics
Ring RAPS RAPS RAPS
====================================================================================
1 790 1523 0 1 1 0 0
17 792 1524 0 0 0 0 0
====================================================================================





With the ring restored to Idle state, X670_2 and E4G_200 should have unblocked the
previously failed ports:

Name: Ring1
Operational State: Idle Node Type: Non-RPL Owner




Vlan Name VID
ERPS_P 10





E4G_200.8 # show erps "Ring1"
Name: Ring1
Operational State: Idle Node Type: Non-RPL Owner




Vlan Name VID
ERPS_P 10





Both inputs indicate that the ports were correctly unblocked. The Unblocked and
Recovered counters on the two recovered ports should have also incremented:

670_2.2 # show erps "Ring1" statistics
Ring RAPS RAPS RAPS
====================================================================================
17 2952 165915 0 0 0 0 0
1 2954 162915 0 1 1 1 1
====================================================================================

E4G_200.8 # show erps "Ring1" statistics
Ring RAPS RAPS RAPS
====================================================================================
11 2941 163003 0 1 1 1 1
12 2943 165852 0 0 0 0 0
====================================================================================

This ERPS ring has now been validated. The ring correctly responded to the link failure
and subsequent link restoration. In the process, it transitioned correctly from the Idle
state to Protection, then to Pending, and finally back to Idle, while blocking and
unblocking ports according to the ERPSv1 standard. Additionally, all these actions
occurred with minimal packet loss and downtime to the network.




9. Summary

This technology guide provides the reader a concise overview of the Ethernet Ring Protection
Standard (G.8032) and illustrates its value in a simple ERPSv1 deployment example using
supported ExtremeXOS switches.

The goal of the ERPS protocol is to establish an Ethernet ring topology that provides both
redundancy and fast failover times in the event of a ring failure. Since ERPS is an industry
standard protocol, it is a good solution for multi-‐vendor environments. This enhances the
flexibility of the ExtremeXOS platform, allowing Extreme Networks hardware to interoperate
with other vendors in Ethernet ring topologies.

Make your network mobile with Ethernet Ring Protection Switching and the ExtremeXOS
platform!




10. References

ExtremeXOS 15.2 Concepts Guide
http://www.extremenetworks.com/libraries/services/EXOS_Concepts_Guide_15.2.pdf

ITU-‐T G.8032: Ethernet Ring Protection Switching
http://www.itu.int/rec/T-‐REC-‐G.8032/en





11. Appendix A: Switch Configurations
11.1 X670_1
#
# Module devmgr configuration.
#
configure snmp sysName "X670_1"
#
# Module vlan configuration.
#
configure vlan default delete ports all
configure vr VR-Default delete ports 1-48
configure vr VR-Default add ports 1-48
configure vlan default delete ports 1-48
create vlan "ERPS_C"
configure vlan ERPS_C tag 11
create vlan "ERPS_P"
configure vlan ERPS_P tag 10
configure ports 1 auto on speed 1000
enable sharing 17 grouping 17-24 algorithm address-based L2
#
# Module erps configuration.
#
enable erps
create erps Ring1
configure erps Ring1 protection-port 1
enable erps Ring1





11.2 E4G_400
#
#
configure snmp sysName "E4G_400"
#
#
configure ports 1 auto on duplex full
#
#
enable erps
create erps Ring1





11.3 E4G_200
#
#
configure snmp sysName "E4G_200"
#
#
#
#
enable erps
create erps Ring1
enable erps Ring1





11.4 X670_2
#
#
configure snmp sysName "X670_2"
#
#
configure ports 1 auto on speed 1000
enable sharing 17 grouping 17-24 algorithm address-based L2
#
#
enable erps
create erps Ring1
enable erps Ring1




SVC Tech MB Tech Guide - ERPSv1 (G.8032v1) v1

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SVC Tech MB Tech Guide - ERPSv1 (G.8032v1) v1

Caricato da

Copyright:

Formati disponibili

Services Technology Office

Author: Chad Smith Ethernet Ring Protection Switching version 1

sFlow is the property of InMon Corporation.

Author: Chad Smith Ethernet Ring Protection Switching version 1

TABLE OF CONTENTS

Table of Contents

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

2.1 ERPS Terminology

Author: Chad Smith Ethernet Ring Protection Switching version 1

2.2 General Operation and Example Scenario

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

2.3 ERPS R-­‐APS Message Frames

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

2.4 ERPS R-­‐APS Messaging

Author: Chad Smith Ethernet Ring Protection Switching version 1

2.4.1 No Request (NR) RPL Blocked

Author: Chad Smith Ethernet Ring Protection Switching version 1

2.4.2 Signal Fail (SF)

2.5 ERPSv1 Timers

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.1 670_1 Configuration

7.1.1 VLAN Configuration

# ERPS_P VLAN Configuration

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.1.2 ERPS Configuration (Ring Port & Control/Protected VLAN designation)

Author: Chad Smith Ethernet Ring Protection Switching version 1

This completes the basic ERPS configuration on X670_1.

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.1.3 ERPS Ring Timers Configuration

Author: Chad Smith Ethernet Ring Protection Switching version 1

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.2 E4G_400 Configuration

7.2.1 VLAN Configuration

# ERPS_P VLAN Configuration

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.2.2 ERPS Configuration (Ring Port & Control/Protected VLAN designation)

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.2.3 ERPS Ring Timers Configuration

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.3 E4G_200 Configuration

7.3.1 VLAN Configuration

# ERPS_C VLAN Configuration

# ERPS_P VLAN Configuration

7.3.2 ERPS Configuration (Ring Port & Control/Protected VLAN designation)

create erps Ring1

7.3.3 ERPS Ring Timers Configuration

configure erps Ring1 timer guard 100

Author: Chad Smith Ethernet Ring Protection Switching version 1

7.4 X670_2 Configuration

7.4.1 VLAN Configuration

# ERPS_C VLAN Configuration

# ERPS_P VLAN Configuration

7.4.2 ERPS Configuration (Ring Port & Control/Protected VLAN designation)

2.3 ERPS R-‐APS Message Frames

2.4 ERPS R-‐APS Messaging