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.
Major functions of Ethernet OAM ·························································································································· 1
Ethernet OAMPDUs ·················································································································································· 1
How Ethernet OAM works ······································································································································ 1
Protocols and standards ·········································································································································· 3
Ethernet OAM configuration task list ······························································································································ 4
Configuring basic Ethernet OAM functions ···················································································································· 4
Configuring the Ethernet OAM connection detection timers ························································································ 4
Configuring link monitoring ············································································································································· 5
Configuring errored symbol event detection ········································································································· 5
Configuring errored frame period event detection ······························································································· 7
Configuring errored frame seconds event detection ···························································································· 7
Configuring the action a port takes after it receives an Ethernet OAM event from the remote end ························ 8
Configuring Ethernet OAM remote loopback ················································································································ 9
Enabling Ethernet OAM remote loopback on a specific port ············································································· 9
Enabling Ethernet OAM remote loopback on the port ······················································································ 10
Rejecting the Ethernet OAM remote loopback request from a remote port ···················································· 10
Displaying and maintaining Ethernet OAM ················································································································ 10
Ethernet OAM configuration example ························································································································· 11
Configuring service instances ······························································································································ 19
Configuring CC on MEPs ····································································································································· 21
Configuring LB on MEPs ······································································································································· 22
Configuring LT on MEPs ········································································································································ 22
CFD configuration example ·········································································································································· 26
How RRPP works ···················································································································································· 51
Configuring RRPP nodes ······································································································································· 59
Activating an RRPP domain ··········································································································································· 61
Configuring RRPP timers ················································································································································ 61
Configuring an RRPP ring group ·································································································································· 62
Displaying and maintaining RRPP ································································································································ 62
RRPP configuration examples ········································································································································ 63
Single ring configuration example ······················································································································ 63
Intersecting ring configuration example ·············································································································· 65
Dual-homed rings configuration example ··········································································································· 71
Configuring Smart Link ·············································································································································· 93
How Smart Link works ·········································································································································· 94
Smart Link collaboration mechanisms ················································································································· 95
Smart Link configuration task list ·································································································································· 96
Configuring a Smart Link device ·································································································································· 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
ii
Configuring the collaboration between Smart Link and Track ········································································· 99
Configuring an associated device ······························································································································· 99
Enabling the receiving of flush messages ··········································································································· 99
Displaying and maintaining Smart Link ····················································································································· 100
Smart Link configuration examples ···························································································································· 100
Single smart link group configuration example ······························································································· 100
Multiple smart link groups load sharing configuration example ···································································· 105
Smart Link and Track collaboration configuration example ··········································································· 109
Configuring Monitor Link ········································································································································ 115
Overview ······································································································································································· 115
Configuration restrictions and guidelines ·················································································································· 116
Monitor Link configuration task list ····························································································································· 116
Enabling Monitor Link globally ··································································································································· 116
Creating a monitor link group ··························································································································· 116
Configuring monitor link group member interfaces ························································································· 117
Configuring the switchover delay for the downlink interfaces in a monitor link group ······························· 117
Displaying and maintaining Monitor Link ················································································································· 118
Monitor Link configuration example ·························································································································· 118
BFD session modes and operating modes ········································································································ 123
Supported features ·············································································································································· 124
Collaboration application example ··················································································································· 130
Track configuration task list ········································································································································· 130
Associating the Track module with a detection module ··························································································· 131
Associating Track with NQA ····························································································································· 131
Associating Track with BFD ································································································································ 131
Associating Track with CFD ······························································································································· 132
Associating Track with interface management ································································································· 132
Associating the Track module with an application module ····················································································· 133
Associating Track with static routing ················································································································· 133
Associating Track with PBR ································································································································ 134
Associating Track with Smart Link ····················································································································· 136
Displaying and maintaining track entries ·················································································································· 136
Track configuration examples ····································································································································· 136
Static routing-Track-NQA collaboration configuration example ···································································· 136
Static routing-Track-BFD collaboration configuration example ······································································· 141
Smart Link-Track-CFD collaboration configuration example ··········································································· 144
Support and other resources ·································································································································· 145
Contacting HP ······························································································································································ 145
Subscription service ············································································································································ 145
iii
Related information ······················································································································································ 145
Index ········································································································································································ 148
iv
Configuring Ethernet OAM
yp
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." Ethernet OAM improves Ethernet
management and maintainability. 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 operates 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 include the following types shown in Table 1.
Table 1 Functions of
OAMPDU t
Information OAMPDU
Event Notification
OAMPDU
Loopback Control
OAMPDU
NOTE:
Throughout this document, an Ethernet OAM-enabled port is called an Ethernet OAM entity or an OAM
entity.
different types of OAMPDUs
e Function
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.
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.
1
Ethernet OAM connection establishment
p
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 the remote
OAM entity to establish a session.
In this phase, two connected OAM entities exchange Information OAMPDUs to advertise their OAM
configuration and capabilities to each other for a comparison. If their Loopback, link detection, and link
event settings match, the OAM entities establish an OAM connection.
An OAM entity operates in active mode or passive mode. OAM entities in active mode initiate OAM
connections, and OAM entities in passive mode wait and respond to the OAM connection requests. To
set up an OAM connection between two OAM entities, you must set at least one entity to operate in
active mode.
Table 2 sho
ws the actions that a device can perform in different modes.
Table 2 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
Transmitting Information
OAMPDUs without any TLV
Transmitting Loopback Control
OAMPDUs
Responding to Loopback Control
OAMPDUs
Available Available
Available Available
Available Available
Available Unavailable
Available when both sides are
operating in active OAM mode
Passive Ethernet OAM mode
Available
After an Ethernet OAM connection is established, the Ethernet OAM entities exchange Information
OAMPDUs at the handshake packet transmission interval to detect the availability of the Ethernet OAM
connection. 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 detects link faults in various environments. Ethernet OAM entities monitor link status by
exchanging Event Notification OAMPDUs. When detecting one of the link error events listed in Table 3,
an O
AM entity sends an Event Notification OAMPDU to its peer OAM entity. The network administrator
can keep track of network status changes by retrieving the log.
Table 3 Ethernet OAM link error events
Ethernet OAM link events Descri
An errored symbol event occurs when the number of detected symbol errors
Errored symbol event
in the detection window (specified number of received symbols) exceeds the
predefined threshold.
tion
2
Ethernet OAM link events Description
yp
Errored frame event
Errored frame period event
Errored frame seconds event
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 (any
critical link event type shown in Table 4) to its peer
status and troubleshoot problems promptly.
Table 4 Critical link events
T
e Description OAMPDU transmission frequencies
An errored frame event occurs when the number of detected error frames in
the detection window (specified detection interval) exceeds the predefined
threshold.
An errored frame period event occurs when the number of frame errors in
the detection window (specified number of received frames) exceeds the
predefined threshold.
An errored frame seconds event occurs when the number of errored frame
seconds (the second in which an errored frame appears is called an errored
frame second) detected on a port in the detection window (specified
detection interval) reaches the predefined threshold.
. You can use the log information to track ongoing link
Link Fault Peer link signal is lost. Once per second.
Dying Gasp
Critical Event An undetermined critical event happened. Non-stop.
The switch is able to receive Information OAMPDUs carrying the critical link events listed in Table 4.
The switch is able to send Information OAMPDUs carrying Link Fault events.
The switch is able to send Information OAMPDUs carrying Dying Gasp events when the switch is
rebooted or relevant ports are manually shut down. Physical IRF ports, however, are unable to send this
type of OAMPDUs.
The switch 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 in active 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.
An unexpected fault, such as power failure,
occurred.
Non-stop.
Protocols and standards
IEEE 802.3ah, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications
• Enabling Ethernet OAM remote loopback on a specific port
• Enabling Ethernet OAM remote loopback on the port
• Rejecting the Ethernet OAM remote loopback request from a remote port
Configuring basic Ethernet OAM functions
To set up an Ethernet OAM connection between two Ethernet OAM entities, you must set at least one
entity to operate in active mode. An Ethernet OAM entity can initiate OAM connection only in active
mode.
To change the Ethernet OAM mode on an Ethernet OAM-enabled port, first disable Ethernet OAM on the
port.
To configure basic Ethernet OAM functions:
Step Command
1. Enter system view.
2. Enter Layer 2 Ethernet port
view.
3. Set the Ethernet OAM mode.
4. Enable Ethernet OAM.
System-view N/A
interface interface-type
interface-number
oam mode { active | passive }
oam enable
Remarks
N/A
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 exchange Information
OAMPDUs at the handshake packet transmission interval to detect the availability of the Ethernet OAM
4
connection. 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.
You c an c onfig ure this c ommand i n syste m view o r port view. The config urat ion i n syste m view ta kes ef fect
on all ports, and the configuration in port view takes effect on the specified port. For a port, the
configuration in port view takes precedence.
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 disconnect. To keep the Ethernet
OAM connections stable, HP recommends that you set the connection timeout timer to be at least five
times the handshake packet transmission interval.
To configure the Ethernet OAM connection detection timers globally:
Step Command
1. Enter system view.
2. Configure the Ethernet OAM
handshake packet
transmission interval.
3. Configure the Ethernet OAM
connection timeout timer.
To configure the Ethernet OAM connection detection timers on a port:
System-view N/A
oam global timer hello interval The default is 1000 milliseconds.
oam global timer keepalive
interval
Step Command
1. Enter system view.
2. Enter Layer 2 Ethernet port
view.
3. Configure the Ethernet OAM
handshake packet
transmission interval.
4. Configure the Ethernet OAM
connection timeout timer.
System-view N/A
interface interface-type interface-number
oam timer hello interval
oam timer keepalive interval
Remarks
The default is 5000 milliseconds.
Remarks
N/A
By default, an interface uses the
value configured globally.
By default, an interface uses the
value configured globally.
Configuring link monitoring
After Ethernet OAM connections are established, the link monitoring periods and thresholds configured
in this section automatically take effect on all Ethernet ports.
Configuring errored symbol event detection
An errored symbol event occurs when the number of detected symbol errors in the detection window
(specified number of received symbols) exceeds the predefined threshold.
You c an c onfig ure this c ommand i n syste m view o r port view. The config urat ion i n syste m view ta kes ef fect
on all ports, and the configuration in port view takes effect on the specified port. For a port, the
configuration in port view takes precedence.
5
To configure errored symbol event detection globally:
Step Command
1. Enter system view.
2. Configure the errored symbol
event detection window.
3. Configure the errored symbol
event triggering threshold.
To configure errored symbol event detection on a port:
system-view N/A
oam global errored-symbol-period
window window-value
oam global errored-symbol-period
threshold threshold-value
By default, the errored symbol
event detection window is
100000000.
By default, the errored symbol
event triggering threshold is 1.
Remarks
N/A
By default, an interface uses the
value configured globally.
By default, an interface uses the
value configured globally.
Configuring errored frame event detection
An errored frame event occurs when the number of times that error frames in the detection window
(specified detection interval) are detected exceeds the predefined threshold.
You c an c onfig ure this c ommand i n syste m view o r port view. The config urat ion i n syste m view ta kes ef fect
on all ports, and the configuration in port view takes effect on the specified port. For a port, the
configuration in port view takes precedence.
To configure errored frame event detection globally:
Step Command
1. Enter system view.
2. Configure the errored frame
event detection window.
3. Configure the errored frame
event triggering threshold.
To configure errored frame event detection on a port:
Step Command
1. Enter system view.
system-view N/A
oam global errored-frame window
window-value
oam global errored-frame
threshold threshold-value
system-view N/A
Remarks
By default, the errored frame event
detection window is 1000
milliseconds.
By default, the errored frame event
triggering threshold is 1.
Remarks
2. Enter Layer 2 Ethernet port
view.
interface interface-type
interface-number
6
N/A
Step Command
gg
w
3. Configure the errored frame
event detection window.
oam errored-frame window
window-value
Remarks
By default, an interface uses the
value configured globally.
4. Configure the errored frame
event triggering threshold.
oam errored-frame threshold
threshold-value
By default, an interface uses the
value configured globally.
Configuring errored frame period event detection
An errored frame period event occurs when the number of times that frame errors in the detection window
(specified number of received frames) are detected exceeds the predefined threshold.
You c an c onfig ure this c ommand i n syste m view o r port view. The config urat ion i n syste m view ta kes ef fect
on all ports, and the configuration in port view takes effect on the specified port. For a port, the
configuration in port view takes precedence.
To configure errored frame period event detection globally:
Step Command
1. Enter system view.
2. Configure the errored frame
period event detection
window.
3. Configure the errored frame
period event triggering
threshold.
system-view N/A
oam global errored-frame-period
window window-value
oam global errored-frame-period
threshold threshold-value
Remarks
By default, the errored frame
period event detection window is
10000000.
By default, the errored frame
period event triggering threshold is
1.
To configure errored frame period event detection on a port:
By default, an interface uses the
value configured globally.
By default, an interface uses the
value configured globally.
Configuring errored frame seconds event detection
CAUTION:
Make sure the errored frame seconds tri
indow. Otherwise, no errored frame seconds event can be generated.
ering threshold is less than the errored frame seconds detection
7
An errored frame seconds event occurs when the number of times that errored frame seconds are
detected on a port in the detection window (specified detection interval) exceeds the predefined
threshold.
You c an c onfig ure this c ommand i n syste m view o r port view. The config urat ion i n syste m view ta kes ef fect
on all ports, and the configuration in port view takes effect on the specified port. For a port, the
configuration in port view takes precedence.
To configure errored frame seconds event detection globally:
Step Command
1. Enter system view.
2. Configure the errored frame
seconds event detection
window.
3. Configure the errored frame
seconds event triggering
threshold.
To configure errored frame seconds event detection on a port:
system-view N/A
oam global errored-frame-seconds
window window-value
oam global errored-frame-seconds
threshold threshold-value
By default, the port only logs the
Ethernet OAM event it receives
from the remote end.
Configuring 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 and evaluate the link performance.
You can enable Ethernet OAM remote loopback on a specific port in user view, system view, or Layer 2
Ethernet port 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 events: disabling Ethernet OAM,
disabling Ethernet OAM remote loopback, and Ethernet OAM connection timing out.
• 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
.
Enabling Ethernet OAM remote loopback on a specific port
By default, Ethernet OAM remote
loopback is disabled.
This command can be executed in
user view or system view.
9
Enabling Ethernet OAM remote loopback on the port
Step Command
1. Enter system view.
2. Enter Layer 2 Ethernet port
view.
3. Enable Ethernet OAM remote
loopback on the port.
system-view N/A
interface interface-type interface-number
oam remote-loopback start
Remarks
N/A
By default, Ethernet OAM remote
loopback is disabled.
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
1. Enter system view.
2. Enter Layer 2 Ethernet port
view.
system-view N/A
interface interface-type interface-number
Remarks
N/A
By default, a port does not reject
the Ethernet OAM remote
loopback request from a remote
3. Reject the Ethernet OAM
remote loopback request from
a remote port.
oam remote-loopback
reject-request
port.
This setting does not affect the
loopback test that has been
performed on the port. It takes
effect when the next loopback
starts on the port.
Displaying and maintaining Ethernet OAM
Execute display commands in any view and reset commands in user view:
Purpose Command
Display information about an Ethernet OAM
connection.
Display Ethernet OAM configuration.
Display the statistics on critical events after an Ethernet
OAM connection is established.
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
-----------[GigabitEthernet1/0/1] ---------- Local link status : UP
Event statistics
Link fault : Not occurred
Dying gasp : Not occurred
Critical event : Not occurred
The output shows that no critical link event occurred on the link between Device A and Device B.
Use the display oam link-event command to display the statistics of Ethernet OAM link events. For
example:
# Display Ethernet OAM link event statistics of the local end of Device A.
[DeviceA] display oam link-event local
------------ [GigabitEthernet1/0/1] ---------- Link status: UP
OAM local errored frame event
Event time stamp : 5789 x 100 milliseconds
Errored frame window : 200 x 100 milliseconds
Errored frame threshold : 10 error frames
Errored frame : 13 error frames
Error running total : 350 error frames
Event running total : 17 events
The output shows that 350 errors occurred after Ethernet OAM is enabled on Device A, 17 of
which were caused by error frames. The link is unstable.
12
Configuring CFD
Overview
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 OAM mechanism. CFD is used for link
connectivity detection, fault verification, and fault location.
Basic CFD concepts
Maintenance domain
A maintenance domain (MD) 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 introduces eight levels (from 0 to 7) to MDs. The bigger the number, the
higher the level and the larger the area covered. Domains can touch or nest (if the outer domain has a
higher level than the nested one) but cannot intersect or overlap.
MD levels facilitate fault location and make fault location more accurate. As shown in Figure 2, MD_A
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, might fail. If a connectivity fault is also
detected at the boundary of MD_B, the failure points can be any of Device B through Device D. If the
devices in MD_B can operate correctly, at least Device C is operational.
Figure 2 Two nested MDs
in
CFD exchanges messages and performs operations on a per-domain basis. By planning MDs correctly
in a network, you can use CFD to rapidly locate failure points.
Maintenance association
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.
13
An MA serves the specified VLAN or no VLAN. An MA that serves a VLAN is considered to be carrying
VL AN attribute. An MA that serves no VLAN is considered to be carrying no VLAN attribute. 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.
Maintenance point
An MP is configured on a port and belongs to an MA. MPs include the following types: maintenance
association end points (MEPs) and maintenance association intermediate points (MIPs).
• MEP
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
equals the level of the MD to which the MEP belongs. 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 packet of its level or lower. The processing procedure is
specific to packets in the same VLAN. Packets of different VLANs are independent.
MEPs include inward-facing MEPs and outward-facing MEPs:
{ An outward-facing MEP sends packets to its host port.
{ An inward-facing MEP does not send packets 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, it 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 level.
The MA to which a MIP belongs defines the VLAN of packets that the MIP can receive. The level
of a MIP is defined by its generation rule and the MD to which the MIP belongs. MIPs are
generated on each port automatically according to related MIP generation rules:
{Default rule—If no lower-level MIP exists on an interface, a MIP is created on the current level.
A MIP can be created even if no MEP is configured on the interface.
{Explicit rule—If no lower-level MIP exists and a lower-level MEP exists on an interface, a MIP is
created on the current level. A MIP can be created only when a lower-level MEP is created on
the interface.
If a port has no M IP, t he sy stem will check the M As in each M D (fr om low to high le vels ), an d fol low
the procedure as described in Figure 3 to create or not
to create MIPs at the current level.
14
Figure 3 Procedure of creating MIPs
Figure 4 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.
MEP list
Figure 4 CFD grading example
A MEP list is a collection of local MEPs allowed to be configured and the remote MEPs to be monitored
in the same MA. It lists all the 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) that
carries a MEP ID not included in the MEP list of the MA, it drops the message.
15
The local device must send CCM messages carrying the Remote Defect Indication (RDI) flag bits;
otherwise, the peer device cannot sense certain failures. When at least one local MEP in an MA has not
learned all remote MEPs in the MEP list, the MEPs in the MA do not carry the RDI flag bits in CCMs.
CFD functions
CFD 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)
Continuity check
Connectivity faults are usually caused by device faults or configuration errors. Continuity check checks
the connectivity between MEPs. This function is implemented through periodic sending of CCMs by the
MEPs. A CCM sent by one MEP is intended to be received by all 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 as 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.
Loopback
Linktrace
AIS
Similar to ping at the IP layer, loopback 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 target MEP,
the link state between the two can be verified. LBM frames and LBR frames are unicast frames.
LBM frames are multicast and unicast frames. HP devices support sending and receiving unicast LBM
frames and receiving multicast LBM frames. HP devices do not support sending multicast LBM frames. LBR
frames are unicast frames.
Linktrace is similar to traceroute. It identifies the path between the source MEP and the target MP. The
source MEP sends the linktrace messages (LTMs) to the target MP. After receiving the messages, the target
MP and the MIPs that the LTM 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 number of error alarms reported by MEPs. If a local MEP does not receive
any CCM frames from its peer MEP within 3.5 times the CCM transmission interval, it immediately starts
sending AIS frames. The AIS frames are sent periodically in the opposite direction of CCM frames. When
the peer MEP receives the AIS frames, it 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.
16
NOTE:
LM
NOTE:
DM
This function is supported only by Release 3108P01 and later versions.
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). 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
unicast frames.
This function is supported only by Release 3108P01 and later versions.
The DM function measures frame delays between two MEPs, including the following types:
• 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. When the target MEP receives the 1DM frame, it does the following:
{ Records the reception time.
{ Calculates and records the link transmission delay and jitter (delay variation) according to the
transmission time and reception time.
NOTE:
TST
1DM frames are unicast frames.
• Two-way frame delay measurement
The source MEP sends a delay measurement message (DMM), which carries the transmission time,
to the target MEP. When the target MEP receives the DMM, it responds with a delay measurement
reply (DMR). The DMR carries the reception time and transmission time of the DMM and the
transmission time of the DMR. When the source MEP receives the DMR, it does the following:
{ Records the DMR reception time.
{ Calculates the link transmission delay and jitter according to the DMR reception time and DMM
transmission time.
DMM frames and DMR frames are unicast frames.
This function is supported only by Release 3108P01 and later versions.
The TST function tests the bit errors between two MEPs. The source MEP sends a TST frame, which carries
the test pattern, such as pseudo random bit sequence (PRBS) or all-zero, to the target MEP. When the
target MEP receives the TST frame, it determines the bit errors by calculating and comparing the content
of the TST frame. TST frames are unicast frames.
NOTE:
This function is supported only by Release 3108P01 and later versions.
17
EAIS
Ethernet Alarm Indication Signal (EAIS) enables collaboration between the Ethernet port status and the
AIS function. When a port on the device (not necessarily an MP) goes down, it immediately starts to send
EAIS frames periodically to suppress the error alarms. When the port goes up again, it immediately stops
sending EAIS frames. When the MEP receives the EAIS frames, it suppresses the error alarms locally, and
continues to send the EAIS frames. If a MEP receives no EAIS frames within 3.5 times the EAIS frame
transmission interval, the fault is considered cleared. The port stops sending EAIS frames and restores the
error alarm function. EAIS frames are multicast frames.
NOTE:
This function is supported only by Release 3108P01 and later versions.
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
CFD configuration task list
For CFD to work correctly, 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 that the devices in the same MD use the same MD name.
• Define the MA in each MD according to the VLAN you want to monitor.
• Assign a name for each MA. Make sure that the devices in the same MA in the same MD use the
same MA name.
• Determine the MEP list of each MA in each MD. Make sure that 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
Typically, a port blocked by the spanning tree feature can not re ceive or se nd C FD messag es exce pt i n th e
following cases:
• The port is configured as an outward-facing MEP.
• The port is configured as a MIP or inward-facing MEP, which 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
Enabling CFD
Step Command
1. Enter system view.
2. Enable CFD.
system-view
cfd enable By default, CFD is disabled.
Configuring service instances
Before configuring the MEPs and MIPs, you must first configure service instances. A service instance is a
set of service access points (SAPs), and belongs to an MA in an MD.
The MD and MA define the level attribute and VLAN attribute of the messages handled by the MPs in a
service instance. The MPs of the MA that carry no VLAN attribute do not belong to any VLAN.
To configure a service instance with the MD name:
Step Command
1. Enter system view.
2. Create an MD.
system-view N/A
cfd md md-name [ index
index-value ] level level-value
CFD is implemented through various operations on MEPs. As a MEP is configured on a service instance,
the MD level and VLAN attribute of the service instance become the attribute of the MEP.
Before creating MEPs, configure the MEP list. A MEP list is a collection of local MEPs that can be
configured in an MA an d the remote MEPs to be mon itored. You ca nnot create a MEP if the MEP I D is not
included in the MEP list of the service instance.
On the same level of an interface, you can configure an outward-facing MEP for only one MA with no
VLAN attribute.
Follow these guidelines when you configure MEPs:
• Configurations in Ethernet interface view take effect only on the current interface.
• Configurations in aggregate interface view take effect on the aggregate interface and all its
member ports.
• Configurations on a member port take effect only when the member port leaves the aggregation
group.
To configure a MEP:
Step Command
1. Enter system view.
2. Configure a MEP list.
3. Enter Layer 2 Ethernet
interface view or Layer 2
aggregate interface view.
As functional entities in a service instance, MIPs respond to various CFD frames, such as LTM and LBM
frames. You can configure MIP auto-generation rules for the system to automatically create MIPs.
Any of the following events can cause MIPs to be created or deleted after you have configured the cfd mip-rule command:
• Enabling or disabling CFD.
• Creating or deleting MEPs on a port.
• Changes occur to the VLAN attribute of a port.
Remarks
By default, no MEP list is
configured.
N/A
By default, no MEP is configured.
• The rule specified in the cfd mip-rule command changes.
An MA carrying no VLAN attribute is mainly used to detect direct link status. It cannot generate MIPs.
For an MA carrying VLAN attribute, if the same or higher level MEP exists on the interface, no MIP is
generated for the MA on the interface.
Configure CC before configuring other CFD functions. After the CC function is configured, MEPs in an
MA can periodically send CCM frames to maintain connectivity. When the lifetime of a CCM frame
expires, the link to the sending MEP is considered disconnected. When setting the CCM interval, use the
settings described in Table 5.
Remarks
By default, no rules for generating
MIPs are configured, and the
system does not automatically
create any MIP.
Table 5 CCM interval field encoding
CCM interval field
1 10/3 milliseconds 35/3 milliseconds
2 10 milliseconds 35 milliseconds
3 100 milliseconds 350 milliseconds
4 1 second 3.5 seconds
5 10 seconds 35 seconds
6 60 seconds 210 seconds
7 600 seconds 2100 seconds
Transmission interval
Maximum CCM lifetime
Follow these guidelines when you configure CC on a MEP:
• Configure the same CCM interval field value for all MEPs in the same MA.
• The switch does not support a CCM interval field value in the range of 1 to 3. If you configure a
CCM interval field value of 1, 2, or 3, the value of 4 takes effect.
• Configurations in Ethernet interface view take effect only on the current interface.
• Configurations in aggregate interface view take effect on the aggregate interface and all its
member ports.
• Configurations on a member port take effect only when the member port leaves the aggregation
group.
To configure CC on a MEP:
21
Step Command
A
1. Enter system view.
system-view N/A
Remarks
2. (Optional.) Set the CCM
interval field.
3. Enter Layer 2 Ethernet
interface view or Layer 2
aggregate interface view.
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
Enable LB.
cfd cc interval interval-value
service-instance instance-id
interface interface-type interface-number
cfd cc service-instance instance-id
mep mep-id enable
LT can trace the path between source and target MEPs, and can locate link faults by automatically
sending LT messages. The two functions are implemented in the following way:
•Tracing path—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 is identified.
•LT messages automatic sending—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 (with the target MEP as the destination and the TTL field in the LTM frames set to the
maximum value 255) will be sent out. Based on the LTRs that the MIPs return, the fault source is
located.
IMPORTANT:
Before you configure LT on a MEP in an MA carrying VLAN attribute, create the VLAN to which the M
belongs.
The AIS function suppresses the number of error alarms reported by MEPs.
For a MEP in the service instance to send AIS frames, set the AIS frame transmission level to be higher
than the MD level of the MEP.
Enable AIS and configure a correct AIS frame transmission level on the target MEP, so the target MEP can
perform the following tasks:
• Suppress the error alarms.
• Send the AIS frame to the MD of a higher level.
If you enable AIS but do not configure a correct AIS frame transmission level, the target MEP can
suppress the error alarms, but cannot send the AIS frames.
To configure AIS:
Ste
1. Enter system view.
cfd linktrace auto-detection [ size
size-value ]
Command
system-view
By default, LT messages
automatic sending is disabled.
Remarks
N/A
2. Enable AIS. cfd ais enable By default, AIS is disabled.
cfd ais period period-value
service-instance instance-id
Configuring LM
The LM function measures frame loss between MEPs. Frame loss statistics include the number of lost
frames, the frame loss ratio, and the average number of lost frames for the source and target MEPs.
To configure LM:
Task
Configure LM.
Command
cfd slm service-instance instance-id mep mep-id
{ target-mac mac-address | target-mep
target-mep-id } [ number number ]
Configuring one-way DM
By default, the AIS frame
transmission level is not
configured.
By default, the AIS frame
transmission interval is 1 second.
Remarks
Available in any view.
The one-way DM function measures the one-way frame delay between two MEPs, and monitors and
manages the link transmission performance.
23
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.
To view the test result, use the display cfd dm one-way history command on the target MEP.
To configure one-way DM:
Task
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. It also monitors and manages the link transmission
performance.
To configure two -way DM:
Task
Configure two-way DM.
Command
cfd dm one-way service-instance
instance-id mep mep-id
{ target-mac mac-address |
target-mep target-mep-id }
[ number number ]
Command
cfd dm two-way service-instance
instance-id mep mep-id
{ target-mac mac-address |
target-mep target-mep-id }
[ number number ]
Remarks
Available in any view.
Remarks
Available in any view.
Configuring TST
The TST function detects bit errors on a link, and monitors and manages the link transmission
performance.
To view the test result, use the display cfd tst command on the target MEP.