SYSTEM ADMINISTRATOR GUIDE 52/1543-CRA 119 1170/1-V1 Uen A

Configuring Ethernet CFM

Copyright

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge		is a registered trademark of Telefonaktiebolaget L M Ericsson.
NetOp		is a trademark of Telefonaktiebolaget L M Ericsson.

Contents

1	Overview
1.1	Ethernet Service Management
1.2	CFM Terminology
1.3	SNMP Support for CFM
1.4	CFM Restrictions and Limitations
1.5	SNMP CFM Problems
1.6	CFM Supported Circuits
2	Configuration and Operations Tasks
2.1	Configuration of an CFM Instance, its MD, and Maintenance Points
2.2	Configuration of the MA Parameters
2.3	CFM Troubleshooting and Status Operations
3	Configuration Examples
3.1	MEP on an Attachment Circuit to an L2VPN Pseudowire
3.2	Link Failure Detection in Link Groups
3.3	Loop Detection
3.4	Monitoring Four Bridges and an L2VPN Circuit
3.5	MEP on a Link Group
3.6	show ethernet-cfm ... Linktrace Output

1 Overview

This document describes the operations, administration, and maintenance (OAM) of Ethernet bridges that link wide area networks (WANs) and metropolitan area networks (MANs). To enable providers and users to monitor Ethernet connectivity faults and quickly determine their location, the SmartEdge router supports IEEE P802.1ag, connectivity fault management (CFM).

In this document, the term CFM identifies the type of Ethernet OAM implemented by the SmartEdge router. This section provides a short description of Ethernet service management, the SmartEdge CFM implementation, definitions, SNMP support, supported circuits, a table of operations commands, and a description of the operating system CLI command modes.

1.1 Ethernet Service Management

The SmartEdge CFM implementation provides service management of the Ethernet and Ethernet emulating interfaces of the SmartEdge router. SmartEdge CFM allows service providers and end users to individually manage their Ethernet service instances on the SmartEdge router.

The mechanisms that the SmartEdge router uses to monitor customer instances for Ethernet faults are based on IEEE P802.1ag PDU messages:

Ethernet Virtual Connection (EVC):
A customer service instance, also called an Ethernet Virtual Connection (EVC), is the service that is sold to a customer and is designated by its service-VLAN (S-VLAN) tag or entire port. SmartEdge CFM enables the service provider to know if an EVC has failed and provides tools to rapidly isolate the failure.
Continuity Check Message (CCM):
The CCM is a multicast unidirectional heartbeat message used for fault detection. The maintenance association endpoint (MEP) broadcasts CCMs to check the continuity of the maintenance association (MA). By default, loss of three consecutive CCMs is reported as a MA connectivity fault.
Loopback Message (LBM), Loopback Reply (LBR):
LBM and LBR are unicast bidirectional request and reply messages used for fault detection and verification. The simplest form of LBM-LBR is a ping message with a static MAC address.
Link-Trace Message (LTM), Link-Trace Reply (LTR):
The multicast request (LTM) but unicast response (LTR) messages are used for fault isolation and path discovery. LTMs are initiated by MEPs. The LTM traverses the bridged Ethernet networks hop by hop.

Each maintenance point along the path examines the LTM and takes the following actions:
1. Responds to the originating MEP by returning an LTR
2. Forwards the LTM to the next hop, based on the target MAC address in the LTM payload

1.2 CFM Terminology

The following terms are used to describe the SmartEdge CFM implementation:

maintenance domain (MD)—The network or the part of the network for which faults in connectivity are managed. An MD can manage a collection of service instances, provided each service instance has a domain service access point (DSAP) available to the MD user. In customer bridges, the service instance corresponds to a C-VLAN, and in provider bridges, the service instance corresponds to an S-VLAN.
CFM instance—A SmartEdge router object that contains a single MD.
maintenance domain name—The identifier of a particular MD. The maintenance domain name is unique over the domain for which CFM protects against accidental concatenation of service instances.
maintenance association (MA)—A set of MEPs, each configured with the same MAID and MD level, established to verify the integrity of a single S-VLAN or C-VLAN.
maintenance association endpoint (MEP)—An actively managed CFM maintenance point associated with a specific domain service access point (DSAP), which can generate and receive CFM PDUs and track any responses. An MEP must also be an MA endpoint.
local and remote MEPs—Local MEPs are bound to SmartEdge router circuit interfaces and ports, while remote MEPs are bound to other network nodes. In Figure 1, Operator A provides bridges 2 and 3. In the MA between the bridges, the MEP on the left is local relative to bridge 2 but remote relative to bridge 3. In the same sense, the MEP on the right is local relative to bridge 3 but remote relative to bridge 2.
Local MEPs can be classified as up or down:
- Up specifies that the MEP resides in a bridge that transmits CFM messages towards, and receives them from, the direction of the bridge relay; that is, an up MEP is an endpoint of an MA that runs through the bridging device.
- Down specifies that the MEP resides in a bridge that transmits CFM messages towards, and receives them from, the direction of the physical medium; that is, a down MEP is an endpoint of an MA that does not run through the bridging device.
circuit—In general telecommunications use, a circuit is a communications path between two or more points. However, in this document, the term circuit refers to the endpoint of any segment of a communications path that terminates on a SmartEdge router.
maintenance association intermediate point (MIP)—An intermediate maintenance point located between the two endpoint MEPs of a point-to-point circuit. A MIP is an actively managed CFM entity that reacts and responds to some OAM flows in a specific MD.
maintenance point (MP)—One of either a MEP or a MIP. Each maintenance point is bound to an ingress or egress port of an Ethernet device or Ethernet-aware device in the MD.
maintenance association endpoint identifier (MEPID)—A small integer, unique over an MA, identifying a specific MEP. Each MEP in an MA has a unique MEPID.
maintenance association identifier (MAID)—An identifier for an MA. The MAID has two parts: the maintenance domain name and the short MA name.
MD level—An integer field associated with each maintenance domain. The MD level, ranging from 0 to 7, allows nested maintenance domains to manage shared maintenance points. MD levels are also referred to as maintenance levels.
continuity check message (CCM)—A multicast CFM PDU transmitted periodically by a MEP to assure continuity over the MA to which the transmitting MEP belongs.
link-trace message (LTM)—A broadcast CFM PDU initiated by a MEP to trace a path to a target MAC address, forwarded from MIP to MIP, up to the point at which the LTM reaches its target MEP or can no longer be forwarded. Each maintenance point along the path to the target generates an LTR.
link-trace reply (LTR)—A unicast CFM PDU sent in response to an LTM. The a destination of the unicast LTR is the address of the MEP that originated the LTM.
loopback message (LBM)—A unicast CFM PDU transmitted by a MEP, addressed to a specific maintenance point, in the expectation of receiving an LBR.
loopback reply (LBR)—A unicast CFM PDU transmitted by an maintenance point to the originating MEP, in response to an LBM received from that MEP.
short MA name—The part of the MAID which is unique within the MD and appended to the MD name to form the MAID.

Figure 1 illustrates concepts described in this section:

Figure 1 Maintenance Domains

1.3 SNMP Support for CFM

Table 1 lists the SNMP MIB tables that report the MAs, MDs, and MEPs managed by the SmartEdge router.

*Table 1 SNMP MIB Tables for CFM*
Table	Description
dot1agCfmMdTable	MD table. Each row in the table represents a different MD.
dot1agCfmMaNetTable	MA table. Each row in the table represents an MA. An MA is a set of MEPs, each configured with a single service instance.
dot1agCfmMepTable	MEP table.
dot1agCfmLtrTable	Extension of the MEP table that contains a list of LTRs received by a specific MEP in response to a LTM.
dot1agCfmMepDbTable	MEP database, which is a database maintained by every MEP, that contains information received about other MEPs in the MD.

