HP A5120 EI Series User manual

HP A5120 EI Switch Series
High Availability
Configuration Guide
Abstract
This document describes the software features for the HP A Series products and guides you through the
software configuration procedures. These configuration guides also provide configuration examples to
help you apply software features to different network scenarios.
This documentation is intended for network planners, field technical support and servicing engineers, and
network administrators working with the HP A Series products.
Part number: 5998-1785
Software version: Release 2208
Document version: 5W100-20110530

Legal and notice information
© Copyright 2011 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

iii
Contents
High availability overview·············································································································································· 1
Availability requirements··················································································································································1
Availability evaluation······················································································································································1
High availability technologies ·········································································································································2
Fault detection technologies····································································································································2
Protection switchover technologies·························································································································3
Ethernet OAM configuration ·········································································································································· 4
Ethernet OAM overview···················································································································································4
Background·······························································································································································4
Major functions of Ethernet OAM ··························································································································4
Ethernet OAMPDUs··················································································································································4
How Ethernet OAM works ······································································································································5
Protocols and Standards··········································································································································8
Ethernet OAM configuration task list ······························································································································8
Configuring basic Ethernet OAM functions ···················································································································8
Configuring the Ethernet OAM connection detection timers························································································9
Configuring link monitoring ·············································································································································9
Configuring errored symbol event detection······································································································ 10
Configuring errored frame event detection ········································································································ 10
Configuring errored frame period event detection···························································································· 10
Configuring errored frame seconds event detection ························································································· 11
Configuring OAM remote loopback···························································································································· 11
Enabling Ethernet OAM remote loopback ········································································································· 11
Rejecting the Ethernet OAM remote loopback request from a remote port ···················································· 12
Displaying and maintaining Ethernet OAM configuration ························································································ 12
Ethernet OAM configuration example························································································································· 13
CFD configuration··························································································································································16
Overview········································································································································································· 16
Basic concepts in CFD ·········································································································································· 16
CFD functions························································································································································· 18
Protocols and standards ······································································································································· 20
CFD configuration task list ············································································································································ 20
Configuring basic CFD settings ···································································································································· 21
Enabling CFD························································································································································· 21
Configuring the CFD protocol version ················································································································ 21
Configuring service instances ······························································································································ 21
Configuring MEPs·················································································································································· 22
Configuring MIP generation rules························································································································ 23
Configuring CFD functions············································································································································ 24
Configuration prerequisites ·································································································································· 24
Configuring CC on MEPs ····································································································································· 24
Configuring LB on MEPs ······································································································································· 25
Configuring LT on MEPs ······································································································································· 25
Configuring AIS····················································································································································· 26
Configuring LM······················································································································································ 26
Configuring one-way DM····································································································································· 27
Configuring two-way DM ····································································································································· 27
Configuring TST····················································································································································· 27

iv
Displaying and maintaining CFD ································································································································· 28
CFD configuration example ·········································································································································· 29
DLDP configuration ························································································································································35
Overview········································································································································································· 35
Background···························································································································································· 35
How DLDP works··················································································································································· 36
DLDP configuration task list··········································································································································· 41
Enabling DLDP································································································································································ 42
Setting DLDP mode························································································································································· 43
Setting the interval for sending advertisement packets ······························································································ 43
Setting the DelayDown timer ········································································································································ 43
Setting the port shutdown mode··································································································································· 44
Configuring DLDP authentication ································································································································· 44
Resetting DLDP state······················································································································································· 45
Displaying and maintaining DLDP································································································································ 46
DLDP configuration examples ······································································································································· 46
Automatically shutting down unidirectional links······························································································· 46
Manually shutting down unidirectional links ······································································································ 50
Troubleshooting DLDP···················································································································································· 53
RRPP configuration·························································································································································54
RRPP overview ································································································································································ 54
Background···························································································································································· 54
Basic concepts in RRPP ········································································································································· 54
RRPPDUs ································································································································································· 57
RRPP timers····························································································································································· 57
How RRPP works···················································································································································· 58
Typical RRPP networking ······································································································································ 59
Protocols and standards ······································································································································· 62
RRPP configuration task list ··········································································································································· 62
Creating an RRPP domain············································································································································· 63
Configuring control VLANs ··········································································································································· 63
Configuring protected VLANs······································································································································· 64
Configuring RRPP rings·················································································································································· 64
Configuring RRPP ports········································································································································· 64
Configuring RRPP nodes ······································································································································· 65
Activating an RRPP domain··········································································································································· 67
Configuring RRPP timers ················································································································································ 67
Configuring an RRPP ring group ·································································································································· 68
Displaying and maintaining RRPP ································································································································ 68
RRPP configuration examples········································································································································ 69
Single ring configuration example ······················································································································ 69
Intersecting ring configuration example·············································································································· 71
Intersecting-ring load balancing configuration example··················································································· 77
Troubleshooting······························································································································································ 86
Smart Link configuration················································································································································88
Smart Link overview ······················································································································································· 88
Background···························································································································································· 88
Terminology ··························································································································································· 89
How Smart Link works ·········································································································································· 90
Smart Link collaboration mechanisms ················································································································· 90
Smart Link configuration task list ·································································································································· 91
Configuring a smart link device ··································································································································· 91
Configuration prerequisites ·································································································································· 91

