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.
All other registered trademarks, trademarks, and service marks are property of their respective owners.
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
Author:
Chad
Smith
Ethernet
Ring
Protection
Switching
version
1
(G.8032v1)
with
ExtremeXOS
Effective
Date:
11/1/2012
Page
4
of
56
©
2012
Extreme
Networks,
Inc.
All
rights
reserved.
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.
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.
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.
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.
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.
Author:
Chad
Smith
Ethernet
Ring
Protection
Switching
version
1
(G.8032v1)
with
ExtremeXOS
Effective
Date:
11/1/2012
Page
15
of
56
©
2012
Extreme
Networks,
Inc.
All
rights
reserved.
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.
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.
Author:
Chad
Smith
Ethernet
Ring
Protection
Switching
version
1
(G.8032v1)
with
ExtremeXOS
Effective
Date:
11/1/2012
Page
17
of
56
©
2012
Extreme
Networks,
Inc.
All
rights
reserved.
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.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
i) VLAN
Configuration
ii) ERPS
Configuration
(Ring
Port
&
Control/Protected
VLAN
designation)
iii) ERPS
Ring
Timers
Configuration
d) E4G_200
Configuration
i) VLAN
Configuration
ii) ERPS
Configuration
(Ring
Port
&
Control/Protected
VLAN
designation)
iii) ERPS
Ring
Timers
Configuration
e) X670_2
Configuration
i) VLAN
Configuration
ii) ERPS
Configuration
(Ring
Port
&
Control/Protected
VLAN
designation)
iii) ERPS
Ring
Timers
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.
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
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.
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.
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.
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
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:
X670_1.7 # show erps
This
is
verified
by
issuing
the
show erps “ring1”
command:
X670_1.8 # show erps "Ring1"
Name: Ring1
Operational State: Protection Node Type: RPL Owner, Revertive
Configured State : Enabled
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
Configured State : Enabled
Name: Ring1
Operational State: Protection Node Type: Non-RPL Owner
Configured State : Enabled
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.
X670_1.11 # show erps
After
a
5
second
wait
time,
the
show erps
command
is
issued
again.
X670_1.11 # show erps
Name: Ring1
Operational State: Idle Node Type: RPL Owner, Revertive
Configured State : Enabled
With
the
ring
restored
to
Idle
state,
X670_2
and
E4G_200
should
have
unblocked
the
previously
failed
ports:
X670_2.2 # show erps "Ring1"
Name: Ring1
Operational State: Idle Node Type: Non-RPL Owner
Configured State : Enabled
Name: Ring1
Operational State: Idle Node Type: Non-RPL Owner
Configured State : Enabled
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
Port Sent Received Discarded Blocked Unblocked Failed Recovered
====================================================================================
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
Port Sent Received Discarded Blocked Unblocked Failed Recovered
====================================================================================
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.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
configure vlan ERPS_C add ports 1, 17 tagged
configure vlan ERPS_P add ports 1, 17 tagged
#
# Module erps configuration.
#
enable erps
create erps Ring1
configure erps Ring1 add control vlan ERPS_C
configure erps Ring1 ring-port east 1
configure erps Ring1 ring-port west 17
configure erps Ring1 protection-port 1
configure erps Ring1 timer wait-to-restore 5000
configure erps Ring1 timer periodic 2000
configure erps Ring1 timer guard 100
enable erps Ring1
configure erps Ring1 add protected vlan ERPS_P
11.2 E4G_400
#
# Module devmgr configuration.
#
configure snmp sysName "E4G_400"
#
# Module vlan configuration.
#
configure vlan default delete ports all
configure vr VR-Default delete ports 1-34
configure vr VR-Default add ports 1-34
configure vlan default delete ports 1-34
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 duplex full
configure vlan ERPS_C add ports 25-26 tagged
configure vlan ERPS_P add ports 25-26 tagged
configure vlan ERPS_P add ports 1 untagged
#
# Module erps configuration.
#
enable erps
create erps Ring1
configure erps Ring1 add control vlan ERPS_C
configure erps Ring1 ring-port east 26
configure erps Ring1 ring-port west 25
configure erps Ring1 timer wait-to-restore 5000
configure erps Ring1 timer periodic 2000
configure erps Ring1 timer guard 100
configure erps Ring1 add protected vlan ERPS_P
11.3 E4G_200
#
# Module devmgr configuration.
#
configure snmp sysName "E4G_200"
#
# Module vlan configuration.
#
configure vlan default delete ports all
configure vr VR-Default delete ports 1-12
configure vr VR-Default add ports 1-12
configure vlan default delete ports 1-12
create vlan "ERPS_C"
configure vlan ERPS_C tag 11
create vlan "ERPS_P"
configure vlan ERPS_P tag 10
configure vlan ERPS_C add ports 11-12 tagged
configure vlan ERPS_P add ports 11-12 tagged
#
# Module erps configuration.
#
enable erps
create erps Ring1
configure erps Ring1 add control vlan ERPS_C
configure erps Ring1 ring-port east 11
configure erps Ring1 ring-port west 12
configure erps Ring1 timer wait-to-restore 5000
configure erps Ring1 timer periodic 2000
configure erps Ring1 timer guard 100
enable erps Ring1
configure erps Ring1 add protected vlan ERPS_P
11.4 X670_2
#
# Module devmgr configuration.
#
configure snmp sysName "X670_2"
#
# 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
configure vlan ERPS_C add ports 1, 17 tagged
configure vlan ERPS_P add ports 1, 17 tagged
configure vlan ERPS_P add ports 2 untagged
#
# Module erps configuration.
#
enable erps
create erps Ring1
configure erps Ring1 add control vlan ERPS_C
configure erps Ring1 ring-port east 17
configure erps Ring1 ring-port west 1
configure erps Ring1 timer wait-to-restore 5000
configure erps Ring1 timer periodic 2000
configure erps Ring1 timer guard 100
enable erps Ring1
configure erps Ring1 add protected vlan ERPS_P