Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Component Configuration Guide
Configuring Ethernet OAM on the Cisco ASR 9000 Series Router
Downloads: This chapterpdf (PDF - 1.08MB) The complete bookPDF (PDF - 8.86MB) | Feedback

Configuring Ethernet OAM on the Cisco ASR 9000 Series Router

Table Of Contents

Configuring Ethernet OAM on the Cisco ASR 9000 Series Router

Contents

Prerequisites for Configuring Ethernet OAM

Information About Configuring Ethernet OAM

Ethernet Link OAM

Neighbor Discovery

Link Monitoring

Remote Loopback

MIB Retrieval

SNMP Traps

Ethernet CFM

Maintenance Domains

Services

Maintenance Points

CFM Protocol Messages

MEP Cross-Check

Configurable Logging

EFD

Flexible VLAN Tagging for CFM

Ethernet SLA (Y.1731 Performance Monitoring)

How to Configure Ethernet OAM

Configuring Ethernet Link OAM

Configuring an Ethernet OAM Profile

Attaching an Ethernet OAM Profile to an Interface

Configuring Ethernet CFM

Configuring a CFM Maintenance Domain

Configuring Services for a CFM Maintenance Domain

Enabling and Configuring Continuity Check for a CFM Service

Configuring Automatic MIP Creation for a CFM Service

Configuring Cross-Check on a MEP for a CFM Service

Configuring Other Options for a CFM Service

Configuring CFM MEPs

Configuring Y.1731 AIS

Configuring EFD for a CFM Service

Configuring Flexible VLAN Tagging for CFM

Verifying the CFM Configuration

Troubleshooting Tips

Configuring Ethernet SLA

Ethernet SLA Configuration Guidelines

Configuration Examples for Ethernet OAM

Configuration Examples for EOAM Interfaces

Configuring an Ethernet OAM Profile Globally: Example

Configuring Ethernet OAM Features on an Individual Interface: Example

Configuring Ethernet OAM Features to Override the Profile on an Individual Interface: Example

Configuring a Remote Loopback on an Ethernet OAM Peer: Example

Clearing Ethernet OAM Statistics on an Interface: Example

Enabling SNMP Server Traps on a Router: Example

Ethernet CFM Configuration: Example

Ethernet CFM Show Command: Examples

AIS for CFM Configuration: Examples

AIS for CFM Show Command: Examples

Show Ethernet CFM Interfaces AIS

Show Ethernet CFM Local MEPs

EFD Configuration: Examples

Show EFD Information: Examples

Flexible Tagging for CFM Configuration: Examples

SLA Configuration: Example

Ethernet SLA Show Command: Examples

Where to Go Next

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance


Configuring Ethernet OAM on the Cisco ASR 9000 Series Router


This module describes the configuration of Ethernet Operations, Administration, and Maintenance (OAM) on the Cisco ASR 9000 Series Aggregation Services Routers.

Feature History for Configuring Ethernet OAM

Release
Modification

Release 3.7.2

Support for the following features was introduced:

Ethernet Link OAM

Ethernet CFM

Release 3.7.3

Support for the CFM Exploratory Linktrace feature was introduced.

Release 3.9.0

Support for the Ethernet SLA feature was introduced:

Release 3.9.1

Support for the following features was introduced:

Ethernet CFM on Link Aggregation Group (LAG) interfaces (Ethernet bundle interfaces), Ethernet and bundle subinterfaces, and LAG member (bundle member) interfaces.

EFD

AIS

Flexible tagging

The ethernet cfm mep domain command is replaced by the ethernet cfm and mep domain commands.


Contents

Prerequisites for Configuring Ethernet OAM

Information About Configuring Ethernet OAM

How to Configure Ethernet OAM

Configuration Examples for Ethernet OAM

Where to Go Next

Additional References

Prerequisites for Configuring Ethernet OAM

You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

Before configuring Ethernet OAM, confirm that at least one of the Gigabit Ethernet line cards supported on the router is installed:

2-Port 10-Gigabit Ethernet, 20-Port Gigabit Ethernet Combination line card (A9K-2T20GE-B and A9K-2T20GE-L)

4-Port 10-Gigabit Ethernet line card (A9K-4T-L, -B, or -E)

8-Port 10-Gigabit Ethernet DX line card (A9K-8T/4-L, -B, or -E)

8-Port 10-Gigabit Ethernet line card (A9K-8T-L, -B, or -E)

16-Port 10-Gigabit Ethernet SFP+ line card (A9K-16T/8-B and A9K-16T/8-B+AIP)

40-Port Gigabit Ethernet line card (A9K-40GE-L, -B, or -E)

Information About Configuring Ethernet OAM

To configure Ethernet OAM, you should understand the following concepts:

Ethernet Link OAM

Ethernet CFM

Ethernet SLA (Y.1731 Performance Monitoring)

Ethernet Link OAM

Ethernet as a Metro Area Network (MAN) or a Wide Area Network (WAN) technology benefits greatly from the implementation of Operations, Administration and Maintenance (OAM) features. Ethernet link OAM features allow Service Providers to monitor the quality of the connections on a MAN or WAN. Service providers can monitor specific events, take actions on events, and if necessary, put specific interfaces into loopback mode for troubleshooting. Ethernet link OAM features can be configured to monitor either side or both sides of a link.

Ethernet link OAM can be configured in the following ways:

A Link OAM profile can be configured, and this profile can be used to set the parameters for multiple interfaces.

Link OAM can be configured directly on an interface.

When an interface is also using a link OAM profile, specific parameters that are set in the profile can be overridden by configuring a different value directly on the interface.

An EOAM profile simplifies the process of configuring EOAM features on multiple interfaces. An Ethernet OAM profile, and all of its features, can be referenced by other interfaces, allowing other interfaces to inherit the features of that Ethernet OAM profile.

Individual Ethernet link OAM features can be configured on individual interfaces without being part of a profile. In these cases, the individually configured features always override the features in the profile.

The preferred method of configuring custom EOAM settings is to create an EOAM profile in Ethernet configuration mode and then attach it to an individual interface or to multiple interfaces.

The following standard Ethernet Link OAM features are supported on the router:

Neighbor Discovery

Link Monitoring

Remote Loopback

MIB Retrieval

SNMP Traps

In addition to these standard Ethernet Link OAM features, the Cisco ASR 9000 Series Router also supports a Cisco-proprietary feature called Miswiring Detection. The Miswiring Detection feature uses the 32-bit vendor field in every Information OAMPDU to identify potential miswiring cases.

Neighbor Discovery

Neighbor discovery enables each end of a link to learn the OAM capabilities of the other end and establish an OAM peer relationship.

Link Monitoring

Link monitoring enables an OAM peer to monitor faults that cause the quality of a link to deteriorate over time. When link monitoring is enabled, an OAM peer can be configured to take action when the configured thresholds are exceeded.

Remote Loopback

Remote loopback enables one side of a link to put the remote side of the link into loopback mode for testing. When remote loopback is enabled, all packets initiated by the master side of the link are looped back to the master side, unaltered by the remote (slave) side. In remote loopback mode, the slave side is not allowed to inject any data into the packets.

MIB Retrieval

MIB retrieval enables an OAM peer on one side of an interface to get the MIB variables from the remote side of the link. The MIB variables that are retrieved from the remote OAM peer are READ ONLY.

SNMP Traps

SNMP traps can be enabled or disabled on an Ethernet OAM interface.

Ethernet CFM

Ethernet Connectivity Fault Management (CFM) is a service-level OAM protocol that provides tools for monitoring and troubleshooting end-to-end Ethernet services per VLAN. This includes proactive connectivity monitoring, fault verification, and fault isolation. CFM uses standard Ethernet frames and can be run on any physical media that is capable of transporting Ethernet service frames. Unlike most other Ethernet protocols which are restricted to a single physical link, CFM frames can transmit across the entire end-to-end Ethernet network.

CFM is defined in two standards:

IEEE 802.1ag—Defines the core features of the CFM protocol.

ITU-T Y.1731—Redefines, but maintains compatibility with the features of IEEE 802.1ag, and defines some additional features.

Ethernet CFM on the Cisco ASR 9000 Series Router supports the following functions of ITU-T Y.1731:

ETH-CC, ETH-RDI, ETH-LB, ETH-LT—These are equivalent to the corresponding features defined in IEEE 802.1ag.


Note The Linktrace responder procedures defined in IEEE 802.1ag are used rather than the procedures defined in Y.1731; however, these are interoperable.


ETH-AIS—The reception of ETH-LCK messages is also supported.

ETH-DM—This is supported with the Ethernet SLA feature. For more information about Ethernet SLA, see the "Ethernet SLA (Y.1731 Performance Monitoring)" section.

To understand how the CFM maintenance model works, you need to understand the following concepts and features:

Maintenance Domains

Services

Maintenance Points

CFM Protocol Messages

MEP Cross-Check

Configurable Logging

EFD

Flexible VLAN Tagging for CFM

Maintenance Domains

A maintenance domain describes a management space for the purpose of managing and administering a network. A domain is owned and operated by a single entity and defined by the set of interfaces internal to it and at its boundary, as shown in Figure 1.

Figure 1 CFM Maintenance Domain

A maintenance domain is defined by the bridge ports that are provisioned within it. Domains are assigned maintenance levels, in the range of 0 to 7, by the administrator. The level of the domain is useful in defining the hierarchical relationships of multiple domains.

CFM maintenance domains allow different organizations to use CFM in the same network, but independently. For example, consider a service provider who offers a service to a customer, and to provide that service, they use two other operators in segments of the network. In this environment, CFM can be used in the following ways:

The customer can use CFM between their CE devices, to verify and manage connectivity across the whole network.

The service provider can use CFM between their PE devices, to verify and manage the services they are providing.

Each operator can use CFM within their operator network, to verify and manage connectivity within their network.

Each organization uses a different CFM maintenance domain.

Figure 2 shows an example of the different levels of maintenance domains in a network.


Note In CFM diagrams, the conventions are that triangles represent MEPs, pointing in the direction that the MEP sends CFM frames, and circles represent MIPs.


Figure 2 Different CFM Maintenance Domains Across a Network

To ensure that the CFM frames for each domain do not interfere with each other, each domain is assigned a maintenance level, between 0 and 7. Where domains are nested, as in this example, the encompassing domain must have a higher level than the domain it encloses. In this case, the domain levels must be negotiated between the organizations involved. The maintenance level is carried in all CFM frames that relate to that domain.

CFM maintenance domains may touch or nest, but cannot intersect. Figure 3 illustrates the supported structure for touching and nested domains, and the unsupported intersection of domains.

Figure 3 Supported CFM Maintenance Domain Structure

Services

A CFM service allows an organization to partition its CFM maintenance domain, according to the connectivity within the network. For example, if the network is divided into a number of virtual LANs (VLANs), a CFM service is created for each of these. CFM can then operate independently in each service. It is important that the CFM services match the network topology, so that CFM frames relating to one service cannot be received in a different service. For example, a service provider may use a separate CFM service for each of their customers, to verify and manage connectivity between that customer's end points.

A CFM service is always associated with the maintenance domain that it operates within, and therefore with that domain's maintenance level. All CFM frames relating to the service carry the maintenance level of the corresponding domain.


Note CFM Services are referred to as Maintenance Associations in IEEE 802.1ag and as Maintenance Entity Groups in ITU-T Y.1731.


Maintenance Points

A CFM Maintenance Point (MP) is an instance of a particular CFM service on a specific interface. CFM only operates on an interface if there is a CFM maintenance point on the interface; otherwise, CFM frames are forwarded transparently through the interface.

A maintenance point is always associated with a particular CFM service, and therefore with a particular maintenance domain at a particular level. Maintenance points generally only process CFM frames at the same level as their associated maintenance domain. Frames at a higher maintenance level are always forwarded transparently, while frames at a lower maintenance level are normally dropped. This helps enforce the maintenance domain hierarchy described in the "Maintenance Domains" section, and ensures that CFM frames for a particular domain cannot leak out beyond the boundary of the domain.

There are two types of MP:

Maintenance End Points (MEPs)—Created at the edge of the domain. Maintenance end points (MEPs) are members of a particular service within a domain and are responsible for sourcing and sinking CFM frames. They periodically transmit continuity check messages and receive similar messages from other MEPs within their domain. They also transmit traceroute and loopback messages at the request of the administrator. MEPs are responsible for confining CFM messages within the domain.

Maintenance Intermediate Points (MIPs)—Created in the middle of the domain. Unlike MEPS, MIPs do allow CFM frames at their own level to be forwarded.

The boundary of a domain is an interface, rather than a bridge or host. Therefore, MEPs can be sub-divided into two categories:

Down MEPs—Send CFM frames from the interface where they are configured, and process CFM frames received on that interface. Down MEPs transmit AIS messages upward (toward the bridge domain or cross-connect).