v
Configuring protected VLANs for a smart link group························································································ 91
Configuring member ports for a smart link group ····························································································· 92
Configuring role preemption for a smart link group ························································································· 92
Enabling the sending of flush messages ············································································································· 93
Configuring an associated device ······························································································································· 93
Configuration prerequisites·································································································································· 93
Enabling the receiving of flush messages··········································································································· 93
Displaying and maintaining Smart Link······················································································································· 94
Smart Link configuration examples ······························································································································ 94
Single smart link group configuration example ································································································· 94
Multiple smart link groups load sharing configuration example······································································ 99
Monitor Link configuration········································································································································· 103
Overview·······································································································································································103
Terminology ·························································································································································103
How Monitor Link works·····································································································································104
Configuring Monitor Link ············································································································································104
Configuration prerequisites ································································································································104
Creating a monitor link group ···························································································································104
Configuring monitor link group member ports·································································································104
Displaying and maintaining Monitor Link ·················································································································105
Monitor Link configuration example ··························································································································105
Track configuration····················································································································································· 109
Track overview ·····························································································································································109
Introduction to collaboration ······························································································································109
Collaboration fundamentals·······························································································································109
Collaboration application example ··················································································································110
Track configuration task list ········································································································································110
Associating the track module with a detection module ···························································································111
Associating track with NQA ······························································································································111
Associating track with interface management ·································································································111
Associating the track module with an application module······················································································112
Associating track with static routing··················································································································112
Displaying and maintaining track entries··················································································································113
Track configuration example ······································································································································113
Static routing-track-NQA collaboration configuration example·····································································113
Support and other resources ····································································································································· 119
Contacting HP ······························································································································································119
Subscription service ············································································································································119
Related information······················································································································································119
Documents····························································································································································119
Websites ······························································································································································119
Conventions ··································································································································································120
Index············································································································································································· 122

1
High availability overview
Communication interruptions can seriously affect widely-deployed value-added services such as IPTV and
video conference. Therefore, the basic network infrastructures must be able to provide high availability.
The following are the effective ways to improve availability:
Increasing fault tolerance
Speeding up fault recovery
Reducing impact of faults on services
Availability requirements
Availability requirements fall into three levels based on purpose and implementation, as shown in Table
1.
Table 1 Availability requirements
Level
Requirement
Solution
1
Decrease system software and
hardware faults
Hardware: Simplified circuit design, enhanced
production techniques, and reliability tests.
Software: Reliability design and test
2
Protect system functions from being
affected by failures
Device and link redundancy and switchover
3
Enable the system to recover as fast
as possible
Fault detection, diagnosis, isolation, and recovery
technologies
The level 1 availability requirement should be considered during the design and production of network
devices. Level 2 should be considered during network design. Level 3 should be considered during
network deployment, according to the network infrastructure and service characteristics.
Availability evaluation
Mean Time Between Failures (MTBF) and Mean Time to Repair (MTTR) evaluate the availability of a
network.
MTBF
MTBF is the predicted elapsed time between inherent failures of a system during operation. It is typically
expressed in hours. A higher MTBF means a higher availability.
MTTR
MTTR is the average time required to repair a failed system. MTTR in a broad sense also involves spare
parts management and customer services.
MTTR = fault detection time + hardware replacement time + system initialization time + link recovery time
+ routing time + forwarding recovery time. A smaller value of each item means a smaller MTTR and a
higher availability.