Table 2 lists the notification (trap) that the SmartEdge router sends to the SNMP management entity whenever a MEP loses or restores contact with other MEPs.

*Table 2 SNMP Traps for CFM*
Trap	Description
dot1agCfmFaultAlarm	The CFM Fault Alarm is sent whenever a MEP loses or restores contact with other MEPs. The notification contains the object ID (OID) of the MEP that has detected the fault.

1.4 CFM Restrictions and Limitations

1.5 SNMP CFM Problems

When a maintenance associate endpoint has a defect condition, such as a loss of CCMs, an SNMP notification with the highest-priority defect is triggered and reported. However, the CFM trap content shows the local maintenance association endpoint index as zero and the dot1agCfmMepHighestPrDefect as none (0), which is incorrect. Use the SNMP get-next operation to obtain the values of the dot1agCfmMepHighestPrDefect MIB object.

The MIB value for the dot1agCfmMepHighestPrDefect object shows text, defRDICCM(1), other than the correct text, defRemoteCCM(3). Ignore defRDICCM(1) for the dot1agCfmMepHighestPrDefect object.

Transmission of Ethernet-OAM loopback messages does not populate values to the following MIB objects:

dot1agCfmMepTransmitLbmResultOK
dot1agCfmMepTransmitLbmDestMacAddress
dot1agCfmMepTransmitLbmDestMepId

Transmission of Ethernet-OAM link-trace messages does not populate values to the following MIB objects

dot1agCfmMepTransmitLtmResult
dot1agCfmMepTransmitLtmTargetMacAddress
dot1agCfmMepTransmitLtmTargetMepId

The CFM database incorrectly reports the value of the dot1agCfmMepTransmitLbmMessages MIB object as always equal to zero.

The different states of the MIB object, Dot1agCfmFngState, such as fngDefect(2), fngReportDefect(3), fngDefectReported(4), fngDefectClearing(5), are not available. SNMP status for Dot1agCfmFngState is always reported with the value fngReset(1) regardless of its actual status.

The local MEP index of the remote MEP database table in IEEE8021-CFM-MIB is always zero (0) instead of the associated local MEP ID.

The value of the dot1agCfmMepLtmNextSeqNumber object is incorrect when running loopback transmission messages (LTMs). The object, dot1agCfmMepLtmNextSeqNumber, is increased by running LTMs, but it should in fact be independent of LTMs.

1.6 CFM Supported Circuits

This section describes the circuits that support CFM MPs.

1.6.1 MPs on Physical Ethernet Circuits

A maintenance point (MEP or MIP) can be configured on a circuit on a physical Ethernet port.

CFM PDUs pass over the cross connection and are processed by the MPs in the MA on both sides of the cross connection.

Each Ethernet circuit can be associated only with a single MA.

The circuit can be part of a bridging group, or it can be cross-connected to another circuit or to a VLAN-based circuit.

1.6.2 MPs on VLAN-Based Circuits

A maintenance point (MEP or MIP) can be configured on an VLAN-based circuit (that is, an 802.1Q PVC, an 802.1Q tunnel, or an 802.1Q PVC in an 802.1Q tunnel). The PVC must use the MAC address of the physical port or system. The VLAN can be part of a bridging group, or it can be cross connected to another VLAN or to a circuit.

CFM PDUs pass over the cross connection and are processed by the MPs in the MA on both sides of the cross connection.

Each VLAN-based circuit can be associated with only one MA.

Processing of CCMs is supported on the port bound to a 802.1Q tunnel, but not on the C-VLAN or S-VLAN-based circuits.

1.6.3 MPs on Link Groups

You can configure maintenance points (MEP or MIP) on link groups of the following types. The link group ports can be configured simply as bundled ports or with aggregated 802.1Q PVCs (VLANs) or 802.1Q tunnels:

Ethernet link group (network side)
802.1Q link group (network side)
Ethernet access link group (subscriber side)