Up MEPs—Send frames into the bridge relay function, as if they had been received on the interface where the MEP is configured. They process CFM frames that have been received on other interfaces, and have been switched through the bridge relay function as if they are going to be sent out of the interface where the MEP is configured. Up MEPs transmit AIS messages downward (toward the wire). However, AIS packets are only sent when there is a MIP configured on the same interface as the MEP and at the level of the MIP.


Note The terms Down MEP and Up MEP are defined in the IEEE 802.1ag and ITU-T Y.1731 standards, and refer to the direction that CFM frames are sent from the MEP. The terms should not be confused with the operational status of the MEP.


Figure 4 illustrates the monitored areas for Down and Up MEPs.

Figure 4 Monitored Areas for Down and Up MEPs

Figure 5 shows maintenance points at different levels. Because domains are allowed to nest but not intersect (see Figure 3), a MEP at a low level always corresponds with a MEP or MIP at a higher level. In addition, only a single MIP is allowed on any interface—this is generally created in the lowest domain that exists at the interface and that does not have a MEP.

Figure 5 CFM Maintenance Points at Different Levels

MIPs and Up MEPs can only exist on switched (Layer 2) interfaces, because they send and receive frames from the bridge relay function. Down MEPs can be created on switched (Layer 2) or router (Layer 3) interfaces.

MEPs continue to operate normally if the interface they are created on is blocked by the Spanning Tree Protocol (STP); that is, CFM frames at the level of the MEP continue to be sent and received, according to the direction of the MEP. MEPs never allow CFM frames at the level of the MEP to be forwarded, so the STP block is maintained.

MIPs also continue to receive CFM frames at their level if the interface is STP blocked, and can respond to any received frames. However, MIPs do not allow CFM frames at the level of the MIP to be forwarded if the interface is blocked.


Note A separate set of CFM maintenance levels is created every time a VLAN tag is pushed onto the frame. Therefore, if CFM frames are received on an interface which pushes an additional tag, so as to "tunnel" the frames over part of the network, the CFM frames will not be processed by any MPs within the tunnel, even if they are at the same level. For example, if a CFM MP is created on an interface with an encapsulation that matches a single VLAN tag, any CFM frames that are received at the interface that have two VLAN tags will be forwarded transparently, regardless of the CFM level.


CFM Protocol Messages

The CFM protocol consists of a number of different message types, with different purposes. All CFM messages use the CFM EtherType, and carry the CFM maintenance level for the domain to which they apply.

This section describes the following CFM messages:

Continuity Check (IEEE 802.1ag and ITU-T Y.1731)

Loopback (IEEE 802.1ag and ITU-T Y.1731)