2
High availability technologies
As previously mentioned, increasing MTBF or decreasing MTTR can enhance the availability of a
network. The high availability technologies described in this section meet the level 3 high availability
requirements by decreasing MTTR.
High availability technologies can be classified as fault detection technologies or protection switchover
technologies.
Fault detection technologies
Fault detection technologies enable detection and diagnosis of network faults. CFD, DLDP, and Ethernet
OAM are data link layer fault detection technologies. NQA is used for diagnosis and evaluation of
network quality. Monitor Link and Track work along with other high availability technologies to detect
faults through a collaboration mechanism. For more information about these technologies, see Table 2.
Table 2 Fault detection technologies
Technology
Introduction
Reference
CFD
Connectivity Fault Detection (CFD), which conforms to IEEE
802.1ag Connectivity Fault Management (CFM) and ITU-T
Y.1731, is an end-to-end per-VLAN link layer Operations,
Administration and Maintenance (OAM) mechanism used for
link connectivity detection, fault verification, and fault location.
CFD configuration in
the High Availability
Configuration Guide
DLDP
The Device link detection protocol (DLDP) deals with
unidirectional links that may occur in a network. Upon detecting
a unidirectional link, DLDP, as configured, can shut down the
related port automatically or prompt users to take actions to
avoid network problems.
DLDP configuration in
the High Availability
Configuration Guide
Ethernet OAM
As a tool monitoring Layer 2 link status, Ethernet OAM is mainly
used to address common link-related issues on the “last mile”.
You can monitor the status of the point-to-point link between two
directly connected devices by enabling Ethernet OAM on them.
Ethernet OAM
configuration in the
High Availability
Configuration Guide
NQA
Network Quality Analyzer (NQA) analyzes network
performance, services and service quality through sending test
packets, and provides you with network performance and
service quality parameters such as jitter, TCP connection delay,
FTP connection delay and file transfer rate.
NQA configuration in
the Network
Management and
Monitoring
Configuration Guide
Monitor Link
Monitor link is a port collaboration function. It is usually used in
conjunction with Layer 2 topology protocols. The idea is to
monitor the states of uplink ports and adapt the up/down state
of downlink ports to the up/down state of uplink ports,
triggering link switchover on the downstream device in time.
Monitor link
configuration in the
High Availability
Configuration Guide

3
Technology
Introduction
Reference
Track
The track module is used to implement collaboration between
different modules. The collaboration here involves three parts:
the application modules, the track module, and the detection
modules. These modules collaborate with one another through
collaboration entries. The detection modules trigger the
application modules to perform certain operations through the
track module. More specifically, the detection modules probe
the link status, network performance and so on, and inform the
application modules of the detection result through the track
module. Upon becoming aware of the changes of network
status, the application modules deal with the changes to avoid
communication interruption and network performance
degradation.
Track configuration in
the High Availability
Configuration Guide
Protection switchover technologies
Protection switchover technologies aim at recovering network faults. They back up hardware, link, routing,
and service information for switchover in case of network faults, to ensure continuity of network services.
Table 3 Protection switchover technologies
Technology
Introduction
Reference
Ethernet Link
Aggregation
Ethernet link aggregation, most often simply called “link
aggregation”, aggregates multiple physical Ethernet links into
one logical link to increase link bandwidth beyond the limits of
any one single link. This logical link is called an aggregate link.
It allows for link redundancy because the member physical links
can dynamically back up one another.
Ethernet link
aggregation
configuration in the
Layer 2—LAN
Switching
Configuration Guide
Smart Link
Smart Link is a feature developed to address the slow
convergence issue with STP. It provides link redundancy as well
as fast convergence in a dual uplink network, allowing the
backup link to take over quickly when the primary link fails.
Smart link
configuration in the
High Availability
Configuration Guide
MSTP
As a Layer 2 management protocol, the Multiple Spanning Tree
Protocol (MSTP) eliminates Layer 2 loops by selectively blocking
redundant links in a network, and in the mean time, allows for
link redundancy.
MSTP configuration in
the Layer 2—LAN
Switching
Configuration Guide
RRPP
The Rapid Ring Protection Protocol (RRPP) is a link layer
protocol designed for Ethernet rings. RRPP can prevent
broadcast storms caused by data loops when an Ethernet ring is
healthy, and rapidly restore the communication paths between
the nodes in the event that a link is disconnected on the ring.
RRPP configuration in
the High Availability
Configuration Guide
A single availability technology cannot solve all problems. Therefore, a combination of availability
technologies, chosen on the basis of detailed analysis of network environments and user requirements,
should be used to enhance network availability. For example, access-layer devices should be connected
to distribution-layer devices over redundant links, and core-layer devices should be fully meshed. Also,
network availability should be considered during planning prior to building a network.

