Configuring Ethernet CFM

Contents

1Overview
1.1Ethernet Service Management
1.2SNMP Support for CFM

2

CFM Restrictions and Limitations
2.1CFM Supported Circuits
2.2SNMP CFM Limitations

3

Configuration and Operations Tasks
3.1Configuration of an CFM Instance, its MD, and Maintenance Points
3.2Configuration of the MA Parameters
3.3CFM Troubleshooting and Status Operations

4

Configuration Examples
4.1MEPs on Two SmartEdge Systems Connected by a Transport-Enabled VLAN-Based Circuit
4.2MEP on an Attachment Circuit to an L2VPN Pseudowire
4.3Link Failure Detection in Link Groups
4.4Loop Detection
4.5Monitoring Four Bridges and an L2VPN Circuit
4.6MEP on a Link Group
4.7show ethernet-cfm ... Linktrace Output

Glossary
Copyright

© Ericsson AB 2009–2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

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 LM Ericsson.
NetOp is a trademark of Telefonaktiebolaget LM Ericsson.

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) and the CFM MIB (IEEE8021-CFM-MIB - IEEE Std 802.1ag-2007), and a subset of ITU-T Recommendation Y.1731, OAM functions and mechanisms for Ethernet based networks.

This document applies to both the Ericsson SmartEdge® and SM family routers. However, the software that applies to the SM family of systems is a subset of the SmartEdge OS; some of the functionality described in this document may not apply to SM family routers.

For information specific to the SM family chassis, including line cards, refer to the SM family chassis documentation.

For specific information about the differences between the SmartEdge and SM family routers, refer to the Technical Product Description SM Family of Systems (part number 5/221 02-CRA 119 1170/1) in the Product Overview folder of this Customer Product Information library.

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 CFM implementation, definitions, SNMP support, supported circuits, a table of operations commands, and a description of the operating system CLI command modes.

Figure 1 illustrates concepts and terms described in this section. For a glossary of terms see the Glossary section of this document:

Figure 1   Maintenance Domains

1.1   Ethernet Service Management

The SmartEdge router CFM implementation provides service management of the Ethernet and Ethernet emulating interfaces of the SmartEdge router. This CFM implementation 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:


The following fault management and performance measurement capabilities are provided through Y.1731:

1.2   SNMP Support for CFM

Table 1 lists the CFM 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.

2   CFM Restrictions and Limitations

2.1   CFM Supported Circuits

This section describes the circuits that support CFM MPs.

2.1.1   MPs on Physical Ethernet Circuits

You can configure a maintenance point (MEP) or maintenance association intermediate point (MIP) 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.

You can configure both up and down MEPs on circuits where the interfaces are bound to Ethernet ports with the bind interface command. The circuits can have 802.1Q or Q-in-Q encapsulation, or no encapsulation (that is, the port itself).

2.1.2   MPs on Subscriber Circuits

You can configure down MEPs on circuits where the subscriber circuit is bound to Ethernet ports with the bind authentication command. These are single 802.1Q PVCs with PPPoE encapsulation. The CFM PDUs do not run over the dynamic subscriber session circuit, but instead run over the circuit or port in which the dynamic subscriber circuits are created.

The SmartEdge router does not support MPs where the maximum subscriber sessions is set to one (bind authention interfaces authenticated by PAP, CHAP, or PAP-CHAP).

You can configure down MEPs on circuits where the subscriber circuits are bound to interfaces with service CLIPS enabled with the service clips command. The CFM PDUs do not run over the circuits of the subscriber sessions, but instead run over the parent circuit or port.

Up MEPs on subscriber circuits are not supported.

2.1.3   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.

A MEP or MIP can be configured on a transport-enabled VLAN-based circuit. The MEP or MIP is matched to the circuit that best matches the VLANs configured under it. For details see the mep-local and mip commands.

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.

2.1.4   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:

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

2.1.5   MPs on L2VPN Cross-Connection Circuits

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

A cross-connection 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 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   L2VPN Cross-Connection

2.1.6   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.2   SNMP CFM Limitations

SNMP set support is not present; SNMP get and get-next are supported for CFM MIB.

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:

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

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.

3   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.

3.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:

Perform the tasks described in Table 3 to configure 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 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.

no linktrace

Enter in CFM configuration mode.

6.

Create an MA in the MD specified in step 2. The MEG-ID/ MAID can be entered in either 802.1ag or ICC format. (802.1ag is the default.)(1)


Repeat this step for every MA in the MD.


Continue with Table 4 for every MA created.

maintenance-association

Enter in CFM configuration mode.

(1)  Changing the MEG-ID type will cause CCM loss of continuity.


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

3.2   Configuration of the MA Parameters

Perform the following tasks described in Table 4 to configure the parameters of an 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.

6.

Set an 802.1p priority level for CCM, ETH-LB, and ETH-LT frames.

priority

Enter in MA configuration mode.


To propagate the priority across bridges for up MEPs, set the qos propagate profile as follows:
dot1q profile dp
propagate qos to ethernet
propagate qos from ethernet

3.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 and Troubleshooting Operations

Task

Root Command

Initiate the CFM link-trace test

ethernet-cfm linktrace(1)

Initiate the CFM loopback test

ethernet-cfm loopback(2)

Initiate CFM debugging

debug cfm

Clear CFM loopback and link-trace counters

clear ethernet-cfm counters

Initiate monitoring of Ethernet frame delay and frame delay variation between MEPs

ethernet-cfm measure-delay

(1)  Use no linktrace to disable linktrace responses.

(2)  Use no loopback to disable loopback responses.


3.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

3.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)

3.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 status of MDs

show ethernet-cfm database (domain)

Show the current CCM database

show ethernet-cfm database (instance-name)

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 MIPs

show ethernet-cfm database (mip)

Displays the CFM error conditions detected in the specified MA

show ethernet-cfm errors

Show the status of remote MEPs

show ethernet-cfm database (rmep)

4   Configuration Examples

This section provides examples of configuring MEP.

4.1   MEPs on Two SmartEdge Systems Connected by a Transport-Enabled VLAN-Based Circuit

Figure 3   Two Systems Connected by a Transport-Enabled VLAN-Based Circuit

The following example shows the configurations of the rock1200 and jazz systems that are connected by a transport-enabled PVC. Following the configuration command, the loopback, linktrace, and show ethernet-cfm errors commands are run to verify the operation of the links and the configuration of the CFM instances that monitor them.

Current configuration:                                                                //NOTE 1

Current configuration:
!
!  Configuration last changed by user 'test' at Fri Jul  2 11:14:09 2010
!
!
service multiple-contexts
!
!
!

! Bridge global configuration
bridge profile trunk
 trunk
!
!
!
context local
!
 no ip domain-lookup
!
 interface cfma1 bridge
  bridge name cfma1

!
 interface mgmt
  ip address 10.18.17.103/24
!
 interface test
  ip address 10.1.1.2/24
 logging console
!
!
 administrator test encrypted 1 $1$........$kvQfdsjs0ACFMeDHQ7n/o.
   privilege start 15
!

!
 ip route 155.53.0.0/16 10.18.17.254
 ip route 155.53.0.0/16 10.18.49.254
!
 bridge cfma1
!
!
! ** End Context **
 logging tdm console
 logging active
 logging standby short

!
!
!Ethernet connectivity fault management configuration
!
ethernet-cfm DOWN-INSTANCE
  level 1
  domain-name ericsson
  maintenance-association devtest
    ccm
    mep-remotelist 106
    mep-local 601 9/1 transport 2 direction down                                      //NOTE 2
!

ethernet-cfm UP-INSTANCE
  level 2
  domain-name redback
  maintenance-association platform
    ccm
    mep-remotelist 105
    mep-local 501 9/2 transport 2                                                     //NOTE 2
!
!
!

port ethernet 7/1
! XCRP management ports on slot 7 and 8 are configured through 7/1
 no shutdown
 bind interface mgmt local
!
card ge-20-port 9
!
port ethernet 9/1                                                                     //NOTE 3
 no shutdown
 encapsulation dot1q
 dot1q pvc transport 2
  bridge profile trunk
  bind interface cfma1 local

!
port ethernet 9/2
 no shutdown
 encapsulation dot1q
 dot1q pvc transport 2
  bridge profile trunk
  bind interface cfma1 local
!
port ethernet 9/3
 no shutdown
 encapsulation dot1q
 dot1q pvc transport 2

!
 system hostname rock1200
 timeout session idle 9999
!
no service console-break
!
service crash-dump-dram
!
no service auto-system-recovery
!
end

NOTE 1: The preceding configuration applies to the rock1200 system.

NOTE 2: The MEP or MIP is matched to the circuit that best matches the VLANs configured under it. For details see the mep-local and mip commands.

NOTE 3: You should specify all the ports in any given CFM instance identically; that is, they should all specify the same VLAN ID, the same transport range, simply specify transport any.

Current configuration:                                                                //NOTE 4
!
!  Configuration last changed by user 'test' at Fri Jul  2 11:34:17 2010
!
!
no service multiple-contexts
!
!
! Bridge global configuration
bridge profile trunk
 trunk
!

!
context local
!
 no ip domain-lookup
!
 interface cfma2 bridge
  bridge name cfma2
!
 interface mgmt
  ip address 10.18.17.102/24
!

interface test
  ip address 10.1.1.3/24
 logging console
!
 enable encrypted 1 $1$........$kvQfdsjs0ACFMeDHQ7n/o.
!
!
 administrator test encrypted 1 $1$........$kvQfdsjs0ACFMeDHQ7n/o.
!
!
 ip route 155.53.0.0/16 10.18.17.254
 ip route 155.53.0.0/16 10.18.49.254
!

 bridge cfma2
!
!
! ** End Context **
 logging tdm console
 logging active
 logging standby short
!
!
!

!Ethernet connectivity fault management configuration
!
ethernet-cfm DOWN-INSTANCE
  level 1
  domain-name ericsson
  maintenance-association devtest
    ccm
    mep-remotelist 601
    mep-local 106 6/1 transport 2 direction down
!

ethernet-cfm UP-INSTANCE
  level 2
  domain-name redback
  maintenance-association platform
    ccm
    mep-remotelist 501
    mep-local 105 6/2 transport 2
!
!
!
card ge-5-port 6
!

port ethernet 6/1
 no shutdown
 encapsulation dot1q
 dot1q pvc transport 2
  bridge profile trunk
  bind interface cfma2 local
!
port ethernet 6/2
 no shutdown
 encapsulation dot1q
 dot1q pvc transport 2
  bridge profile trunk
  bind interface cfma2 local

!
port ethernet 6/3
 no shutdown
 encapsulation dot1q
 dot1q pvc transport 2
!
!
port ethernet 7/1
! XCRP management ports on slot 7 and 8 are configured through 7/1
 no shutdown
 bind interface mgmt local
!

 system hostname jazz
 timeout session idle 999
!
no service console-break
!
service crash-dump-dram
!
no service auto-system-recovery
!
end

Note:  
The preceding configuration applies to the jazz system.

[local]jazz#show ethernet-cfm database DOWN-INSTANCE                                  //NOTE 5
DOMAIN NAME     : ericsson
-----------------

Level           : 1              Domain Id      : 1
Number of MAs   : 1              Number of MIPs : 0

MA Name : devtest (Index : 1)
---------
Ccms    : Enabled                Ccm Interval   : 1s
Number of local meps : 1         Number of remote meps : 1

Local MEP Information:
MepId  Level  MacAddr            State  Dir  Defects        Circuit
------------------------------------------------------------------------------
106    1      00:30:88:03:a7:f8  DefRpt Down Port/IF TLV down 6/1 vlan-id 2

Remote MEP Information:
MepId  MacAddr            State
--------------------------------
601    00:30:88:11:d1:8d  OK

                                                                                      //NOTE 6
[local]jazz#ethernet-cfm linktrace from 6/1 transport 2 vlan-id 2 to 00:30:88:11:d1:8d level 1 
circuit: 6/1 vlan-id 2, handle: 6/1:1023:63/1/2/16, vlan id: 2, inner vlan id: 0
ethernet-cfm linktrace from 6/1 vlan-id 2 to 601 level 1
CFM linktrace in progress...
cct: 5/0/2/0
Transaction id: 0
 1  00:30:88:11:d1:8d    5 ms
CFM linktrace completed.

 

[local]rock1200#ethernet-cfm linktrace from md 1 ma 1 mep 106 to rmep 601 level 1     //NOTE 7
domain: 1, ma: 1, local mep id: 106
ethernet-cfm linktrace from md 1 ma 1 mep 106 to 601 level 1
CFM linktrace in progress...
cct: 5/0/2/0
Transaction id: 0
 1  00:30:88:11:d1:8d    5 ms
CFM linktrace completed.

Note:  
The show ethernet-cfm database command displays the index numbers for the MD, MA, and the VLAN ID of the local MEP 106 are 1, 2, and 2 respectively. The show configuration command displays the transport identifier (2).

Note:  
Linktrace from 6/1 PVC 2 of the jazz system to 00:30:88:11:d1:8d (the MAC address of port 9/1).

Note:  
The same linktrace to the jazz system as the preceding example expressed in terms of the indexes of the MD and MA, and the local-MEP and remote MEP IDs.

[local]jazz#show ethernet-cfm errors DOWN-INSTANCE ericsson devtest
---------------------------------------------------------------
Instance Name    : DOWN-INSTANCE                                                      // NOTE 8
Domain Name      : ericsson       Domain Id      : 1
Level            : 1
MA Name          : devtest        MA Id          : 1
RMEP Id          : 601            Mac addr       : 00:30:88:11:d1:8d
Error            : MEP down (Port down)

Note:  
The show ethernet-cfm errors command shows any errors in the CFM DOWN-INSTANCE instance, ericsson MD, and devtest MA

4.2   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)#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

4.3   Link Failure Detection in Link Groups

Figure 4 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 4   Simplified Two-Node, Four-Circuit Network

For the A-B segment of the network, this example configures one maintenance association (ma-vlan1) in the same domain. Link failures are detected through CCM PDUs.

[local]Redback(config)#ethernet-cfm instance-1
[local]Redback(config-ether-cfm)#level 2
[local]Redback(config-ether-cfm)#domain-name abc
[local]Redback(config-ether-cfm)#maintenance-association ma-vlan1
!Creation of MA and configuration of MEP
[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 lg blue vlan-id 1 dir down
Note:  
MEP configuration is applied to the VLANs in the link group and not to ports in the link group. The following configuration of a MEP on port 5/1 is incorrect. Although port 5/1 is in the link-group blue, MEPs configured on individual ports in the link group do not detect link failures. The system does not provide an error message if you enter the following incorrect configuration:

[local]Redback(config-ether-cfm-ma)#mep-local 11 5/1 direction down

4.4   Loop Detection

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

Figure 5   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

4.5   Monitoring Four Bridges and an L2VPN Circuit

In the example illustrated by Figure 6, 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 6   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

4.6   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

4.7   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

Glossary

CFM instance
SmartEdge router object that contains a single MD.
 
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 the SmartEdge router.
 
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.
 
delay measurement message (DMM)
Delay measurement message.
 
delay measurement reply (DMR)
Delay measurement reply.
 
down MEP
A local MEP that 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.
 
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.
 
local MEP (LMEP)
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.
 
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.
 
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 entity (ME)
Maintenance Entity in Y.1731, same as an MD.
 
maintenance entity group (MEG)
ME group in Y.1731, same as an MA .
 
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. It is the end point of an ETH MEG in Y.1731 that is capable of initiating and terminating OAM frames for fault management and performance monitoring.
 
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.
 
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 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.
 
maintenance domain (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.
 
maintenance domain (MD) 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 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.
 
remote MEP (RMEP)
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.
 
short MA name
The part of the MAID which is unique within the MD and appended to the MD name to form the MAID.
 
Up MEPs
A local MEP that 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.