Linktrace (IEEE 802.1ag and ITU-T Y.1731

Exploratory Linktrace (Cisco)

Alarm Indication Signal (ITU-T Y.1731)

Delay Measurement (ITU-T Y.1731)

Continuity Check (IEEE 802.1ag and ITU-T Y.1731)

Continuity Check Messages (CCMs) are "heartbeat" messages exchanged periodically between all the MEPs in a service. Each MEP sends out multicast CCMs, and receives CCMs from all the other MEPs in the service—these are referred to as peer MEPs. This allows each MEP to discover its peer MEPs, and to verify that there is connectivity between them.

MIPs also receive CCMs. MIPs use the information to build a MAC learning database that is used when responding to Linktrace. For more information about Linktrace, see the "Linktrace (IEEE 802.1ag and ITU-T Y.1731" section.

Figure 6 Continuity Check Message Flow

All the MEPs in a service must transmit CCMs at the same interval. IEEE 802.1ag defines 7 possible intervals that can be used:

3.3ms

10ms

100ms

1s

10s

1 minute

10 minutes

A MEP detects a loss of connectivity with one of its peer MEPs when some number of CCMs have been missed. This occurs when sufficient time has passed during which a certain number of CCMs were expected, given the CCM interval. This number is called the loss threshold, and is usually set to 3.

CCM messages carry a variety of information that allows different defects to be detected in the service. This information includes:

A configured identifier for the domain of the transmitting MEP. This is referred to as the Maintenance Domain Identifier (MDID).

A configured identifier for the service of the transmitting MEP. This is referred to as the Short MA Name (SMAN). Together, the MDID and the SMAN make up the Maintenance Association Identifier (MAID). The MAID must be configured identically on every MEP in the service.

A configured numeric identifier for the MEP (the MEP ID). Each MEP in the service must be configured with a different MEP ID.

A sequence number.

A Remote Defect Indication (RDI). Each MEP includes this in the CCMs it is sending, if it has detected a defect relating to the CCMs it is receiving. This notifies all the MEPs in the service that a defect has been detected somewhere in the service.

The interval at which CCMs are being transmitted.

The status of the interface where the MEP is operating—for example, whether the interface is up, down, STP blocked, and so on.


Note The status of the interface (up/down) should not be confused with the direction of any MEPs on the interface (Up MEPs/Down MEPs).


The following defects can be detected from received CCMs:

Interval mismatch—The CCM interval in the received CCM does not match the interval that the MEP is sending CCMs.

Level mismatch—A MEP has received a CCM carrying a lower maintenance level than the MEPs own level.

Loop—A CCM is received with the source MAC address equal to the MAC address of the interface where the MEP is operating.

Configuration error—A CCM is received with the same MEP ID as the MEP ID configured for the receiving MEP.

Cross-connect—A CCM is received with an MAID that does not match the locally configured MAID. This generally indicates a VLAN misconfiguration within the network, such that CCMs from one service are leaking into a different service.

Peer interface down—A CCM is received that indicates the interface on the peer is down.

Remote defect indication—A CCM is received carrying a remote defect indication.


Note This defect does not cause the MEP to include a remote defect indication in the CCMs that it is sending.


Out-of-sequence CCMs can also be detected by monitoring the sequence number in the received CCMs from each peer MEP. However, this is not considered a CCM defect.

Loopback (IEEE 802.1ag and ITU-T Y.1731)

Loopback Messages (LBM) and Loopback Replies (LBR) are used to verify connectivity between a local MEP and a particular remote MP. At the request of the administrator, a local MEP sends unicast LBMs to the remote MP. On receiving each LBM, the target maintenance point sends an LBR back to the originating MEP. Loopback indicates whether the destination is reachable or not—it does not allow hop-by-hop discovery of the path. It is similar in concept to an ICMP Echo (ping). Since loopback messages are destined for unicast addresses, they are forwarded like normal data traffic, while observing the maintenance levels. If the outgoing interface is known (in the bridge's forwarding database), then the frame is sent out on that interface. If the outgoing interface is not known, then the message is flooded on all interfaces in that bridge domain.

Figure 7 shows an example of CFM loopback message flow between a MEP and MIP.

Figure 7 Loopback Messages

Loopback messages can be padded with user-specified data. This allows data corruption to be detected in the network. They also carry a sequence number which allows for out-of-order frames to be detected.

Loopback messages can also be used for Ethernet SLA, if the peer does not support delay measurement.

Linktrace (IEEE 802.1ag and ITU-T Y.1731

Linktrace Messages (LTM) and Linktrace Replies (LTR) are used to track the path (hop-by-hop) to a unicast destination MAC address. At the request of the operator, a local MEP sends an LTM. Each hop where there is a maintenance point sends an LTR back to the originating MEP. This allows the administrator to discover connectivity data about the path. It is similar in concept to IP traceroute, although the mechanism is different. In IP traceroute, successive probes are sent, whereas CFM Linktrace uses a single LTM which is forwarded by each MP in the path. LTMs are multicast, and carry the unicast target MAC address as data within the frame. They are intercepted at each hop where there is a maintenance point, and either retransmitted or dropped to discover the unicast path to the target MAC address.

Figure 8 shows an example of CFM linktrace message flow between MEPs and MIPs.

Figure 8 Linktrace Message Flow

The linktrace mechanism is designed to provide useful information even after a network failure. This allows it to be used to locate failures, for example after a loss of continuity is detected. To achieve this, each MP maintains a CCM Learning Database. This maps the source MAC address for each received CCM to the interface through which the CCM was received. It is similar to a typical bridge MAC learning database, except that it is based only on CCMs and it times out much more slowly—on the order of days rather than minutes.


Note In IEEE 802.1ag, the CCM Learning Database is referred to as the MIP CCM Database. However, it applies to both MIPs and MEPs.


In IEEE 802.1ag, when an MP receives an LTM message, it determines whether to send a reply using the following steps:

1. The target MAC address in the LTM is looked up in the bridge MAC learning table. If the MAC address is known, and therefore the egress interface is known, then an LTR is sent.

2. If the MAC address is not found in the bridge MAC learning table, then it is looked up in the CCM learning database. If it is found, then an LTR is sent.

3. If the MAC address is not found, then no LTR is sent (and the LTM is not forwarded).

If the target MAC has never been seen previously in the network, the linktrace operation will not produce any results.


Note IEEE 802.1ag and ITU-T Y.1731 define slightly different linktrace mechanisms. In particular, the use of the CCM learning database and the algorithm described above for responding to LTM messages are specific to IEEE 802.1ag. IEEE 802.1ag also specifies additional information that can be included in LTRs. Regardless of the differences, the two mechanisms are interoperable.


Exploratory Linktrace (Cisco)

Exploratory Linktrace is a Cisco extension to the standard linktrace mechanism described above. It has two primary purposes:

Provide a mechanism to locate faults in cases where standard linktrace does not work, such as when a MAC address has never been seen previously in the network. For example, if a new MEP has been provisioned but is not working, standard linktrace does not help isolate a problem because no frames will ever have been received from the new MEP. Exploratory Linktrace overcomes this problem.

Provide a mechanism to map the complete active network topology from a single node. This can only be done currently by examining the topology (for example, the STP blocking state) on each node in the network individually, and manually combining this information to create the overall active topology map. Exploratory linktrace allows this to be done automatically from a single node.

Exploratory Linktrace is implemented using the Vendor Specific Message (VSM) and Vendor Specific Reply (VSR) frames defined in ITU-T Y.1731. These allow vendor-specific extensions to be implemented without degrading interoperability. Exploratory Linktrace can safely be deployed in a network that includes other CFM implementations because those implemenation will simply ignore the Exploratory Linktrace messages.

Exploratory Linktrace is initiated at the request of the administrator, and results in the local MEP sending a multicast Exploratory Linktrace message. Each MP in the network that receives the message sends an Exploratory Linktrace reply. MIPs that receive the message also forward it on. The initiating MEP uses all the replies to create a tree of the overall network topology.

Figure 9 show an example of the Exploratory Linktrace message flow between MEPs.

Figure 9 Exploratory Linktrace Messages and Replies

To avoid overloading the originating MEP with replies in a large network, responding MPs delay sending their replies for a random amount of time, and that time increases as the size of the network increases.

In a large network, there will be a corresponding large number of replies and the resulting topology map will be equally large. If only a part of the network is of interest, for example, because a problem has already been narrowed down to a small area, then the Exploratory Linktrace can be "directed" to start at a particular MP. Replies will thus only be received from MPs beyond that point in the network. The replies are still sent back to the originating MEP.

Alarm Indication Signal (ITU-T Y.1731)

Alarm Indication Signal (AIS) messages are used to rapidly notify MEPs when a fault is detected in the middle of a domain, in an event driven way. MEPs thereby learn of the fault much sooner than if they relied on detecting a loss of continuity, for example, failure to receive some number of consecutive CCMs.

Unlike all other CFM messages, AIS messages are injected into the middle of a domain, and sent outward toward the MEPs at the edge of the domain. Typically, AIS messages are injected by a MEP in a lower level domain. To put it another way, when a MEP sends AIS messages, they are sent in the opposite direction to other CFM messages sent by the MEP, and at a level above the MEP's own level. The AIS messages are received by the MEPs in the higher level domain, not by the peer MEPs in the same domain as the MEP sending the AIS. When a MEP receives an AIS message, it may itself send another AIS message at an even higher level.

Figure 10 show an example of AIS message flow. The maintenance domain levels are numbered at the right side of the diagram.

Figure 10 AIS Message Flow

AIS is only applicable in point-to-point networks. In multipoint networks with redundant paths, a failure at a low level does not necessarily result in a failure at a higher level, as the network may reconverge so as to route around the failed link.

AIS messages are typically sent by a MEP. However, AIS messages can also be sent when there is no MEP present, if a fault is detected in the underlying transport, such as if an interface goes down. In ITU-T Y.1731 these are referred to as server MEPs.

AIS messages are sent in response to a number of failure conditions:

Detection of CCM defects, as described "Continuity Check (IEEE 802.1ag and ITU-T Y.1731)" section.

Loss of continuity.

Receipt of AIS messages.

Failure in the underlying transport, such as when an interface is down.

Received AIS messages can be used to detect and act on failures more quickly than waiting for a loss of continuity. They can also be used to suppress any failure action, on the basis that the failure has already been detected at a lower level and will be handled there. This is described in ITU-T Y.1731; however, the former is often more useful.

Delay Measurement (ITU-T Y.1731)

The router supports two-way delay measurement using two new packet types, Delay Measurement Message (DMM) and Delay Measurement Response (DMR), that are unicast similar to loopback messages. The packets carry timestamps generated by the system time-of-day clock to support more accurate delay measurement, and also support an SLA manageability front-end.

For more information about SLA, see the "Ethernet SLA (Y.1731 Performance Monitoring)" section.

MEP Cross-Check

MEP cross-check supports configuration of a set of expected peer MEPs so that errors can be detected when any of the known MEPs are missing, or if any additional peer MEPs are detected that are not in the expected group.

The set of expected MEP IDs in the service is user-defined. Optionally, the corresponding MAC addresses can also be specified. CFM monitors the set of peer MEPs from which CCMs are being received. If no CCMs are ever received from one of the specified expected peer MEPs, or if a loss of continuity is detected, then a cross-check "missing" defect is detected. Similarly, if CCMs are received from a matching MEP ID but with the wrong source MAC address, a cross-check "missing" defect is detected. If CCMs are subsequently received that match the expected MEP ID, and if specified, the expected MAC address, then the defect is cleared.


Note While loss of continuity can be detected for any peer MEP, it is only treated as a defect condition if cross-check is configured.


If cross-check is configured and CCMs are received from a peer MEP with a MEP ID that is not expected, this is detected as a cross-check "unexpected" condition. However, this is not treated as a defect condition.

Configurable Logging

CFM supports logging of various conditions to syslog. Logging can be enabled independently for each service, and when the following conditions occur:

New peer MEPs are detected, or loss of continuity with a peer MEP occurs.

Changes to the CCM defect conditions are detected.

Cross-check "missing" or "unexpected" conditions are detected.

AIS condition detected (AIS messages received) or cleared (AIS messages no longer received).

EFD used to shut down an interface, or bring it back up.

EFD

Ethernet Fault Detection (EFD) is a mechanism that allows Ethernet OAM protocols, such as CFM, to control the "line protocol" state of an interface.

Unlike many other interface types, Ethernet interfaces do not have a line protocol, whose state is independent from that of the interface. For Ethernet interfaces, this role is handled by the physical-layer Ethernet protocol itself, and therefore if the interface is physically up, then it is available and traffic can flow.

EFD changes this to allow CFM to act as the line protocol for Ethernet interfaces. This allows CFM to control the interface state so that if a CFM defect (such as AIS or loss of continuity) is detected with an expected peer MEP, the interface can be shut down. This not only stops any traffic flowing, but also triggers actions in any higher-level protocols to route around the problem. For example, in the case of Layer 2 interfaces, the MAC table would be cleared and MSTP would reconverge. For Layer 3 interfaces, the ARP cache would be cleared and potentially the IGP would reconverge.


Note EFD can only be used for down MEPs. When EFD is used to shut down the interface, the CFM frames continue to flow. This allows CFM to detect when the problem has been resolved, and thus bring the interface backup automatically.


Figure 11 shows CFM detection of an error on one of its sessions EFD signaling an error to the corresponding MAC layer for the interface. This triggers the MAC to go to a down state, which further triggers all higher level protocols (Layer 2 pseudowires, IP protocols, and so on) to go down and also trigger a reconvergence where possible. As soon as CFM detects there is no longer any error, it can signal to EFD and all protocols will once again go active.

Figure 11 CFM Error Detection and EFD Trigger

Flexible VLAN Tagging for CFM

The Flexible VLAN Tagging for CFM feature ensures that CFM packets are sent with the right VLAN tags so that they are appropriately handled as a CFM packet by the remote device. When packets are received by an edge router, they are treated as either CFM packets or data packets, depending on the number of tags in the header. The system differentiates between CFM packets and data packets based on the number of tags in the packet, and forwards the packets to the appropriate paths based on the number of tags in the packet.

CFM frames are normally sent with the same VLAN tags as the corresponding customer data traffic on the interface, as defined by the configured encapsulation and tag rewrite operations. Likewise, received frames are treated as CFM frames if they have the correct number of tags as defined by the configured encapsulation and tag rewrite configuration, and are treated as data frames (that is, they are forwarded transparently) if they have more than this number of tags.

In most cases, this behavior is as desired, since the CFM frames are then treated in exactly the same way as the data traffic flowing through the same service. However, in a scenario where multiple customer VLANs are multiplexed over a single multipoint provider service (for example, N:1 bundling), a different behavior might be desirable.

Figure 12 shows an example of a network with multiple VLANS using CFM.

Figure 12 Service Provider Network With Multiple VLANs and CFM

Figure 12 shows a provider's access network, where the S-VLAN tag is used as the service delimiter. PE1 faces the customer, and PE2 is at the edge of the access network facing the core. N:1 bundling is used, so the interface encapsulation matches a range of C-VLAN tags. This could potentially be the full range, resulting in all:1 bundling. There is also a use case where only a single C-VLAN is matched, but the S-VLAN is nevertheless used as the service delimiter—this is more in keeping with the IEEE model, but limits the provider to 4094 services.

CFM is used in this network with a MEP at each end of the access network, and MIPs on the boxes within the network (if it is native Ethernet). In the normal case, CFM frames are sent by the up MEP on PE1 with two VLAN tags, matching the customer data traffic. This means that at the core interfaces and at the MEP on PE2, the CFM frames are forwarded as if they were customer data traffic, since these interfaces match only on the S-VLAN tag. So, the CFM frames sent by the MEP on PE1 are not seen by any of the other MPs.

Flexible VLAN tagging changes the encapsulation for CFM frames that are sent and received at Up MEPs. Flexible VLAN tagging allows the frames to be sent from the MEP on PE1 with just the S-VLAN tag that represents the provider service. If this is done, the core interfaces will treat the frames as CFM frames and they will be seen by the MIPs and by the MEP on PE2. Likewise, the MEP on PE1 should handle received frames with only one tag, as this is what it will receive from the MEP on PE2.

To ensure that CFM packets from Up MEPs are routed to the appropriate paths successfully, tags may be set to a specific number in a domain service, using the tags command. Currently, tags can only be set to one (1).

Ethernet SLA (Y.1731 Performance Monitoring)

Customers require their service providers to conform to a Service Level Agreement (SLA). Consequently, service providers must be able to monitor the performance characteristics of their networks. Likewise, customers also want to monitor the performance characteristics of their networks. Cisco provides Y.1731 performance monitoring using the Cisco Ethernet SLA.

An SLA defines a set of criteria that guarantees a minimum level of service for customers using a service provider network. The criteria can cover many different areas, including latency, jitter, frame loss, and availability.

The Cisco Ethernet SLA conforms to the following standards:

IEEE 802.1ag

ITU-T Y.1731

The Cisco Ethernet SLA provides the tools for monitoring a network at Layer 2. These tools provide functions such as collecting, storing, displaying, and analyzing SLA statistics. These SLA statistics can be stored and displayed in various ways, so that statistical analysis can be performed.

Ethernet SLA provides the tools for performing the following major functions:

Sending probes consisting of one or more packets to measure performance.

Scheduling of operations consisting of periodic probes.

Collecting and storing results.

Analyzing and displaying results.

Metrics Collection

Metrics collection consists of collecting measurements of network performance by sending packets and storing data about such things as:

Round-trip delay time: the time for a packet to travel from source to destination and back to source again.

Round-trip jitter: the variance in round-trip delay time (latency).

These metrics are value-based. Each metric consists of a value (a time or a packet count). These values are aggregated with the values of other metrics that have been collected. The aggregated metrics are stored in configured buckets.

A bucket represents a time period during which statistics are collected. All the results received during that time period are recorded in the corresponding bucket. If aggregation is enabled, each bucket has its own set of bins and counters, and only results received during the time period represented by the bucket are included in those counters.

By default, there is a separate bucket for each probe. The time period is determined by how long the probe lasts (configured by the probe, send (SLA), and schedule (SLA) commands).You can modify the size of buckets so that you can have more buckets per probe or less buckets per probe (less buckets allows the results from multiple probes to be included in the same bucket). Changing the size of the buckets for a given metric clears all stored data for that metric. All existing buckets are deleted and new buckets are created.

A bin contains the count of the results for a range of values. When aggregation is enabled, bins are created. Each bin stores a counter of the results for a range of values. Only a counter of the number of results that fall within the range for each bin is stored. This uses less memory than storing individual results.

An Ethernet SLA configuration has the following major components:

Profile—An SLA profile is the container for all SLA operations (probes), storage units (statistics), and scheduling:

Probe—A probe is a component of a profile and defines the operations for the profile, such as when to send packets, packet types, and packet sizes. A profile can contain only one probe.

Statistics—Statistics measurement is a component of a profile and defines the storage units for metrics collected by probes. Statistics configuration defines things such as how to aggregate the metrics, the number of bins and buckets, and the size of bins and buckets.

Schedule—The schedule is a component of a profile and defines when probes are sent, how often, and for how long.

Operations—Configuration of operations is based on a particular profile and is configured for a specific CFM MEP, towards a specified target.

When you configure Ethernet SLA, you perform the following basic steps:

1. Configure global profiles to define how packets are sent in each probe, how

the probes are scheduled, and how the results are stored.

2. Configure operations from a specific local MEP to a specific peer MEP using these profiles.


Note Certain Ethernet SLA configurations use large amounts of memory which can affect the performance of other features on the system. For more information, see the "Configuring Ethernet SLA" section.


How to Configure Ethernet OAM

This section provides the following configuration procedures:

Configuring Ethernet Link OAM

Configuring Ethernet CFM

Configuring Ethernet SLA

Configuring Ethernet Link OAM

Custom EOAM settings can be configured and shared on multiple interfaces by creating an EOAM profile in Ethernet configuration mode and then attaching the profile to individual interfaces. The profile configuration does not take effect until the profile is attached to an interface. After an EOAM profile is attached to an interface, individual EOAM features can be configured separately on the interface to override the profile settings when desired.

This section describes how to configure an EOAM profile and attach it to an interface in the following procedures:

Configuring an Ethernet OAM Profile

Attaching an Ethernet OAM Profile to an Interface

Configuring an Ethernet OAM Profile

Perform the following steps to configure an Ethernet OAM profile.

SUMMARY STEPS

1. configure

2. ethernet oam profile profile-name

3. link-monitor

4. symbol-period window window

5. symbol-period threshold low threshold

6. frame window window

7. frame threshold low threshold

8. frame-period window window

9. frame-period threshold low threshold

10. frame-seconds window window

11. frame-seconds threshold low threshold

12. exit

13. mib-retrieval

14. connection timeout seconds

15. require-remote mode active

16. require-remote link-monitoring

17. require-remote mib-retrieval

18. action link-fault error-disable-interface

19. action high-threshold {error-disable-interface | log}

20. action dying-gasp error-disable-interface

21. action critical-event error-disable-interface

22. action discovery-timeout error-disable-interface

23. action session-down error-disable-interface

24. action capabilities-conflict error-disable-interface

25. action wiring-conflict error-disable-interface

26. action remote-loopback error-disable-interface

27. commit

28. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RSP0/CPU0:router# configure terminal

Enters global configuration mode.

Step 2 

ethernet oam profile profile-name

Example:

RP/0/RSP0/CPU0:router(config)# ethernet oam profile Profile_1

Creates a new Ethernet Operations, Administration and Maintenance (OAM) profile and enters Ethernet OAM configuration mode.

Step 3 

link-monitor

Example:

RP/0/RSP0/CPU0:router(config-eoam)# link-monitor

Enters the Ethernet OAM link monitor configuration mode.

Step 4 

symbol-period window window

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# symbol-period window 60000

(Optional) Configures the window size (in milliseconds) for an Ethernet OAM symbol-period error event.

The range is 1000 to 60000.

The default value is 1000.

Step 5 

symbol-period threshold low threshold high threshold

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# symbol-period threshold low 10000000 high 60000000

(Optional) Configures the thresholds (in symbols) that trigger an Ethernet OAM symbol-period error event. The high threshold is optional and is configurable only in conjunction with the low threshold.

The range is 0 to 60000000.

The default low threshold is 1.

Step 6 

frame window window

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# frame window 60

(Optional) Configures the frame window size (in milliseconds) of an OAM frame error event.

The range is 1000 to 60000.

The default value is 1000.

Step 7 

frame threshold low threshold high threshold

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# frame threshold low 10000000 high 60000000

(Optional) Configures the thresholds (in symbols) that triggers an Ethernet OAM frame error event. The high threshold is optional and is configurable only in conjunction with the low threshold.

The range is 0 to 60000000.

The default low threshold is 1.

Step 8 

frame-period window window

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# frame-period window 60000

(Optional) Configures the window size (in milliseconds) for an Ethernet OAM frame-period error event.

The range is 100 to 60000.

The default value is 1000.

Step 9 

frame-period threshold low threshold high threshold

RP/0/RSP0/CPU0:router(config-eoam-lm)# frame-period threshold low 100 high 1000000

(Optional) Configures the thresholds (in frames) that trigger an Ethernet OAM frame-period error event. The high threshold is optional and is configurable only in conjunction with the low threshold.

The range is 0 to 1000000.

The default low threshold is 60000.

Step 10 

frame-seconds window window

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# frame-seconds window 900000

(Optional) Configures the window size (in milliseconds) for the OAM frame-seconds error event.

The range is 10000 to 900000.

The default value is 6000.

Step 11 

frame-seconds threshold low threshold high threshold

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# frame-seconds threshold 3 threshold 900

(Optional) Configures the thresholds (in seconds) that trigger a frame-seconds error event. The high threshold value can be configured only in conjunction with the low threshold value.

The range is 1 to 900

The default value is 1.

Step 12 

exit

Example:

RP/0/RSP0/CPU0:router(config-eoam-lm)# exit

Exits back to Ethernet OAM mode.

Step 13 

mib-retrieval

Example:

RP/0/RSP0/CPU0:router(config-eoam)# mib-retrieval

Enables MIB retrieval in an Ethernet OAM profile or on an Ethernet OAM interface.

Step 14 

connection timeout seconds

Example:

RP/0/RSP0/CPU0:router(config-eoam)# connection timeout 30

Configures the timeout value (in seconds) for an Ethernet OAM session.

The range is 2 to 30.

The default value is 5.

Step 15 

require-remote mode active

Example:

RP/0/RSP0/CPU0:router(config-eoam)# require-remote mode active

Requires that active mode or passive mode is configured on the remote end before the OAM session becomes active.

Step 16 

require-remote link-monitoring

Example:

RP/0/RSP0/CPU0:router(config-eoam)# require-remote link-monitoring

Requires that link-monitoring is configured on the remote end before the OAM session becomes active.

Step 17 

require-remote mib-retrieval

Example:

RP/0/RSP0/CPU0:router(config-eoam)# require-remote mib-retrieval

Requires that MIB-retrieval is configured on the remote end before the OAM session becomes active.

Step 18 

action link-fault error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action link-fault error-disable-interface

Puts the interface into the error-disable state when a link-fault notification is received. The default action is to create a syslog entry.

Step 19 

action high-threshold {error-disable-interface | log}

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action high-threshold error-disable-interface

Specifies the action that is taken on an interface when a high threshold is exceeded. The default is to take no action when a high threshold is exceeded.

Note If you change the default, the disable keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and take no action at the interface when the event occurs.

Step 20 

action dying-gasp error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action dying-gasp error-disable-interface

Puts the interface into the error-disable state when a dying-gasp notification is received. The default action is to create a syslog entry.

Note If you change the default, the log keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and log the event for the interface when it occurs.

Step 21 

action critical-event error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action critical-event error-disable-interface

Puts the interface into the error-disable state when a critical-event notification is received. The default action is to create a syslog entry.

Note If you change the default, the log keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and log the event for the interface when it occurs.

Step 22 

action discovery-timeout error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action discovery-timeout error-disable-interface

Puts the interface into the error-disable state when a connection timeout occurs. The default action is to create a syslog entry.. The default action is to create a syslog entry.

Note If you change the default, the log keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and log the event for the interface when it occurs.

Step 23 

action session-down error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action session-down error-disable-interface

Puts the interface into the error-disable state when an Ethernet OAM session goes down.

Note If you change the default, the log keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and log the event for the interface when it occurs.

Step 24 

action capabilities-conflict error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action capabilities-conflict error-disable-interface

Puts the interface into the error-disable state when a capabilities-conflict event occurs. The default action is to create a syslog entry.

Note If you change the default, the log keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and log the event for the interface when it occurs.

Step 25 

action wiring-conflict error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action wiring-conflict error-disable-interface

Puts the interface into the error-disable state when a wiring-conflict event occurs. The default is to put the interface into error-disable state.

Note If you change the default, the error-disable-interface keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and put the interface into error-disable state when the event occurs.

Step 26 

action remote-loopback error-disable-interface

Example:

RP/0/RSP0/CPU0:router(config-eoam)# action remote-loopback error-disable-interface

Puts the interface into the error-disable state when a remote-loopback event occurs. The default action is to create a syslog entry.

Note If you change the default, the log keyword option is available in Interface Ethernet OAM configuration mode to override the profile setting and log the event for the interface when it occurs.

Step 27 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Saves the configuration changes to the running configuration file and remains within the configuration session.

Step 28 

end

Example:

RP/0/RSP0/CPU0:router(config-if)# end

Ends the configuration session and exits to the EXEC mode.

Attaching an Ethernet OAM Profile to an Interface

Perform the following steps to attach an Ethernet OAM profile to an interface:

SUMMARY STEPS

1. configure

2. interface [GigabitEthernet | TenGigE] interface-path-id

3. ethernet oam

4. profile profile-name

5. commit

6. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RSP0/CPU0:router# configure terminal

Enters global configuration mode.

Step 2 

interface [GigabitEthernet | TenGigE] inter- face-path-id

Example:

RP/0/RSP0/CPU0:router(config)# interface
TenGigE 0/1/0/0

Enters interface configuration mode and specifies the Ethernet interface name and notation rack/slot/module/port. Possible interface types for this procedure are:

GigabitEthernet

TenGigE

Note The example indicates an 8-port 10-Gigabit Ethernet interface in modular services card slot 1.

Step 3 

ethernet oam

Example:

RP/0/RSP0/CPU0:router(config-if)# ethernet oam

Enables Ethernet OAM and enters interface Ethernet OAM configuration mode.

Step 4 

profile profile-name

Example:

RP/0/RSP0/CPU0:router(config-if-eoam)# profile Profile_1

Attaches the specified Ethernet OAM profile (profile-name), and all of its configuration, to the interface.

Step 5 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Saves the configuration changes to the running configuration file and remains within the configuration session.

Step 6 

end

Example:

RP/0/RSP0/CPU0:router(config-if)# end

Ends the configuration session and exits to the EXEC mode.

Configuring Ethernet CFM

To configure Ethernet CFM, perform the following tasks:

Configuring a CFM Maintenance Domain

Configuring Services for a CFM Maintenance Domain

Enabling and Configuring Continuity Check for a CFM Service (optional)

Configuring Automatic MIP Creation for a CFM Service (optional)

Configuring Cross-Check on a MEP for a CFM Service (optional)

Configuring Other Options for a CFM Service (optional)

Configuring CFM MEPs

Configuring Y.1731 AIS (optional)

Configuring EFD for a CFM Service (optional)

Configuring Flexible VLAN Tagging for CFM (optional)

Verifying the CFM Configuration

Troubleshooting Tips

Configuring a CFM Maintenance Domain

To configure a CFM Maintenance Domain, perform the following steps:

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

4. traceroute cache hold-time minutes size entries

5. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# ethernet cfm

Enters Ethernet Connectivity Fault Management (CFM) configuration mode.

Step 3 

domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

Example:
RP/0/RSP0/CPU0:router(config-cfm)# domain 
Domain_One level 1 id string D1 

Creates and names a container for all domain configurations and enters CFM domain configuration mode.

The level must be specified.

The id is the maintenance domain identifier (MDID) and is used as the first part of the maintenance association identifier (MAID) in CFM frames. If the MDID is not specified, the domain name is used as the MDID by default.

Step 4 

traceroute cache hold-time minutes size entries

Example:
RP/0/RSP0/CPU0:router(config-cfm-dmn)# 
traceroute cache hold-time 1 size 3000 

(Optional) Sets the maximum limit of traceroute cache entries or the maximum time limit to hold the traceroute cache entries. The default is 100 minutes and 100 entries.

Step 5 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Services for a CFM Maintenance Domain

You can configure up to 32000 CFM services for a maintenance domain.

To configure services for a CFM Maintenance Domain, perform the following steps:

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string]]

4. service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

5. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# ethernet cfm

Enters Ethernet CFM configuration mode.

Step 3 

domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

Example:
RP/0/RSP0/CPU0:router(config-cfm)# domain 
Domain_One level 1 id string D1 

Creates and names a container for all domain configurations at a specified maintenance level, and enters CFM domain configuration mode.

The id is the maintenance domain identifier (MDID) and is used as the first part of the maintenance association identifier (MAID) in CFM frames. If the MDID is not specified, the domain name is used as the MDID by default.

Step 4 

service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service Bridge_Service bridge group BD1 bridge-domain B1

Configures and associates a service with the domain and enters CFM domain service configuration mode. You can specify that the service is used only for down MEPs, or associate the service with a bridge domain or xconnect where MIPs and up MEPs will be created.

Step 5 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Enabling and Configuring Continuity Check for a CFM Service

The Cisco ASR 9000 Series Router supports Continuity Check as defined in the IEEE 802.1ag specification, and supports CCMs intervals of 100 ms and longer. The overall packet rates for CCM messages are up to 16000 CCMs-per-second sent, and up to 16000 CCMs-per-second received, per card.


Note If Ethernet SLA is configured, the overall combined packet rate for CCMs and SLA frames is 4000 frames-per-second in each direction, per card.


To configure Continuity Check for a CFM service, complete the following steps:

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string]]