4
Ethernet OAM configuration
Ethernet OAM overview
Background
Ethernet, because of its ease of use and low price, has become the major underlying technology for local
area networks (LANs). With the emergence of Gigabit Ethernet and 10-Gigabit Ethernet, Ethernet is
gaining popularity in metropolitan area networks (MANs) and wide area networks (WANs) as well,
increasing the need for an effective management and maintenance mechanism for Ethernet. This makes it
urgent to implement Operation, Administration and Maintenance (OAM) on Ethernet networks.
As a tool monitoring Layer 2 link status, Ethernet OAM mainly addresses common link-related issues on
the “last mile.” When you enable Ethernet OAM on two devices connected by a point-to-point link, you
can monitor the status of the link.
Major functions of Ethernet OAM
Ethernet OAM is an effective tool for management and maintenance of Ethernet networks, helping to
ensure network stability. It includes the following major functions:
Link performance monitoring—Monitors the performance indices of a link, including packet loss,
delay, and jitter, and collects traffic statistics of various types
Fault detection and alarm—Checks the connectivity of a link by sending OAM protocol data units
(OAMPDUs) and reports to the network administrators when a link error occurs
Remote loopback—Checks link quality and locates link errors by looping back OAMPDUs
Ethernet OAMPDUs
Ethernet OAM works on the data link layer. Ethernet OAM reports the link status by periodically
exchanging OAMPDUs between devices so that the administrator can effectively manage the network.
Figure 1 Formats of different types of Ethernet OAMPDUs
Dest addr
6
Source addr Type Subtype Flags Code Data/Pad CRC
0x00 Local info TLV Remote info TLV ...
12126 42 to 1496 4
Information OAMPDU
Event notification OAMPDU
Loopback control OAMPDU
0x01
0x04
seq Link event TLV
Loopback command
...

5
Table 4 Description of the fields in an OAMPDU
Field
Description
Dest addr
Destination MAC address of the Ethernet OAMPDU
It is a slow protocol multicast address, 0180c2000002. Bridges
cannot forward slow protocol packets, so Ethernet OAMPDUs cannot
be forwarded.
Source addr
Source MAC address of the Ethernet OAMPDU
It is the bridge MAC address of the sending side and is a unicast MAC
address.
Type
Type of the encapsulated protocol in the Ethernet OAMPDU
The value is 0x8809.
Subtype
The specific protocol being encapsulated in the Ethernet OAMPDU
The value is 0x03.
Flags
Status information of an Ethernet OAM entity
Code
Type of the Ethernet OAMPDU
NOTE:
Throughout this document, a port with Ethernet OAM enabled is an Ethernet OAM entity or an OAM
entity.
Table 5 Functions of different types of OAMPDUs
OAMPDU type
Function
Information OAMPDU
Used for transmitting state information of an Ethernet OAM entity—including the
information about the local device and remote devices and customized
information—to the remote Ethernet OAM entity and maintaining OAM
connections.
Event Notification
OAMPDU
Used by link monitoring to notify the remote OAM entity when it detects problems
on the link in between
Loopback Control
OAMPDU
Used for remote loopback control. By inserting the information used to
enable/disable loopback to a loopback control OAMPDU, you can
enable/disable loopback on a remote OAM entity.
How Ethernet OAM works
This section describes the working procedures of Ethernet OAM.
Ethernet OAM connection establishment
Ethernet OAM connection is the base of all the other Ethernet OAM functions. OAM connection
establishment is also known as the “Discovery phase”, where an Ethernet OAM entity discovers remote
OAM entities and establishes sessions with them.
In this phase, interconnected OAM entities notify the peer of their OAM configuration information and the
OAM capabilities of the local nodes by exchanging Information OAMPDUs to determine whether
Ethernet OAM connections can be established. An Ethernet OAM connection can be established only

