The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Configuring ITU-T Y.1731 Fault Management Functions in IEEE CFM
This document describes the implementation of the ITU-Y.1731 fault management functions Ethernet Alarm Indication Signal
(ETH-AIS) and Ethernet Remote Defect Indication (ETH-RDI) as part of the IEEE Ethernet Connectivity Fault Management (CFM)
protocol.
Prerequisites for Configuring ITU-T Y.1731 Fault Management Functions
Business Requirements
Business and service policies have been established.
Network topology and network administration have been evaluated.
Technical Requirements
CFM must be configured and enabled for Y.1731 fault management features to function.
A server maintenance endpoint (SMEP) is needed to support the ETH-AIS function.
Maintenance intermediate points (MIPs) must be configured to support AIS messages; they are generated only on an interface
on which a MIP is configured.
Restrictions for Configuring ITU-T Y.1731 Fault Management Functions
Because of a port-ASIC hardware limitation, IEEE CFM cannot coexist with the Per VLAN Spanning Tree (PVST) protocol, and IEEE
CFM cannot operate with the following line cards on the same system:
FI_WS_X6196_RJ21
FI_WS_X6196_RJ45
FI_WS_X6548_RJ21
FI_WS_X6548_RJ45
CFM loopback messages are not confined within a maintenance domain according to their maintenance level. The impact of not
having CFM loopback messages confined to their maintenance levels occurs at these levels:
Architecture--CFM layering is violated for loopback messages.
Deployment--A user may misconfigure a network and have loopback messages succeed.
Security--A malicious device that recognizes devices’ MAC addresses and levels may explore a network topology that should
be transparent.
Routed interfaces are supported only in Cisco IOS Release 12.4(11)T.
IEEE CFM is not fully supported on a Multiprotocol Label Switching (MPLS) provider edge (PE) device. There is no interaction
between IEEE CFM and an Ethernet over MPLS (EoMPLS) pseudowire. A CFM packet can be transparently passed like regular data
packets only via pseudowire, with the following restriction:
For policy feature card (PFC)-based EoMPLS, which uses a Cisco Catalyst LAN card as the MPLS uplink port, a CFM packet can
be transparently passed via an EoMPLS pseudowire the same way regular data packets are passed. The EoMPLS endpoint interface,
however, cannot be a maintenance endpoint (MEP) or an MIP, although a CFM MEP or MIP can be supported on regular Layer 2 switchport
interfaces.
CFM configuration is not supported on an EtherChannel in FastEthernet Channel (FEC) mode.
Information About Configuring ITU-T Y.1731 Fault Management Functions
Continuity Check Messages
CFM continuity check messages (CCMs) are multicast heartbeat messages exchanged periodically among MEPs. CCMs allow MEPs
to discover other MEPs within a domain and allow MIPs to discover MEPs. CCMs are confined to a domain.
For more information about CCMs, see the “Continuity Check Messages” section of the "Configuring IEEE Standard-Compliant
Ethernet CFM in a Service Provider Network" configuration module.
Server MEPs
Server MEPs (SMEPs) are virtual MEPs that perform two functions--server layer termination for CFM maintenance associations
defined at a link or at the transport layer and server-Ethernet adaptation. When a SMEP detects a defect at the server layer,
it issues frames containing ETH-AIS information.
Defect Conditions Detected by a MEP
The defect conditions that a MEP detects and subsequently acts upon are the following:
AIS condition--A MEP receives an AIS frame.
Dying gasp--An unrecoverable and vendor-specific condition. Dying gasp is generated in the following conditions:
Administratively disabling 802.3ah
Link down caused by administration down
Power failure
Reload
Note
Administratively disabling 802.3ah does not disrupt traffic and should not generate an AIS. If a Reason field is empty, however,
disabling always generates an AIS when Cisco routers and non-Cisco routers are interworking.
A notification about the defect condition may be sent immediately and continuously.
Loss of continuity (LOC) condition--A MEP stops receiving CCMs from a peer MEP. An LOC condition is a MEP down error.
LOC results when a remote MEP lifetime timer expires and causes an AIS condition for the local MEP. The LOC condition is cleared
when connectivity is restored.
Mismerge condition--A CCM with a correct maintenance level but incorrect maintenance ID indicates that frames from a different
service instance are merged with the service instance represented by the receiving MEP’s maintenance ID. A mismerge condition
is a cross-connect error.
RDI condition--A MEP receives a CCM with the RDI field set.
Signal fail condition--Declared by a MEP or the server layer termination function to notify the SMEP about a defect condition
in the server layer. Signal fail conditions are as follows:
Configuration error
Cross-connect error
LOC
Loop error
MEP missing
MEP unknown (same as unexpected MEP)
Signal fail conditions cause AIS defect conditions for the MEP, resulting in the MEP receiving an AIS frame.
A MEP that detects a signal fail condition sends AIS frames to each of the client layer or sublayer maintenance associations.
Unexpected MEP condition--A CCM with a correct maintenance level, correct maintenance ID, and an unexpected maintenance point
ID (MPID) that is the same as the receiving MEP’s MPID. An unexpected MEP condition is either a cross-check error or a configuration
error.
Determination of an unexpected MPID is possible when a MEP maintains a list of its peer MPIDs. Peer MPIDs must be configured
on each MEP during provisioning.
ETH-AIS Function
The ETH-AIS function suppresses alarms when a defect condition is detected at either the server layer or the server sublayer
(virtual MEP). Transmission of frames carrying ETH-AIS information can be either enabled or disabled on either a MEP or a
SMEP and can be sent at the client maintenance level by either a MEP or SMEP when a defect condition is detected.
SMEPs monitor the entire physical link so that an AIS is generated for each VLAN or server on the network. MEPs monitor VLANs,
Ethernet virtual circuits (EVCs), and SMEPs where link up or link down and 802.3ah interworking are supported. A MEP that
detects a connectivity fault at a specific level multicasts an AIS in the direction opposite the detected failure at the client
maintenance association (MA) level.
An AIS causes a receiving MEP to suppress traps to prevent the network management system (NMS) from receiving an excessive
number of redundant traps and also so that clients are asynchronously informed about faults.
In a point-to-point topology, a MEP has a single peer MEP and there is no ambiguity regarding the peer MEP for which it should
suppress alarms when it receives ETH-AIS information.
In a multipoint Ethernet topology, a MEP that receives a frame with ETH-AIS information cannot determine which remote peer
lost connectivity. The MEP also cannot determine the associated subset of peer MEPs for which it should suppress alarms because
the ETH-AIS information does not include that MEP information. Because the MEP cannot determine the affected peer MEPs, it
suppresses alarms for all peer MEPs whether or not there is connectivity.
Due to independent restoration capabilities within Spanning Tree Protocol (STP) environments, ETH-AIS is not expected to be
applied in these environments; however, ETH-AIS transmission is configurable in STP environments by a network administrator.
ETH-AIS Transmission Reception and Processing
Only a MEP or a SMEP can be configured to send frames with ETH-AIS information. When a MEP detects a defect condition, it
immediately begins transmitting frames with ETH-AIS information at the configured client maintenance level, which is the level
at which the MIP is configured on the interface. Frames are transmitted to peer MEPs in the direction opposite the fault.
The first AIS frame must always be transmitted immediately following the detection of a defect condition, but thereafter frames
are transmitted at a frequency based on the configured AIS transmission period. The transmitting MEP continues to transmit
frames with ETH-AIS information until the defect condition is removed. The period flag in the frame’s header indicates the
transmission interval. The default is that a MEP clears a defect condition only if no AIS frames are received within a time
period equal to 3.5 times the configured transmission interval.
Note
An AIS transmission period of one second is recommended; however, an AIS transmission period of one minute is supported to
enable ETH-AIS across all VLANs supported by IEEE CFM.
When a MEP receives a frame with ETH-AIS information, it examines the frame to ensure that the maintenance association level
corresponds to its own maintenance association level. The MEP detects the AIS condition and suppresses loss-of-continuity
alarms associated with all its peer MEPs. Peer MEPs can resume generating loss-of-continuity alarms only when the receiving
MEP exits the AIS condition.
The client layer or client sublayer may consist of multiple maintenance associations that should also be notified to suppress
alarms when either a server layer or server sublayer MEP detects a defect condition. The first AIS frame for all client layer
or sublayer maintenance associations must be transmitted within one second after the defect condition is detected.
AIS and 802.3ah Interworking
The following conditions impact SMEP AIS conditions:
By default, link down events cause the SMEP to enter the AIS condition and generate AIS frames for all services at the immediate
client maintenance association level.
Link up events cause the SMEP to exit the AIS state and stop generating AIS frames.
Local fault detection results from dying gasp, link fault, or critical 802.3ah Remote Fault Indication (RFI). When 802.3ah
is reestablished, the SMEP exits the AIS state and stops generating AIS frames.
Local fault detection due to crossing of a high threshold with a configurable action of error disabling the interface.
RFI received from a dying gasp, link fault, or critical event.
If a detected fault is due to dying gasp, the link goes down in both directions, creating AIS and RDI frame flow as shown
in the figure below.
ETH-RDI Function
The ETH-RDI function is used by a MEP to communicate to its peer MEPs that a defect condition has been encountered. ETH-RDI
is used only when ETH-CC transmission is enabled.
ETH-RDI has the following two applications:
Single-ended fault management--A receiving MEP detects an RDI defect condition, which is correlated with other defect conditions
in the MEP and may become the cause of a fault. If ETH-RDI information is not received by a single MEP, there are no defects
in the entire MA.
Contribution to far-end performance monitoring--A defect condition in the far end is used as an input to the performance
monitoring process.
A MEP in a defect condition transmits CCMs with ETH-RDI information. A MEP that receives a CCM examines it to ensure that
its maintenance association level corresponds to its configured maintenance association level and detects the RDI condition
if the RDI field is set. The receiving MEP sets the RDI field in CCMs for the duration of a defect condition, and if the MEP
is enabled for CCM transmission, transmits CCMs based on the configured transmission interval. When the defect condition clears,
the MEP clears the RDI field in CCMs for subsequent transmissions.
In a point-to-point Ethernet connection, a MEP can clear an RDI condition when it receives the first CCM with the RDI field
cleared from its peer MEP. In a multipoint Ethernet connection, a MEP cannot determine the peer MEP with the default condition
and can clear an RDI condition only when it receives a CCM with the RDI field cleared from each of its peer MEPs.
The ETH-RDI function is part of continuity checking and is enabled by default. For more information about continuity checking,
see the "Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network" configuration module.
How to Configure ITU-T Y.1731 Fault Management Functions
ETH-AIS and ETH-RDI both are enabled by default when CFM is configured, but each can also be manually enabled by a separate
command during CFM configuration. Perform these tasks to either disable or enable the functions.
Disabling the ETH-AIS Function
Perform this task to disable the ETH-AIS function.
The following sample output from the
showethernetcfmsmep command shows the settings for a SMEP:
Device# show ethernet cfm smep
SMEP Settings:
--------------
Interface: Ethernet0/0
AIS-Status: Enabled
AIS Period: 60000 (ms)
Level to transmit AIS: 4
Defect Condition: No Defect
The following sample output from the
showethernetcfmsmepinterface command shows the settings for a specific interface on a SMEP:
Device# show ethernet cfm smep interface ethernet 0/1
SMEP Settings:
--------------
Interface: Ethernet0/1
LCK-Status: Enabled
LCK Period: 60000 (ms)
Level to transmit LCK: Default
AIS-Status: Enabled
AIS Period: 60000 (ms)
Level to transmit AIS: Default
Defect Condition: No Defect
Router#
The following sample output from the
showethernetcfmerrors command shows the Ethernet CFM errors on a device:
Device# show ethernet cfm errors
Level Vlan MPID Remote MAC Reason Service ID
5 102 - aabb.cc00.ca10 Receive AIS service test
The following sample output from the
showethernetcfmmaintenance-pointsremotedetail command shows the detailed information about a specific remote MEP:
Device# show ethernet cfm maintenance-points remote detail mpid 66
MAC Address: aabb.cc00.ca10
Domain/Level: PROVIDERDOMAIN/4
EVC: test
MPID: 66 (Can ping/traceroute)
Incoming Port(s): Ethernet0/2
CC Lifetime(sec): 75
Age of Last CC Message(sec): 8
Receive RDI: TRUE
Frame Loss: 0%
CC Packet Statistics: 2/0 (Received/Error)
R1#MAC Address: aabb.cc00.ca10
Domain/Level: PROVIDERDOMAIN/4
EVC: test
MPID: 66 (Can ping/traceroute)
Incoming Port(s): Ethernet0/2
CC Lifetime(sec): 75
Age of Last CC Message(sec): 8
Receive RDI: TRUE
Frame Loss: 0%
CC Packet Statistics: 2/0 (Received/Error)
Additional References
Related Documents
Related Topic
Document Title
IEEE CFM
“Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network”
Using OAM
“Using Ethernet Operations, Administration, and Maintenance”
IEEE CFM and Y.1731 commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS Carrier Ethernet Command Reference
Standards
Standard
Title
IEEE 802.1ag
802.1ag - Connectivity Fault Management
IEEE 802.3ah
Ethernet in the First Mile
ITU-T
ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks
Technical Assistance
Description
Link
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use
these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products
and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
Feature Information for Configuring ITU-T Y.1731 Fault Management Functions
The following table provides release information about the feature or features described in this module. This table lists
only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco
Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1. Feature Information for Configuring ITU-T Y.1731 Fault Management Functions
The ITU-Y.1731 Fault Management Functions feature adds to IEEE CFM the ETH-AIS and ETH-RDI functions for fault detection,
fault verification, and fault isolation in large MANs and WANs.
The following commands were introduced or modified:
ais,
clearethernetcfmais,
disable(CFM-AIS-link),
ethernetcfmaislink-status,
ethernetcfmaislink-statusglobal,
level(cfm-ais-link),
period(cfm-ais-link),
showethernetcfmerrors,showethernetcfmmaintenance-pointslocal,
showethernetcfmmaintenance-pointsremotedetail,
showethernetcfmsmep.
Feedback