4. service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

5. continuity-check interval time [loss-threshold threshold ]

6. continuity-check archive hold-time minutes

7. continuity-check loss auto-traceroute

8. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# ethernet cfm

Enters Ethernet Connectivity Fault Management (CFM) configuration mode.

Step 3 

domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

Example:
RP/0/RSP0/CPU0:router(config-cfm)# domain 
Domain_One level 1 id string D1 

Creates and names a container for all domain configurations and enters the CFM domain configuration mode.

The level must be specified.

The id is the maintenance domain identifier (MDID) and is used as the first part of the maintenance association identifier (MAID) in CFM frames. If the MDID is not specified, the domain name is used as the MDID by default.

Step 4 

service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service Bridge_Service bridge group BD1 bridge-domain B1

Configures and associates a service with the domain and enters CFM domain service configuration mode. You can specify that the service is used only for down MEPs, or associate the service with a bridge domain or xconnect where MIPs and up MEPs will be created.

Step 5 

continuity-check interval time [loss-threshold threshold]

Example:
RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# 
continuity-check interval 100m loss-threshold 
10 

(Optional) Enables Continuity Check and specifies the time interval at which CCMs are transmitted or to set the threshold limit for when a MEP is declared down.

Step 6 

continuity-check archive hold-time minutes

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# continuity-check archive hold-time 100

(Optional) Configures how long information about peer MEPs is stored after they have timed out.

Step 7 

continuity-check loss auto-traceroute

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# continuity-check loss auto-traceroute

(Optional) Configures automatic triggering of a traceroute when a MEP is declared down.

Step 8 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Automatic MIP Creation for a CFM Service

To configure automatic MIP creation for a CFM service, complete the following steps:

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string]]

4. service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

5. mip auto-create {all | lower-mep-only}

6. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router# ethernet cfm

Enters the Ethernet Connectivity Fault Management (CFM) configuration mode.

Step 3 

domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

Example:
RP/0/RSP0/CPU0:router(config-cfm)# domain 
Domain_One level 1 id string D1 

Creates and names a container for all domain configurations and enters the CFM domain configuration mode.

The level must be specified.

The id is the maintenance domain identifier (MDID) and is used as the first part of the maintenance association identifier (MAID) in CFM frames. If the MDID is not specified, the domain name is used as the MDID by default.

Step 4 

service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service Bridge_Service bridge group BD1 bridge-domain B1

Configures and associates a service with the domain and enters CFM domain service configuration mode. You can specify that the service is used only for down MEPs, or associate the service with a bridge domain or xconnect where MIPs and up MEPs will be created.

Step 5 

mip auto-create {all | lower-mep-only}

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# mip auto-create all

(Optional) Enables the automatic creation of MIPs in a bridge domain or xconnect.

Step 6 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Cross-Check on a MEP for a CFM Service

To configure cross-check on a MEP for a CFM service and specify the expected set of MEPs, complete the following steps:

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string]]

4. service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

5. mep crosscheck

6. mep-id mep-id-number [mac-address mac_address]

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router# ethernet cfm

Enters the Ethernet Connectivity Fault Management (CFM) configuration mode.

Step 3 

domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

Example:
RP/0/RSP0/CPU0:router(config-cfm)# domain 
Domain_One level 1 id string D1 

Creates and names a container for all domain configurations and enters the CFM domain configuration mode.

The level must be specified.

The id is the maintenance domain identifier (MDID) and is used as the first part of the maintenance association identifier (MAID) in CFM frames. If the MDID is not specified, the domain name is used as the MDID by default.

Step 4 

service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service Bridge_Service bridge group BD1 bridge-domain B1

Configures and associates a service with the domain and enters CFM domain service configuration mode. You can specify that the service is used only for down MEPs, or associate the service with a bridge domain or xconnect where MIPs and up MEPs will be created.

Step 5 

mep crosscheck

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# mep crosscheck mep-id 10

Enters CFM MEP crosscheck configuration mode.