6
when the settings for loopback, link detecting, and link event of both sides match. After an Ethernet OAM
connection is established, Ethernet OAM takes effect on both sides.
For Ethernet OAM connection establishment, a device can operate in active Ethernet OAM mode or
passive Ethernet OAM mode.
Table 6 Active and passive Ethernet OAM modes
Item
Active Ethernet OAM mode
Passive Ethernet OAM mode
Initiating OAM Discovery
Available
Unavailable
Responding to OAM Discovery
Available
Available
Transmitting Information
OAMPDUs
Available
Available
Transmitting Event Notification
OAMPDUs
Available
Available
Transmitting Information
OAMPDUs without any TLV
Available
Available
Transmitting Loopback Control
OAMPDUs
Available
Unavailable
Responding to Loopback Control
OAMPDUs
Available—if both sides operate
in active OAM mode
Available
NOTE:
OAM connections can be initiated only by OAM entities operating in active OAM mode. OAM entities
operating in passive mode wait and respond to the connection requests sent by their peers.
No OAM connection can be established between OAM entities operating in passive OAM mode.
After an Ethernet OAM connection is established, the Ethernet OAM entities on both sides exchange
Information OAMPDUs at a specified interval—handshake packet transmission interval—to check whether
the Ethernet OAM connection is normal. If an Ethernet OAM entity receives no Information OAMPDU
within the Ethernet OAM connection timeout time, the Ethernet OAM connection is considered
disconnected.
Link monitoring
Error detection in an Ethernet is difficult, especially when the physical connection in the network is not
disconnected but network performance is degrading gradually. Link monitoring is used to detect and
indicate link faults in various environments. Ethernet OAM implements link monitoring through the
exchange of Event Notification OAMPDUs. When detecting a link error event listed in Table 7, the local
OAM entity sends an Event Notification OAMPDU to notify the remote OAM entity. With the log
information, network administrators can keep track of network status promptly.
Table 7 Ethernet OAM link error events
Ethernet OAM link events
Description
Errored symbol event
An errored symbol event occurs when the number of
detected symbol errors over a specific detection
interval exceeds the configured threshold.

7
Ethernet OAM link events
Description
Errored frame event
An errored frame event occurs when the number of
detected error frames over a specific interval
exceeds the configured threshold.
Errored frame period event
An errored frame period event occurs if the number
of frame errors in a specific number of received
frames exceeds the configured threshold.
Errored frame seconds event
An errored frame seconds event occurs when the
number of error frame seconds detected on a port
over a detection interval reaches the error threshold.
NOTE:
The system transforms the period of detecting errored frame period events into the maximum number of 64-byte
frames that a port can send in the specific period. The system takes the maximum number of frames sent as the
period. The maximum number of frames sent is calculated using this formula: the maximum number of frames =
interface bandwidth (bps) × errored frame period event detection period (in ms)/(64 × 8 × 1000).
If errored frames appear in a certain second, this second is an errored frame second.
Remote fault detection
Information OAMPDUs are exchanged periodically among Ethernet OAM entities across established
OAM connections. In a network where traffic is interrupted due to device failures or unavailability, the
flag field defined in information OAMPDUs allows an Ethernet OAM entity to send error information—the
critical link event type—to its peer. You can use the log information to track ongoing link status and
troubleshoot problems promptly.
Table 8 Critical link events
Type
Description
OAMPDU transmission
frequencies
Link Fault
Peer link signal is lost.
Once per second
Dying Gasp
A power failure or other
unexpected error occurred.
Non-stop
Critical Event
An undetermined critical event
occurred.
Non-stop
NOTE:
A5120 EI Switch Series is able to receive information OAMPDUs carrying the critical link events listed in Table 8.
Only the Gigabit optical ports are able to send information OAMPDUs carrying Link Fault events.
A5120 EI Switch Series is able to send information OAMPDUs carrying Dying Gasp events when the device is
rebooted or relevant ports are manually shut down. Physical IRF ports, however, are unable to send this type of
OAMPDU. For more information about physical IRF ports, see the IRF Configuration Guide .
A5120 EI Switch Series is unable to send information OAMPDUs carrying Critical Events.
Remote loopback
Remote loopback is available only after the Ethernet OAM connection is established. With remote
loopback enabled, the Ethernet OAM entity operating in active Ethernet OAM mode sends non-

8
OAMPDUs to its peer. After receiving these frames, the peer does not forward them according to their
destination addresses. Instead, it returns them to the sender along the original path.
Remote loopback enables you to check the link status and locate link failures. Performing remote
loopback periodically helps to detect network faults promptly. Furthermore, performing remote loopback
by network segments helps to locate network faults.
Protocols and Standards
IEEE 802.3h, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications
Ethernet OAM configuration task list
Complete the following tasks to configure Ethernet OAM:
Task
Remarks
Configuring basic Ethernet OAM functions
Required
Configuring the Ethernet OAM connection detection timers
Optional
Configuring link
monitoring
Configuring errored symbol event detection
Optional
Configuring errored frame event detection
Optional
Configuring errored frame period event detection
Optional
Configuring errored frame seconds event
detection
Optional
Configuring OAM
remote loopback
Enabling Ethernet OAM remote loopback
Optional
Rejecting the Ethernet OAM remote loopback
request from a remote port
Optional
Configuring basic Ethernet OAM functions
For Ethernet OAM connection establishment, an Ethernet OAM entity operates in active mode or passive
mode. Only an Ethernet OAM entity in active mode can initiate connection establishment. After Ethernet
OAM is enabled on an Ethernet port, according to its Ethernet OAM mode, the Ethernet port establishes
an Ethernet OAM connection with its peer port.
Follow these steps to configure basic Ethernet OAM functions:
To do…
Use the command…
Remarks
Enter system view
System-view
—
Enter Ethernet port view
interface interface-type interface-
number
—
Set the Ethernet OAM mode
oam mode { active | passive }
Optional
The default is active Ethernet
OAM mode.

9
To do…
Use the command…
Remarks
Enable Ethernet OAM on the
current port
oam enable
Required
Ethernet OAM is disabled by
default.
NOTE:
To change the Ethernet OAM mode on an Ethernet OAM-enabled port, you must first disable Ethernet
OAM on the port.
Configuring the Ethernet OAM connection detection
timers
After an Ethernet OAM connection is established, the Ethernet OAM entities on both sides exchange
Information OAMPDUs at a specified interval—handshake packet transmission interval—to check whether
the Ethernet OAM connection is normal. If an Ethernet OAM entity receives no Information OAMPDU
within the Ethernet OAM connection timeout time, the Ethernet OAM connection is considered
disconnected.
By adjusting the handshake packet transmission interval and the connection timeout timer, you can
change the detection time resolution for Ethernet OAM connections.
Follow these steps to configure the Ethernet OAM connection detection timers:
To do…
Use the command…
Remarks
Enter system view
System-view
—
Configure the Ethernet OAM
handshake packet transmission
interval
oam timer hello interval
Optional
1000 millisecond by default
Configure the Ethernet OAM
connection timeout timer
oam timer keepalive interval
Optional
5000 milliseconds by default
CAUTION:
After the timeout timer of an Ethernet OAM connection expires, the local OAM entity ages out its
connection with the peer OAM entity, causing the OAM connection to be disconnected. HP
recommends setting the connection timeout timer to at least five times the handshake packet
transmission interval, ensuring the stability of Ethernet OAM connections.
Configuring link monitoring
NOTE:
After Ethernet OAM connections are established, the link monitoring periods and thresholds configured
in this section take effect on all Ethernet ports automatically.

10
Configuring errored symbol event detection
An errored symbol event occurs when the number of detected symbol errors during a specific detection
interval exceeds the configured threshold.
Follow these steps to configure errored symbol event detection:
To do…
Use the command…
Remarks
Enter system view
system-view
—
Configure the errored
symbol event detection
interval
oam errored-symbol period period-value
Optional
1 second by default
Configure the errored
symbol event triggering
threshold
oam errored-symbol threshold threshold-
value
Optional
1 by default
Configuring errored frame event detection
An errored frame event occurs when the number of detected error frames during a specific interval
exceeds the configured threshold.
Follow these steps to configure errored frame event detection:
To do…
Use the command…
Remarks
Enter system view
system-view
—
Configure the errored frame
event detection interval
oam errored-frame period period-value
Optional
1 second by default
Configure the errored frame
event triggering threshold
oam errored-frame threshold threshold-
value
Optional
1 by default
Configuring errored frame period event detection
An errored frame period event occurs if the number of frame errors within a specific number of received
frames exceeds the configured threshold.
Follow these steps to configure errored frame period event detection:
To do…
Use the command…
Remarks
Enter system view
system-view
—
Configure the errored frame
period event detection
period
oam errored-frame-period period period-
value
Optional
1000 milliseconds by default
Configure the errored frame
period event triggering
threshold
oam errored-frame-period threshold
threshold-value
Optional
1 by default

11
Configuring errored frame seconds event detection
An errored frame seconds event occurs when the number of error frame seconds detected on a port
during a detection interval exceeds the error threshold.
Follow these steps to configure errored frame seconds event detection:
To do…
Use the command…
Remarks
Enter system view
system-view
—
Configure the errored frame
seconds event detection
interval
oam errored-frame-seconds period
period-value
Optional
60 second by default
Configure the errored frame
seconds event triggering
threshold
oam errored-frame-seconds threshold
threshold-value
Optional
1 by default
CAUTION:
Make sure the errored frame seconds triggering threshold is less than the errored frame seconds
detection interval. Otherwise, no errored frame seconds event can be generated.
Configuring OAM remote loopback
Enabling Ethernet OAM remote loopback
When you enable Ethernet OAM remote loopback on a port, the port sends Loopback Control
OAMPDUs to a remote port, and the remote port enters the loopback state. The port then sends test
frames to the remote port. By observing how many of these test frames return, you can calculate the
packet loss ratio on the link, to evaluate the link performance.
Follow these steps to enable Ethernet OAM remote loopback in interface view:
To do…
Use the command…
Remarks
Enter system view
system-view
—
Enter Layer 2 Ethernet port view
interface interface-type interface-
number
—
Enable Ethernet OAM remote
loopback on the port
oam loopback
Required
Disabled by default.
NOTE:
Use this function with caution because enabling Ethernet OAM remote loopback impacts other services.

12
NOTE:
Ethernet OAM remote loopback is available only after the Ethernet OAM connection is established and can be
performed only by the Ethernet OAM entities operating in active Ethernet OAM mode.
Remote loopback is available only on full-duplex links that support remote loopback at both ends.
Ethernet OAM remote loopback needs the support of the peer hardware.
Enabling Ethernet OAM remote loopback interrupts data communications. After Ethernet OAM remote loopback
is disabled, all the ports involved will shut down and then come up. Ethernet OAM remote loopback is disabled
by any of the following actions: executing the undo oam enable command to disable Ethernet OAM; executing
the undo oam loopback command to disable Ethernet OAM remote loopback; timeout of the Ethernet OAM
connection.
Ethernet OAM remote loopback is only applicable to individual links. It is not applicable to link aggregation
member ports. In addition, do not assign ports where Ethernet OAM remote loopback is being performed to link
aggregation groups. For more information about link aggregation groups, see the Layer 2—LAN Switching
Configuration Guide .
Enabling internal loopback test on a port in remote loopback test can terminate the remote loopback test. For
more information about loopback test, see the Layer 2—LAN Switching Configuration Guide .
Rejecting the Ethernet OAM remote loopback request from a
remote port
The Ethernet OAM remote loopback function impacts other services. To solve this problem, you can
disable a port from being controlled by the Loopback Control OAMPDUs sent by a remote port. The local
port then rejects the Ethernet OAM remote loopback request from the remote port.
Follow these steps to reject the Ethernet OAM remote loopback request from a remote port:
To do…
Use the command…
Remarks
Enter system view
system-view
—
Enter Layer 2 Ethernet port view
interface interface-type interface-
number
—
Reject the Ethernet OAM remote
loopback request from a remote
port
oam loopback reject-request
Required
By default, a port does not reject
the Ethernet OAM remote
loopback request from a remote
port.
Displaying and maintaining Ethernet OAM
configuration
To do…
Use the command…
Remarks
Display global Ethernet OAM
configuration
display oam configuration [ |{ begin |
exclude | include } regular-expression ]
Available in any view
Display the statistics on critical
events after an Ethernet OAM
connection is established
display oam critical-event [interface interface-
type interface-number ] [ |{ begin | exclude |
include } regular-expression ]

