HP 3100 v2 Configuration Manual
HPE 3100 v2 Switch Series
High Availability
Configuration Guide
Part number: 5998-5997s
Software version: Release 5213 and Release 5213P02
Document version: 6W101-20160506
© Copyright 2016 Hewlett Packard Enterprise Development LP
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard
Enterprise products and services are set forth in the express warranty statements acco mpanying such
products and services. Nothing herein should be construe d as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions co ntained herein.
Confidential computer software. V alid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and T e chnical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard
Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise
website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are trademarks of the Microsoft group of companies.
Adobe® and Acrobat® are trademarks of Adobe Systems In corporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
Contents
High availability overview ················································································ 1
Availability requirements ···································································································································· 1
Availability evaluation ········································································································································· 1
High availability technologies ····························································································································· 2
Fault detection technologies ······················································································································ 2
Protection switchover technologies ············································································································ 2
Configuring Ethernet OAM ·············································································· 4
Ethernet OAM overview ····································································································································· 4
Major functions of Ethernet OAM ··············································································································· 4
Ethernet OAMPDUs ··································································································································· 4
How Ethernet OAM works ·························································································································· 5
Standards and protocols ···························································································································· 7
Ethernet OAM configuration task list ·················································································································· 7
Configuring basic Ethernet OAM functions ········································································································ 8
Configuring the Ethernet OAM connection detection timers ·············································································· 8
Configuring link monitoring ································································································································ 9
Configuring errored symbol event detection ······························································································ 9
Configuring errored frame event detection ································································································· 9
Configuring errored frame period event detection ······················································································ 9
Configuring errored frame seconds event detection ·················································································· 9
Configuring Ethernet OAM remote loopback ··································································································· 10
Enabling Ethernet OAM remote loopback ································································································ 10
Rejecting the Ethernet OAM remote loopback request from a remote port ············································· 11
Displaying and maintaining Ethernet OAM configuration ················································································· 11
Ethernet OAM configuration example ·············································································································· 12
Configuring CFD (available only on the HPE 3100 v2 EI) ····························· 15
Overview ·························································································································································· 15
Basic CFD concepts ································································································································· 15
CFD functions ·········································································································································· 17
Protocols and standards ·························································································································· 18
CFD configuration task list ······························································································································· 19
Configuring basic CFD settings ······················································································································· 19
Enabling CFD ··········································································································································· 20
Configuring the CFD protocol version ······································································································ 20
Configuring service instances ·················································································································· 20
Configuring MEPs ···································································································································· 21
Configuring MIP generation rules ············································································································· 21
Configuring CFD functions ······························································································································· 22
Configuration prerequisites ······················································································································ 22
Configuring CC on MEPs ························································································································· 22
Configuring LB on MEPs ·························································································································· 23
Configuring LT on MEPs ·························································································································· 23
Configuring AIS ········································································································································ 24
Configuring LM ········································································································································· 24
Configuring one-way DM ·························································································································· 24
Configuring two-way DM ·························································································································· 25
Configuring TST ······································································································································· 25
Displaying and maintaining CFD ······················································································································ 26
CFD configuration example ····························································································································· 27
Configuring DLDP ························································································· 33
DLDP overview ················································································································································ 33
Background ·············································································································································· 33
How DLDP works ····································································································································· 34
DLDP configuration task list ····························································································································· 40
i
Configuring the duplex mode and speed of an Ethernet interface ··································································· 40
Enabling DLDP ················································································································································ 40
Setting DLDP mode ········································································································································· 41
Setting the interval to send advertisement packets ························································································· 41
Setting the delaydown timer ····························································································································· 42
Setting the port shutdown mode ······················································································································ 42
Configuring DLDP authentication ····················································································································· 43
Resetting DLDP state ······································································································································ 43
Displaying and maintaining DLDP ··················································································································· 44
DLDP configuration examples ························································································································· 44
Automatically shutting down unidirectional links ······················································································ 44
Manually shutting down unidirectional links ····························································································· 48
Troubleshooting DLDP ····································································································································· 51
Configuring RRPP ························································································· 52
RRPP overview ················································································································································ 52
Background ·············································································································································· 52
Basic concepts in RRPP ·························································································································· 52
RRPPDUS ················································································································································ 54
RRPP timers ············································································································································ 55
How RRPP works ····································································································································· 55
Typical RRPP networking ························································································································ 56
Protocols and standards ·························································································································· 59
RRPP configuration task list ···························································································································· 60
Creating an RRPP domain ······························································································································· 60
Configuring control VLANs ······························································································································· 61
Configuration guidelines ··························································································································· 61
Configuration procedure ··························································································································· 61
Configuring protected VLANs ·························································································································· 61
Configuring RRPP rings ··································································································································· 62
Configuring RRPP ports ··························································································································· 63
Configuring RRPP nodes ························································································································· 63
Activating an RRPP domain ····························································································································· 64
Configuring an RRPP ring group ····················································································································· 65
Configuration restrictions and guidelines ································································································· 65
Configuration procedure ··························································································································· 65
Displaying and maintaining RRPP ··················································································································· 66
RRPP configuration examples ························································································································· 66
Single ring configuration example ············································································································ 66
Intersecting ring configuration example ··································································································· 69
Dual homed rings configuration example ································································································· 74
Intersecting-ring load balancing configuration example ··········································································· 83
Troubleshooting ··············································································································································· 91
Configuring Smart Link (available only on the HPE 3100 v2 EI) ··················· 93
Smart Link overview ········································································································································· 93
Background ·············································································································································· 93
Terminology ············································································································································· 94
How Smart Link works ····························································································································· 94
Smart Link collaboration mechanisms ····································································································· 95
Smart Link configuration task list ····················································································································· 95
Configuring a Smart Link device ······················································································································ 96
Configuration prerequisites ······················································································································ 96
Configuring protected VLANs for a smart link group ················································································ 96
Configuring member ports for a smart link group ····················································································· 97
Configuring role preemption for a smart link group ·················································································· 98
Enabling the sending of flush messages ·································································································· 98
Configuring an associated device ···················································································································· 99
Configuration prerequisites ······················································································································ 99
Enabling the receiving of flush messages ································································································ 99
Displaying and maintaining Smart Link ············································································································ 99
Smart Link configuration examples ················································································································ 100
ii
Single smart link group configuration example ······················································································ 100
Multiple smart link groups load sharing configuration example ······························································ 104
Configuring Monitor Link (available only on the HPE 3100 v2 EI) ·············· 109
Monitor Link overview ···································································································································· 109
Terminology ··········································································································································· 109
How Monitor Link works ························································································································· 110
Configuring Monitor Link ································································································································ 110
Configuration prerequisites ···················································································································· 110
Creating a monitor link group ················································································································· 110
Configuring monitor link group member ports ························································································ 110
Displaying and maintaining Monitor Link ······································································································· 111
Monitor Link configuration example ··············································································································· 111
Document conventions and icons ······························································· 115
Conventions ··················································································································································· 115
Network topology icons ·································································································································· 116
Support and other resources ······································································ 117
Accessing Hewlett Packard Enterprise Support ···························································································· 117
Accessing updates ········································································································································· 117
Websites ················································································································································ 118
Customer self repair ······························································································································· 118
Remote support ······································································································································ 118
Documentation feedback ······················································································································· 118
Index ··········································································································· 120
iii
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 implementa tion.
Table 1 Availability requirements
Level Requirement Solution
• Hardware—Simplifying circuit design, enhancing
1
Decrease system software and
hardware faults
production techniques, and performing reliability
tests.
• Software—Reliability design and test
2
3
The level 1 availability requirement should be considered during the design and production process
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.
Protect system functions from being
affected if faults occur
Enable the system to recover as fast
as possible
Availability evaluation
Mean Time Between Failures (MTBF) and Mean Time to Repair (MTTR) are used to evaluate the
availability of a network.
MTBF
MTBF is the predicted elapsed time between inherent failures of a system during operation. It is
typically in the unit of hours. A higher MTBF means a high 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.
Device and link redundancy and deployment of
switchover strategies
Performing fault detection, diagnosis, isolation, and
recovery technologies
1
High availability technologies
Increasing MTBF or decreasing MTTR can enhance the availability of a network. The high
availability technologies described in this section meet the level 2 and 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 works along with other high availability technologies to
detect faults through a collaboration mechanism.
Table 2 Fault detection technologies
Technology Introduction Reference
Connectivity Fault Detection (CFD), which conforms to IEEE
CFD (available only
on the HPE 3100
v2 EI)
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.
"Configuring CFD" in
High Availability
Configuration Guide
The Device link detection protocol (DLDP) deals with
unidirectional links that may occur in a network. Upon
DLDP
Ethernet OAM
NQA
Monitor Link
(available only on
the HPE 3100 v2
EI)
detecting a unidirectional link, DLDP, as configured, can
shut down the related port automatically or prompt users to
take actions to avoid network problems.
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.
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.
Monitor Link works together with Layer 2 topology protocols
to adapt the up/down state of a downlink port to the state of
an uplink port. This feature enables fast link switchover on a
downstream device in response to the uplink state change
on its upstream device.
Protection switchover technologies
"Configuring DLDP"
in Hig
h Availability
Configuration Guide
"Configuring Ethernet
OAM" in High
ability
Avail
Configuration Guide
"Configuring NQA" in
Network
Management and
Monitoring
Configuration Guide
"Configuring Monitor
Link" in High
Availability
Configuration Guide
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.
2
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 l imits
of any one single link. This logical link is an aggregate link. It
allows for link redundancy because the member phys ical
links can dynamically back up one another.
"Configuring Ethernet
ink aggregation" in
—
Layer 2
Switching
Configuration Guide
LAN
Smart Link
(available only on
the HPE 3100 v2
EI)
MSTP
RRPP
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.
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.
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.
"Configuring Smart
Link" in High
Availability
Configuration Guide
"Configuring
spanning tree" in
Layer 2—LAN
Switching
Configuration Guide
"Configuring RRPP"
h Availability
in Hig
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.
3
Configuring Ethernet OAM
Ethernet OAM overview
Ethernet Operation, Administration and Maintenance (OAM) is a tool that monitors Layer 2 link
status and addresses common link-related issues on the "last mile." You can use it to monitor the
status of the point-to-point link between two directly connected devices.
Major functions of Ethernet OAM
Ethernet OAM provides the following 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.
Ethernet OAMPDUs fall into the following types: Information, Event Notification, and Loopback
Control.
Figure 1 Formats of different types of Ethernet OAMPDUs
Table 4 Fields in an OAMPDU
Field Description
Destination MAC address of the Ethernet OAMPDU
Dest addr
It is a slow protocol multicast address, 0180c2000002. Bridges cannot forward
slow protocol packets, so Ethernet OAMPDUs cannot be forwarded.
Source addr
Type
Source MAC address of the Ethernet OAMPDU
It is the bridge MAC address of the sending side and is a unicast MAC address.
Type of the encapsulated protocol in the Ethernet OAMPDU
The value is 0x8809.
4
Field Description
Subtype
Flags Status information of an Ethernet OAM entity
Code Type of the Ethernet OAMPDU
NOTE:
The specific protocol being encapsulated in the Ethernet OAMPDU
The value is 0x03.
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
Used for transmitting state information of an Ethernet OAM entity—including the
Information OAMPDU
information about the local device and remote devices and customized
information—to the remote Ethernet OAM entity and maintaining OAM
connections.
Event Notification
OAMPDU
Loopback Control
OAMPDU
Used by link monitoring to notify the remote OAM entity when it detects problems
on the link in between.
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 basis 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 determine whether Ethernet OAM connections can be
established, by exchanging Information OAMPDUs to notify the peer of their OAM configuration
information and the OAM capabilities of the local nodes. An Ethernet OAM connection can be
established between entities that have matching Loopback, link detecting, and link event settings.
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, but a switch role will be somewhat different depending on the mode.
Table 6 Active Ethernet OAM mode and passive Ethernet OAM mode
Item Active Ethernet OAM mode
Initiating OAM Discovery Available Unavailable
Responding to OAM Discovery Available Available
Transmitting Information
OAMPDUs
Transmitting Event Notification
OAMPDUs
Available Available
Available Available
5
Passive Ethernet OAM
mode
Item Active Ethernet OAM mode
Transmitting Information
OAMPDUs without any TLV
Transmitting Loopback Control
OAMPDUs
Responding to Loopback Control
OAMPDUs
NOTE:
• Only OAM entities operating in active OAM mode can initiate OAM connections. 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 ex change
Information OAMPDUs at the 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 one of the link error events listed
in Table 7, the local OAM entity sends
entity. With the log information, network administrators can keep track of network status promptly.
Passive Ethernet OAM
mode
Available Available
Available Unavailable
Available—if both sides operate
in active OAM mode
Available
an Event Notification OAMPDU to notify the remote OAM
Table 7 Ethernet OAM link error events
Ethernet OAM link events Description
Errored symbol event
Errored frame event
Errored frame period event
Errored frame seconds event
The system transforms the period of detecting errored frame period events into the maximum
number of 64-byte frames (excluding the interframe spacing and preamble) that a port can send in
the specified 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).
A second in which errored frames appear is called an "errored frame second."
Remote fault detection
An errored symbol event occurs when the number of detected
symbol errors during a specified detection interval exceeds the
predefined threshold.
An errored frame event occurs when the number of detected error
frames during a specified interval exceeds the predefined
threshold.
An errored frame period event occurs if the number of frame errors
in a specific number of received frames exceeds the predefined
threshold.
An errored frame seconds event occurs when the number of error
frame seconds detected on a port during a specified detection
interval reaches the error threshold.
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
6
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
Link Fault Peer link signal is lost. Once per second
Dying Gasp
Critical Event An undetermined critical event occurred. Non-stop
This Switch Series is able to receive information OAMPDUs carrying the critical link events listed
in Table 8.
Only the Giga
This Switch Series is able to send information OAMPDUs carrying Dying Gasp events when the
device is rebooted or relevant ports are manually shut down.
This 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-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.
OAMPDU transmission
frequencies
A power failure or other unexpected error
occurred.
Non-stop
bit fiber ports are able to send information OAMPDUs carrying Link Fault events.
Standards and protocols
Ethernet OAM is defined in IEEE 802.3ah (Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications.
Ethernet OAM configuration task list
Task Remarks
Configuring basic Ethernet OAM functions Required
Configuring the Ethernet OAM connection detection timers Optional
Configuring errored symbol event detection Optional
Configuring link
monitoring
Configuring
Ethernet OAM
remote loopback
Configuring errored frame event detection Optional
Configuring errored frame period event detection Optional
Configuring errored frame seconds event
detection
Enabling Ethernet OAM remote loopback Optional
Rejecting the Ethernet OAM remote loopback
request from a remote port
Optional
Optional
7
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.
To change the Ethernet OAM mode on an Ethernet OAM-enabled port, you must first disable
Ethernet OAM on the port.
To configure basic Ethernet OAM functions:
Step Command Remarks
1. Enter system view.
2. Enter Layer 2 Ethernet
interface view.
3. Set the Ethernet OAM mode.
4. Enable Ethernet OAM on the
current port.
system-view
interface
interface-number
oam mode
oam enable
interface-type
active
{
passive
|
N/A
N/A
Optional.
}
The default is active Ethernet
OAM mode.
Ethernet OAM is disabled by
default.
Configuring the Ethernet OAM connection detection timers
After an Ethernet OAM connection is established, the Ethernet OAM entities on both sides ex change
Information OAMPDUs at the 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.
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. Hewlett
Packard Enterprise recommends that you set the connection timeout timer to at least five times the
handshake packet transmission interval, ensuring the stability of Ethernet OAM conne ction s.
To configure the Ethernet OAM connection detection timers:
Step Command Remarks
1. Enter system view.
2. Configure the Ethernet OAM
handshake packet
transmission interval.
3. Configure the Ethernet OAM
connection timeout timer.
system-view
oam timer hello
oam timer keepalive
interval
interval
N/A
Optional.
1000 millisecond by default.
Optional.
5000 milliseconds by default.
8
Configuring link monitoring
After Ethernet OAM connections are established, the link monitoring periods and thresholds
configured in this section take effect on all Ethernet ports automatically.
Configuring errored symbol event detection
Step Command Remarks
4. Enter system view.
5. Configure the errored
symbol event
detection interval.
6. Configure the errored
symbol event
triggering threshold.
Configuring errored frame event detection
system-view
oam errored-symbol period
period-value
oam errored-symbol threshold
threshold-value
N/A
Optional.
1 second by default.
Optional.
1 by default.
Step Command Remarks
1. Enter system view.
2. Configure the errored frame
event detection interval.
3. Configure the errored frame
event triggering threshold.
system-view
oam errored-frame period
period-value
oam errored-frame threshold
threshold-value
N/A
Optional.
1 second by default.
Optional.
1 by default.
Configuring errored frame period event detection
Step Command Remarks
1. Enter system view.
2. Configure the errored
frame period event
detection period.
3. Configure the errored
frame period event
triggering threshold.
system-view
oam errored-frame-period period
period-value
oam errored-frame-period threshold
threshold-value
N/A
Optional.
1000 milliseconds by default.
Optional.
1 by default.
Configuring errored frame seconds event detection
IMPORTANT:
Make sure the errored frame seconds triggering thre shold is less than the errored frame seconds
detection interval. Otherwise, no errored frame seconds event can be generated.
9
To configure errored frame seconds event detection:
Step Command Remarks
1. Enter system view.
2. Configure the errored frame
seconds event detection
interval.
3. Configure the errored frame
seconds event triggering
threshold.
system-view
oam errored-frame-seconds
period
oam errored-frame-seconds
threshold
period-value
threshold-value
N/A
Optional.
60 second by default.
Optional.
1 by default.
Configuring Ethernet OAM remote loopback
Enabling Ethernet OAM remote loopback
CAUTION:
Use this function with caution, because enabling Ethernet OAM remote loopback impacts other
services.
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.
Y ou can enable Ethernet OAM remote l oopback on a specific port in user view , system view , or Layer
2 Ethernet interface view. The configuration effects are the same.
Configuration guidelines
• Ethernet OAM remote loopback is available only after the Ethernet OAM connection is
established and can be performed only by 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 must be supported by both the remote port and the sending
port.
• 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 can be disabled by any of the following actions: executing the undo
oam enable command to disable Ethernet OAM; executing the undo oam loopback interface
or undo oam loopback command to disable Ethernet OAM remote loopback; and Ethernet
OAM connection timing out.
• 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 a bout link
aggregation groups, see 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 Layer 2—LAN Switching
Configuration Guide
.
Configuration procedure
To enable Ethernet OAM remote loopback in user view:
10
Task Command Remarks
Enable Ethernet OAM remote
loopback on a specific port.
To enable Ethernet OAM remote loopback in system view:
oam loopback interface
interface-type interface-number
Disabled by default.
Step Command Remarks
1. Enter system view.
2. Enable Ethernet OAM
remote loopback on a
specific port.
To enable Ethernet OAM remote loopback in Layer 2 Ethernet interface view:
system-view
oam loopback interface
interface-type interface-number
N/A
Disabled by default.
Step Command Remarks
1. Enter system view.
2. Enter Layer 2 Ethernet
interface view.
3. Enable Ethernet OAM
remote loopback on the port.
system-view
interface
interface-number
oam loopback
interface-type
N/A
N/A
Disabled by default.
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.
To reject the Ethernet OAM remote loopback request from a remote port:
Step Command Remarks
1. Enter system view.
2. Enter Layer 2 Ethernet
interface view.
3. Reject the Ethernet OAM
remote loopback request
from a remote port.
system-view
interface
interface-number
oam loopback reject-request
interface-type
N/A
N/A
By default, a port does not reject
the Ethernet OAM remote
loopback request from a remote
port.
Displaying and maintaining Ethernet OAM configuration
Task Command Remarks
Display global Ethernet OAM
configuration.
display oam configuration
begin
{
regular-expression ]
exclude
|
11
include
|
}
[ |
Available in any view
Task Command Remarks
display oam critical-event
interface
Display the statistics on critical
events after an Ethernet OAM
connection is established.
[
interface-number ] [ | {
exclude
regular-expression ]
interface-type
include
|
}
begin
|
Available in any view
Display the statistics on Ethernet
OAM link error events after an
Ethernet OAM connection is
established.
Display the information about an
Ethernet OAM connection.
Clear statistics on Ethernet OAM
packets and Ethernet OAM link
error events.
display oam link-event { local
remote
interface-type interface-number ]
[ | {
regular-expression ]
display oam { local
interface
[
interface-number ] [ | {
exclude
regular-expression ]
reset oam [ interface
interface-type interface-number ]
} [
begin
|
interface
exclude
|
interface-type
include
|
|
}
include
remote }
begin
|
Available in any view
}
|
Available in any view
Available in user view
Ethernet OAM configuration example
Network requirements
On the network shown in Figure 2, perform the following operations:
• Enable Ethernet OAM on Device A and Device B to auto-detect link errors between the two
devices
• Monitor the performance of the link between Device A and Device B by collecting statistics
about the error frames received by Device A
Figure 2 Network diagram
Configuration procedure
1. Configure Device A:
# Configure Ethernet 1/0/1 to operate in passive Ethernet OAM mode and enable Ethernet
OAM for it.
<DeviceA> system-view
[DeviceA] interface ethernet 1/0/1
[DeviceA-Ethernet1/0/1] oam mode passive
[DeviceA-Ethernet1/0/1] oam enable
[DeviceA-Ethernet1/0/1] quit
# Set the errored frame detection interval to 20 seconds and set the errored frame event
triggering threshold to 10.
[DeviceA] oam errored-frame period 20
[DeviceA] oam errored-frame threshold 10
2. Configure Device B:
12
# Configure Ethernet 1/0/1 to operate in active Ethernet OAM mode (the default) and enable
Ethernet OAM for it.
<DeviceB> system-view
[DeviceB] interface ethernet 1/0/1
[DeviceA-Ethernet1/0/1] oam mode active
[DeviceB-Ethernet1/0/1] oam enable
[DeviceB-Ethernet1/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 Device A.
[DeviceA] 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 Device A.
[DeviceA] display oam critical-event
Port : Ethernet1/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 Device A and Device
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 Device B.
[DeviceB] display oam link-event remote
Port :Ethernet1/0/1
Link Status :Up
OAMRemoteErrFrameEvent : (ms = milliseconds)
--------------------------------------------------------------------Event Time Stamp : 5789 Errored FrameWindow : 200(100ms)
13
Errored Frame Threshold : 10 Errored Frame : 13
Error Running Total : 350 Event Running Total : 17
The output shows that 350 errors occurred since Ethernet OAM was enabled on Device A, 17 of
which are caused by error frames. The link is unstable.
14
Configuring CFD (available only on the HPE 3100 v2 EI)
Overview
Connectivity Fault Detection (CFD) is an end-to-end per-VLAN link layer OAM mechanism used for
link connectivity detection, fault verification, and fault location. It conforms to IEEE 802.1ag CFM and
ITU-T Y.1731.
Basic CFD concepts
This section explains the concepts of CFD.
MD
A maintenance domain (M D) defines the network or part of the network where CFD plays its role. An
MD is identified by its MD name.
To accurately locate faults, CFD assigns eight levels ranging from 0 to 7 to MDs. The bigger the
number, the higher the leve l, and the larger the area covered. If the outer domain has a higher level
than the nested one, domains can touch or nest, but they cannot intersect or overlap.
MD levels facilitate fault location and its accuracy. As shown in Figure 3, MD_A
in light blue nests
MD_B in dark blue. If a connectivity fault is detected at the boundary of MD_A, any of the devices in
MD_A, including Device A through Device E, may fail. If a connectivity fault is also detected at the
boundary of MD_B, the failure points may be any of Device B through Device D. If the devices in
MD_B can operate properly, at least Device C is operational.
Figure 3 Two nested MDs
Port
Port2
Port1 Port3
Device A Device B Device C Device D
Port4 Port4 Port4 Port4
Port1 Port3
Port1 Port3
Device E
Port2
Port2
Port4
Port2
Port1 Port3
Port2
Port1 Port3
MD_B
MD_A
VLAN 100
CFD exchanges messages and performs operations on a per-domain basis. By planning MDs
properly in a network, you can use CFD to rapidly locate failure points.
MA
A maintenance association (MA) is a part of an MD. You can configure multiple MAs in an MD as
needed. An MA is identified by the "MD name + MA name".
15
MP
An MA serves a VLAN. Packets sent by the MPs in an MA carry the relevant VLAN tag. An MP can
receive packets sent by other MPs in the same MA. The level of an MA equals the level of the MD
that the MA belongs to.
An MP is configured on a port and belongs to an MA. MPs include maintenance association end
points (MEPs) and maintenance association intermediate points (MIPs).
• MEPs
MEPs define the boundary of the MA. Each MEP is identified by a MEP ID.
The MA to which a MEP belongs defines the VLAN of packets sent by the MEP. The level of a
MEP is equal to the level of the MD to which the MEP belongs, and the level of packets sent by
a MEP equals the level of the MEP. The level of a MEP determines the levels of packets that the
MEP can process. A MEP forwards packets at a higher level and processes packets of its own
level or lower. The processing procedure is specific to packets in the same VLAN. Packets of
different VLANs are independent.
MEPs are either inward-facing or outward-facing. An outward-facing MEP sends packets to its
host port. An inward-facing MEP does not send packet s to its host port. Rather, it sends packets
to other ports on the device.
• MIP
A MIP is internal to an MA. It cannot send CFD packets actively. However, a MIP can handle
and respond to CFD packets. By cooperating with MEPs, a MIP can perform a function similar
to ping and traceroute. A MIP forwards packets of a different level without any processing and
only processes packet of its own level.
The MA to which a MIP belongs defines the VLAN of packets that the MEP can receive. The
level of a MIP is defined by its generation rule and the MD that the MIP belongs to. MIPs are
generated on each port automatically according to related MIP generation rules. If a port has no
MIP, the system will examine the MAs in each MD (from low to high levels), and follow the
procedure as described in Figure 4 to determin
e whether to create MIPs at the relevant level.
Figure 4 Procedure of creating MIPs
Figure 5 demonstrates a grading example of the CFD module. Four levels of MDs (0, 2, 3, and 5) are
designed. The bigger the number, the higher the level, and the larger the area covered. MPs are
configured on the ports of device A through device F. Port 1 of device B is configured with the
following MPs—a level 5 MIP, a level 3 inward-facing MEP, a level 2 inward-facing MEP, and a level
0 outward-facing MEP.
16
Figure 5 CFD grading example
MEP list
A MEP list is a collection of configurable local MEPs and the remote MEPs to be monitored in the
same MA. It lists all MEPs configured on different devices in the same MA. The MEPs all have
unique MEP IDs. When a MEP receives from a remote device a continuity check message (CCM)
with a MEP ID not included in the MEP list of the MA, it drops the message.
CFD functions
CFD works effectively only in properly configured networks. Its functions, which are implemented
through the MPs, include:
• Continuity check (CC)
• Loopback (LB)
• Linktrace (LT)
• Alarm indication signal (AIS)
• Loss measurement (LM)
• Delay measurement (DM)
• Test (TST)
CC
Connectivity faults are usua lly caused by device faults or configuration errors. CC examines the
connectivity between MEPs. This function is implemented through periodic sending of continuity
check messages (CCMs) by the MEPs. A CCM sent by one MEP is intended to be received by all of
the other MEPs in the same MA. If a MEP fails to receive the CCMs within 3.5 times the sending
interval, the link is considered faulty and a log is generated. When multiple MEPs send CCMs at the
same time, the multipoint-to-multipoint link check is achieved. CCM frames are multicast frames.
LB
Similar to ping at the IP layer, LB verifies the connectivity between a source device and a target
device. To implement this function, the source MEP sends loopback messages (LBMs) to the target
MEP. Depending on whether the source MEP can receive a loopback reply message (LBR) from the
17
LT
AIS
LM
target MEP, the link state between the two can be verified. LBM frames and LBR frames are unicast
frames.
LT is similar to traceroute. It identifies the path between the source MEP and the target MP. This
function is implemented in the following way—the source MEP sends the linktrace messages (LTMs)
to the target MP. After receiving the messages, the target MP and the MIPs that the L TM frames pass
send back linktrace reply messages (LTRs) to the source MEP. Based on the reply messages, the
source MEP can identify the path to the target MP. LTM frames are multicast frames and LTRs are
unicast frames.
The AIS function suppresses the numbe r of error ala rms reported by MEPs. If a local MEP receives
no CCM frames from its peer MEP within 3.5 times the CCM transmission interval, it immediately
starts to send AIS frames periodically in the opposite direction of CCM frames. Upon receiving the
AIS frames, the peer MEP suppresses the error alarms locally , and continues to send the AIS frames.
If the local MEP receives CCM frames within 3.5 times the CCM transmission interval, it stops
sending AIS frames and restores the error alarm function. AIS frames are multicast frames.
The LM function measures the frame loss in a certain direction between a pair of MEPs. The source
MEP sends loss measurement messages (LMMs) to the target MEP, the target MEP responds with
loss measurement replies (LMRs), and the source MEP calculates the number of lost frames
according to the counter values of the two consecutive LMRs (the current LMR and the previous
LMR). LMMs and LMRs are multicast frames.
DM
TST
The DM function measures frame delays between two MEPs, including one-way and two-way frame
delays.
1. One-way frame delay measurement
The source MEP sends a one-way delay measurement (1DM) frame, which carries the
transmission time, to the target MEP. Upon receiving the 1DM frame, the target MEP records
the reception time, and calculates and records the link transmission delay and jitter (delay
variation) according to the transmission time and reception time. 1DM frames are multicast
frames.
2. Two-way frame delay measurement
The source MEP sends a delay measurement message (DMM), which carries the transmi ssion
time, to the target MEP. Upon receiving the DMM, the target MEP responds with a delay
measurement reply (DMR), which carries the reception time and transmission time of the DMM
and the transmission time of the DMR. Upon receiving the DMR, the source MEP reco rds the
DMR reception time, and calculates the link transmission delay and jitter according to the DMR
reception time and DMM transmission time. DMM frames and DMR frames are multicast
frames.
The TST function tests the bit errors between two MEPs. The source MEP sends a TST frame, whi ch
carries the test pattern, such as pseudo random bit sequence (PRBS) or all-zero, to the target MEP.
Upon receiving the TST frame, the target MEP determines the bit errors by calculating and
comparing the content of the TST frame. TST frames are unicast frames.
Protocols and standards
• IEEE 802.1ag, Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault
Management
• ITU-T Y.1731, OAM functions and mechanisms for Ethernet based networks
18
CFD configuration task list
For CFD to operate properly, design the network by performing the following tasks:
• Grade the MDs in the entire network and define the boundary of each MD.
• Assign a name for each MD. Make sure the same MD has the same name on different devices.
• Define the MA in each MD according to the VLAN you want to monitor.
• Assign a name for each MA. Make sure the same MA in the same MD has the same name on
different devices.
• Determine the MEP list of each MA in each MD. Make sure devices in the same MA maintain
the same MEP list.
• At the edges of MD and MA, MEPs should be designed at the device port. MIPs can be
designed on devices or ports that are not at the edges.
Tasks Remarks
Enabling CFD Req
Configuring the CFD protocol version Optional.
Creating a service instance
ith the MD name
Configuring basic CFD settings
Configuring
service instances
w
Creating a service instance
without the MD name
uired.
Required.
Perform either task.
Configuring MEPs Required.
Configuring MIP generation rules Required.
uired.
Configuring CFD
functions
Configuring CC on MEPs Req
Configuring LB on MEPs Optional.
Configuring LT on MEPs Optional.
Configuring AIS Optional.
Configuring LM Optional.
Configuring one-way DM Optional.
Configuring two-way DM Optional.
Configuring TST Optional.
Typically, a port blocked by the spanning tree feature cannot receive or send CFD messages except
in the following cases:
• The port is configured as an outward-facing MEP.
• The port is configured as a MIP or an inward-facing MEP that can still receive and send CFD
messages except CCM messages.
For more information about the spanning tree feature, see Layer 2—LAN Switching Configuration
Guide.
Configuring basic CFD settings
This section provides procedures for configuring basic CFD setting s.
19
Enabling CFD
Enable CFD before you perform other configuration tasks.
To enable CFD on a device:
Step Command Remarks
1. Enter system view.
system-view
N/A
2. Enable CFD.
cfd enable
Configuring the CFD protocol version
Three CFD protocol versions are available: IEEE 802.1ag draft5.2 version, IEEE 802.1ag draft5.2
interim version, and IEEE 802.1ag standard version.
Devices in the same MD must use the same CFD protocol ve rsion. Otherwise, they cannot exchange
CFD protocol packets.
If an MD is created by using the cfd md command or automatically generated by using the cfd
service-instance maid format command on a device, you cannot switch between the standard
version and draft5.2 version (or draft5.2 interim version). However, you can switch between the
draft5.2 version and draft5.2 interim version. This restriction does not apply to the device without an
MD configured.
To configure the CFD protocol version:
Step Command Remarks
1. Enter system view.
2. Configure the CFD protocol
version.
system-view
cfd version
standard
|
}
draft5
{
draft5-plus
|
By default, CFD is disabled.
N/A
Optional.
By default, CFD uses the
standard version of IEEE
802.1ag.
Configuring service instances
Before configuring the MEPs and MIPs, first configure service instances. A service instance is a set
of service access points (SAPs), and belongs to an MA in an MD.
A service instance is indi cated by an integer to represent an MA in an MD. The MD and MA define the
level and VLAN attribute of the messages handled by the MPs in a service instance.
Service instances fall into two types:
• Service instance with the MD name, which takes effect in any version of CFD.
• Service instance without the MD name, which takes effect in only CFD IEEE 802.1ag.
You can create either type of service instance as needed.
Creating a service instance with the MD name
To create a service instance with the MD name, create the MD and MA for the service instance first.
To configure a service instance with the MD name:
Step Command Remarks
1. Enter system view.
system-view
N/A
20
Step Command Remarks
2. Create an MD.
cfd md
level-value
md-name
level
By default, no MD is created.
3. Create an MA.
4. Create a service instance
with the MD name
cfd ma
vlan
cfd service-instance
md
ma-name
vlan-id
md-name
ma
Creating a service instance without the MD name
When you create a service instance without the MD name, the system automati cally creates th e MA
and MD for the service instance.
To create a service instance without the MD name:
Step Command Remarks
1. Enter system view.
2. Create a service instance
without the MD name.
system-view
cfd service-instance
format
ma-name }
icc-based
{
level
Configuring MEPs
CFD is implemented through various operations on MEPs. A MEP is configured on a service
instance, so the MD level and VLAN attribute of the service instance become the attribute of the
MEP.
md
md-name
instance-id
ma-name
instance-id
ma-name |
level-value
vlan
By default, no MA is created.
By default, no service instance
with the MD name is created.
N/A
maid
string
vlan-id
By default, no service
instance without the MD
name is created.
Before creating MEPs, configure the MEP list. A MEP list is a collection of local configurable MEPs in
an MA and the remote MEPs to be monitored.
To configure a MEP:
Step Command Remarks
1. Enter system view.
2. Configure a MEP list.
3. Enter Layer 2 Ethernet
interface view.
4. Create a MEP.
5. Enable the MEP.
system-view
cfd meplist
service-instance
interface
interface-number
cfd mep
service-instance
inbound
{
cfd mep service-instance
instance-id
mep-list
interface-type
mep-id
outbound
|
mep
Configuring MIP generation rules
instance-id
instance-id
}
enable
mep-id
N/A
By default, no MEP list is
configured.
To create a MEP, the MEP ID
must be included in the MEP list
of the service instance.
N/A
By default, no MEP is created.
By default, the MEP is disabled.
As functional entities in a service instance, MIPs respond to various CFD frames, such as LTM
frames, LBM frames, 1DM frames, DMM frames, and TST frames. You can choose appropriate MIP
generation rules based on your network design.
21
Any of the following actions or cases can cause MIPs to be created or deleted after you configure the
cfd mip-rule command:
• Enabling or disabling CFD (use the cfd enable command).
• Creating or deleting the MEPs on a port.
• Changes occur to the VLAN attribute of a port.
• The rule specified in the cfd mip-rule command changes.
To configure the rules for generating MIPs:
Step Command Remarks
1. Enter system view.
system-view
N/A
2. Configure the rules for
generating MIPs.
cfd mip-rule { default | explicit }
service-instance
Configuring CFD functions
This section provides information about configuring CFD functions.
Configuration prerequisites
Complete basic CFD settings.
Configuring CC on MEPs
This section describes how to configure CC on MEPs.
Configuration guidelines
• Configure CC before you configure other CFD functions. After the CC function is configured,
MEPs can send CCM frames to each other to examine the connectivity between them.
• Configure the same interval field value in CCM messages sent by the MEPs belonging to the
same MA.
instance-id
By default, neither MIPs nor the
rules for generating MIPs are
configured.
Table 9 Relationship between the interval field value in the CCM message, the interval
between CCM messages, and the timeout time of the remote MEP
The interval field value
in the CCM message
4 1 second 3.5 seconds
5 10 second 35 seconds
6 60 seconds 210 seconds
7 600 seconds 2100 seconds
Configuration procedure
To configure CC on a MEP:
Step Command Remarks
1. Enter system view.
The interval between CCM
messages
system-view
22
The timeout time of the remote
MEP
N/A
Step Command Remarks
2. Configure the interval field
value in the CCM messages
sent by MEPs.
3. Enter Layer 2 Ethernet
interface view.
cfd cc interval
interval-value
service-instance
instance-id
interface
interface-number
interface-type
Optional.
By default, the interval field value is 4.
N/A
4. Enable CCM sending on a
MEP.
Configuring LB on MEPs
The LB function can verify the link state between the local MEP and the remote MEP or MIP.
To configure LB on a MEP:
Task Command Remarks
Enable LB.
Configuring LT on MEPs
L T can trace the path bet ween the source and target MEPs, and can also locate link faults by sending
LT messages automatically. The two functions are implemented in the following way:
• To implement the first function, the source MEP first sends LTM messages to the target MEP.
Based on the LTR messages in response to the LTM messages, the path between the two
MEPs can be identified.
• In the latter case, after LT messages automatic sending is enabled, if the source MEP fails to
receive the CCM frames from the target MEP within 3.5 times the transmission interval, the link
between the two is considered faulty. LTM frames will be sent out with the target MEP as the
destination and the TTL fie ld in the LTM frames set to the maximum value 255. Based on the
LTRs that the MIPs return, the fault source can be located.
cfd cc service-instance
instance-id
enable
cfd loopback service-instance
instance-id
target-mep
{
target-mac
number
[
mep
mep
target-mep-id |
mac-address }
number ]
mep-id
mep-id
By default, CCM sending on a MEP is
disabled.
By default, LB is disabled.
Available in any view.
To configure LT on MEPs:
Step Command Remarks
1. Find the path between a
source MEP and a target
MEP.
2. Enter system view.
3. Enable LT messages
automatic sending.
cfd linktrace service-instance
instance-id
target-mep-id |
mac-address } [
hw-only
[
system-view
cfd linktrace auto-detection [ size
size-value ]
mep
target-mac
]
23
mep-id {
ttl
target-mep
ttl-value ]
Available in any view.
N/A
By default, LT messages
automatic sending is disabled.
Configuring AIS
The AIS function suppresses the number of error alarms reported by MEPs.
Configuration guidelines
• To have a MEP in the service instance send AIS frames, configure the AIS frame transmission
level to be higher than the MD level of the MEP.
• Enable AIS and configure the prope r AIS frame transmission level on the target MEP, so the
target MEP can suppress the error alarms an d send the AIS frame to the MD of a higher level. If
you enable AIS but do not configure the proper AIS fra me transmission level on the target MEP,
the target MEP can suppress the error alarms, but cannot send the AIS frames.
Configuration procedure
To configure AIS:
Step Command Remarks
1. Enter system view.
2. Enable AIS.
system-view
cfd ais enable
N/A
By default, AIS is disabled.
3. Configure the AIS frame
transmission level.
4. Configure the AIS frame
transmission interval.
Configuring LM
The LM function measures frame loss between MEPs, including the number of lost frames, the frame
loss ratio, and the average number of lost frames for the source and target MEPs. The LM function
takes effect only in CFD IEEE 802.1ag.
To configure LM:
Step Command Remarks
1. Enter system view.
2. Configure LM.
cfd ais level
service-instance
cfd ais period
service-instance
system-view
cfd slm service-instance
instance-id
target-mac
{
target-mep
number
[
level-value
period-value
mep
mac-address |
target-mep-id }
number ]
instance-id
instance-id
mep-id
By default, the AIS frame
transmission level is not
configured.
Optional.
The default is 1 second.
N/A
By default, LM is disabled.
Configuring one-way DM
The one-way DM function measures the one-way frame delay between two MEPs, and monitors and
manages the link transmission performance.
Configuration guidelines
• The one-way DM function takes effect only in CFD IEEE 802.1ag.
• One-way DM requires that the clocks at the transmitting MEP and the receiving MEP be
synchronized. For the purpose of frame delay variation measurement, the requirement for clock
synchronization can be relaxed.
24
• To view the test result, use the display cfd dm one-way history command on the target MEP.
Configuration procedure
To configure one-way DM:
Step Command Remarks
1. Enter system view.
2. Configure one-way DM.
Configuring two-way DM
The two-way DM function measures the two-way frame delay, average two-way frame delay, and
two-way frame delay variation between two MEPs, and monitors and manages the link transmission
performance. The two-way DM function is available only under the IEEE 802.1ag standard version of
CFD.
To configure two-way DM:
system-view
cfd dm one-way
service-instance
mep
mep-id {
mac-address |
target-mep-id } [
number ]
target-mac
target-mep
instance-id
number
N/A
By default, one-way DM is
disabled.
Step Command Remarks
1. Enter system view.
2. Configure two-way DM.
Configuring TST
The TST function detects bit errors on a link, and monitors and manages the link transmission
performance. The TST function takes effect only in CFD IEEE 802.1ag.
To configure TST:
Step Command Remarks
1. Enter system view.
2. Configure TST .
system-view
cfd dm two-way
service-instance
mep
mep-id {
mac-address |
target-mep-id } [
number ]
system-view
cfd tst service-instance
instance-id
{
target-mep
[
[
[
prbs
target-mac
number
length-of-test
pattern-of-test { all-zero
with-crc
} [
number ]
instance-id
target-mac
target-mep
number
mep
mep-id
mac-address |
target-mep-id }
length ]
] ]
N/A
By default, two-way DM is
disabled.
N/A
By default, TST is disabled.
To view the test result, use the
display cfd tst
target MEP.
|
command on the
25
Loading...