Step 6 

mep-id mep-id-number [mac-address mac_address]

Example:

RP/0/RSP0/CPU0:router(config-cfm-xcheck)# mep-id 10

Enables cross-check on a MEP.

Note Repeat this command for every MEP that you want included in the expected set of MEPs for cross-check.

Step 7 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-xcheck)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Other Options for a CFM Service

To configure other options for a CFM service, complete the following steps:

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string]]

4. service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

5. maximum meps number

6. log continuity-check errors | continuity-check mep | crosscheck errors

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router# ethernet cfm

Enters the Ethernet Connectivity Fault Management (CFM) configuration mode.

Step 3 

domain domain_name level level_value [id [null] [dns DNS_name] [mac H.H.H] [string string] ]

Example:
RP/0/RSP0/CPU0:router(config-cfm)# domain 
Domain_One level 1 id string D1 

Creates and names a container for all domain configurations and enters the CFM domain configuration mode.

The level must be specified.

The id is the maintenance domain identifier (MDID) and is used as the first part of the maintenance association identifier (MAID) in CFM frames. If the MDID is not specified, the domain name is used as the MDID by default.

Step 4 

service service_name bridge group bridge_domain_group bridge-domain  bridge_domain_name | down-meps | xconnect group xconnect_group_name p2p xconnect_name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service Bridge_Service bridge group BD1 bridge-domain B1

Configures and associates a service with the domain and enters CFM domain service configuration mode. You can specify that the service is used only for down MEPs, or associate the service with a bridge domain or xconnect where MIPs and up MEPs will be created.

Step 5 

maximum-meps number

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# maximum-meps 1000

(Optional) Configures the maximum number (2 to 8190) of MEPs across the network, which limits the number of peer MEPs recorded in the database.

Step 6 

log continuity-check errors | continuity-check mep | crosscheck errors

Example:
RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# log 
continuity-check errors 

(Optional) Enables logging of certain types of events.

Step 7 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring CFM MEPs

When you configure CFM MEPs, consider the following guidelines:

Up to 32000 local MEPs are supported per card.

CFM maintenance points can be created on the following interface types:

All physical Ethernet interfaces (except for the RSP Management interfaces).

Ethernet bundle interfaces.

All physical and bundle Ethernet subinterfaces, providing the encapsulation is configured according to the following guidelines:

Frames are only matched based on VLAN IDs and CoS bits.

Frames are not matched using VLAN "any."

Ethernet bundle member interfaces—Only down MEPs at level 0 can be created.

CFM maintenance points can be created on both Layer 2 and Layer 3 interfaces. On L3 interfaces, only down MEPs can be created.

Restrictions

When you configure MEPs, consider the following restrictions:

Maintenance points at level 0 are not supported on bundle interfaces.

If a subinterface is configured that matches untagged Ethernet frames (for example, by configuring the encapsulation default command), then you can not create a down MEP on the underlying physical or bundle interface.

Up MEPs are not supported on Layer 3 interfaces.

SUMMARY STEPS

1. config

2. interface {GigabitEthernet | TenGigE | Bundle-Ether} interface-path-id.subinterface

3. ethernet cfm

4. mep domain domain_name service service_name mep-id id_number

5. cos cos

6. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

interface {GigabitEthernet | TenGigE | 
Bundle-Ether} interface-path-id.subinterface
Example:
RP/0/RSP0/CPU0:router(config)# interface 
gigabitethernet 0/1/0/1

Type of Ethernet interface on which you want to create a MEP. Enter GigabitEthernet, TenGigE, or Bundle-Ether and the physical interface or virtual interface followed by the subinterface path ID.

Naming notation is interface-path-id.subinterface. The period in front of the subinterface value is required as part of the notation.

For more information about the syntax for the router, use the question mark (?) online help function.

 

RP/0/RSP0/CPU0:router(config-if)# ethernet cfm mep domain Dm1 service Sv1 mep-id 1

Creates a maintenance end point (MEP) on an interface and enters interface CFM MEP configuration mode.

Step 3 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config-if)# ethernet cfm

Enters interface Ethernet CFM configuration mode.

Step 4 

mep domain domain_name service service_name mep-id id_number

Example:

RP/0/RSP0/CPU0:router(config-if-cfm)# mep domain Dm1 service Sv1 mep-id 1

Creates a maintenance end point (MEP) on an interface and enters interface CFM MEP configuration mode.

Step 5 

cos cos

Example:

RP/0/RSP0/CPU0:router(config-if-cfm-mep)# cos 7

(Optional) Configures the class of service (CoS) (from 0 to 7) for all CFM packets generated by the MEP on an interface. If not configured, the CoS is inherited from the Ethernet interface.

Step 6 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-if-cfm-mep)# commit

Saves configuration changes.

When you use the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Y.1731 AIS

This section has the following step procedures:

Configuring AIS in a CFM Domain Service

Configuring AIS on a CFM Interface

Configuring AIS in a CFM Domain Service

Use the following procedure to configure Alarm Indication Signal (AIS) transmission for a CFM domain service and configure AIS logging.

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain name level level

4. service name bridge group name bridge-domain name

5. ais transmission interval 1m cos cos

6. log ais

7. commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# ethernet cfm

Enters Ethernet CFM global configuration mode.

Step 3 

domain name level level

Example:

RP/0/RSP0/CPU0:router(config-cfm)# domain D1 level 1

Specifies the domain and domain level.

Step 4 

service name bridge group name bridge-domain name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S1 bridge group BG1 bridge-domain BD2

Specifies the service, bridge group, and bridge domain.

Step 5 

ais transmission interval 1m cos cos

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# ais transmission interval 1m cos 7

Configures Alarm Indication Signal (AIS) transmission for a Connectivity Fault Management (CFM) domain service.

Step 6 

log ais

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# log ais

Configures AIS logging for a Connectivity Fault Management (CFM) domain service to indicate when AIS or LCK packets are received.

Step 7 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Saves configuration changes.

Configuring AIS on a CFM Interface

To configure AIS on a CFM interface, perform the following steps:

SUMMARY STEPS

1. config

2. interface gigabitethernet interface-path-id

3. ethernet cfm

4. ais transmission up interval 1m cos cos

5. commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

interface gigabitethernet interface-path-id

Example:

RP/0/RSP0/CPU0:router# config

Enters interface configuration mode.

Step 3 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# interface gigabitethernet 0/1/0/2

Enters Ethernet CFM interface configuration mode.

Step 4 

ais transmission up interval 1m cos cos

Example:

RP/0/RSP0/CPU0:router(config-if-cfm)# ais transmission up interval 1m cos 7

Configures Alarm Indication Signal (AIS) transmission on a Connectivity Fault Management (CFM) interface.

Step 5 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Saves configuration changes.

Configuring EFD for a CFM Service

To configure EFD for a CFM service, complete the following steps.

Restrictions

EFD is not supported on up MEPs. It can only be configured on down MEPs, within a particular service.

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain domain_name level level_value

4. service service_name down-meps

5. efd

6. log efd

7. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# ethernet cfm

Enters CFM configuration mode.

Step 3 

domain domain_name level level_value

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# domain D1 level 1

Specifies or creates the CFM domain and enters CFM domain configuration mode.

Step 4 

service service_name down-meps

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S1 down-meps

Specifies or creates the CFM service for down MEPS and enters CFM domain service configuration mode.

Step 5 

efd

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# efd

Enables EFD on all down MEPs in the down MEPS service.

Step 6 

log efd

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# log efd

(Optional) Enables logging of EFD state changes on an interface.

Step 7 

end

or

commit

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# commit

Saves configuration changes.

When you issue the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Verifying the EFD Configuration

The following example shows how to display all interfaces that are shut down because of Ethernet Fault Detection (EFD):

RP/0/RSP0/CPU0:router# show efd interfaces 
 
   
Server VLAN MA
==============
Interface         Clients
-------------------------
GigE0/0/0/0.0     CFM

Configuring Flexible VLAN Tagging for CFM

Use the following procedure to set the number of tags in CFM packets from up MEPs to 1, in a CFM domain service.

SUMMARY STEPS

1. config

2. ethernet cfm

3. domain name level level

4. service name bridge group name bridge-domain name

5. tags number

6. commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

config

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet cfm

Example:

RP/0/RSP0/CPU0:router(config)# ethernet cfm

Enters Ethernet CFM global configuration mode.

Step 3 

domain name level level

Example:

RP/0/RSP0/CPU0:router(config-cfm)# domain D1 level 1

Specifies the domain and domain level.

Step 4 

service name bridge group name bridge-domain name

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S2 bridge group BG1 bridge-domain BD2

Specifies the service, bridge group, and bridge domain.

Step 5 

tags number

Example:

RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# tags 1

Specifies the number of tags in CFM packets from up MEPs. Currently, the only valid value is 1.

Step 6 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Saves configuration changes.

Verifying the CFM Configuration

To verify the CFM configuration, use one or more of the following commands:

Command
Purpose

show ethernet cfm configuration-errors [domain domain_name] [interface interface-path-id ]

Displays information about errors that are preventing configured CFM operations from becoming active, as well as any warnings that have occurred.

show ethernet cfm local maintenance-points domain name [service name] | interface type interface-path-id] [mep | mip]

Displays a list of local maintenance points.


Troubleshooting Tips

To troubleshoot problems within the CFM network, perform the following steps:


Step 1 To verify connectivity to a problematic MEP, use the ping ethernet cfm command as shown in the following example:

RP/0/RSP0/CPU0:router# ping ethernet cfm domain D1 service S1 mep-id 16 source 
interface GigabitEthernet 0/0/0/0 
 
   
Type escape sequence to abort.
Sending 5 CFM Loopbacks, timeout is 2 seconds -
Domain foo (level 2), Service foo
Source: MEP ID 1, interface GigabitEthernet0/0/0/0
Target: 0001.0002.0003 (MEP ID 16):
  Running (5s) ...
Success rate is 60.0 percent (3/5), round-trip min/avg/max = 1251/1349/1402 ms
Out-of-sequence: 0.0 percent (0/3)
Bad data: 0.0 percent (0/3)
Received packet rate: 1.4 pps
 
   

Step 2 If the results of the ping ethernet cfm command show a problem with connectivity to the peer MEP, use the traceroute ethernet cfm command to help further isolate the location of the problem as shown in the following example:

RP/0/RSP0/CPU0:router# traceroute ethernet cfm domain D1 service S1 mep-id 16 source 
interface gigabitethernet 0/0/0/0 
 
   
Traceroutes in domain D1 (level 4), service S1
Source: MEP-ID 1, interface GigabitEthernet0/0/0/0
================================================================================
Traceroute at 2009-05-18 12:09:10 to 0001.0203.0402,
TTL 64, Trans ID 2:
 
   
Hop Hostname/Last            Ingress MAC/name       Egress MAC/Name        Relay
--- ------------------------ ---------------------- ---------------------- -----
  1 ios                      0001.0203.0400 [Down]                         FDB  
      0000-0001.0203.0400    Gi0/0/0/0                                          
  2 abc                                             0001.0203.0401 [Ok]    FDB  
      ios                                           Not present                 
  3 bcd                      0001.0203.0402 [Ok]                           Hit  
      abc                    GigE0/0                                            
Replies dropped: 0

If the target was a MEP, verify that the last hop shows "Hit" in the Relay field to confirm connectivity to the peer MEP.

If the Relay field contains "MPDB" for any of the hops, then the target MAC address was not found in the bridge MAC learning table at that hop, and the result is relying on CCM learning. This result can occur under normal conditions, but it can also indicate a problem. If you used the ping ethernet cfm command before using the traceroute ethernet cfm command, then the MAC address should have been learned. If "MPDB" is appearing in that case, then this indicates a problem at that point in the network.

Configuring Ethernet SLA

This section describes how to configure Ethernet SLA.

Ethernet SLA Configuration Guidelines


Caution Certain SLA configurations can use a large amount of memory which can affect the performance of other features on the router.

Before you use Ethernet SLA, consider the following information about some of the types of configuration that use more memory:

Aggregation—Use of the aggregate none command significantly increases the amount of memory required because each individual measurement is recorded, rather than just counts for each aggregation bin. When you configure aggregation, consider that more bins will require more memory.

Buckets archive—When you configure the buckets archive command, consider that the more history that is kept, the more memory will be used.

Measuring two statistics (such as both delay and jitter) will use approximately twice as much memory as measuring one.

The following procedure provides the steps to configure Ethernet Service Level Agreement (SLA) monitoring at Layer 2.

Configuring SLA consists of configuring the following SLA components:

Configuring a Profile

Configuring Profile Probe Parameters

Configuring Profile Statistics Measurement

Configuring Profile Schedule

Configuring Operations

Checking Configuration Errors

Verifying SLA Configuration

SUMMARY STEPS

Configuring a Profile

1. config

2. ethernet sla

3. profile profile_name type cfm-delay-measurement | cfm-loopback