13
To do…
Use the command…
Remarks
Display the statistics on Ethernet
OAM link error events after an
Ethernet OAM connection is
established
display oam link-event {local | remote } [
interface interface-type interface-number ] [ |{
begin | exclude | include } regular-expression
]
Display the information about an
Ethernet OAM connection
display oam {local | remote }[interface
interface-type interface-number ] [ |{ begin |
exclude | include } regular-expression ]
Clear statistics on Ethernet OAM
packets and Ethernet OAM link
error events
reset oam [interface interface-type interface-
number ]
Available in user
view only
Ethernet OAM configuration example
Network requirements
On the network shown in Figure 2, perform the following operations:
Enable Ethernet OAM on Switch A and Switch B to auto-detect link errors between the two devices
Monitor the performance of the link between Switch A and Switch B by collecting statistics about the
error frames received by Switch A
Figure 2 Network diagram for Ethernet OAM configuration
GE1/0/1 GE1/0/1
Switch A Switch B
Configuration procedure
1. Configure Switch A.
# Configure GigabitEthernet 1/0/1 to operate in passive Ethernet OAM mode and enable Ethernet
OAM for it.
<SwitchA> system-view
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] oam mode passive
[SwitchA-GigabitEthernet1/0/1] oam enable
[SwitchA-GigabitEthernet1/0/1] quit
# Set the errored frame detection interval to 20 seconds and set the errored frame event triggering
threshold to 10.
[SwitchA] oam errored-frame period 20
[SwitchA] oam errored-frame threshold 10
2. Configure Switch B.
# Configure GigabitEthernet 1/0/1 to operate in active Ethernet OAM mode (the default) and enable
Ethernet OAM for it.
<SwitchB> system-view
[SwitchB] interface gigabitethernet 1/0/1
[SwitchB-GigabitEthernet1/0/1] oam mode active

14
[SwitchB-GigabitEthernet1/0/1] oam enable
[SwitchB-GigabitEthernet1/0/1] quit
3. Verify the configuration.
Use the display oam configuration command to display the Ethernet OAM configuration. For example:
# Display the Ethernet OAM configuration on Switch A.
[SwitchA] display oam configuration
Configuration of the link event window/threshold :
--------------------------------------------------------------------------
Errored-symbol Event period(in seconds) : 1
Errored-symbol Event threshold : 1
Errored-frame Event period(in seconds) : 20
Errored-frame Event threshold : 10
Errored-frame-period Event period(in ms) : 1000
Errored-frame-period Event threshold : 1
Errored-frame-seconds Event period(in seconds) : 60
Errored-frame-seconds Event threshold : 1
Configuration of the timer :
--------------------------------------------------------------------------
Hello timer(in ms) : 1000
Keepalive timer(in ms) : 5000
The output shows that the detection period of errored frame events is 20 seconds, the detection threshold
is 10 seconds, and all the other parameters use the default values.
You can use the display oam critical-event command to display the statistics of Ethernet OAM critical link
events. For example:
# Display the statistics of Ethernet OAM critical link events on all the ports of Switch A.
[SwitchA] display oam critical-event
Port : GigabitEthernet1/0/1
Link Status : Up
Event statistic :
-------------------------------------------------------------------------
Link Fault :0 Dying Gasp : 0 Critical Event : 0
The output shows that no critical link event occurred on the link between Switch A and Switch B.
You can use the display oam link-event command to display the statistics of Ethernet OAM link error
events. For example:
# Display Ethernet OAM link event statistics of the remote end of Switch B.
[SwitchB] display oam link-event remote
Port :GigabitEthernet1/0/1
Link Status :Up
OAMRemoteErrFrameEvent : (ms = milliseconds)
---------------------------------------------------------------------
Event Time Stamp : 5789 Errored FrameWindow : 10(100ms)
Errored Frame Threshold : 1 Errored Frame : 3
Error Running Total : 35 Event Running Total : 17

15
The output indicates that 35 errors occurred since Ethernet OAM was enabled on Switch A, 17 of which
are caused by error frames. The link is unstable.