When link groups are configured for CFM, only one port in the link group bundle transmits CFM PDUs.

1.6.4 MPs on VLAN-Based Circuits Cross Connected to a VLL

CFM can be configured on a L2VPN circuit; that is, MPs can be configured on VLAN-based circuits cross connected to a virtual leased line (VLL) in the L2VPN circuit. CFM PDUs pass over the cross connection and VLL and are processed by the MPs in the MA on the VLAN based-circuits on both ends of the cross connection.

A VLL is a pseudowire that uses an L2VPN circuit to provide point-to-point service between two network nodes over a packet network that supports MPLS. Use the xc (cross connect) command to attach the local VLAN-based circuit to the VLL pseudowire. In SmartEdge router documentation, the connection between the local circuit and the pseudowire is sometimes called a cross connection, although in a more general sense the connection between the two nodes over the pseudowire could also be called a cross connection.

You can configure MPs on the VLAN-based circuits that are attached to the pseudowire, but because the pseudowire has no physical interface, you cannot configure MPs on the pseudowire itself. See Figure 2

Figure 2 Circuits Cross Connected to a VLL

1.6.5 MPs on a VLAN-Based Circuits Cross Connected to a VPLS Pseudowire

CFM can be configured on VLAN-based circuits cross connected to a VPLS pseudowire. CFM PDUs pass over the cross connection and pseudowire and are processed by the MPs in the MA on the VLAN based-circuits on both ends of the cross connection.

You can configure MPs on the local VLAN-based circuits attached to a pseudowire, but not on the VPLS pseudowire itself.

2 Configuration and Operations Tasks

To configure a CFM instance, its MD, maintenance points, and MA parameters, and to troubleshoot and determine the status of CFM, see the following sections.

2.1 Configuration of an CFM Instance, its MD, and Maintenance Points

The following rules apply to the configuration of an CFM Instance, its MD, and its Maintenance Points:

You can configure multiple CFM instances in the SmartEdge router, but each must have a different CFM instance name.
Each CFM instance can have at most one MD level and one MD name.
If you configure multiple CFM instances in a SmartEdge router, their levels can be the same, but their domain names must be different.
Optionally, you configure multiple MAs in a CFM instance.
Optionally, you can configure multiple MIPs in a CFM instance.
The MEPIDs of all MEPs must be specified whether to MEP is local or remote.
The MEPIDs must be specified for both local and remote MEPs.

Perform the tasks described in Table 3 to configure SmartEdge system maintenance points of a maintenance domain.

*Table 3 Configuration of an CFM Instance, its MD, and Maintenance Points*
Step	Task	Root Command	Notes
1.	Give a name to the CFM instance.	ethernet-cfm	Enter in global configuration mode.
2.	Enter the name of the MD for which the SmartEdge CFM instance is a component.	domain-name	Enter in CFM configuration mode.
3.	Enter the MD level of the maintenance domain specified in step 2.	level	Enter in CFM configuration mode.
4.	Create a list of (MIPs) in the MD and associate each MIP with a physical port or interface.	mip	Enter in CFM configuration mode. A maintenance point not having a domain service access point, but connected to MEPs in this domain, should be configured as a MIP.
5.	Optionally disable the responses of maintenance points in the MD specified in step 2 from responding to LTM PDUs.	Commands: ip through li	Enter in CFM configuration mode.
6.	Create an MA in the MD specified in step 2. Repeat this step for every MA in the MD. Continue with Table 4 for every MA created.	maintenance-association	Enter in CFM configuration mode.

Use the show configuration cfm command to see the resulting CFM configuration.

2.2 Configuration of the MA Parameters

Perform the following tasks described in Table 4 to configure the parameters of a SmartEdge MA.

*Table 4 Configuration of the MA Parameters*
Step	Task	Root Command	Notes
1.	Create a list of remote maintenance endpoints (MEPs) in the MA, and give each MEP its own ID (MEPID) in the MA.	mep-remotelist	Enter in MA configuration mode. The mesh of MEPs forms a single C-VLAN or S-VLAN.
2.	Bind each MEPID with a local physical interface or port, and specify the MEP direction.	mep-local	Enter in MA configuration mode. Repeat this step for each and every MEPID in the MA: `Up` specifies that the MEP resides in a bridge that transmits CFM Messages towards, and receives them from, the direction of the bridge relay. `Down` specifies that the MEP resides in a bridge that transmits CFM Messages towards, and receives them from, the direction of the physical medium.
3.	Enable CCM and enter the CCM configuration mode.	ccm	Enter in MA configuration mode
4.	Configure CCM connectivity fault failed frames criteria.	frame-loss	Enter in CCM configuration mode
5.	Configure the interval between sending CCM PDUs.	std-interval	Enter in CCM configuration mode

2.3 CFM Troubleshooting and Status Operations

If a link fails, you can troubleshoot the problem through CFM link trace and loopback testing. These commands are listed in Table 5.

*Table 5 CFM Status Troubleshooting Operations*
Task	Root Command
Initiate the CFM link-trace test	ethernet-cfm linktrace⁽¹⁾
Initiate the CFM loopback test	ethernet-cfm loopback⁽²⁾
Initiate CFM debugging	debug cfm
Clear CFM loopback and link-trace counters	clear ethernet-cfm counters

(1) Use no linktrace to disable linktrace responses.

(2) Use no loopback to disable loopback responses.

2.3.1 Troubleshooting with the ethernet-cfm loopback Command

The following example shows a successful loopback test.

[local]Redback(config-if)#ethernet-cfm loopback from 2/11 vlan-id 1 to 00:30:88:02:f2:d8 level 2
circuit: 2/11 vlan-id 1, handle: 2/11:1023:63/1/2/14, vlan id: 1, inner vlan id: 0ethernet-cfm 
loopback from 2/11 vlan-id 1 to 00:30:88:02:f2:d8 level 2
CFM loopback in progress...
source mac: 00:30:88:02:82:88, cct: 1/10/1/0, data: 
timeout is 1 second
!!!!!

-----CFM Loopback statistics-----
5 loopback packets sent, 5 packets received, 0.0% packet loss
round-trip min/avg/max = 0/2/4 ms

2.3.2 Troubleshooting with the ethernet-cfm linktrace Command

The following example shows a working linktrace test.

[local]Redback(config-if)#ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5
ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5
CFM linktrace in progress...
cct: 1/1/100/0, data:
1  00:30:88:12:3d:86    4 ms
2  00:30:88:02:f3:23    8 ms
CFM linktrace completed.

The following example shows a linktrace test that failed after completing one hop.

[local]Redback(config-if)#ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5
ethernet-cfm linktrace from 2/2 vlan-id 100 to 00:30:88:02:f3:23 level 5
CFM linktrace in progress...
cct: 1/1/100/0, data:
1  00:30:88:12:3d:86    4 ms
0   *
CFM linktrace could not be completed. (Reason : timeout)

2.3.3 Monitoring CFM Database Commands

Use the following CLI commands in Table 6 to monitor link status and the CFM database. Examples of the output fields displayed by these commands are found in the reference pages for these commands.

*Table 6 CFM Status Monitoring Status Operations*
Task	Root Command
Show the CFM information for a specified circuit	show ethernet-cfm circuit
Show the current CCM database	show ethernet-cfm database instance-name
Show the status of MDs	show ethernet-cfm database... domain
Show the status of MAs	show ethernet-cfm database... ma
Show the status of local MEPs	show ethernet-cfm database... mep
Show the status of remote MEPs	show ethernet-cfm database... rmep
Show the status of MIPs	show ethernet-cfm database... mip

3 Configuration Examples

This section provides examples of configuring MEP.

3.1 MEP on an Attachment Circuit to an L2VPN Pseudowire

The following example show how to create an 802.1Q PVC attachment circuit on port 5/1 and cross-connect it to an L2VPN pseudowire. The local MEP is configured on the 802.1Q PVC:

[local]Redback(config)#context local
[local]Redback(config-ctx)#interface foo
[local]Redback(config-if)#ip address 200.2.2.2/24
[local]Redback(config-if)#exit
[local]Redback(config-ctx)#l2vpn
[local]Redback(config-l2vpn)#xc-group bar
[local]Redback(config-l2vpn-xc-group)#xc 5/1 vlan-id 300 vpn-label 5000 peer 100.1.1.1
!
[local]Redback(config-ctx)#port ethernet 5/1
[local]Redback(config-port)#no shutdown
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 300
[local]Redback(config-dot1q-pvc)#l2vpn local
!
[local]Redback(config)#ethernet-cfm instance-3
[local]Redback(config-ether-cfm)#level 5
[local]Redback(config-ether-cfm)#maintenance-association green
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma-ccm)#exit
[local]Redback(config-ether-cfm-ma)#mep-remotelist 12
[local]Redback(config-ether-cfm-ma)#mep-local 102 5/1 vlan-id 300 direction up
!
[local]Redback#show config cfm
!
Building configuration...
Current configuration:
!
!Ethernet connectivity fault management configuration
!
ethernet-cfm instance-3
  level 5
  domain-name instance-3
  maintenance-association R&D
    ccm
    mep-remotelist 11
    mep-local 101 5/1 vlan-id 300
  maintenance-association green
    ccm
    mep-remotelist 12
    mep-local 102 5/1 vlan-id 300
end

3.2 Link Failure Detection in Link Groups

Figure 3 illustrates a simplified network of two nodes (A and B), where CFM reports the failure of any of the four links between the nodes. This type of CFM configuration is applicable to link groups, where the four links are in the link bundle:

Figure 3 Simplified Two-Node, Four-Circuit Network

For the A-B segment of the network, the example configures four maintenance associations (vlan1-vlan4) in the same domain. Link failures are detected through CCM PDUs.

Link failure detection is configured on nodes A and B in the following sections.

3.2.1 Node A

Create CFM instance-1 and MD abc in it. Each CFM instance can have at most one MD level and one MD name:

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 2
[local]Redback(config-ether-cfm)#domain-name abc

Create MA vlan1, which corresponds to the Ethernet VLAN between cct1 on node A and cct5 on node B. There is one link per Ethernet port: cct1 is 5/1 on node A and cct5 is 9/1 on node B. The local MEP on one instance (node) is the remote MEP on the other; that is why the local MEP ID on instance-1 matches the remote MEP ID on instance-2:

[local]Redback(config-ether-cfm)#maintenance-association vlan1
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 101
[local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down

Create MA vlan2, which corresponds to the Ethernet VLAN between cct2 on node A and cct6 on node B, where cct2 is 5/2 and cct6 is 9/2:

[local]Redback(config-ether-cfm)#maintenance-association vlan2
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 201
[local]Redback(config-ether-cfm-ma)#mep-local 21 5/2 direction down

Create MA vlan3, which corresponds to the Ethernet VLAN between cct3 on node A and cct7 on node B, where cct3 is 5/3 and cct7 is 9/3:

[local]Redback(config-ether-cfm)#maintenance-association vlan3
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 301
[local]Redback(config-ether-cfm-ma)#mep-local 31 5/3 direction down

Create MA vlan4, which corresponds to the Ethernet VLAN between cct4 on node A and cct8 on node B, where cct3 is 5/4 and cct7 is 9/4:

[local]Redback(config-ether-cfm)#maintenance-association vlan4
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 401
[local]Redback(config-ether-cfm-ma)#mep-local 41 5/4 direction down

3.2.2 Node B

Create CFM instance-2 and MD abc in it. Each CFM instance can have at most one MD level and one MD name:

[local]Redback(config)#ethernet-cfm instance-2
[local]Redback(config-ether-cfm)#level 2
[local]Redback(config-ether-cfm)#domain-name abc

Create MA vlan1, which corresponds to the Ethernet VLAN between cct1 on node A and cct5 on node B. There is one link per Ethernet port, cct1 is 5/1 on node A and cct5 is 9/1 on node B:

[local]Redback(config-ether-cfm)#maintenance-association vlan1
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 11
[local]Redback(config-ether-cfm-ma)#mep-local 101 9/1 direction down

Create MA vlan2, which corresponds to the Ethernet VLAN between cct2 on node A and cct6 on node B, where cct2 is 5/2 and cct6 is 9/2:

[local]Redback(config-ether-cfm)#maintenance-association vlan2
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 21
[local]Redback(config-ether-cfm-ma)#mep-local 201 9/2 direction down

Create MA vlan3, which corresponds to the Ethernet VLAN between cct3 on node A and cct7 on node B, where cct3 is 5/3 and cct7 is 9/3:

[local]Redback(config-ether-cfm)#maintenance-association vlan3
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 31
[local]Redback(config-ether-cfm-ma)#mep-local 301 9/3 direction down

Create MA vlan4, which corresponds to the Ethernet VLAN between cct4 on node A and cct8 on node B, where cct3 is 5/4 and cct7 is 9/4:

[local]Redback(config-ether-cfm)#maintenance-association vlan4
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 41
[local]Redback(config-ether-cfm-ma)#mep-local 401 9/4 direction down

3.3 Loop Detection

In the example illustrated by Figure 4, the SmartEdge router monitors whether or not there is a loop for the circuit with interface 5/1 on router A:

Figure 4 Loop Detection

The down MEP at cct continuously sends CCM PDUs. If there is a loop, it receives the CCMs back and reports a circuit fault:

[local]Redback(config)#ethernet-cfm teleportics
[local]Redback(config-ether-cfm)#domain-name teleportics.com
[local]Redback(config-ether-cfm)#level 5
[local]Redback(config-ether-cfm)#maintenance-association sp
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 101
[local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down

3.4 Monitoring Four Bridges and an L2VPN Circuit

In the example illustrated by Figure 5, a single customer service instance (C-VLAN) connects port 5/1 on bridge A to port 6/1 on bridge D. Service provider bridge B and C maintain the S-VLAN service instance, which encapsulates the customer C-VLAN:

Figure 5 Monitoring Bridges

The following is the CFM configuration for subscriber bridge A. The instance-1 service instance contains a single MA name R&D. From the point of view of bridge A, R&D is terminated by the local MEP (11) at port 5/1 and a remote MEP (101) on subscriber bridge D:

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 5
[local]Redback(config-ether-cfm)#domain-name redback.com
[local]Redback(config-ether-cfm)#maintenance-association R&D
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma-ccm)#exit
[local]Redback(config-ether-cfm-ma)#mep-remotelist 101
[local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down

The following is the CFM configuration for subscriber bridge D. Subscriber bridges A and D monitor the customer service instance (instance-1). From the point of view of bridge D, R&D is locally terminated by MEP (101) at port 6/1 and remote MEP (11) on subscriber bridge A:

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 5
[local]Redback(config-ether-cfm)#domain-name redback.com
[local]Redback(config-ether-cfm)#maintenance-association R&D
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 11
[local]Redback(config-ether-cfm-ma)#mep-local 101 6/1 direction down

In the following configuration of provider bridge B, the instance-2 service instance monitors the S-VLAN between local MEP (31) at port 4/2 on bridge B and remote MEP (301) on bridge C. The provider MD level 4 must be lower than the subscriber MD level:

[local]Redback(config)#ethernet-cfm instance-2
[local]Redback(config-ether-cfm)#level 4
[local]Redback(config-ether-cfm)#domain-name sbc.com
[local]Redback(config-ether-cfm)#maintenance-association bayarea
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 301
[local]Redback(config-ether-cfm-ma)#mep-local 31 4/2 direction up

The following configures port 4/2 on bridge B in the redback.com domain as a MIP in the instance-1 at MD level 4:

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 5
[local]Redback(config-ether-cfm)#domain-name redback.com
[local]Redback(config-ether-cfm)#mip 31 4/2

The following is the CFM configuration for provider bridge C, instance-2 service instance. Provider bridges B and C monitor the S-VLAN between port 4/2 on bridge B and port 9/1 on bridge C:

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 4
[local]Redback(config-ether-cfm)#domain-name sbc.com
[local]Redback(config-ether-cfm)#maintenance-association bayarea
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma)#mep-remotelist 31
[local]Redback(config-ether-cfm-ma)#mep-local 301 9/1 direction up

The following configures port 9/1 on bridge C in the redback.com domain as a MIP in the instance-1 at MD level 4:

[local]Redback(config)#ethernet-cfm instance-2
[local]Redback(config-ether-cfm)#level 5
[local]Redback(config-ether-cfm)#domain-name redback.com
[local]Redback(config-ether-cfm)#mip 301 9/1

3.5 MEP on a Link Group

The following example show how to create an access link group named dslam-face and an aggregated PVC with ID 1 on the link group. The local MEP 101 is one configured on the aggregated 802.1Q PVC:

[local]Redback(config)#link-group dslam-face access
[local]Redback(config-link-group)#encapsulation dot1q
[local]Redback(config-link-group)#dot1q pvc 1
[local]Redback(config-dot1q-pvc)#bind interface downstream peter
!
[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#maintenance-association R&D
[local]Redback(config-ether-cfm-ma)#ccm
[local]Redback(config-ether-cfm-ma-ccm)#exit
[local]Redback(config-ether-cfm-ma)#mep-local 101 lg dslam-face vlan-id 1
!
[local]Redback(config-ether-cfm-ma)#show configuration link
Building configuration...
Current configuration:
!
link-group dslam-face access
 encapsulation dot1q
 dot1q pvc 1
  bind interface downstream peter
!
!
end
!
[local]Redback(config-ether-cfm)#show configuration cfm instance-1
Building configuration...
Current configuration:
!
!Ethernet connectivity fault management configuration
!
ethernet-cfm instance-1
  level 0
  domain-name instance-1
  maintenance-association R&D
    ccm
    mep-local 101 lg dslam-face vlan-id 1
!
end

3.6 show ethernet-cfm ... Linktrace Output

Example 1 Undetailed Linktrace Output of show ethernet-cfm... Command

[local]Redbacj#show ethernet-cfm database down domain ericsson ma devtest mep 201 linktrace
    SeqNum  Ingress Mac         Egress Mac          Relay Action   TTL
    6       00:30:88:13:07:8f   00:00:00:00:00:00   RlyFDB         63
    6       00:30:88:01:a0:74   00:00:00:00:00:00   RlyFDB         62
    6       00:30:88:13:44:ad   00:00:00:00:00:00   RlyHit         61

Example 2 Detailed Linktrace Output of show ethernet-cfm... Command

[local]Redback#show ethernet-cfm database up domain dd ma platform mep 101 linktrace detail
-------------------------------------------------------------------
SequenceNumber: 32                          ReceiveOrder   : 1
-------------------------------------------------------------------
Ttl                    : 63                      Forwarded : No
TerminalMep            : No                   Relay Action : RlyMpDB
LastEgressId           : 00:00:00:30:88:13:07:8f
NextEgressId           : 00:00:00:00:00:00:00:00
ChassisId Subtype      : NetworkAddress
ChassisId              : 01 0a 0d 0b 1e
ManAddressDomain       : snmpOther
ManAddress             : 0 0 0 0 0
IngressMac             : 00:30:88:01:a0:74  Ingress Action : IngOk
IngressPortIdSubtype   : Local
IngressPortId          : 9/5:1023:63/1/2/18
EgressMac              : 00:00:00:00:00:00   Egress Action : IngNoTlv