4. commit

Configuring Profile Probe Parameters

5. probe

6. send burst every number seconds | minutes | hours packet count packets interval number seconds | milliseconds
or
send burst once packet count packets interval number seconds | milliseconds
or
send packet every number milliseconds | seconds | minutes | hours

7. packet size bytes

8. priority priority

9. commit

10. exit

Configuring Profile Statistics Measurement

11. statistics measure round-trip-delay | round-trip-jitter

12. aggregate bins count width width | none

13. buckets size number per-probe | probes

14. buckets archive number

15. commit

16. exit

17. exit

Configuring Profile Schedule

18. schedule every week on day at hh:mm for duration seconds | minutes | hours | days | week
or
schedule every day at hh:mm for duration seconds | minutes | hours | days | week
or
schedule every number hours | minutes for duration seconds | minutes | hours | days | week

19. commit

Configuring Operations

20. interface [GigabitEthernet | TenGigE] interface-path-id

21. ethernet cfm mep domain domain_name service service_name mep-id id_number

22. sla operation profile profile_name target mep-id id_number | mac-address mac_address

23. commit

24. end

Checking Configuration Errors

25. show ethernet sla configuration-errors [domain domain_name] [interface interface-path-id] [profile profile_name]

Verifying SLA Configuration

26. show ethernet sla operations [detail] [domain domain_name] [interface interface-path-id] [profile profile_name]

DETAILED STEPS

 
Command or Action
Purpose
 
Configuring a Profile

Step 1 

configure

Example:

RP/0/RSP0/CPU0:router# config

Enters global configuration mode.

Step 2 

ethernet sla

Example:

RP/0/RSP0/CPU0:router# ethernet sla

Enters the SLA configuration mode.

Step 3 

profile profile_name type cfm-delay-measurement | cfm-loopback

Example:
RP/0/RSP0/CPU0:router(config-sla)# profile  
Prof1  type  cfm-loopback 

Creates an SLA operation profile and enters the SLA profile configuration mode.

Step 4 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Save the configuration changes to the running configuration file and remains in the configuration session.

 
Configuring Profile Probe Parameters

Step 5 

probe

Example:
RP/0/RSP0/CPU0:router(config-sla-prof)# probe 

Enters the SLA profile probe configuration mode.

Step 6 

send burst every number seconds | minutes | hours packet count packets interval number seconds | milliseconds

or

send burst once packet count packets interval number seconds | milliseconds

or

send packet every number milliseconds | seconds | minutes | hours

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# send burst every 60 seconds packet count 100 interval 100 milliseconds

or

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# send burst once packet count 2 interval 1 second

or

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# send 
packet every 100 milliseconds 

Configures the types of packets sent by a probe in an operations profile.

Step 7 

packet size bytes

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# packet size 9000

Configures the minimum size (in bytes) for outgoing probe packets, including padding when necessary.

Step 8 

priority priority

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# priority 7

Configures the priority of outgoing SLA probe packets.

Step 9 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Save the configuration changes to the running configuration file and remains in the configuration session.

Step 10 

exit

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# exit

Exits to the previous mode.

 
Configuring Profile Statistics Measurement

Step 11 

statistics measure round-trip-delay | round-trip-jitter

Example:

RP/0/RSP0/CPU0:router(config-sla-prof)# statistics measure round-trip-delay

Enables the collection of SLA statistics, and enter the SLA profile statistics configuration mode.

Step 12 

aggregate bins count width width | none

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-stat-cfg) # aggregate bins 100 width 10000

Configures the size and number of bins into which to aggregate the results of statistics collection.

Step 13 

buckets size number per-probe | probes

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-stat-cfg) # buckets size 100 per-probe

Configures the size of the buckets in which statistics are collected.

Step 14 

buckets archive number

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-stat-cfg) # buckets archive 50

Configures the number of buckets to store in memory.

Step 15 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Save the configuration changes to the running configuration file and remains in the configuration session.

Step 16 

exit

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# exit

Exits to the previous mode.

Step 17 

exit

Example:

RP/0/RSP0/CPU0:router(config-sla-prof-pb)# exit

Exits to the previous mode.

 
Configuring a Profile Schedule

Step 18 

schedule every week on day at hh:mm for duration seconds | minutes | hours | days | week
or
schedule every day at hh:mm for duration seconds | minutes | hours | days | week
or
schedule every number hours | minutes first at hh:mm[.ss]
or
schedule every number hours | minutes for duration seconds | minutes | hours | days | week

Example:

RP/0/RSP0/CPU0:router(config-sla-prof)# schedule every week on Monday at 23:30 for 1 hour

or

RP/0/RSP0/CPU0:router(config-sla-prof)# schedule every day at 11:30 for 5 minutes

or

RP/0/RSP0/CPU0:router(config-sla-prof)# schedule every 2 hours first at 13:45:01

or

RP/0/RSP0/CPU0:router(config-sla-prof)# 
schedule every 6 hours for 2 hours 

Schedules an operation probe in a profile. A profile may contain only one schedule.

Step 19 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Save the configuration changes to the running configuration file and remains in the configuration session.

 
Configuring Operations

Step 20 

interface [GigabitEthernet | TenGigE] 
interface-path-id 
Example:

RP/0/RSP0/CPU0:router(config-if)# interface gigabitethernet 0/1/0/1

Physical interface or virtual interface.

Note Use the show interfaces command to see a list of all interfaces currently configured on the router.

For more information about the syntax for the router, use the question mark (?) online help function.

Step 21 

ethernet cfm mep domain domain_name service service_name mep-id id_number

Example:

RP/0/RSP0/CPU0:router(config-if)# ethernet cfm mep domain Dm1 service Sv1 mep-id 1

Creates a maintenance end point (MEP) on an interface and enters the interface CFM MEP configuration mode,

Step 22 

sla operation profile profile_name target mep-id id_number | mac-address mac_address

Example:

RP/0/RSP0/CPU0:router(config-if-cfm-mep)# sla operation profile Profile_1 target mac-address 01:23:45:67:89:ab

Creates an operation instance from a maintenance end point (MEP) to a specified destination.

Step 23 

commit

Example:

RP/0/RSP0/CPU0:router(config-if)# commit

Save the configuration changes to the running configuration file and remains in the configuration session.

Step 24 

end

Example:

RP/0/RSP0/CPU0:router(config-if)# end

Prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

 
Checking Configuration Errors

Step 25 

show ethernet sla configuration-errors [domain domain_name] [interface interface-path-id] [profile profile_name]

Example:

RP/0/RSP0/CPU0:router# show ethernet sla configuration-errors

Displays information about errors that are preventing configured SLA operations from becoming active, as well as any warnings that have occurred.

 
Verifying SLA Configuration

Step 26 

show ethernet sla operations [detail] [domain domain_name] [interface interface-path-id] [profile profile_name]

Example:

RP/0/RSP0/CPU0:router# show ethernet sla operations interface gigabitethernet 0/0/0/0.0

Displays information about configured SLA operations.

Configuration Examples for Ethernet OAM

This section provides the following configuration examples:

Configuration Examples for EOAM Interfaces

Ethernet CFM Configuration: Example

Ethernet CFM Show Command: Examples

AIS for CFM Configuration: Examples

AIS for CFM Show Command: Examples

EFD Configuration: Examples

Show EFD Information: Examples

Flexible Tagging for CFM Configuration: Examples

SLA Configuration: Example

Ethernet SLA Show Command: Examples

Configuration Examples for EOAM Interfaces

This section provides the following configuration examples:

Configuring an Ethernet OAM Profile Globally: Example

Configuring Ethernet OAM Features on an Individual Interface: Example

Configuring Ethernet OAM Features to Override the Profile on an Individual Interface: Example

Configuring a Remote Loopback on an Ethernet OAM Peer: Example

Clearing Ethernet OAM Statistics on an Interface: Example

Enabling SNMP Server Traps on a Router: Example

Configuring an Ethernet OAM Profile Globally: Example

The following example shows how to configure an Ethernet OAM profile globally:

configure terminal
 ethernet oam profile Profile_1
  link-monitor
   symbol-period window 60000
   symbol-period threshold low 10000000 high 60000000
   frame window 60
   frame threshold low 10000000 high 60000000 
   frame-period window 60000
   frame-period threshold low 100 high 12000000 
   frame-seconds window 900000
   frame-seconds threshold 3 threshold 900 
   exit
  mib-retrieval
  connection timeout 30
  require-remote mode active 
  require-remote link-monitoring 
  require-remote mib-retrieval
  action link-fault  error-disable-interface
  action dying-gasp error-disable-interface 
  action critical-event error-disable-interface
  action discovery-timeout error-disable-interface
  action session-down error-disable-interface
  action capabilities-conflict error-disable-interface
  action wiring-conflict error-disable-interface
  action remote-loopback error-disable-interface
  commit

Configuring Ethernet OAM Features on an Individual Interface: Example

The following example shows how to configure Ethernet OAM features on an individual interface:

configure terminal
 interface TenGigE 0/1/0/0
  ethernet oam 
   link-monitor
    symbol-period window 60000
    symbol-period threshold low 10000000 high 60000000
    frame window 60
    frame threshold low 10000000 high 60000000 
    frame-period window 60000
    frame-period threshold low 100 high 12000000 
    frame-seconds window 900000
    frame-seconds threshold 3 threshold 900 
    exit
   mib-retrieval
   connection timeout 30
   require-remote mode active 
   require-remote link-monitoring 
   require-remote mib-retrieval
   action link-fault  error-disable-interface
   action dying-gasp error-disable-interface 
   action critical-event error-disable-interface
   action discovery-timeout error-disable-interface
   action session-down error-disable-interface
   action capabilities-conflict error-disable-interface
   action wiring-conflict error-disable-interface
   action remote-loopback error-disable-interface
   commit

Configuring Ethernet OAM Features to Override the Profile on an Individual Interface: Example

The following example shows how to disable Ethernet OAM features to override the profile on an individual interface:

configure terminal
 ethernet oam profile Profile_1
  mode passive 
   action link-fault disable
   action dying-gasp disable 
   action critical-event disable
   action discovery-timeout disable
   action session-up disable 
   action session-down disable 
   action capabilities-conflict disable
   action wiring-conflict disable 
   action remote-loopback disable 
   commit
 
   

The following example shows how to configure Ethernet OAM features to override the profile on an individual interface so that errors are logged:

configure terminal
 interface TenGigE 0/1/0/0
  ethernet oam 
   profile Profile_1
   mode active 
   action link-fault log 
   action dying-gasp log 
   action critical-event log 
   action discovery-timeout log 
   action session-up log
   action session-down log
   action capabilities-conflict log
   action wiring-conflict log
   action remote-loopback log
   commit

Configuring a Remote Loopback on an Ethernet OAM Peer: Example

The following example shows how to configure a remote loopback on an Ethernet OAM peer:

configure terminal
 interface gigabitethernet 0/1/5/6 
  ethernet oam 
   profile Profile_1 
   remote-loopback 
 
   

The following example shows how to start a remote loopback on a configured Ethernet OAM interface:

RP/0/RP0/CPU0:router# ethernet oam loopback enable tengigE 0/6/1/0 

Clearing Ethernet OAM Statistics on an Interface: Example

The following example shows how to clear Ethernet OAM statistics on an interface:

RP/0/RP0/CPU0:router# clear ethernet oam statistics interface gigabitethernet 0/1/5/1 

Enabling SNMP Server Traps on a Router: Example

The following example shows how to enable SNMP server traps on a router:

configure terminal
  ethernet oam profile Profile_1 
  snmp-server traps ethernet oam events 

Ethernet CFM Configuration: Example

The following example shows how to configure Ethernet Connectivity Fault Management (CFM):

Configuring a Domain: Example

config 
 ethernet cfm 
  traceroute cache hold-time 1 size 3000 
  domain Domain_One level 1 id string D1 
  commit

Configuring Services for a Domain: Example

  service Bridge_Service bridge group BD1 bridge-domain B1 
  commit

Configuring Continuity Check for a Service: Example

   continuity-check archive hold-time 100 
   continuity-check loss auto-traceroute
   continuity-check interval 100ms loss-threshold 10 
   commit

Configuring MIP Creation for a Service: Example

   mip auto-create all 
   commit

Configuring Cross-check for a Service: Example

   mep crosscheck 
    mep-id 10 
    mep-id 20 
    commit

Configuring Other Service Parameters: Example

    maximum-meps 4000 
    log continuity-check errors 
    commit
    exit
   exit
  exit

Configuring MEPs: Example

 interface gigabitethernet 0/1/0/1
  ethernet cfm 
  mep domain Dm1 service Sv1 mep-id 1 
  commit

Checking for Configuration Errors: Example

show ethernet cfm configuration-errors 

Verifying CFM Configuration: Example

show ethernet cfm local maintenance-points 

Ethernet CFM Show Command: Examples

The following examples show how to verify the configuration of Ethernet Connectivity Fault Management (CFM):

Example 1

The following example shows how to display all the maintenance points that have been created on an interface:

RP/0/RSP0/CPU0:router# show ethernet cfm local maintenance-points 
 
   
Domain/Level         Service             Interface         Type   ID   MAC
-------------------- ------------------- ----------------- ------ ---- --------
fig/5                bay                 Gi0/10/0/12.23456 Dn MEP    2 44:55:66
fig/5                bay                 Gi0/0/1/0.1       MIP         55:66:77
fred/3               barney              Gi0/1/0/0.1       Up MEP    5 66:77:88!

Example 2

The following example shows how to display all the CFM configuration errors on all domains:

show ethernet cfm configuration-errors 
 
   
Domain fig (level 5), Service bay
 * MIP creation configured using bridge-domain blort, but bridge-domain blort does not 
exist.
 * An Up MEP is configured for this domain on interface GigabitEthernet0/1/2/3.234 and an 
Up MEP is also configured for domain blort, which is at the same level (5).
 * A MEP is configured on interface GigabitEthernet0/3/2/1.1 for this domain/service, 
which has CC interval 100ms, but the lowest interval supported on that interface is 1ms

Example 3

The following example shows how to display operational state for local maintenance end points (MEPs):

RP/0/RSP0/CPU0:router# show ethernet cfm local meps 
 
   
 A - AIS received                I - Wrong interval
 R - Remote Defect received      V - Wrong Level
 L - Loop (our MAC received)     T - Timed out (archived)
 C - Config (our ID received)    M - Missing (cross-check)
 X - Cross-connect (wrong MAID)  U - Unexpected (cross-check)
 P - Peer port down
 
   
Domain foo (level 6), Service bar
   ID Interface (State)        Dir MEPs/Err RD Defects AIS
----- ------------------------ --- -------- -- ------- ---
  100 Gi1/1/0/1.234 (Up)       Up     0/0   N  A       L7
                                                          
Domain fred (level 5), Service barney            
   ID Interface (State)        Dir MEPs/Err RD Defects AIS
----- ------------------------ --- -------- -- ------- ---
    2 Gi0/1/0/0.234 (Up)       Up     3/2   Y  RPC     L6

Example 4

The following example shows how to display operational state of other maintenance end points (MEPs) detected by a local MEP:

show ethernet cfm peer meps 
 
   
Flags:
 > - Ok                           I - Wrong interval
 R - Remote Defect received       V - Wrong level
 L - Loop (our MAC received)      T - Timed out
 C - Config (our ID received)     M - Missing (cross-check)
 X - Cross-connect (wrong MAID)   U - Unexpected (cross-check)
 
   
Domain fred (level 7), Service barney
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 2
================================================================================
St    ID MAC address    Port    Up/Downtime   CcmRcvd SeqErr   RDI Error
-- ----- -------------- ------- ----------- --------- ------ ----- -----
 >     1 0011.2233.4455 Up      00:00:01         1234      0     0     0
R>     4 4455.6677.8899 Up      1d 03:04         3456      0   234     0
L      2 1122.3344.5566 Up      3w 1d 6h         3254      0     0  3254
C      2 7788.9900.1122 Test    00:13            2345      6    20  2345
X      3 2233.4455.6677 Up      00:23              30      0     0    30
I      3 3344.5566.7788 Down    00:34           12345      0   300  1234
V      3 8899.0011.2233 Blocked 00:35              45      0     0    45
 T     5 5566.7788.9900         00:56              20      0     0     0
M      6                                            0      0     0     0
U>     7 6677.8899.0011 Up      00:02             456      0     0     0
 
   
Domain fred (level 7), Service fig 
Down MEP on GigabitEthernet0/10/0/12.123, MEP-ID 3
================================================================================
St    ID MAC address    Port    Up/Downtime  CcmRcvd SeqErr   RDI Error
-- ----- -------------- ------- ----------- -------- ------ ----- -----
 >     1 9900.1122.3344 Up      03:45           4321      0     0     0

Example 5

The following example shows how to display operational state of other maintenance end points (MEPs) detected by a local MEP with details:

RP/0/RSP0/CPU0:router# show ethernet cfm peer meps detail
Domain dom3 (level 5), Service ser3
Down MEP on GigabitEthernet0/0/0/0 MEP-ID 1
================================================================================
Peer MEP-ID 10, MAC 0001.0203.0403
   CFM state: Wrong level, for 00:01:34
   Port state: Up
   CCM defects detected:    V - Wrong Level
   CCMs received: 5
     Out-of-sequence:             0
     Remote Defect received:      5
     Wrong Level:                 0
     Cross-connect (wrong MAID):  0
     Wrong Interval:              5
     Loop (our MAC received):     0
     Config (our ID received):    0
Last CCM received 00:00:06 ago:
     Level: 4, Version: 0, Interval: 1min
     Sequence number: 5, MEP-ID: 10
     MAID: String: dom3, String: ser3
     Port status: Up, Interface status: Up
 
   
 
   
Domain dom4 (level 2), Service ser4
Down MEP on GigabitEthernet0/0/0/0 MEP-ID 1
================================================================================
Peer MEP-ID 20, MAC 0001.0203.0402
   CFM state: Ok, for 00:00:04
   Port state: Up
   CCMs received: 7
     Out-of-sequence:             1
     Remote Defect received:      0
     Wrong Level:                 0
     Cross-connect (wrong MAID):  0
     Wrong Interval:              0
     Loop (our MAC received):     0
	 Config (our ID received):    0
Last CCM received 00:00:04 ago:
     Level: 2, Version: 0, Interval: 10s
     Sequence number: 1, MEP-ID: 20
     MAID: String: dom4, String: ser4
     Chassis ID: Local: ios; Management address: 'Not specified'
     Port status: Up, Interface status: Up
 
   
Peer MEP-ID 21, MAC 0001.0203.0403
   CFM state: Ok, for 00:00:05
   Port state: Up
   CCMs received: 6
     Out-of-sequence:             0
     Remote Defect received:      0
     Wrong Level:                 0
     Cross-connect (wrong MAID):  0
     Wrong Interval:              0
     Loop (our MAC received):     0
     Config (our ID received):    0
Last CCM received 00:00:05 ago:
     Level: 2, Version: 0, Interval: 10s
     Sequence number: 1, MEP-ID: 21
     MAID: String: dom4, String: ser4
     Port status: Up, Interface status: Up
 
   
 
   
Domain dom5 (level 2), Service ser5
Up MEP on Standby Bundle-Ether 1 MEP-ID 1
================================================================================
Peer MEP-ID 600, MAC 0001.0203.0401
   CFM state: Ok (Standby), for 00:00:08, RDI received
   Port state: Down
   CCM defects detected:    Defects below ignored on local standby MEP
                            I - Wrong Interval
                            R - Remote Defect received
   CCMs received: 5
     Out-of-sequence:             0
     Remote Defect received: 	  5
	 Wrong Level:                 0
     Cross-connect W(wrong MAID): 0
     Wrong Interval:              5
     Loop (our MAC received):     0
     Config (our ID received):    0
   Last CCM received 00:00:08 ago:
     Level: 2, Version: 0, Interval: 10s
     Sequence number: 1, MEP-ID: 600
     MAID: DNS-like: dom5, String: ser5
     Chassis ID: Local: ios; Management address: 'Not specified'
     Port status: Up, Interface status: Down
 
   
Peer MEP-ID 601, MAC 0001.0203.0402
   CFM state: Timed Out (Standby), for 00:15:14, RDI received
   Port state: Down
   CCM defects detected:    Defects below ignored on local standby MEP
                            I - Wrong Interval
                            R - Remote Defect received
                            T - Timed Out
                            P - Peer port down
   CCMs received: 2
     Out-of-sequence:             0
     Remote Defect received:      2
     Wrong Level:                 0
     Cross-connect (wrong MAID):  0
     Wrong Interval:              2
     Loop (our MAC received):     0
     Config (our ID received):    0
   Last CCM received 00:15:49 ago:
     Level: 2, Version: 0, Interval: 10s
     Sequence number: 1, MEP-ID: 600
     MAID: DNS-like: dom5, String: ser5
     Chassis ID: Local: ios; Management address: 'Not specified'
     Port status: Up, Interface status: Down

AIS for CFM Configuration: Examples

The following example shows how to configure Alarm Indication Signal (AIS) transmission for a CFM domain service:

RP/0/RSP0/CPU0:router# config 
RP/0/RSP0/CPU0:router(config)# ethernet cfm
RP/0/RSP0/CPU0:router(config-cfm)# domain D1 level 1 
RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S1 bridge group BG1 bridge-domain BD2 
RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# ais transmission interval 1m cos 7 
 
   
 
   

The following example shows how to configure AIS logging for a Connectivity Fault Management (CFM) domain service to indicate when AIS or LCK packets are received:

RP/0/RSP0/CPU0:router# config 
RP/0/RSP0/CPU0:router(config)# ethernet cfm
RP/0/RSP0/CPU0:router(config-cfm)# domain D1 level 1
RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S2 bridge group BG1 bridge-domain BD2 
RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# log ais
 
   
 
   

The following example shows how to configure AIS transmission on a CFM interface.

RP/0/RSP0/CPU0:router# config 
RP/0/RSP0/CPU0:router(config)# interface gigabitethernet 0/1/0/2 
RP/0/RSP0/CPU0:router(config-if)# ethernet cfm 
RP/0/RSP0/CPU0:router(config-if-cfm)# ais transmission up interval 1m cos 7 

AIS for CFM Show Command: Examples

Show Ethernet CFM Interfaces AIS

The following example shows how to display the information published in the Interface AIS table:

RP/0/RSP0/CPU0:router# show ethernet cfm interfaces ais 
 
   
Defects (from at least one peer MEP):
 A - AIS received                I - Wrong interval
 R - Remote Defect received      V - Wrong Level
 L - Loop (our MAC received)     T - Timed out (archived)
 C - Config (our ID received)    M - Missing (cross-check)
 X - Cross-connect (wrong MAID)  U - Unexpected (cross-check)
 P - Peer port down              D - Local port down
 
   
                               Trigger                   Transmission
                         AIS  ---------    Via    ---------------------------
Interface (State)        Dir  L Defects  Levels   L Int Last started  Packets
------------------------ ---  - -------  -------  - --- ------------ --------
Gi0/1/0/0.234 (Up)       Dn   5 RPC      6        7 1s  01:32:56 ago     5576
Gi0/1/0/0.567 (Up)       Up   0 M        2,3      5 1s  00:16:23 ago      983
Gi0/1/0/1.1 (Dn)         Up     D                 7 60s 01:02:44 ago     3764
Gi0/1/0/2 (Up)           Dn   0 RX       1!
 
   

Show Ethernet CFM Local MEPs

Example 1: Default

The following example shows how to display statistics for local maintenance end points (MEPs):

RP/0/RSP0/CPU0:router# show ethernet cfm local meps 
 
   
 A - AIS received                I - Wrong interval
 R - Remote Defect received      V - Wrong Level
 L - Loop (our MAC received)     T - Timed out (archived)
 C - Config (our ID received)    M - Missing (cross-check)
 X - Cross-connect (wrong MAID)  U - Unexpected (cross-check)
 P - Peer port down
 
   
Domain foo (level 6), Service bar
   ID Interface (State)        Dir MEPs/Err RD Defects AIS
----- ------------------------ --- -------- -- ------- ---
  100 Gi1/1/0/1.234 (Up)       Up     0/0   N  A       7
                                                          
Domain fred (level 5), Service barney            
   ID Interface (State)        Dir MEPs/Err RD Defects AIS
----- ------------------------ --- -------- -- ------- ---
    2 Gi0/1/0/0.234 (Up)       Up     3/2   Y  RPC     6
 
   

Example 2: Domain Service

The following example shows how to display statistics for MEPs in a domain service:

RP/0/RSP0/CPU0:router# show ethernet cfm local meps domain foo service bar detail
 
   
Domain foo (level 6), Service bar
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 100
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 0 up, 0 with errors, 0 timed out (archived)
 
   
  CCM generation enabled:  No
  AIS generation enabled:  Yes (level: 7, interval: 1s)
  Sending AIS:             Yes (started 01:32:56 ago)
  Receiving AIS:           Yes (from lower MEP, started 01:32:56 ago)
 
   
Domain fred (level 5), Service barney 
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 2
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 3 up, 2 with errors, 0 timed out (archived)
  Cross-check defects: 0 missing, 0 unexpected
 
   
  CCM generation enabled:  Yes (Remote Defect detected: Yes)
  CCM defects detected:    R - Remote Defect received
                           P - Peer port down
                           C - Config (our ID received)
  AIS generation enabled:  Yes (level: 6, interval: 1s)
  Sending AIS:             Yes (to higher MEP, started 01:32:56 ago)
  Receiving AIS:           No

Example 3: Verbose

The following example shows how to display verbose statistics for MEPs in a domain service:


Note The Discarded CCMs field is not displayed when the number is zero (0). It is unusual for the count of discarded CCMs to be any thing other than zero, since CCMs are only discarded when the limit on the number of peer MEPs is reached.


 
   
RP/0/RSP0/CPU0:router# show ethernet cfm local meps domain foo service bar verbose 
 
   
Domain foo (level 6), Service bar
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 100
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 0 up, 0 with errors, 0 timed out (archived)
 
   
  CCM generation enabled:  No
  AIS generation enabled:  Yes (level: 7, interval: 1s)
  Sending AIS:             Yes (started 01:32:56 ago)
  Receiving AIS:           Yes (from lower MEP, started 01:32:56 ago)
  
  Packet        Sent      Received
  ------  ----------  -----------------------------------------------------
  CCM              0             0  (out of seq: 0)
  LBM              0             0
  LBR              0             0  (out of seq: 0, with bad data: 0)
  AIS           5576             0
  LCK              -             0
 
   
Domain fred (level 5), Service barney 
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 2
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 3 up, 2 with errors, 0 timed out (archived)
  Cross-check defects: 0 missing, 0 unexpected
 
   
  CCM generation enabled:  Yes (Remote Defect detected: Yes)
  CCM defects detected:    R - Remote Defect received
                           P - Peer port down
                           C - Config (our ID received)
  AIS generation enabled:  Yes (level: 6, interval: 1s)
  Sending AIS:             Yes (to higher MEP, started 01:32:56 ago)
  Receiving AIS:           No
  
  Packet        Sent      Received
  ------  ----------  ----------------------------------------------------------
  CCM          12345         67890  (out of seq: 6, discarded: 10)
  LBM              5             0
  LBR              0             5  (out of seq: 0, with bad data: 0)
  AIS              0         46910
  LCK              -             0

Example 4: Detail

The following example shows how to display detailed statistics for MEPs in a domain service:

RP/0/RSP0/CPU0:router# show ethernet cfm local meps detail
 
   
Domain foo (level 6), Service bar
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 100
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 0 up, 0 with errors, 0 timed out (archived)
 
   
  CCM generation enabled:  No
  AIS generation enabled:  Yes (level: 7, interval: 1s)
  Sending AIS:             Yes (started 01:32:56 ago)
  Receiving AIS:           Yes (from lower MEP, started 01:32:56 ago)
 
   
Domain fred (level 5), Service barney 
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 2
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 3 up, 2 with errors, 0 timed out (archived)
  Cross-check defects: 0 missing, 0 unexpected
 
   
  CCM generation enabled:  Yes (Remote Defect detected: Yes)
  CCM defects detected:    R - Remote Defect received
                           P - Peer port down
                           C - Config (our ID received)
  AIS generation enabled:  Yes (level: 6, interval: 1s)
  Sending AIS:             Yes (to higher MEP, started 01:32:56 ago)
  Receiving AIS:           No

EFD Configuration: Examples

The following example shows how to enable EFD:

RP/0/RSP0/CPU0:router# config 
RP/0/RSP0/CPU0:router(config)# ethernet cfm 
RP/0/RSP0/CPU0:router(config-cfm)# domain D1 level 1
RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S1 down-meps
RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# efd 
 
   

The following example shows how to enable EFD logging:

RP/0/RSP0/CPU0:router# config 
RP/0/RSP0/CPU0:router(config)# ethernet cfm 
RP/0/RSP0/CPU0:router(config-cfm)# domain D1 level 1
RP/0/RSP0/CPU0:router(config-cfm-dmn)# service S1 down-meps
RP/0/RSP0/CPU0:router(config-cfm-dmn-svc)# log efd 

Show EFD Information: Examples

The following example shows how to display all interfaces that are shut down because of Ethernet Fault Detection (EFD):

RP/0/RSP0/CPU0:router# show efd interfaces 
 
   
Server VLAN MA
==============
Interface         Clients
-------------------------
GigE0/0/0/0.0     CFM
 
   

Note Use the show ethernet cfm local meps detail command to display MEP-related EFD status information.


The following example shows that EFD is triggered for MEP-ID 100:

RP/0/RSP0/CPU0:router# show ethernet cfm local meps detail
 
   
Domain foo (level 6), Service bar
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 100
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 0 up, 0 with errors, 0 timed out (archived)
  Cross-check errors: 2 missing, 0 unexpected
 
   
  CCM generation enabled:  No
  AIS generation enabled:  Yes (level: 7, interval: 1s)
  Sending AIS:             Yes (started 01:32:56 ago)
  Receiving AIS:           Yes (from lower MEP, started 01:32:56 ago)
  EFD triggered:           Yes
 
   
Domain fred (level 5), Service barney 
Up MEP on GigabitEthernet0/1/0/0.234, MEP-ID 2
================================================================================
  Interface state: Up      MAC address: 1122.3344.5566
  Peer MEPs: 3 up, 0 with errors, 0 timed out (archived)
  Cross-check errors: 0 missing, 0 unexpected
 
   
  CCM generation enabled:  Yes (Remote Defect detected: No)
  AIS generation enabled:  Yes (level: 6, interval: 1s)
  Sending AIS:             No
  Receiving AIS:           No
  EFD triggered:           No

Note You can also verify that EFD has been triggered on an interface using the show interfaces and show interfaces brief commands. When an EFD trigger has occurred, these commands will show the interface status as up and the line protocol state as down.


Flexible Tagging for CFM Configuration: Examples

The following example shows how to set the number of tags in CFM packets from up MEPs in a CFM domain service:

RP/0/RP0/CPU0:router# config 
RP/0/RP0/CPU0:router(config)# ethernet cfm
RP/0/RP0/CPU0:router(config-cfm)# domain D1 level 1
RP/0/RP0/CPU0:router(config-cfm-dmn)# service S2 bridge group BG1 bridge-domain BD2 
RP/0/RP0/CPU0:router(config-cfm-dmn-svc)# tags 1 
RP/0/RP0/CPU0:router(config-cfm-dmn-svc)#
config 
 ethernet cfm
  domain D1 level 1
   service S2 bridge group BG1 bridge-domain BD2 
    tags 1 

SLA Configuration: Example

The following example shows how to configure an Ethernet Service Level Agreement (SLA):

Configuring a Profile

config 
 ethernet sla 
  profile  Prof1  type  cfm-loopback 
   commit

Configuring Profile Probe Parameters

   probe 
    send burst every 60 seconds packet count 100 interval 100 milliseconds 
! or
    send burst once packet count 1 interval 1 second 
! or
    send packet every 100 milliseconds 
    packet size 9000 
    priority 7 
    commit
    exit 

Configuring Profile Statistics Measurement

  statistics measure round-trip-delay 
   aggregate bins 100 width 10000 
   buckets size 100 per-probe 
   buckets archive 50 
   commit
   exit 
  exit 

Configuring Profile Schedule

  schedule every week on Monday at 23:30 for 1 hour 
! or
  schedule every day at 11:30 for 5 minutes 
! or
  schedule every 6 hours for 2 hours 
  commit
  exit 
 exit 

Configuring Operations

 interface gigabitethernet 0/1/0/1
  ethernet cfm mep domain Dm1 service Sv1 mep-id 1 
  sla operation profile Profile_1 target mac-address 01:23:45:67:89:ab s
  commit 
  end

Checking Configuration Errors

show ethernet sla configuration-errors 

Verifying SLA Configuration

show ethernet sla operations 

Ethernet SLA Show Command: Examples

The following examples show how to display information about configured SLA operations:

Example 1

RP/0/RP0/CPU0:router# show ethernet sla operations interface gigabitethernet 0/1/0/1.1 
 
   
Interface GigabitEthernet0/1/0/1.1
Domain mydom Service myser to 00AB.CDEF.1234
-----------------------------------------------------------------------------
Profile 'business-gold'
Probe type CFM-delay-measurement:
    bursts sent every 1min, each of 20 packets sent every 100ms
    packets padded to 1500 bytes with zeroes
    packets use priority value of 7
Measures RTT: 5 bins 20ms wide; 2 buckets/ probe; 75/100 archived
Measures Jitter (interval 1): 3 bins 40ms wide; 2 buckets/probe; 50 archived
Scheduled to run every Sunday at 4am for 2 hours:
    last run at 04:00 25/05/2008
 
   

Example 2

RP/0/RP0/CPU0:router# show ethernet sla configuration-errors 
 
   
Errors:
-------
  Profile 'gold' is not defined but is used on Gi0/0/0/0.0
  Profile 'red' defines a test-pattern, which is not supported by the type
 
   

The following examples show how to display the contents of buckets containing SLA metrics collected by probes:

Example 3

RP/0/RP0/CPU0:router# show ethernet sla statistics current interface GigabitEthernet 
0/0/0/0.0 
 
   
Interface GigabitEthernet 0/0/0/0.0
Domain mydom Service myser to 00AB.CDEF.1234
=============================================================================
Profile 'business-gold', packet type 'cfm-loopback'
Scheduled to run every Sunday at 4am for 2 hours
 
   
Round Trip Delay
~~~~~~~~~~~~~~~~
2 buckets per probe
 
   
Bucket started at 04:00 Sun 17 Feb 2008 lasting 1 hour:
    Pkts sent: 2342; Lost 2 (0%); Corrupt: 0 (0%); Misordered: 0 (0%)
    Min: 13ms; Max: 154ms; Mean: 28ms; StdDev: 11ms
 
   
Round Trip Jitter
~~~~~~~~~~~~~~~~~
2 buckets per probe
 
   
Bucket started at 04:00 Sun 17 Feb 2008 lasting 1 hour:
    Pkts sent: 2342; Lost: 2 (0%); Corrupt: 0 (0%); Misordered: 0 (0%)
    Min: -5ms; Max: 8ms; Mean: 0ms; StdDev: 3.6ms
 
   
Bucket started at 04:00 Sun 17 Feb 2008 lasting 1 hour:
    Pkts sent: 2342; Lost: 2 (0%); Corrupt: 0 (0%); Misordered: 0 (0%)
    Min: 0; Max: 4; Mean: 1.4; StdDev: 1
 
   

Example 4

RP/0/RP0/CPU0:router# show ethernet sla history detail GigabitEthernet 0/0/0/0.0 
 
   
Interface GigabitEthernet 0/0/0/0.0
Domain mydom Service myser to 00AB.CDEF.1234
===============================================================================
Profile 'business-gold', packet type 'cfm-loopback'
Scheduled to run every Sunday at 4am for 2 hours
 
   
Round Trip Delay
~~~~~~~~~~~~~~~~
2 buckets per probe
 
   
Bucket started at 04:00 Sun 17 Feb 2008 lasting 1 hour:
    Pkts sent: 2342; Lost: 2 (0%); Corrupt: 0 (0%); Misordered: 0 (0%)
    Min: 13ms; Max: 154ms; Mean: 28ms; StdDev: 11ms
 
   
    Results suspect as more than 10 seconds time drift detected
    Results suspect as scheduling latency prevented some packets being sent
 
   
    Samples:
    Time sent       Result  Notes     
    ------------  --------  ----------
    04:00:01.324      23ms            
    04:00:01.425      36ms            
    04:00:01.525         -  Timed Out 
    ...
 
   
Round Trip Jitter
~~~~~~~~~~~~~~~~~
2 buckets per probe
 
   
Bucket started at 04:00 Sun 17 Feb 2008, lasting 1 hour:
    Pkts sent: 2342; Lost: 2 (0%); Corrupt: 0 (0%); Misordered: 0 (0%)
    Min: -5ms; Max: 10ms; Mean: 0ms; StdDev: 3.6ms
 
   
    Samples:
    Time sent       Result  Notes     
    ------------  --------  ----------
    04:00:01.324         -            
    04:00:01.425      13ms            
    04:00:01.525         -  Timed out 
    ...

Where to Go Next

When you have configured an Ethernet interface, you can configure individual VLAN subinterfaces on that Ethernet interface.

For information about modifying Ethernet management interfaces for the shelf controller (SC), route processor (RP), and distributed RP, see the Advanced Configuration and Modification of the Management Ethernet Interface on the Cisco ASR 9000 Series Router module later in this document.

For information about IPv6 see the Implementing Access Lists and Prefix Lists on
Cisco IOS XR Softwar
e module in the Cisco IOS XR IP Addresses and Services Configuration Guide.

Additional References

The following sections provide references related to implementing Gigabit and 10-Gigabit Ethernet interfaces.

Related Documents

Related Topic
Document Title

Ethernet L2VPN

Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Configuration Guide

Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Command Reference


Standards

Standards
Title

IEEE 802.1ag

Connectivity Fault Management

ITU-T Y.1731

OAM Functions and Mechansims for Ethernet Based Networks


MIBs

MIBs
MIBs Link

IEEE8021-CFM-MIB

To locate and download MIBs for selected platforms using
Cisco IOS XR Software, use the Cisco MIB Locator found at the following URL:

http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


RFCs

RFCs
Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.


Technical Assistance

Description
Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport