Copyright Page

Chapter 1. Using Ethernet Operations Administration and Maintenance

Finding Feature Information

Information About Using Ethernet Operations Administration and Maintenance

Ethernet OAM

OAM Client

OAM Sublayer

Benefits of Ethernet OAM

Cisco Implementation of Ethernet OAM

OAM Features

OAM Messages

IEEE 802.3ah Link Fault RFI Support

Ethernet Connectivity Fault Management

High Availability Features Supported by 802.3ah

Benefits of 802.3ah HA

NSF SSO Support in 802.3ah OAM

ISSU Support in 802.3ah OAM

How to Set Up and Configure Ethernet Operations Administration and Maintenance

Enabling Ethernet OAM on an Interface

Disabling and Enabling a Link Monitoring Session

Disabling a Link Monitoring Session

Enabling a Link Monitoring Session

Stopping and Starting Link Monitoring Operations

Stopping Link Monitoring Operations

Starting Link Monitoring Operations

Configuring Link Monitoring Options

Configuring Global Ethernet OAM Options Using a Template

Configuring a Port for Link Fault RFI Support

Configuration Examples for Ethernet Operations Administration and Maintenance

Additional References

Feature Information for Using Ethernet Operations Administration and Maintenance

Chapter 2. Configuring Ethernet Connectivity Fault Management in a Service Provider Network

Prerequisites for Configuring Ethernet CFM in a Service Provider Network

Restrictions for Configuring Ethernet CFM in a Service Provider Network

Information About Configuring Ethernet CFM in a Service Provider Network

Ethernet CFM

Benefits of Ethernet CFM

Customer Service Instance

Maintenance Domain

Maintenance Point

Maintenance Endpoints

Maintenance Intermediate Points

CFM Messages

Cross-Check Function

SNMP Traps

Ethernet CFM and Ethernet OAM Interaction

Ethernet Virtual Circuit

OAM Manager

CFM over Bridge Domains

HA Features Supported by CFM

CFM HA in a Metro Ethernet Network

NSF SSO Support in CFM 802.1ag 1.0d

ISSU Support in CFM 802.1ag 1.0d

How to Set Up Ethernet CFM in a Service Provider Network

Designing CFM Domains

Examples

What to Do Next

Configuring Ethernet CFM

Provisioning the Network

Provisioning the Network on the CE-A

Provisioning the Network on the U-PE A

Provisioning the Network on the PE-AGG A

Provisioning the Network on the N-PE A

Provisioning the Network on the CE-B

Provisioning the Network on the U-PE B

Provisioning the Network on the PE-AGG B

Provisioning the Network on the N-PE B

Provisioning Service

Provisioning Service on the CE-A

Provisioning Service on the U-PE A

Provisioning Service on the PE-AGG A

Provisioning Service on the N-PE A

Provisioning Service on the CE-B

Provisioning Service on the U-PE B

Provisioning Service on the PE-AGG B

Provisioning Service on the N-PE B

Configuring and Enabling the Cross-Check Function

Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-A

Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-B

Configuring and Enabling Cross-Checking for an Outward Facing MEP on the CE-A

Configuring and Enabling Cross-Checking for an Outward Facing MEP on the CE-B

Configuring CFM over Bridge Domains

Configuring UP MEP over Port Channel in L2VPN

Configuring UP MEP over Port Channel in VPLS

Configuring Down MEP over Port Channel

Configuring CFM Offload

Troubleshooting Tips

Configuring Ethernet OAM Interaction with CFM

Configuring the OAM Manager

Enabling Ethernet OAM

Configuration Examples for Configuring Ethernet CFM in a Service Provider Network

Example: Provisioning a Network

Example: Provisioning Service

Glossary

Chapter 3. CFM CCM Extensions to Support the NSN Microwave 1+1 Hot Standby Protocol

Finding Feature Information

Restrictions for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

Information About CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

NSN Microwave 1+1 HSBY and CFM Integration

CFM Continuity Check Messages

Monitoring Devices and Suspending CFM Traffic

NSN Microwave 1+1 HSBY Protocol Monitoring of Maintenance Associations

Microwave 1+1 HSBY Configuration

IDU Configuration Values

ODU Configuration Values

How to Configure CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

Configuring NSN Microwave 1+1 HSBY Protocol and CFM CCM Extensions

Configuration Examples for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

CFM Domain and MEP Configuration

Example 1+1 HSBY Protocol Configuration

Additional References for CFM CCM Extensions to Support the NSN Microwave 1+1 Hot Standby Protocol

Feature Information for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

Chapter 4. Configuring Ethernet CFM for the Cisco ASR 1000 Router

Finding Feature Information

Prerequisites for Configuring Ethernet CFM for the Cisco ASR 1000 Router

Restrictions for Configuring Ethernet CFM for the Cisco ASR 1000 Router

Information About Configuring Ethernet CFM for the Cisco ASR 1000 Router

Ethernet CFM

Benefits of Ethernet CFM

Maintenance Associations

Maintenance Domains

Maintenance Points

Maintenance Association Endpoints

Ethernet CFM Messages

Cross-Check Function

SNMP Traps

HA Feature Support in Ethernet CFM

NSF SSO Support in Ethernet CFM

ISSU Support in Ethernet CFM

How to Configure Ethernet CFM for the Cisco ASR 1000 Router

Designing CFM Domains

Examples

Configuring Ethernet CFM

Provisioning the Network (CE-A)

Provisioning the Network (CE-B)

Provisioning Service (CE-A)

Provisioning Service (CE-B)

Configuring and Enabling the Cross-Check Function (CE-A)

Configuring and Enabling the Cross-Check Function (CE-B)

Configuration Examples for Configuring Ethernet CFM for the Cisco ASR 1000 Router

Example: Provisioning a Network

Example: Provisioning Service

Additional References

Feature Information for Configuring Ethernet CFM for the Cisco ASR 1000 Router

Glossary

Chapter 5. Configuring Ethernet Virtual Connections on the Cisco ASR 1000 Series Router

Finding Feature Information

Restrictions for Configuring EVCs on the Cisco ASR 1000 Series Router

Information About Configuring EVCs on the Cisco ASR 1000 Series Router

EVCs

Service Instances and Associated EFPs

Encapsulation (Flexible Service Mapping)

Layer 3 and Layer 4 ACL Support

Advanced Frame Manipulation

EFPs and Layer 2 Protocols

Egress Frame Filtering

Bridge Domains

Ethernet MAC Address Learning

Flooding of Layer 2 Frames for Unknown MAC Multicast and Broadcast Addresses

Layer 2 Destination MAC Address-Based Forwarding

MAC Address Aging

MAC Address Move

MAC Address Table

Split Horizon Group

EFP Bridge Domain and BDI Support Based on the Cisco ASR 1000 Series Router Forwarding Processors

How to Configure EVCs on the Cisco ASR 1000 Series Router

Configuring an EFP and a Bridge Domain on the Cisco ASR 1000 Series Router

Configuring an ACL on an EFP

Configuration Examples for EVCs on the Cisco ASR 1000 Series Router

Example Configuring EFPs on a Gigabit Ethernet Interface

Additional References

Feature Information for Configuring EVCs on the Cisco ASR 1000 Series Router

Chapter 6. Using the IEEE 802.3ad Link Aggregation MIB

Finding Feature Information

Prerequisites for Using the IEEE 802.3ad Link Aggregation MIB

Information About Using the IEEE 802.3ad Link Aggregation MIB

IEEE 802.3ad LAG MIB

Configuration and Management of LACP bundles

LAG MIB Table Object Definitions

dot3adTablesLastChanged Object

dot3adAggTable

dot3adAggPortListTable

dot3adAggPortTable

dot3adAggPortStatsTable

Additional References

Feature Information for Using the IEEE 802.3ad Link Aggregation MIB

Chapter 7. Configuring IEEE 802.3ad Link Bundling

Finding Feature Information

Prerequisites for Configuring IEEE 802.3ad Link Bundling

Restrictions for Configuring IEEE 802.3ad Link Bundling

Information About Configuring IEEE 802.3ad Link Bundling

Gigabit EtherChannel

Port-Channel and LACP-Enabled Interfaces

IEEE 802.3ad Link Bundling

Benefits of IEEE 802.3ad Link Bundling

LACP Enhancements

LACP for Gigabit Interfaces

Features Supported on Gigabit EtherChannel Bundles

Guidelines for LACP for Gigabit Interfaces Configuration

How to Configure IEEE 802.3ad Link Bundling

Enabling LACP

Configuring a Port Channel

Configuring LACP (802.3ad) for Gigabit Interfaces

Setting LACP System Priority and Port Priority

Adding and Removing Interfaces from a Link Bundle

Removing a Channel Group from a Port

Setting a Minimum Threshold of Active Links

Monitoring LACP Status

Troubleshooting Tips

Displaying Gigabit EtherChannel Information

Configuration Examples for IEEE 802.3ad Link Bundling

Example: Configuring LACP for Gigabit Interfaces

Example Associating a Channel Group with a Port Channel

Example Adding and Removing Interfaces from a Bundle

Example Monitoring LACP Status

Example: Displaying Port-Channel Interface Information

Additional References Configuring IEEE 802.3ad Link Bundling

Feature Information for Configuring IEEE 802.3ad Link Bundling

Chapter 8. ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Finding Feature Information

Prerequisites for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Information About ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Frame Delay and Frame-Delay Variation

Benefits of ITU-T Y.1731 Performance Monitoring

How to Configure ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Configuring Performance Monitoring Parameters

Configuration Examples for Configuring ITU-T Y.1731 Performance Monitoring Functions

Example: Configuring Performance Monitoring

Additional References

Feature Information for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Chapter 9. ICCP Multichassis VLAN Redundancy

Finding Feature Information

Prerequisites for ICCP Multichassis VLAN Redundancy

Restrictions for ICCP Multichassis VLAN Redundancy

Information About ICCP Multichassis VLAN Redundancy

Pseudo mLACP Multihoming Redundancy

Pseudo mLACP Active/Active Support

Failure Recovery

Pseudo mLACP Failover Operations

How to Configure ICCP Multichassis VLAN Redundancy

Configuring a Port Channel for Pseudo mLACP

Configuration Examples for ICCP Multichassis VLAN Redundancy

Example: Port Channel Configuration for Pseudo mLACP

Additional References

Feature Information for ICCP Multichassis VLAN Redundancy

Glossary

Chapter 10. Trunk EFP Support

Finding Feature Information

Restrictions for Trunk EFP Support

Information About Trunk EFP Support

Benefits of Trunk EFP Support

Ethernet Flow Points

Trunk Ports

How to Enable Trunk EFP Support

Enabling Trunk EFP Support

Verifying the Trunk EFP Support Configuration

Configuration Examples for Trunk EFP Support

Example: Configuring Trunk EFP Support

Example: Verifying the Trunk EFP Support Configuration

Additional References

Feature Information for Trunk EFP Support

Chapter 11. ITU-T G.8032 Ethernet Ring Protection Switching

Finding Feature Information

Prerequisites for Configuring ITU-T G.8032 Ethernet Ring Protection Switching

About ITU-T G.8032 Ethernet Ring Protection Switching

Ring Protection Links

ITU-T G.8032 Ethernet Ring Protection Switching Functionality

R-APS Control Messages

CFM Protocols and Link Failures

G.8032 Ring-Supported Commands and Functionality

G.8032 ERP Timers

Protection Switching Functionality in a Single Link Failure and Recovery

Ethernet Flow Points

Service Instances and Associated EFPs

How to Configure ITU-T G.8032 Ethernet Ring Protection Switching

Configuring the Ethernet Ring Profile

Configuring Ethernet CFM MEPs

Enabling Ethernet Fault Detection for a Service

Configuring the Ethernet Protection Ring

Configuring Topology Change Notification Propagation

Configuring a Service Instance

Verifying the Ethernet Ring Protection (ERP) Switching Configuration

Configuration Examples for ITU-T G.8032 Ethernet Ring Protection Switching

Example: Configuring Ethernet Ring Protection Switching

Example: Enabling Ethernet Fault Detection for a Service

Example: Verifying the Ethernet Ring Protection Configuration

Additional References for ITU-T G.8032 Ethernet Ring Protection Switching

Feature Information For ITU-T G.8032 Ethernet Ring Protection Switching

Chapter 12. Layer 2 Access Control Lists on EVCs

Finding Feature Information

Prerequisites for Layer 2 Access Control Lists on EVCs

Restrictions for Layer 2 Access Control Lists on EVCs

Information About Layer 2 Access Control Lists on EVCs

EVCs

Relationship Between ACLs and Ethernet Infrastructure

How to Configure Layer 2 Access Control Lists on EVCs

Creating a Layer 2 ACL

Applying a Layer 2 ACL to a Service Instance

Configuring a Layer 2 ACL with ACEs on a Service Instance

Verifying the Presence of a Layer 2 ACL on a Service Instance

Configuration Examples for Layer 2 Access Control Lists on EVCs

Example Applying a Layer 2 ACL to a Service Instance

Example Applying a Layer 2 ACL to Three Service Instances on the Same Interface

Example Creating a Layer 2 ACL with ACEs

Example Displaying the Details of a Layer 2 ACL on a Service Instance

Additional References

Feature Information for Layer 2 Access Control Lists on EVCs

Chapter 13. Configuring MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Finding Feature Information

Prerequisites for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Restrictions for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Information About MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Ethernet Virtual Circuits, Service Instances, and Bridge Domains

EVCs on Port Channels

MAC Security and MAC Addressing

MAC Address Permit List

MAC Address Deny List

MAC Address Limiting and Learning

Static and Dynamic MAC Addresses

Dynamic MAC Address Learning

MAC Address Limiting on Service Instances

MAC Address Limiting for Bridge Domains

Relationship Between the MAC Address Limit on a Bridge Domain and on a Service Instance

MAC Move and MAC Locking

Violation Response Configuration

MAC Address Aging Configuration

Sticky MAC Address Configurations

Aging for Sticky Addresses

Transitions

MAC Security Enabled on a Service Instance

MAC Security Disabled on a Service Instance

Service Instance Moved to a New Bridge Domain

Service Instance Removed from a Bridge Domain

Service Instance Shut Down Due to Violation

Interface Service Instance Down Linecard OIR Removed

Interface Service Instance Re-activated Linecard OIR Inserted

MAC Address Limit Decreased

Sticky Addresses Added or Removed on a Service Instance

How to Configure MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Enabling MAC Security on a Service Instance

Enabling MAC Security on an EVC Port Channel

Configuring a MAC Address Permit List

Configuring a MAC Address Deny List

Configuring MAC Address Limiting on a Bridge Domain

Configuring MAC Address Limiting on a Service Instance

Configuring a MAC Address Violation

Configuring MAC Address Aging

Configuring a Sticky MAC Address

Displaying the MAC Security Status of a Specific Service Instance

Displaying the Service Instances with MAC Security Enabled

Displaying the Service Instances with MAC Security Enabled on a Specific Bridge Domain

Showing the MAC Addresses of All Secured Service Instances

Showing the MAC Addresses of a Specific Service Instance

Showing the MAC Addresses of All Service Instances on a Specific Bridge Domain

Showing the MAC Security Statistics of a Specific Service Instance

Showing the MAC Security Statistics of All Service Instances on a Specific Bridge Domain

Showing the Last Violation Recorded on Each Service Instance on a Specific Bridge Domain

Clearing All Dynamically Learned MAC Addresses on a Service Instance

Clearing All Dynamically Learned MAC Addresses on a Bridge Domain

Bringing a Specific Service Instance Out of the Error-Disabled State

Configuration Examples for MAC Address Limiting on Service Instances and Bridge Domains and EVC Port Channels

Example Enabling MAC Security on a Service Instance

Example Enabling MAC Security on an EVC Port Channel

Example Configuring a MAC Address Permit List

Example Configuring a MAC Address Deny List

Example Configuring MAC Address Limiting on a Bridge Domain

Example Configuring a MAC Address Limit on a Service Instance

Example Configuring a MAC Address Violation Response

Example Configuring MAC Address Aging

Example Configuring a Sticky MAC Address

Example Displaying the MAC Addresses on a Specific Secure Service Instance

Example Displaying the Last Violation on a Specific Service Instance

Example Displaying the MAC Security Status of a Specific Service Instance

Example Displaying the MAC Addresses of All Secured Service Instances

Example Displaying the MAC Security Statistics of All Service Instances

Example: Displaying the MAC Addresses on All Service Instances for a Bridge Domain

Example Displaying the Secured Service Instances for a Specific Bridge Domain

Additional References

Feature Information for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Chapter 14. Configuring Ethernet Local Management Interface at a Provider Edge

Finding Feature Information

Prerequisites for Configuring Ethernet Local Management Interface at a Provider Edge

Restrictions for Configuring Ethernet Local Management Interface at a Provider Edge

Information About Configuring Ethernet Local Management Interface at a Provider Edge

Ethernet Virtual Circuits Overview

Ethernet LMI Overview

Ethernet CFM Overview

OAM Manager Overview

Benefits of Ethernet LMI at a Provider Edge

HA Features Supported by Ethernet LMI

Benefits of Ethernet LMI HA

NSF SSO Support in Ethernet LMI

ISSU Support in Ethernet LMI

How to Configure Ethernet Local Management Interface at a Provider Edge

Configuring Ethernet LMI Interaction with CFM

Configuring the OAM Manager

Enabling Ethernet LMI

Displaying Ethernet LMI and OAM Manager Information

Configuration Examples for Ethernet Local Management Interface at a Provider Edge

Example: Ethernet OAM Manager on a PE Device Configuration

Example: Ethernet LMI on a CE Device Configuration

Additional References for Configuring Ethernet Local Management Interface at a Provider Edge

Feature Information for Configuring Ethernet Local Management Interface at a Provider Edge

Chapter 15. Using Link Layer Discovery Protocol in Multivendor Networks

Finding Feature Information

Prerequisites for Using Link Layer Discovery Protocol in Multivendor Networks

Restrictions for Using Link Layer Discovery Protocol in Multivendor Networks

Information About Using Link Layer Discovery Protocol in Multivendor Networks

IEEE 802.1ab LLDP

LLDP-MED

Classes of Endpoints

Types of Discovery Supported

Benefits of LLDP-MED

TLV Elements

Benefits of LLDP

How to Configure Link Layer Discovery Protocol in Multivendor Networks

Enabling and Disabling LLDP Globally

Enabling LLDP Globally

Disabling and Enabling LLDP on a Supported Interface

Disabling LLDP on a Supported Interface

Setting LLDP Packet Hold Time

Setting LLDP Packet Frequency

Monitoring and Maintaining LLDP in Multivendor Networks

Enabling and Disabling LLDP TLVs

Enabling LLDP TLVs

Enabling and Disabling LLDP-MED TLVs

Enabling LLDP-MED TLVs

Configuration Examples for Link Layer Discovery Protocol in Multivendor Networks

Example: Configuring Voice VLAN

Example Configuring LLDP on Two Devices

Additional References for Using Link Layer Discovery Protocol in Multivendor Networks

Feature Information for Link Layer Discovery Protocol in Multivendor Networks

Chapter 16. Configuring ITU-T Y.1731 Fault Management Functions in IEEE CFM

Finding Feature Information

Prerequisites for Configuring ITU-T Y.1731 Fault Management Functions

Restrictions for Configuring ITU-T Y.1731 Fault Management Functions

Information About Configuring ITU-T Y.1731 Fault Management Functions

Continuity Check Messages

Server MEPs

Defect Conditions Detected by a MEP

ETH-AIS Function

ETH-AIS Transmission Reception and Processing

AIS and 802.3ah Interworking

ETH-RDI Function

How to Configure ITU-T Y.1731 Fault Management Functions

Disabling the ETH-AIS Function

Enabling ETH-AIS for a Single Interface SMEP and Disabling ETH-AIS for All Other Ports

Configuration Examples for Configuring ITU-T Y.1731 Fault Management Functions

Example: Enabling IEEE CFM on an Interface

Example: Enabling AIS

Example: Show Commands Output

Additional References

Feature Information for Configuring ITU-T Y.1731 Fault Management Functions

Chapter 17. G.8032 and CFM Support for Microwave Adaptive Bandwidth

Finding Feature Information

Prerequisites for G.8032 and CFM Microwave Adaptive Bandwidth Support

Microwave Adaptive Bandwidth Feature Functionality

Fixed Versus Adaptive Bandwidth Modulation and the Microwave Adaptive Bandwidth Feature

Creating the Ethernet Microwave Event and Using G.8032 to Specify Appropriate Actions

Modifying Ethernet Microwave Event Settings

Example: Configuring the Ethernet Microwave Event

Example: Verifying the Ethernet Microwave Event Configuration

Additional References for G.8032 and CFM Support for Microwave Adaptive Bandwidth

Feature Information for G.8032 and CFM Support for Microwave Adaptive Bandwidth

Chapter 18. Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Finding Feature Information

Prerequisites for ITU-T Y.1731 Operations

Restrictions for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731)

Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

How to Configure IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Configuring a Dual-Ended Ethernet Delay or Delay Variation Operation

Configuring a Receiver MEP on the Destination Device

Configuring the Sender MEP on the Source Router

Configuring a Sender MEP for a Single-Ended Ethernet Delay or Delay Variation Operation

Configuring a Sender MEP for a Single-Ended Ethernet Frame Loss Ratio Operation

Scheduling IP SLAs Operations

Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Example: Dual-Ended Ethernet Delay Operation

Example: Frame Delay and Frame Delay Variation Measurement Configuration

Example: Sender MEP for a Single-Ended Ethernet Delay Operation

Example: Sender MEP for a Single-Ended Ethernet Frame Loss Operation

Additional References for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Feature Information for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Chapter 19. IPSLA Y1731 On-Demand and Concurrent Operations

Finding Feature Information

Prerequisites for ITU-T Y.1731 Operations

Restrictions for IP SLAs Y.1731 On-Demand Operations

IPSLA Y1731 SLM Feature Enhancements

Configuring a Direct On-Demand Operation on a Sender MEP

Configuring a Referenced On-Demand Operation on a Sender MEP

Configuring an IP SLAs Y.1731 Concurrent Operation on a Sender MEP

Example: On-Demand Operation in Direct Mode

Example: On-Demand Operation in Referenced Mode

Additional References for IP SLAs Y.1731 On-Demand and Concurrent Operations

Feature Information for IP SLAs Y.1731 On-Demand and Concurrent Operations

Chapter 20. VXLAN-MCLAG Active-Active High Availability Support

Finding Feature Information

Restrictions for VXLAN-MCLAG Active-Active High Availability Support

Information About VXLAN-MCLAG Active-Active High Availability Support

Virtual Extensible LAN

Multichassis Link Aggregation Group

How to Configure VXLAN-MCLAG Active-Active High Availability Support

Configuring Interchassis Redundancy Groups on PoA

Configuring Port Channel on PoA

Configuring Vxlan Unicast Core Configuration on POA

Configuring Vxlan Multicast Core Configuration on POA

Configuring Dual-homed Device

Verifying VXLAN-MCLAG Active-Active High Availability Support

Configuration Examples for VXLAN-MCLAG Active-Active High Availability Support

Example: Configuring VXLAN HA on Multicast Mode

Example: Configuring VXLAN HA on Unicast Mode

Additional References for VXLAN-MCLAG Active-Active High Availability Support

Feature Information for VXLAN-MCLAG Active-Active High Availability Support

Chapter 21. Cisco ASR 1000 VxLAN Support

Introduction

Prerequisites for Cisco ASR 1000 Series Routers VxLAN Support

Limitations of Cisco ASR 1000 Series Routers VxLAN Support

New Scale Number after Enhancements

Configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 Gateway with Multicast

Configuring the VxLAN UDP Destination Port (Optional)

Creating the Network Virtualization Endpoint (NVE) Interface

Creating the Access Ethernet Flow Point (EFP)

Mapping the VLAN to the Bridge Domain

Configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 Gateway with Unicast

Feature Information for Cisco ASR 1000 Series Routers VxLAN Support

Technical Assistance

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Chapter 1. Using Ethernet Operations Administration and Maintenance

Ethernet Operations, Administration, and Maintenance (OAM) is a protocol for installing, monitoring, and troubleshooting Ethernet metropolitan-area networks (MANs) and Ethernet WANs. It relies on a new, optional sublayer in the data link layer of the Open Systems Interconnection (OSI) model. The OAM features covered by this protocol are Discovery, Link Monitoring, Remote Fault Detection, Remote Loopback, and Cisco Proprietary Extensions.

The advent of Ethernet as a MAN and WAN technology has emphasized the necessity for integrated management for larger deployments. For Ethernet to extend into public MANs and WANs, it must be equipped with a new set of requirements on Ethernet’s traditional operations, which had been centered on enterprise networks only. The expansion of Ethernet technology into the domain of service providers, where networks are substantially larger and more complex than enterprise networks and the user-base is wider, makes operational management of link uptime crucial.

- Finding Feature Information

- Information About Using Ethernet Operations Administration and Maintenance

- How to Set Up and Configure Ethernet Operations Administration and Maintenance

- Configuration Examples for Ethernet Operations Administration and Maintenance

- Additional References

- Feature Information for Using Ethernet Operations Administration and Maintenance

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Information About Using Ethernet Operations Administration and Maintenance

- Ethernet OAM

- Cisco Implementation of Ethernet OAM

- OAM Features

- OAM Messages

- IEEE 802.3ah Link Fault RFI Support

- Ethernet Connectivity Fault Management

- High Availability Features Supported by 802.3ah

Ethernet OAM

Ethernet OAM is a protocol for installing, monitoring, and troubleshooting metro Ethernet networks and Ethernet WANs. It relies on a new, optional sublayer in the data link layer of the OSI model. Ethernet OAM can be implemented on any full-duplex point-to-point or emulated point-to-point Ethernet link. A system-wide implementation is not required; OAM can be deployed for part of a system; that is, on particular interfaces.

Normal link operation does not require Ethernet OAM. OAM frames, called OAM protocol data units (PDUs), use the slow protocol destination MAC address 0180.c200.0002. They are intercepted by the MAC sublayer and cannot propagate beyond a single hop within an Ethernet network.

Ethernet OAM is a relatively slow protocol with modest bandwidth requirements. The frame transmission rate is limited to a maximum of 10 frames per second; therefore, the impact of OAM on normal operations is negligible. However, when link monitoring is enabled, the CPU must poll error counters frequently. In this case, the required CPU cycles will be proportional to the number of interfaces that have to be polled.

Two major components, the OAM client and the OAM sublayer, make up Ethernet OAM. The following two sections describe these components.

- OAM Client

- OAM Sublayer

- Benefits of Ethernet OAM

OAM Client

The OAM client is responsible for establishing and managing Ethernet OAM on a link. The OAM client also enables and configures the OAM sublayer. During the OAM discovery phase, the OAM client monitors OAM PDUs received from the remote peer and enables OAM functionality on the link based on local and remote state as well as configuration settings. Beyond the discovery phase (at steady state), the OAM client is responsible for managing the rules of response to OAM PDUs and managing the OAM remote loopback mode.

OAM Sublayer

The OAM sublayer presents two standard IEEE 802.3 MAC service interfaces: one facing toward the superior sublayers, which include the MAC client (or link aggregation), and the other interface facing toward the subordinate MAC control sublayer. The OAM sublayer provides a dedicated interface for passing OAM control information and OAM PDUs to and from a client.

The OAM sublayer is made up of three components: control block, multiplexer, and packet parser (p-parser). Each component is described in the following sections.

Control Block

The control block provides the interface between the OAM client and other blocks internal to the OAM sublayer. The control block incorporates the discovery process, which detects the existence and capabilities of remote OAM peers. It also includes the transmit process that governs the transmission of OAM PDUs to the multiplexer and a set of rules that govern the receipt of OAM PDUs from the p-parser.

Multiplexer

The multiplexer manages frames generated (or relayed) from the MAC client, control block, and p-parser. The multiplexer passes through frames generated by the MAC client untouched. It passes OAM PDUs generated by the control block to the subordinate sublayer; for example, the MAC sublayer. Similarly, the multiplexer passes loopback frames from the p-parser to the same subordinate sublayer when the interface is in OAM remote loopback mode.

P-Parser

The p-parser classifies frames as OAM PDUs, MAC client frames, or loopback frames and then dispatches each class to the appropriate entity. OAM PDUs are sent to the control block. MAC client frames are passed to the superior sublayer. Loopback frames are dispatched to the multiplexer.

Benefits of Ethernet OAM

Ethernet OAM provides the following benefits:

- Competitive advantage for service providers

- Standardized mechanism to monitor the health of a link and perform diagnostics

Cisco Implementation of Ethernet OAM

The Cisco implementation of Ethernet OAM consists of the Ethernet OAM shim and the Ethernet OAM module.

The Ethernet OAM shim is a thin layer that connects the Ethernet OAM module and the platform code. It is implemented in the platform code (driver). The shim also communicates port state and error conditions to the Ethernet OAM module via control signals.

The Ethernet OAM module, implemented within the control plane, handles the OAM client as well as control block functionality of the OAM sublayer. This module interacts with the CLI and Simple Network Management Protocol (SNMP)/programmatic interface via control signals. In addition, this module interacts with the Ethernet OAM shim through OAM PDU flows.

OAM Features

The OAM features as defined by IEEE 802.3ah, Ethernet in the First Mile , are discovery, Link Monitoring, Remote Fault Detection, Remote Loopback, and Cisco Proprietary Extensions.

Discovery

Discovery is the first phase of Ethernet OAM and it identifies the devices in the network and their OAM capabilities. Discovery uses information OAM PDUs. During the discovery phase, the following information is advertised within periodic information OAM PDUs:

- OAM mode--Conveyed to the remote OAM entity. The mode can be either active or passive and can be used to determine device functionality.

- OAM configuration (capabilities)--Advertises the capabilities of the local OAM entity. With this information a peer can determine what functions are supported and accessible; for example, loopback capability.

- OAM PDU configuration--Includes the maximum OAM PDU size for receipt and delivery. This information along with the rate limiting of 10 frames per second can be used to limit the bandwidth allocated to OAM traffic.

- Platform identity--A combination of an organization unique identifier (OUI) and 32-bits of vendor-specific information. OUI allocation, controlled by the IEEE, is typically the first three bytes of a MAC address.

Discovery includes an optional phase in which the local station can accept or reject the configuration of the peer OAM entity. For example, a node may require that its partner support loopback capability to be accepted into the management network. These policy decisions may be implemented as vendor-specific extensions.

Link Monitoring

Link monitoring in Ethernet OAM detects and indicates link faults under a variety of conditions. Link monitoring uses the event notification OAM PDU and sends events to the remote OAM entity when there are problems detected on the link. The error events include the following:

- Error Symbol Period (error symbols per second)--The number of symbol errors that occurred during a specified period exceeded a threshold. These errors are coding symbol errors.

- Error Frame (error frames per second)--The number of frame errors detected during a specified period exceeded a threshold.

- Error Frame Period (error frames per n frames)--The number of frame errors within the last n frames has exceeded a threshold.

- Error Frame Seconds Summary (error seconds per m seconds)--The number of error seconds (1-second intervals with at least one frame error) within the last m seconds has exceeded a threshold.

Since IEEE 802.3ah OAM does not provide a guaranteed delivery of any OAM PDU, the event notification OAM PDU may be sent multiple times to reduce the probability of a lost notification. A sequence number is used to recognize duplicate events.

Remote Failure Indication

Faults in Ethernet connectivity that are caused by slowly deteriorating quality are difficult to detect. Ethernet OAM provides a mechanism for an OAM entity to convey these failure conditions to its peer via specific flags in the OAM PDU. The following failure conditions can be communicated:

- Link Fault--Loss of signal is detected by the receiver; for instance, the peer’s laser is malfunctioning. A link fault is sent once per second in the information OAM PDU. Link fault applies only when the physical sublayer is capable of independently transmitting and receiving signals.

- Dying Gasp--An unrecoverable condition has occurred; for example, when an interface is shut down. This type of condition is vendor specific. A notification about the condition may be sent immediately and continuously.

- Critical Event--An unspecified critical event has occurred. This type of event is vendor specific. A critical event may be sent immediately and continuously.

Remote Loopback

An OAM entity can put its remote peer into loopback mode using the loopback control OAM PDU. Loopback mode helps an administrator ensure the quality of links during installation or when troubleshooting. In loopback mode, every frame received is transmitted back on the same port except for OAM PDUs and pause frames. The periodic exchange of OAM PDUs must continue during the loopback state to maintain the OAM session.

The loopback command is acknowledged by responding with an information OAM PDU with the loopback state indicated in the state field. This acknowledgement allows an administrator, for example, to estimate if a network segment can satisfy a service-level agreement. Acknowledgement makes it possible to test delay, jitter, and throughput.

When an interface is set to the remote loopback mode the interface no longer participates in any other Layer 2 or Layer 3 protocols; for example Spanning Tree Protocol (STP) or Open Shortest Path First (OSPF). The reason is that when two connected ports are in a loopback session, no frames other than the OAM PDUs are sent to the CPU for software processing. The non-OAM PDU frames are either looped back at the MAC level or discarded at the MAC level.

From a user’s perspective, an interface in loopback mode is in a link-up state.

Cisco Vendor-Specific Extensions

Ethernet OAM allows vendors to extend the protocol by allowing them to create their own type-length-value (TLV) fields.

OAM Messages

Ethernet OAM messages or OAM PDUs are standard length, untagged Ethernet frames within the normal frame length bounds of 64 to 1518 bytes. The maximum OAM PDU frame size exchanged between two peers is negotiated during the discovery phase.

OAM PDUs always have the destination address of slow protocols (0180.c200.0002) and an Ethertype of 8809. OAM PDUs do not go beyond a single hop and have a hard-set maximum transmission rate of 10 OAM PDUs per second. Some OAM PDU types may be transmitted multiple times to increase the likelihood that they will be successfully received on a deteriorating link.

Four types of OAM messages are supported:

- Information OAM PDU--A variable-length OAM PDU that is used for discovery. This OAM PDU includes local, remote, and organization-specific information.

- Event notification OAM PDU--A variable-length OAM PDU that is used for link monitoring. This type of OAM PDU may be transmitted multiple times to increase the chance of a successful receipt; for example, in the case of high-bit errors. Event notification OAM PDUs also may include a time stamp when generated.

- Loopback control OAM PDU--An OAM PDU fixed at 64 bytes in length that is used to enable or disable the remote loopback command.

- Vendor-specific OAM PDU--A variable-length OAM PDU that allows the addition of vendor-specific extensions to OAM.

IEEE 802.3ah Link Fault RFI Support

The IEEE 802.3ah Link Fault RFI Support feature provides a per-port configurable option that moves a port into a blocking state when an OAM PDU control request packet is received with the Link Fault Status flag set. In the blocking state, the port can continue to receive OAM PDUs, detect remote link status, and automatically recover when the remote link becomes operational. When an OAM PDU is received with the Link Fault Status flag set to zero or FALSE, the port is enabled and all VLANs configured on the port are set to “forwarding.”

Note

If you configure the Ethernet OAM timeout period to be the minimum allowable value of 2 seconds, the Ethernet OAM session may be dropped briefly when the port transitions from blocked to unblocked. This action will not occur by default; the default timeout value is 5 seconds.

Before the release of the IEEE 802.3ah Link Fault RFI Support feature, when an OAM PDU control request packet was received with the Link Fault Status flag set, one of three actions was taken:

- A warning message was displayed or logged, and the port remained operational.

- The Link Fault Status flag was ignored.

Ethernet Connectivity Fault Management

Ethernet connectivity fault management (CFM) is an end-to-end per-service-instance Ethernet layer OAM protocol that includes proactive connectivity monitoring, fault verification, and fault isolation. End to end can be provider edge (PE) to PE or customer edge (CE) to CE. Per service instance means per VLAN.

For more information about Ethernet CFM, see Ethernet Connectivity Fault Management .

High Availability Features Supported by 802.3ah

In access and service provider networks using Ethernet technology, High Availability (HA) is a requirement, especially on Ethernet OAM components that manage Ethernet virtual circuit (EVC) connectivity. End-to-end connectivity status information is critical and must be maintained on a hot standby Route Switch Processor (RSP) (a standby RSP that has the same software image as the active RSP and supports synchronization of line card, protocol, and application state information between RSPs for supported features and protocols). End-to-end connectivity status is maintained on the CE, PE, and access aggregation PE (uPE) network nodes based on information received by protocols such as CFM and 802.3ah. This status information is used to either stop traffic or switch to backup paths when an EVC is down. Metro Ethernet clients (for example, CFM and 802.3ah) maintain configuration data and dynamic data, which is learned through protocols. Every transaction involves either accessing or updating data among the various databases. If the databases are synchronized across active and standby modules, the RSPs are transparent to clients.

Cisco infrastructure provides various component application program interfaces (APIs) for clients that are helpful in maintaining a hot standby RSP. Metro Ethernet HA clients (such as, HA/ISSU, CFM HA/ISSU, 802.3ah HA/ISSU) interact with these components, update the databases, and trigger necessary events to other components.

- Benefits of 802.3ah HA

- NSF SSO Support in 802.3ah OAM

- ISSU Support in 802.3ah OAM

Benefits of 802.3ah HA

- Elimination of network downtime for Cisco software image upgrades, resulting in higher availability

- Elimination of resource scheduling challenges associated with planned outages and late night maintenance windows

- Accelerated deployment of new services and applications and faster implementation of new features, hardware, and fixes due to the elimination of network downtime during upgrades

- Reduced operating costs due to outages while delivering higher service levels due to the elimination of network downtime during upgrades

NSF SSO Support in 802.3ah OAM

The redundancy configurations Stateful Switchover (SSO) and Nonstop Forwarding (NSF) are both supported in Ethernet OAM and are automatically enabled. A switchover from an active to a standby Route Switch Processor (RSP) occurs when the active RSP fails, is removed from the networking device, or is manually taken down for maintenance. NSF interoperates with the SSO feature to minimize network downtime following a switchover. The primary function of Cisco NSF is to continue forwarding IP packets following an RSP switchover.

For detailed information about the SSO feature, see the “Configuring Stateful Switchover” module of the High Availability Configuration Guide. For detailed information about the NSF feature, see the “Configuring Cisco Nonstop Forwarding” module of the High Availability Configuration Guide.

ISSU Support in 802.3ah OAM

Cisco In-Service Software Upgrades (ISSUs) allow you to perform a Cisco software upgrade or downgrade without disrupting packet flow. ISSU is automatically enabled in 802.3ah. OAM performs a bulk update and a runtime update of the continuity check database to the standby Route Switch Processor (RSP), including adding, deleting, or updating a row. This checkpoint data requires ISSU capability to transform messages from one release to another. All the components that perform active RSP to standby RSP updates using messages require ISSU support.

ISSU lowers the impact that planned maintenance activities have on network availability by allowing software changes while the system is in service. For detailed information about ISSU, see the “Performing an In Service Software Upgrade” module of the High Availability Configuration Guide.

How to Set Up and Configure Ethernet Operations Administration and Maintenance

- Enabling Ethernet OAM on an Interface

- Disabling and Enabling a Link Monitoring Session

- Stopping and Starting Link Monitoring Operations

- Configuring Link Monitoring Options

- Configuring Global Ethernet OAM Options Using a Template

- Configuring a Port for Link Fault RFI Support

Enabling Ethernet OAM on an Interface

Ethernet OAM is by default disabled on an interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 4

ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

Example:

Device(config-if)# ethernet oam

Enables Ethernet OAM.

Step 5

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Disabling and Enabling a Link Monitoring Session

Link monitoring is enabled by default when you enable Ethernet OAM. Perform these tasks to disable and enable link monitoring sessions:

- Disabling a Link Monitoring Session

- Enabling a Link Monitoring Session

Disabling a Link Monitoring Session

Perform this task to disable a link monitoring session.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

5.    no ethernet oam link-monitor supported

6.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 4

ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

Example:

Device(config-if)# ethernet oam

Enables Ethernet OAM.

Step 5

no ethernet oam link-monitor supported

Example:

Device(config-if)# no ethernet oam link-monitor supported

Disables link monitoring on the interface.

Step 6

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Enabling a Link Monitoring Session

Perform this task to reenable a link monitoring session after it was previously disabled.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam link-monitor supported

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 4

ethernet oam link-monitor supported

Example:

Device(config-if)# ethernet oam link-monitor supported

Enables link monitoring on the interface.

Step 5

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Stopping and Starting Link Monitoring Operations

Link monitoring operations start automatically when Ethernet OAM is enabled on an interface. When link monitoring operations are stopped, the interface does not actively send or receive event notification OAM PDUs. The tasks in this section describe how to stop and start link monitoring operations.

- Stopping Link Monitoring Operations

- Starting Link Monitoring Operations

Stopping Link Monitoring Operations

Perform this task to stop link monitoring operations.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

5.    no ethernet oam link-monitor on

6.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 4

ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

Example:

Device(config-if)# ethernet oam

Enables Ethernet OAM.

Step 5

no ethernet oam link-monitor on

Example:

Device(config-if)# no ethernet oam link-monitor on

Stops link monitoring operations.

Step 6

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Starting Link Monitoring Operations

Perform this task to start link monitoring operations.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam link-monitor on

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 4

ethernet oam link-monitor on

Example:

Device(config-if)# ethernet oam link-monitor on

Starts link monitoring operations.

Step 5

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Configuring Link Monitoring Options

Perform this optional task to specify link monitoring options. Steps 4 through 10 can be performed in any sequence.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

5.    ethernet oam link-monitor frame {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

6.    ethernet oam link-monitor frame-period {threshold {high {none | high-frames} | low low-frames} | window frames}

7.    ethernet oam link-monitor frame-seconds {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

8.    ethernet oam link-monitor receive-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

9.    ethernet oam link-monitor transmit-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

10.    ethernet oam link-monitor symbol-period {threshold {high {none | high-symbols} | low low-symbols} | window symbols}

11.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Identifies the interface and enters interface configuration mode.

Step 4

ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

Example:

Device(config-if)# ethernet oam

Enables Ethernet OAM.

Step 5

ethernet oam link-monitor frame {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

Example:

Device(config-if)# ethernet oam link-monitor frame window 399

Configures a number for error frames that when reached triggers an action.

Step 6

ethernet oam link-monitor frame-period {threshold {high {none | high-frames} | low low-frames} | window frames}

Example:

Device(config-if)# ethernet oam link-monitor frame-period threshold high 599

Configures a number of frames to be polled.

Frame period is a user-defined parameter.

Step 7

ethernet oam link-monitor frame-seconds {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

Example:

Device(config-if)# ethernet oam link-monitor frame-seconds window 699

Configures a period of time in which error frames are counted.

Step 8

ethernet oam link-monitor receive-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

Example:

Device(config-if)# ethernet oam link-monitor receive-crc window 99

Configures an Ethernet OAM interface to monitor ingress frames with cyclic redundancy check (CRC) errors for a period of time.

Step 9

ethernet oam link-monitor transmit-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

Example:

Device(config-if)# ethernet oam link-monitor transmit-crc threshold low 199

Configures an Ethernet OAM interface to monitor egress frames with CRC errors for a period of time.

Step 10

ethernet oam link-monitor symbol-period {threshold {high {none | high-symbols} | low low-symbols} | window symbols}

Example:

Device(config-if)# ethernet oam link-monitor symbol-period threshold high 299

Configures a threshold or window for error symbols, in number of symbols.

Step 11

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Example

Configuring Global Ethernet OAM Options Using a Template

Perform this task to create a template to use for configuring a common set of options on multiple Ethernet OAM interfaces. Steps 4 through 10 are optional and can be performed in any sequence. These steps may also be repeated to configure different options.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    template template-name

4.    ethernet oam link-monitor receive-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

5.    ethernet oam link-monitor transmit-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

6.    ethernet oam link-monitor symbol-period {threshold {high {none | high-symbols} | low low-symbols} | window symbols}

7.    ethernet oam link-monitor frame {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

8.    ethernet oam link-monitor frame-period {threshold {high {none | high-frames} | low low-frames} | window frames}

9.    ethernet oam link-monitor frame-seconds {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

10.    exit

11.    interface type number

12.    source template template-name

13.    exit

14.    exit

15.    show running-config

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

template template-name

Example:

Device(config)# template oam-temp

Configures a template and enters template configuration mode.

Step 4

ethernet oam link-monitor receive-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

Example:

Device(config-template)# ethernet oam link-monitor receive-crc window 99

Configures an Ethernet OAM interface to monitor ingress frames with CRC errors for a period of time.

Step 5

ethernet oam link-monitor transmit-crc {threshold {high {high-frames | none} | low low-frames} | window milliseconds}

Example:

Device(config-template)# ethernet oam link-monitor transmit-crc threshold low 199

Configures an Ethernet OAM interface to monitor egress frames with CRC errors for a period of time.

Step 6

ethernet oam link-monitor symbol-period {threshold {high {none | high-symbols} | low low-symbols} | window symbols}

Example:

Device(config-template)# ethernet oam link-monitor symbol-period threshold high 299

Configures a threshold or window for error symbols, in number of symbols.

Step 7

ethernet oam link-monitor frame {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

Example:

Device(config-template)# ethernet oam link-monitor frame window 399

Configures a number for error frames that when reached triggers an action.

Step 8

ethernet oam link-monitor frame-period {threshold {high {none | high-frames} | low low-frames} | window frames}

Example:

Device(config-template)# ethernet oam link-monitor frame-period threshold high 599

Configures a number of frames to be polled.

Frame period is a user-defined parameter.

Step 9

ethernet oam link-monitor frame-seconds {threshold {high {none | high-frames} | low low-frames} | window milliseconds}

Example:

Device(config-template)# ethernet oam link-monitor frame-seconds window 699

Configures a period of time in which error frames are counted.

Step 10

exit

Example:

Device(config-template)# exit

Returns to global configuration mode.

Step 11

interface type number

Example:

Identifies the interface on which to use the template and enters interface configuration mode.

Step 12

source template template-name

Example:

Device(config-if)# source template oam-temp

Applies to the interface the options configured in the template.

Step 13

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 14

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 15

show running-config

Example:

Device# show running-config

Displays the updated running configuration.

Configuring a Port for Link Fault RFI Support

Perform this task to put a port into a blocking state when an OAM PDU control request packet is received with the Link Fault Status flag set.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam remote-failure {critical-event | dying-gasp | link-fault} action {}

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Enters interface configuration mode.

Step 4

ethernet oam remote-failure {critical-event | dying-gasp | link-fault} action {}

Sets the interface to the blocking state when a critical event occurs.

Step 5

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Configuration Examples for Ethernet Operations Administration and Maintenance

The following example shows how to configure Ethernet OAM options using a template and overriding that configuration by configuring an interface. In this example, the network supports a Gigabit Ethernet interface between the customer edge device and provider edge device.

! Configure a global OAM template for both PE and CE configuration.
!
Device(config)# template oam
Device(config-template)# ethernet oam link-monitor symbol-period threshold low 10
Device(config-template)# ethernet oam link-monitor symbol-period threshold high 100
Device(config-template)# ethernet oam link-monitor frame window 100
Device(config-template)# ethernet oam link-monitor frame threshold low 10
Device(config-template)# ethernet oam link-monitor frame threshold high 100
Device(config-template)# ethernet oam link-monitor frame-period window 100
Device(config-template)# ethernet oam link-monitor frame-period threshold low 10
Device(config-template)# ethernet oam link-monitor frame-period threshold high 100
Device(config-template)# ethernet oam link-monitor frame-seconds window 1000
Device(config-template)# ethernet oam link-monitor frame-seconds threshold low 10
Device(config-template)# ethernet oam link-monitor frame-seconds threshold high 100
Device(config-template)# ethernet oam link-monitor receive-crc window 100
Device(config-template)# ethernet oam link-monitor receive-crc threshold high 100
Device(config-template)# ethernet oam link-monitor transmit-crc window 100
Device(config-template)# ethernet oam link-monitor transmit-crc threshold high 100

Device(config-template)# exit
!
! Enable Ethernet OAM on the CE interface
!
Device(config)#
Device(config-if)# ethernet oam
!
! Apply the global OAM template named "oam" to the interface.
!
Device(config-if)# source template oam
!
! Configure any interface-specific link monitoring commands to override the template configuration. The following example disables the high threshold link monitoring for receive CRC errors.
!
Device(config-if)# ethernet oam link-monitor receive-crc threshold high none
!
! Enable Ethernet OAM on the PE interface
!
Device(config)#
Device(config-if)# ethernet oam
!
! Apply the global OAM template named "oam" to the interface.
!
Device(config-if)# source template oam

The following examples show how to verify various Ethernet OAM configurations and activities.

Verifying an OAM Session

The following example shows that the local OAM client, Gigabit Ethernet interface , is in session with a remote client with MAC address 0012.7fa6.a700 and OUI 00000C, which is the OUI for Cisco. The remote client is in active mode and has established capabilities for link monitoring and remote loopback for the OAM session.

Device# show ethernet oam summary
Symbols:          * - Master Loopback State,  # - Slave Loopback State
Capability codes: L - Link Monitor,  R - Remote Loopback
U - Unidirection,  V - Variable Retrieval
Local                       Remote
Interface       MAC Address    OUI    Mode    Capability
Gi6/1/1       0012.7fa6.a700 00000C active      L R

Verifying OAM Discovery Status

The following example shows how to verify OAM discovery status of a local client and a remote peer:

Device#

Local client
------------
Administrative configurations:
Mode:              active
Unidirection:      not supported
Link monitor:      supported (on)
Remote loopback:   not supported
MIB retrieval:     not supported
Mtu size:          1500
Operational status:
Port status:       operational
Loopback status:   no loopback
PDU permission:    any
PDU revision:      1
Remote client
-------------
MAC address: 0030.96fd.6bfa
Vendor(oui): 0x00 0x00 0x0C (cisco)
Administrative configurations:
Mode:              active
Unidirection:      not supported
Link monitor:      supported
Remote loopback:   not supported
MIB retrieval:     not supported
Mtu size:          1500

Verifying Information OAMPDU and Fault Statistics

The following example shows how to verify statistics for information OAM PDUs and local and remote faults:

Device#

Counters:
---------
Information OAMPDU Tx                   : 588806
Information OAMPDU Rx                   : 988
Unique Event Notification OAMPDU Tx     : 0
Unique Event Notification OAMPDU Rx     : 0
Duplicate Event Notification OAMPDU TX  : 0
Duplicate Event Notification OAMPDU RX  : 0
Loopback Control OAMPDU Tx              : 1
Loopback Control OAMPDU Rx              : 0
Variable Request OAMPDU Tx              : 0
Variable Request OAMPDU Rx              : 0
Variable Response OAMPDU Tx             : 0
Variable Response OAMPDU Rx             : 0
Cisco OAMPDU Tx                         : 4
Cisco OAMPDU Rx                         : 0
Unsupported OAMPDU Tx                   : 0
Unsupported OAMPDU Rx                   : 0
Frames Lost due to OAM                  : 0
Local Faults:
-------------
0 Link Fault records
2 Dying Gasp records
Total dying gasps       : 4
Time stamp              : 00:30:39
Total dying gasps       : 3
Time stamp              : 00:32:39
0 Critical Event records
Remote Faults:
--------------
0 Link Fault records
0 Dying Gasp records
0 Critical Event records
Local event logs:
-----------------
0 Errored Symbol Period records
0 Errored Frame records
0 Errored Frame Period records
0 Errored Frame Second records
Remote event logs:
------------------
0 Errored Symbol Period records
0 Errored Frame records
0 Errored Frame Period records
0 Errored Frame Second records

Verifying Link Monitoring Configuration and Status

The following example shows how to verify link monitoring configuration and status on the local client. The highlighted Status field in the example shows that link monitoring status is supported and enabled (on).

Device#

General
-------
Mode:                  active
PDU max rate:          10 packets per second
PDU min rate:          1 packet per 1 second
Link timeout:          5 seconds
High threshold action: no action
Link Monitoring
---------------
Status: supported (on)
Symbol Period Error
Window:              1 million symbols
Low threshold:       1 error symbol(s)
High threshold:      none
Frame Error
Window:              10 x 100 milliseconds
Low threshold:       1 error frame(s)
High threshold:      none
Frame Period Error
Window:              1 x 100,000 frames
Low threshold:       1 error frame(s)
High threshold:      none
Frame Seconds Error
Window:              600 x 100 milliseconds
Low threshold:       1 error second(s)
High threshold:      none

Verifying Status of a Remote OAM Client

The following example shows that the local client interface Gi6/1/1 is connected to a remote client. Note the values in the Mode and Capability fields.

Device# show ethernet oam summary
Symbols:          * - Master Loopback State,  # - Slave Loopback State
Capability codes: L - Link Monitor,  R - Remote Loopback
U - Unidirection,  V - Variable Retrieval
Local                       Remote
Interface       MAC Address    OUI    Mode    Capability
Gi6/1/1       0012.7fa6.a700 00000C active      L R

Additional References

Related Documents

Related Topic

Document Title

Ethernet CFM

“Configuring Ethernet Connectivity Fault Management in a Service Provider Network” module in the Carrier Ethernet Configuration Guide

NSF SSO Support in 802.3ah OAM

“Configuring Stateful Switchover” module in the High Availability Configuration Guide and “Configuring Nonstop Forwarding” in the High Availability Configuration Guide

ISSU Support in 802.3ah OAM

“Configuring In Service Software Upgrades" module in the High Availability Configuration Guide

Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Configuring CFM over an EFP Interface with the Cross Connect feature on the Cisco ASR 903 Router

Configuring the CFM over EFP Interface with Cross Connect Feature

Configuring Ethernet Virtual Connections on the Cisco ASR 903 Router

Configuring Ethernet Virtual Connections on the Cisco ASR 903 Router

Standards

Standard

Title

IEEE Draft P802.3ah/D3.3

Ethernet in the First Mile - Amendment

IETF VPLS OAM

L2VPN OAM Requirements and Framework

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Using Ethernet Operations Administration and Maintenance

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Using Ethernet Operations, Administration, and Maintenance

Feature Name

Releases

Feature Information

Ethernet Operations, Administration, and Maintenance

12.4(15)T

Ethernet OAM is a protocol for installing, monitoring, and troubleshooting metro Ethernet networks and Ethernet WANs. It relies on a new, optional sublayer in the data link layer of the OSI model. The OAM features covered by this protocol are Discovery, Link Monitoring, Remote Fault Detection, Remote Loopback, and Cisco Proprietary Extensions.

The Ethernet Operations, Administration, and Maintenance feature was integrated into Cisco IOS Release 12.4(15)T.

The following commands were introduced or modified: clear ethernet oam statistics, debug ethernet oam, ethernet oam, ethernet oam link-monitor frame, ethernet oam link-monitor frame-period, ethernet oam link-monitor frame-seconds, ethernet oam link-monitor high-threshold action, ethernet oam link-monitor on, ethernet oam link-monitor receive-crc, ethernet oam link-monitor supported, ethernet oam link-monitor symbol-period, ethernet oam link-monitor transmit-crc, ethernet oam remote-loopback, ethernet oam remote-loopback (interface), show ethernet oam discovery, show ethernet oam statistics, show ethernet oam status, show ethernet oam summary, source template (eoam), template (eoam).

Chapter 2. Configuring Ethernet Connectivity Fault Management in a Service Provider Network

Ethernet Connectivity Fault Management (CFM) is an end-to-end per-service-instance Ethernet layer operations, administration, and maintenance (OAM) protocol. It includes proactive connectivity monitoring, fault verification, and fault isolation for large Ethernet metropolitan-area networks (MANs) and WANs.

The advent of Ethernet as a MAN and WAN technology imposes a new set of OAM requirements on Ethernet’s traditional operations, which were centered on enterprise networks only. The expansion of Ethernet technology into the domain of service providers, where networks are substantially larger and more complex than enterprise networks and the user base is wider, makes operational management of link uptime crucial. More importantly, the timeliness in isolating and responding to a failure becomes mandatory for normal day-to-day operations, and OAM translates directly to the competitiveness of the service provider.

Note

As an alternative, CFM can be configured over an Ethernet flow point (EFP) interface by using the cross connect functionality. For more information about this alternative, see Configuring the CFM over EFP Interface with Cross Connect Feature.

- Prerequisites for Configuring Ethernet CFM in a Service Provider Network

- Restrictions for Configuring Ethernet CFM in a Service Provider Network

- Information About Configuring Ethernet CFM in a Service Provider Network

- How to Set Up Ethernet CFM in a Service Provider Network

- Configuration Examples for Configuring Ethernet CFM in a Service Provider Network

- Glossary

Prerequisites for Configuring Ethernet CFM in a Service Provider Network

Business Requirements

- Network topology and network administration have been evaluated.

- Business and service policies have been established.

Restrictions for Configuring Ethernet CFM in a Service Provider Network

- CFM loopback messages will not be confined within a maintenance domain according to their maintenance level. The impact of not having CFM loopback messages confined to their maintenance levels occurs at these levels:

- Architecture—CFM layering is violated for loopback messages.

- Deployment—A user may potentially misconfigure a network and have loopback messages succeed.

- Security—A malicious device that recognizes devices’ MAC addresses and levels may potentially explore a network topology that should be transparent.

- CFM is not fully supported on a Multiprotocol Label Switching (MPLS) provider edge (PE) device. There is no interaction between CFM and an Ethernet over MPLS (EoMPLS) pseudowire.

- CFM configuration is not supported on an EtherChannel in FastEthernet Channel (FEC) mode.

Information About Configuring Ethernet CFM in a Service Provider Network

- Ethernet CFM

- Customer Service Instance

- Maintenance Domain

- Maintenance Point

- CFM Messages

- Cross-Check Function

- SNMP Traps

- Ethernet CFM and Ethernet OAM Interaction

- HA Features Supported by CFM

- NSF SSO Support in CFM 802.1ag 1.0d

- ISSU Support in CFM 802.1ag 1.0d

Ethernet CFM

Ethernet CFM is an end-to-end per-service-instance Ethernet layer OAM protocol that includes proactive connectivity monitoring, fault verification, and fault isolation. End to end can be PE to PE or CE to CE. A service can be identified as a service provider VLAN (S-VLAN) or an EVC service.

Being an end-to-end technology is the distinction between CFM and other metro-Ethernet OAM protocols. For example, MPLS, ATM, and SONET OAM help in debugging Ethernet wires but are not always end-to-end. 802.3ah OAM is a single-hop and per-physical-wire protocol. It is not end to end or service aware.

Troubleshooting carrier networks offering Ethernet Layer 2 services is challenging. Customers contract with service providers for end-to-end Ethernet service and service providers may subcontract with operators to provide equipment and networks. Compared to enterprise networks, where Ethernet traditionally has been implemented, these constituent networks belong to distinct organizations or departments, are substantially larger and more complex, and have a wider user base. Ethernet CFM provides a competitive advantage to service providers for which the operational management of link uptime and timeliness in isolating and responding to failures is crucial to daily operations.

- Benefits of Ethernet CFM

Benefits of Ethernet CFM

- End-to-end service-level OAM technology

- Reduced operating expense for service provider Ethernet networks

- Competitive advantage for service providers

- Supports both distribution and access network environments with the outward facing MEPs enhancement

Customer Service Instance

A customer service instance is an Ethernet virtual connection (EVC), which is identified by an S-VLAN within an Ethernet island, and is identified by a globally unique service ID. A customer service instance can be point-to-point or multipoint-to-multipoint. The figure below shows two customer service instances. Service Instance Green is point to point; Service Instance Blue is multipoint to multipoint.

Maintenance Domain

A maintenance domain is 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 ports internal to it and at its boundary. The figure below illustrates a typical maintenance domain.

A unique maintenance level in the range of 0 to 7 is assigned to each domain by a network administrator. Levels and domain names are useful for defining the hierarchical relationship that exists among domains. The hierarchical relationship of domains parallels the structure of customer, service provider, and operator. The larger the domain, the higher the level value. For example, a customer domain would be larger than an operator domain. The customer domain may have a maintenance level of 7 and the operator domain may have a maintenance level of 0. Typically, operators would have the smallest domains and customers the largest domains, with service provider domains between them in size. All levels of the hierarchy must operate together.

Domains should not intersect because intersecting would mean management by more than one entity, which is not allowed. Domains may nest or touch but when two domains nest, the outer domain must have a higher maintenance level than the domain nested within it. Nesting maintenance domains is useful in the business model where a service provider contracts with one or more operators to provide Ethernet service to a customer. Each operator would have its own maintenance domain and the service provider would define its domain—a superset of the operator domains. Furthermore, the customer has its own end-to-end domain which is in turn a superset of the service provider domain. Maintenance levels of various nesting domains should be communicated among the administering organizations. For example, one approach would be to have the service provider assign maintenance levels to operators.

CFM exchanges messages and performs operations on a per-domain basis. For example, running CFM at the operator level does not allow discovery of the network by the higher provider and customer levels.

Network designers decide on domains and configurations. The figure below illustrates a hierarchy of operator, service provider, and customer domains and also illustrates touching, intersecting, and nested domains.

Maintenance Point

A maintenance point is a demarcation point on an interface (port) that participates in CFM within a maintenance domain. Maintenance points on device ports act as filters that confine CFM frames within the bounds of a domain by dropping frames that do not belong to the correct level. Maintenance points must be explicitly configured on Cisco devices. Two classes of maintenance points exist, MEPs and MIPs.

- Maintenance Endpoints

- Maintenance Intermediate Points

Maintenance Endpoints

Maintenance endpoints (MEPs) have the following characteristics:

- Per maintenance domain (level) and service (S-VLAN or EVC)

- At the edge of a domain, define the boundary

- Within the bounds of a maintenance domain, confine CFM messages

- When configured to do so, proactively transmit Connectivity Fault Management (CFM) continuity check messages (CCMs)

- At the request of an administrator, transmit traceroute and loopback messages

Inward Facing MEPs

Inward facing means the MEP communicates through the Bridge Relay function and uses the Bridge-Brain MAC address. An inward facing MEP performs the following functions:

- Sends and receives CFM frames at its level through the relay function, not via the wire connected to the port on which the MEP is configured.

- Drops all CFM frames at its level (or lower level) that come from the direction of the wire.

- Processes all CFM frames at its level coming from the direction of the relay function.

- Drops all CFM frames at a lower level coming from the direction of the relay function.

- Transparently forwards all CFM frames at its level (or a higher level), independent of whether they come in from the relay function side or the wire side.

Note

A MEP of level L (where L is less than 7) requires a MIP of level M > L on the same port; hence, CFM frames at a level higher than the level of the MEP will be catalogued by this MIP.

- If the port on which the inward MEP is configured is blocked by Spanning-Tree Protocol, the MEP can no longer transmit or receive CFM messages.

Outward Facing MEPs for Port Channels

Outward facing means that the MEP communicates through the wire. Outward facing MEPs can be configured on port channels (using cross connect functionality). A MIP configuration at a level higher than the level of the outward facing MEP is not required.

Outward facing MEPs on port channels use the Bridge-Brain MAC address of the first member link. When port channel members change, the identities of outward facing MEPs do not have to change.

An outward facing MEP performs the following functions:

- Sends and receives CFM frames at its level via the wire connected to the port where the MEP is configured.

- Drops all CFM frames at its level (or at a lower level) that come from the direction of the relay function.

- Processes all CFM frames at its level coming from the direction of the wire.

- Drops all CFM frames at a lower level coming from the direction of the wire.

- Transparently forwards all CFM frames at levels higher than the level of the outward facing MEP, independent of whether they come in from the relay function side or the wire side.

- If the port on which the outward MEP is configured is blocked by the Spanning-Tree Protocol, the MEP can still transmit and receive CFM messages via the wire.

Maintenance Intermediate Points

MIPs have the following characteristics:

- Per maintenance domain (level) and for all S-VLANs enabled or allowed on a port.

- Internal to a domain, not at the boundary.

- CFM frames received from MEPs and other MIPs are cataloged and forwarded, using both the wire and the relay function.

- All CFM frames at a lower level are stopped and dropped, independent of whether they originate from the wire or relay function.

- All CFM frames at a higher level are forwarded, independent of whether they arrive from the wire or relay function.

- Passive points respond only when triggered by CFM traceroute and loopback messages.

- Bridge-Brain MAC addresses are used.

If the port on which a MIP is configured is blocked by Spanning-Tree Protocol, the MIP cannot receive CFM messages or relay them toward the relay function side. The MIP can, however, receive and respond to CFM messages from the wire.

A MIP has only one level associated with it and the command-line interface (CLI) does not allow you to configure a MIP for a domain that does not exist.

The figure below illustrates MEPs and MIPs at the operator, service provider, and customer levels.

CFM Messages

CFM uses standard Ethernet frames. CFM frames are distinguishable by EtherType and for multicast messages by MAC address. CFM frames are sourced, terminated, processed, and relayed by bridges. Routers can support only limited CFM functions.

Bridges that cannot interpret CFM messages forward them as normal data frames. All CFM messages are confined to a maintenance domain and to an S-VLAN (PE-VLAN or Provider-VLAN). Three types of messages are supported:

- Continuity Check

- Loopback

- Traceroute

Continuity Check Messages

CFM CCMs are multicast heartbeat messages exchanged periodically among MEPs. They allow MEPs to discover other MEPs within a domain and allow MIPs to discover MEPs. CCMs are confined to a domain and S-VLAN.

CFM CCMs have the following characteristics:

- Transmitted at a configurable periodic interval by MEPs. The interval can be from 10 seconds to 65535 seconds, the default is 30.

- Contain a configurable hold-time value to indicate to the receiver the validity of the message. The default is 2.5 times the transmit interval.

- Catalogued by MIPs at the same maintenance level.

- Terminated by remote MEPs at the same maintenance level.

- Unidirectional and do not solicit a response.

- Carry the status of the port on which the MEP is configured.

Loopback Messages

CFM loopback messages are unicast frames that a MEP transmits, at the request of an administrator, to verify connectivity to a particular maintenance point. A reply to a loopback message indicates whether a destination is reachable but does not allow hop-by-hop discovery of the path. A loopback message is similar in concept to an Internet Control Message Protocol (ICMP) Echo (ping) message.

A CFM loopback message can be generated on demand using the CLI. The source of a loopback message must be a MEP; the destination may be a MEP or a MIP. CFM loopback messages are unicast; replies to loopback messages also are unicast. CFM loopback messages specify the destination MAC address, VLAN, and maintenance domain.

Traceroute Messages

CFM traceroute messages are multicast frames that a MEP transmits, at the request of an administrator, to track the path (hop-by-hop) to a destination MEP. They allow the transmitting node to discover vital connectivity data about the path, and allow the discovery of all MIPs along the path that belong to the same maintenance domain. For each visible MIP, traceroute messages indicate ingress action, relay action, and egress action. Traceroute messages are similar in concept to User Datagram Protocol (UDP) traceroute messages.

Traceroute messages include the destination MAC address, VLAN, and maintenance domain and they have Time To Live (TTL) to limit propagation within the network. They can be generated on demand using the CLI. Traceroute messages are multicast; reply messages are unicast.

Cross-Check Function

The cross-check function is a timer-driven post-provisioning service verification between dynamically discovered MEPs (via CCMs) and expected MEPs (via configuration) for a service. The cross-check function verifies that all endpoints of a multipoint or point-to-point service are operational. The function supports notifications when the service is operational; otherwise it provides alarms and notifications for unexpected endpoints or missing endpoints.

The cross-check function is performed one time. You must initiate the cross-check function from the CLI every time you want a service verification.

SNMP Traps

The support provided by the Cisco software implementation of CFM traps is Cisco proprietary information. MEPs generate two types of Simple Network Management Protocol (SNMP) traps, continuity check (CC) traps and cross-check traps.

CC Traps

- MEP up—Sent when a new MEP is discovered, the status of a remote port changes, or connectivity from a previously discovered MEP is restored after interruption.

- MEP down—Sent when a timeout or last gasp event occurs.

- Cross-connect—Sent when a service ID does not match the VLAN.

- Loop—Sent when a MEP receives its own CCMs.

- Configuration error—Sent when a MEP receives a continuity check with an overlapping MPID.

Cross-Check Traps

- Service up—Sent when all expected remote MEPs are up in time.

- MEP missing—Sent when an expected MEP is down.

- Unknown MEP—Sent when a CCM is received from an unexpected MEP.

Ethernet CFM and Ethernet OAM Interaction

To understand how CFM and OAM interact, you should understand the following concepts:

- Ethernet Virtual Circuit

- OAM Manager

- CFM over Bridge Domains

Ethernet Virtual Circuit

An EVC as defined by the Metro Ethernet Forum is a port-level point-to-point or multipoint-to-multipoint Layer 2 circuit. EVC status can be used by a CE device either to find an alternative path in to the service provider network or in some cases, to fall back to a backup path over Ethernet or over another alternative service such as ATM.

OAM Manager

The OAM manager is an infrastructure element that streamlines interaction between OAM protocols. The OAM manager requires two interworking OAM protocols, in this case Ethernet CFM and Ethernet OAM. Interaction is unidirectional from the OAM manager to the CFM protocol and the only information exchanged is the user network interface (UNI) port status. Additional port status values available include

- REMOTE_EE—Remote excessive errors

- LOCAL_EE—Local excessive errors

- TEST—Either remote or local loopback

After CFM receives the port status, it communicates that status across the CFM domain.

CFM over Bridge Domains

Connectivity Fault Management (CFM) over bridge domains allows untagged CFM packets to be associated with a maintenance end point (MEP). An incoming untagged customer CFM packet has an EtherType of CFM and is mapped to an Ethernet virtual circuit (EVC) or bridge domain based on the encapsulation configured on the Ethernet flow point (EFP). The EFP is configured specifically to recognize these untagged packets.

An EFP is a logical demarcation point of an EVC on an interface and can be associated with a bridge domain. The VLAN ID is used to match and map traffic to the EFP. VLAN IDs have local significance per port similar to an ATM virtual circuit. CFM is supported on a bridge domain associated with an EFP. The association between the bridge domain and the EFP allows CFM to use the encapsulation on the EFP. All EFPs in the same bridge domain form a broadcast domain. The bridge domain ID determines the broadcast domain.

The distinction between a VLAN port and the EFP is the encapsulation. VLAN ports use a default dot1q encapsulation. For EFPs, untagged, single tagged, and double tagged encapsulation exists with dot1q and IEEE dot1ad EtherTypes. Different EFPs belonging to the same bridge domain can use different encapsulations.

Both up MEP, down MEP and MIP are supported. If an up MEP is configured under an EFP within a bridge domain, CFM messages would be routed into the bridge, and the rest members of the same bridge domain would be able to receive messages from this MEP. If a down MEP is configured, the messages will not goes into the bridge domain.

HA Features Supported by CFM

In access and service provider networks using Ethernet technology, High Availability (H)A is a requirement, especially on Ethernet OAM components that manage EVC connectivity. End-to-end connectivity status information is critical and must be maintained on a hot standby Route Switch Processor (RSP).

Note

A hot standby Route Switch Processor (RSP) has the same software image as the active RSP and supports synchronization of protocol and application state information between RSPs for supported features and protocols.

End-to-end connectivity status is maintained on the customer edge (CE), provider edge (PE), and access aggregation PE (uPE) network nodes based on information received by protocols such as Connectivity Fault Management (CFM) and 802.3ah. This status information is used to either stop traffic or switch to backup paths when an EVC is down.

Every transaction involves either accessing or updating data among various databases. If the database is synchronized across active and standby modules, the modules are transparent to clients.

The Cisco infrastructure provides various component application program interfaces (APIs) that help to maintain a hot standby RSP. Metro Ethernet HA clients HA/ISSU, CFM HA/ISSU, and 802.3ah HA/ISSU interact with these components, update the database, and trigger necessary events to other components.

Benefits of CFM HA

- Elimination of network downtime for Cisco software image upgrades, allowing for faster upgrades.

- Elimination of resource scheduling challenges associated with planned outages and late night maintenance windows.

- Accelerated deployment of new services and applications and facilitation of faster implementation of new features.

- Reduced operating costs due to outages while delivering higher service levels.

- CFM updates its databases and controls its own HA messaging and versioning, and this control facilitates maintenance.

- CFM HA in a Metro Ethernet Network

CFM HA in a Metro Ethernet Network

A standalone Connectivity Fault Management (CFM) implementation does not have explicit high availability (HA) requirements. When CFM is implemented on a customer edge (CE) or provider edge (PE), CFM must maintain the Ethernet virtual circuit (EVC) state, which requires HA because the EVC state is critical in maintaining end-to-end connectivity. CFM configures the platform with maintenance level, domain, and maintenance point, learns the remote maintenance point information, and maps it to the appropriate EVC. CFM then aggregates data received from all remote ports; consequently HA requirements vary for CE and PE.

The CE receives the EVC ID, associated customer VLANs, UNI information, EVC state, and remote UNI ID and state from the MEN. The CE relies on the EVC state to send or stop traffic to the MEN.

The PE has EVC configuration and associated customer VLAN information and derives the EVC state and remote UNI from CFM.

Note

PEs and CEs running 802.3ah OAM must maintain the port state so peers are not affected by a switchover. This information is also sent to remote nodes in CFM CC messages.

NSF SSO Support in CFM 802.1ag 1.0d

The redundancy configurations Stateful Switchover (SSO) and Nonstop Forwarding (NSF) are both supported in Ethernet Connectivity Fault Management (CFM) and are automatically enabled. A switchover from an active to a standby Route Switch Processor (RSP) occurs when the active RSP fails, is removed from the networking device, or is manually taken down for maintenance. NSF interoperates with the SSO feature to minimize network downtime following a switchover. The primary function of Cisco NSF is to continue forwarding IP packets following an RSP switchover.

For detailed information about SSO, see the “Configuring Stateful Switchover” module of the High Availability Configuration Guide. For detailed information about the NSF feature, see the “Configuring Cisco Nonstop Forwarding” module of the High Availability Configuration Guide.

ISSU Support in CFM 802.1ag 1.0d

In Service Upgrades (ISSUs) allow you to perform a Cisco software upgrade or downgrade without disrupting packet flow. Connectivity Fault Management (CFM) performs a bulk update and a runtime update of the continuity check database to the standby Route Switch Processor (RSP), including adding, deleting, or updating a row. This checkpoint data requires ISSU capability to transform messages from one release to another. All the components that perform active RSP to standby RSP updates using messages require ISSU support.

ISSU is automatically enabled in CFM and lowers the impact that planned maintenance activities have on network availability by allowing software changes while the system is in service. For detailed information about ISSU, see the “Performing an In Service Software Upgrade ” module of the High Availability Configuration Guide.

How to Set Up Ethernet CFM in a Service Provider Network

- Designing CFM Domains

- Configuring Ethernet CFM

- Configuring Ethernet OAM Interaction with CFM

Designing CFM Domains

Note

To have an operator, service provider, or customer domain is optional. A network may have a single domain or multiple domains. The steps listed here show the sequence when all three types of domains will be assigned.

Before You Begin

- Knowledge and understanding of the network topology.

- Understanding of organizational entities involved in managing the network; for example, operators, service providers, network operations centers (NOCs), and customer service centers.

- Understanding of the type and scale of services to be offered.

- Agreement by all organizational entities on the responsibilities, roles, and restrictions for each organizational entity.

- Determination of the number of maintenance domains in the network.

- Determination of the nesting and disjoint maintenance domains.

- Assignment of maintenance levels and names to domains based on agreement between the service provider and operator or operators.

- Determination of whether the domain should be inward or outward.

SUMMARY STEPS

1.    Determine operator level MIPs.

2.    Determine operator level MEPs.

3.    Determine service provider MIPs.

4.    Determine service provider MEPs.

5.    Determine customer MIPs.

6.    Determine customer MEPs.

DETAILED STEPS

Command or Action

Purpose

Step 1

Determine operator level MIPs.

Follow these steps:

- Starting at lowest operator level domain, assign a MIP at every interface internal to the operator network to be visible to CFM.

- Proceed to next higher operator level and assign MIPs.

- Verify that every port that has a MIP at a lower level does not have maintenance points at a higher level.

- Repeat steps a through d until all operator MIPs are determined.

Step 2

Determine operator level MEPs.

Follow these steps:

- Starting at the lowest operator level domain, assign a MEP at every UNI that is part of a service instance.

- Assign a MEP at the network to network interface (NNI) between operators, if there is more than one operator.

- Proceed to next higher operator level and assign MEPs.

- A port with a MIP at a lower level cannot have maintenance points at a higher level. A port with a MEP at a lower level should have either a MIP or MEP at a higher level.

Step 3

Determine service provider MIPs.

Follow these steps:

- Starting at the lowest service provider level domain, assign service provider MIPs at the NNI between operators (if more than one).

- Proceed to next higher service provider level and assign MIPs.

- A port with a MIP at a lower level cannot have maintenance points at a higher level. A port with a MEP at a lower level should not have either a MIP or a MEP at a higher level.

Step 4

Determine service provider MEPs.

Follow these steps:

- Starting at the lowest service provider level domain, assign a MEP at every UNI that is part of a service instance.

- Proceed to next higher service provider level and assign MEPs.

- A port with a MIP at a lower level cannot have maintenance points at a higher level. A port with a MEP at a lower level should have either a MIP or a MEP at a higher level.

Step 5

Determine customer MIPs.

Customer MIPs are allowed only on the UNIs at the uPEs if the service provider allows the customer to run CFM. Otherwise, the service provider can configure Cisco devices to block CFM frames.

- Configure a MIP on every uPE, at the UNI port, in the customer maintenance domain.

- Ensure the MIPs are at a maintenance level that is at least one higher than the highest level service provider domain.

Step 6

Determine customer MEPs.

Customer MEPs are on customer equipment. Assign an outward facing MEP within an outward domain at the appropriate customer level at the handoff between the service provider and the customer.

- Examples

- What to Do Next

Examples

The figure below shows an example of a network with a service provider and two operators, A and B. Three domains are to be established to map to each operator and the service provider. In this example, for simplicity we assume that the network uses Ethernet transport end to end. CFM, however, can be used with other transports.

What to Do Next

After you have defined the Ethernet CFM domains, configure Ethernet CFM functionality by first provisioning the network and then provisioning service.

Configuring Ethernet CFM

Configuring Ethernet CFM consists of the following tasks:

- Provisioning the Network

- Provisioning Service

- Configuring and Enabling the Cross-Check Function

- Configuring CFM over Bridge Domains

- Troubleshooting Tips

Provisioning the Network

- Provisioning the Network on the CE-A

- Provisioning the Network on the U-PE A

- Provisioning the Network on the PE-AGG A

- Provisioning the Network on the N-PE A

- Provisioning the Network on the CE-B

- Provisioning the Network on the U-PE B

- Provisioning the Network on the PE-AGG B

- Provisioning the Network on the N-PE B

Provisioning the Network on the CE-A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

15.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM continuity check events.

Step 15

snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown mep-missing service-up

Enables SNMP trap generation for Ethernet CFM continuity check events in relation to the cross-check operation between statically configured MEPS and those learned via CCMs.

Step 16

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Provisioning the Network on the U-PE A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mip level { level }

19.    exit

20.    exit

21.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

22.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

23.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mip level { level }

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM mep-up, mep-down, config, loop, and cross-connect events.

Step 22

snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown mep-missing service-up

Enables SNMP trap generation for Ethernet CFM mep-unknown, mep-missing, and service-up continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 23

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Provisioning the Network on the PE-AGG A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [ interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    interface type number

12.    service instance id ethernet [evc-name]

13.    encapsulation encapsulation-type

14.    bridge-domain bridge-id

15.    cfm mip level level

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [ interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 65

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns the CLI to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 12

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 13

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 14

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 15

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 16

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Provisioning the Network on the N-PE A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    ethernet cfm global

9.    ethernet cfm traceroute cache

10.    ethernet cfm traceroute cache size entries

11.    ethernet cfm traceroute cache hold-time minutes

12.    interface type number

13.    service instance id ethernet [evc-name]

14.    encapsulation encapsulation-type

15.    bridge-domain bridge-id

16.    cfm mip level level

17.    exit

18.    exit

19.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

20.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

21.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 9

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 10

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 11

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 12

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 13

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 14

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 15

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 16

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 17

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 18

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 19

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM mep-up, mep-down, config, loop, and cross-connect events.

Step 20

snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown mep-missing service-up

Enables SNMP trap generation for Ethernet CFM mep-unknown, mep-missing, and service-up continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 21

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Provisioning the Network on the CE-B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

15.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM mep-up, mep-down, config, loop, and cross-connect events.

Step 15

snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown mep-missing service-up

Enables SNMP trap generation for Ethernet CFM mep-unknown, mep-missing, and service-up continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 16

end

Example:

Device(config)# end#

Returns to privileged EXEC mode.

Provisioning the Network on the U-PE B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mip level level

19.    exit

20.    exit

21.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

22.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

23.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM mep-up, mep-down, config, loop, and cross-connect events.

Step 22

snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown mep-missing service-up

Enables SNMP trap generation for Ethernet CFM mep-unknown, mep-missing, and service-up continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 23

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Provisioning the Network on the PE-AGG B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    interface type number

12.    service instance id ethernet [evc-name]

13.    encapsulation encapsulation-type

14.    bridge-domain bridge-id

15.    cfm mip level level

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 65

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 12

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 13

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 14

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 15

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 16

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning the Network on the N-PE B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mip level level

19.    exit

20.    exit

21.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

22.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

23.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM mep-up, mep-down, config, loop, and cross-connect events.

Step 22

snmp-server enable traps ethernet cfm crosscheck [mep-unknown | mep-missing | service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown mep-missing service-up

Enables SNMP trap generation for Ethernet CFM mep-unknown, mep-missing, and service-up continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 23

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Provisioning Service

- Provisioning Service on the CE-A

- Provisioning Service on the U-PE A

- Provisioning Service on the PE-AGG A

- Provisioning Service on the N-PE A

- Provisioning Service on the CE-B

- Provisioning Service on the U-PE B

- Provisioning Service on the PE-AGG B

- Provisioning Service on the N-PE B

Provisioning Service on the CE-A

Perform this task to set up service for Ethernet CFM. Optionally, when this task is completed, you may configure and enable the cross-check function. To perform this optional task, see “Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-A”.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mep domain domain-name mpid id

19.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mep domain domain-name mpid id

Example:

Device(config-if-srv)# cfm mep domain L4 mpid 4001

Configures the MEP domain and the ID.

Step 19

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the U-PE A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mep domain domain-name mpid id

19.    exit

20.    exit

21.    interface type number

22.    service instance id ethernet [evc-name]

23.    encapsulation encapsulation-type

24.    bridge-domain bridge-id

25.    cfm mip level level

26.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mep domain domain-name mpid id

Example:

Device(config-if-srv)# cfm mep domain L4 mpid 4001

Configures the MEP domain and the ID.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 22

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 23

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 24

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 25

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 26

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the PE-AGG A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    interface type number

12.    service instance id ethernet [evc-name]

13.    encapsulation encapsulation-type

14.    bridge-domain bridge-id

15.    cfm mip level level

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 65

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 12

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 13

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 14

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 15

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 16

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the N-PE A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mip level level

19.    exit

20.    exit

21.    interface type number

22.    service instance id ethernet [evc-name ]

23.    encapsulation encapsulation-type

24.    bridge-domain bridge-id

25.    cfm mep domain domain-name mpid id

26.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

interface type number

Example:

Specifies an interface.

Step 22

service instance id ethernet [evc-name ]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 23

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 24

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 25

cfm mep domain domain-name mpid id

Example:

Device(config-if-srv)# cfm mep domain L4 mpid 4001

Configures the MEP domain and the ID.

Step 26

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the CE-B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mep domain domain-name mpid id

19.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mep domain domain-name mpid id

Example:

Device(config-if-srv)# cfm mep domain L4 mpid 4001

Configures the MEP domain and the ID.

Step 19

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the U-PE B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mip level level

19.    exit

20.    exit

21.    interface type number

22.    service instance id ethernet [evc-name]

23.    encapsulation encapsulation-type

24.    bridge-domain bridge-id

25.    cfm mep domain domain-name mpid id

26.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 22

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 23

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 24

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 25

cfm mep domain domain-name mpid id

Example:

Device(config-if-srv)# cfm mep domain L4 mpid 4001

Configures the MEP domain and the ID.

Step 26

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the PE-AGG B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    interface type number

12.    service instance id ethernet [evc-name]

13.    encapsulation encapsulation-type

14.    bridge-domain bridge-id

15.    cfm mip level level

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 65

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 12

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 13

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 14

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 15

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 16

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Provisioning Service on the N-PE B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    continuity-check

6.    continuity-check [interval cc-interval]

7.    exit

8.    mep archive-hold-time minutes

9.    exit

10.    ethernet cfm global

11.    ethernet cfm traceroute cache

12.    ethernet cfm traceroute cache size entries

13.    ethernet cfm traceroute cache hold-time minutes

14.    interface type number

15.    service instance id ethernet [evc-name]

16.    encapsulation encapsulation-type

17.    bridge-domain bridge-id

18.    cfm mip level level

19.    exit

20.    exit

21.    interface type number

22.    service instance id ethernet [evc-name]

23.    encapsulation encapsulation-type

24.    bridge-domain bridge-id

25.    cfm mep domain domain-name mpid id

26.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Configures the transmission of continuity check messages (CCMs).

Step 6

continuity-check [interval cc-interval]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the per-service parameters and sets the interval at which CCMs are transmitted.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet connectivity fault management configuration mode.

Step 8

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 12

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 13

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 16

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 17

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 18

cfm mip level level

Example:

Device(config-if-srv)#cfm mip level 4

Creates a MIP and sets the maintenance level number.

Step 19

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 20

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 21

interface type number

Example:

Specifies an interface.

Step 22

service instance id ethernet [evc-name]

Example:

Device(config-if)# service instance 333 ethernet evc1

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 23

encapsulation encapsulation-type

Example:

Sets the encapsulation method used by the interface.

Step 24

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds a service instance to a bridge domain instance.

Step 25

cfm mep domain domain-name mpid id

Example:

Device(config-if-srv)# cfm mep domain L4 mpid 4001

Configures the MEP domain and the ID.

Step 26

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Configuring and Enabling the Cross-Check Function

- Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-A

- Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-B

- Configuring and Enabling Cross-Checking for an Outward Facing MEP on the CE-A

- Configuring and Enabling Cross-Checking for an Outward Facing MEP on the CE-B

Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-A

Perform this task to configure and enable cross-checking for an inward facing MEP. This task requires you to configure and enable cross-checking on two devices. This task is optional.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    mep crosscheck mpid id vlan vlan-id [mac mac-address]

5.    exit

6.    ethernet cfm mep crosscheck start-delay delay

7.    exit

8.    ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain ServiceProvider level 4

Defines a CFM domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

mep crosscheck mpid id vlan vlan-id [mac mac-address]

Example:

Device(config-ether-cfm)# mep crosscheck mpid 402 vlan 100

Statically defines a remote MEP on a specified VLAN within the domain.

Step 5

exit

Example:

Device(config-ether-cfm)# exit#

Returns to global configuration mode.

Step 6

ethernet cfm mep crosscheck start-delay delay

Example:

Device(config)# ethernet cfm mep crosscheck start-delay 60

Configures the maximum amount of time that the device waits for remote MEPs to come up before the cross-check operation is started

Step 7

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 8

ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

Example:

Device# ethernet cfm mep crosscheck enable level 4 vlan 100

Enables cross-checking between remote MEPs in the domain and MEPs learned through CCMs.

Example

The following example configures cross-checking on an inward facing MEP (U-PE A):

U-PE A
ethernet cfm domain ServiceProvider level 4
mep crosscheck mpid 402 vlan 100
!
ethernet cfm mep crosscheck start-delay 60

The following example enables cross-checking on an inward facing MEP (U-PE A):

U-PE A
U-PEA# ethernet cfm mep crosscheck enable level 4 vlan 100

Configuring and Enabling Cross-Checking for an Inward Facing MEP on the U PE-B

Perform this task to configure and enable cross-checking for an inward facing MEP. This task requires you to configure and enable cross-checking on two devices. This task is optional.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    mep crosscheck mpid id vlan vlan-id [mac mac-address]

5.    exit

6.    ethernet cfm mep crosscheck start-delay delay

7.    exit

8.    ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain ServiceProvider level 4

Defines a CFM domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

mep crosscheck mpid id vlan vlan-id [mac mac-address]

Example:

Device(config-ether-cfm)# mep crosscheck mpid 401 vlan 100

Statically defines a remote MEP on a specified VLAN within the domain.

Step 5

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 6

ethernet cfm mep crosscheck start-delay delay

Example:

Device(config)# ethernet cfm mep crosscheck start-delay 60

Configures the maximum amount of time that the device waits for remote MEPs to come up before the cross-check operation is started.

Step 7

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 8

ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

Example:

Device# ethernet cfm mep crosscheck enable level 4 vlan 100

Enables cross-checking between MEPs.

Example

The following example configures cross-checking on an inward facing MEP (U-PE B)

U-PE B
ethernet cfm domain ServiceProvider level 4
mep crosscheck mpid 401 vlan 100
!
ethernet cfm mep crosscheck start-delay 60

The following example enables cross-checking on an inward facing MEP (U-PE B)

U-PE B
U-PEB# ethernet cfm mep crosscheck enable level 4 vlan 100

Configuring and Enabling Cross-Checking for an Outward Facing MEP on the CE-A

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id [direction outward]

4.    mep crosscheck mpid id vlan vlan-id [mac mac-address]

5.    exit

6.    ethernet cfm mep crosscheck start-delay delay

7.    exit

8.    ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain Customer level 7 direction outward

Defines a CFM domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

mep crosscheck mpid id vlan vlan-id [mac mac-address]

Example:

Device(config-ether-cfm)# mep crosscheck mpid 702 vlan 100

Statically defines a remote MEP with a specified ID, VLAN, and domain.

Step 5

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 6

ethernet cfm mep crosscheck start-delay delay

Example:

Device(config)# ethernet cfm mep crosscheck start-delay 60

Configures the maximum amount of time that the device waits for remote MEPs to come up before the cross-check operation is started.

Step 7

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 8

ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

Example:

Device# ethernet cfm mep crosscheck enable level 7 vlan 100

Enables cross-checking between MEPs.

Configuring and Enabling Cross-Checking for an Outward Facing MEP on the CE-B

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id [direction outward]

4.    mep crosscheck mpid id vlan vlan-id [mac mac-address]

5.    exit

6.    ethernet cfm mep crosscheck start-delay delay

7.    exit

8.    ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain Customer level 7 direction outward

Defines an outward CFM domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

mep crosscheck mpid id vlan vlan-id [mac mac-address]

Example:

Device(config-ether-cfm)# mep crosscheck mpid 401 vlan 100

Statically defines a remote MEP on a VLAN within a specified domain.

Step 5

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 6

ethernet cfm mep crosscheck start-delay delay

Example:

Device(config)# ethernet cfm mep crosscheck start-delay 60

Configures the maximum amount of time that the device waits for remote MEPs to come up before the cross-check operation is started.

Step 7

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Step 8

ethernet cfm mep crosscheck {enable | disable} level {level-id | level-id-level-id [,level-id-level-id]} vlan {vlan-id | any | vlan-id-vlan-id [,vlan-id-vlan-id]}

Example:

Device# ethernet cfm mep crosscheck enable level 7 vlan 100

Enables cross-checking between MEPs.

Configuring CFM over Bridge Domains

Perform this task to configure Ethernet CFM over bridge domains. This task is optional.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id direction outward

4.    service csi-id evc evc-name

5.    exit

6.    ethernet cfm domain domain-name level level-id

7.    exit

8.    ethernet cfm domain domain-name level level-id

9.    service csi-id evc evc-name

10.    mep crosscheck mpid id evc evc-name mac mac-address

11.    exit

12.    ethernet evc evc-name

13.    exit

14.    interface type number

15.    no ip address

16.    service instance id ethernet evc-id

17.    encapsulation dot1q vlan-id

18.    bridge-domain bridge-id

19.    cfm mep domain domain-name mpid mpid-value

20.    end

21.    configure terminal

22.    interface type name

23.    no ip address

24.    ethernet cfm mip level level-id

25.    service instance id ethernet evc-id

26.    encapsulation dot1q vlan-id

27.    bridge-domain bridge-id

28.    cfm mep domain domain-name mpid mpid-value

29.    end

30.    configure terminal

31.    ethernet cfm cc enable level level-id evc evc-name

32.    ethernet cfm cc level any evc evc-name interval seconds loss-threshold num-msgs

33.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id direction outward

Example:

Device(config)# ethernet cfm domain CUSTOMER level 7 direction outward

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 4

service csi-id evc evc-name

Example:

Device(config-ether-cfm)# service customer_100 evc evc_100

Sets a universally unique ID for a CSI within a maintenance domain.

Step 5

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 6

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain MIP level 7

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 7

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 8

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain PROVIDER level 4

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 9

service csi-id evc evc-name

Example:

Device(config-ether-cfm)# service provider_1 evc evc_100

Sets a universally unique ID for a CSI within a maintenance domain.

Step 10

mep crosscheck mpid id evc evc-name mac mac-address

Example:

Device(config-ether-cfm)# mep crosscheck mpid 200 evc evc_100 mac 1010.1010.1010

Statically defines a remote MEP within a maintenance domain.

Step 11

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 12

ethernet evc evc-name

Example:

Device(config)# ethernet evc evc_100

Defines an EVC and enters EVC configuration mode.

Step 13

exit

Example:

Device(config-evc)# exit

Returns to global configuration mode.

Step 14

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 15

no ip address

Example:

Device(config-if)# no ip address

Disables IP processing.

Step 16

service instance id ethernet evc-id

Example:

Device(config-if)# service instance 100 ethernet evc_100

Specifies an Ethernet service instance on an interface and enters service instance configuration mode.

Step 17

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to map 802.1Q frames on an ingress interface to the appropriate service instance.

Step 18

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Establishes a bridge domain.

Step 19

cfm mep domain domain-name mpid mpid-value

Example:

Device(config-if-srv)# cfm mep domain CUSTOMER mpid 1001

Configures a MEP for a domain.

Step 20

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Step 21

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 22

interface type name

Example:

Specifies an interface and enters interface configuration mode.

Step 23

no ip address

Example:

Device(config-if)# no ip address

Disables IP processing.

Step 24

ethernet cfm mip level level-id

Example:

Device(config-if)# ethernet cfm mip level 7

Provisions a MIP at a specified maintenance level on an interface.

Step 25

service instance id ethernet evc-id

Example:

Device(config-if)# service instance 100 ethernet evc_100

Configures an Ethernet service instance on an interface and enters service instance configuration mode.

Step 26

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to map 802.1Q frames on an ingress interface to the appropriate service instance.

Step 27

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Establishes a bridge domain.

Step 28

cfm mep domain domain-name mpid mpid-value

Example:

Device(config-if-srv)# cfm mep domain PROVIDER inward mpid 201

Configures a MEP for a domain.

Step 29

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Step 30

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 31

ethernet cfm cc enable level level-id evc evc-name

Example:

Device(config)# ethernet cfm cc enable level 0-7 evc evc_100

Globally enables transmission of CCMs.

Step 32

ethernet cfm cc level any evc evc-name interval seconds loss-threshold num-msgs

Example:

Device(config)# ethernet cfm cc level any evc evc_100 interval 100 loss-threshold 2

Sets the parameters for CCMs.

Step 33

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

What to Do Next

Note

When configuring CFM over bridge domains where the bridge-domain ID matches the vlan ID service, you must configure the vlan service and the EVC service with the same service name. The bridge-domain is associated with the EVC service. The vlan and the bridge-domain represent the same broadcast domain.

Configuring UP MEP over Port Channel in L2VPN

Perform this task to configure up Maintenance End Point (MEP) over port channel in Layer 2 VPN (L2VPN). This task shows Provider Edge 1 and 2 configurations.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm ieee

4.    ethernet cfm global

5.    ethernet cfm domain domain-name level level-id

6.    service csi-id evc evc-name

7.    continuity-check [inteval time]

8.    exit

9.    ethernet evc evc-name

10.    pseudowire-class pw-class-name

11.    encapsulation mpls

12.    exit

13.    interface type number

14.    service instance id ethernet evc-id

15.    encapsulation dot1q vlan-id

16.    rewrite ingress tag pop 1 symmetric

17.    xconnect peer-ip-addressvc-id pw-class pw-class-name

18.    cfm mep domain domain-name mpid mpid-value

19.    exit

20.    ethernet cfm ieee

21.    ethernet cfm global

22.    ethernet cfm domain domain-name level level-id

23.    service csi-id evc evc-name

24.    continuity-check [inteval ime]

25.    exit

26.    ethernet evc evc-name

27.    pseudowire-class pw-class-name

28.    encapsulation mpls

29.    exit

30.    interface type number

31.    service instance id ethernet evc-id

32.    encapsulation dot1q vlan-id

33.    rewrite ingress tag pop 1 symmetric

34.    xconnect peer-ip-addressvc-id pw-class pw-class-name

35.    cfm mep domain domain-name mpid mpid-value

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 4

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables Ethernet connectivity fault management (CFM) globally on a device.

Step 5

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain CUSTOMER level 7

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 6

service csi-id evc evc-name

Example:

Device(config-ether-cfm)# service customer100 evc evc100

Sets a universally unique ID for a customer service instance (CSI) within a maintenance domain.

Step 7

continuity-check [inteval time]

Example:

Device(config-ether-cfm)# continuity-check interval 1s

Enables the transmission of continuity check messages (CCMs)

Step 8

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 9

ethernet evc evc-name

Example:

Device(config)# ethernet evc evc100

Enables Ethernet Virtual Circuit (EVC).

Step 10

pseudowire-class pw-class-name

Example:

Device(config-evc)# pseudowire-class vlan-xconnect

Specifies the name of a Layer 2 pseudowire class and enter pseudowire class configuration mode.

Step 11

encapsulation mpls

Example:

Device(config-pw)# encapsulation mpls

Specifies an encapsulation type for tunneling Layer 2 traffic over a pseudowire

Step 12

exit

Example:

Device (config-ecfm-srv)# exit

Exits Ethernet CFM configuration mode and returns to global configuration mode.

Step 13

interface type number

Example:

Device(config)# interface port-channel 10

Specifies an interface and enters interface configuration mode.

Step 14

service instance id ethernet evc-id

Example:

Device(config-if)# service instance 100 ethernet evc100

Specifies an Ethernet service instance on an interface and enters service instance configuration mode.

Step 15

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to map 802.1Q frames on an ingress interface to the appropriate service instance.

Step 16

rewrite ingress tag pop 1 symmetric

Example:

Device(config-if-srv)#  rewrite ingress tag pop 1 symmetric

Specifies the encapsulation adjustment to be performed on a frame ingressing a service instance.

Step 17

xconnect peer-ip-addressvc-id pw-class pw-class-name

Example:

Device(config-if-srv)#  xconnect 10.1.1.1 100 pw-class vlan-xconnect

Specifies the encapsulation adjustment to be performed on a frame ingressing a service instance.

Step 18

cfm mep domain domain-name mpid mpid-value

Example:

Device(config-if-srv)# cfm mep domain CUSTOMER mpid 1111

Configures a MEP for a domain.

Step 19

exit

Example:

Device(config-if-srv)# exit

Exits service instance configuration mode and enters global configuration mode.
Note:
The configuration for Provider Edge Device 1 (PE1) ends here. Perform the next steps for PE2 configuration.

Step 20

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 21

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables Ethernet connectivity fault management (CFM) globally on a device.

Step 22

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain CUSTOMER level 7

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 23

service csi-id evc evc-name

Example:

Device(config-ether-cfm)# service customer100 evc evc100

Sets a universally unique ID for a customer service instance (CSI) within a maintenance domain.

Step 24

continuity-check [inteval ime]

Example:

Device(config-ether-cfm)# continuity-check interval 1s

Enables the transmission of continuity check messages (CCMs)

Step 25

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 26

ethernet evc evc-name

Example:

Device(config)# ethernet evc evc_100

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 27

pseudowire-class pw-class-name

Example:

Device(config-evc)# pseudowire-class vlan-xconnect

Specifies the name of a Layer 2 pseudowire class and enter pseudowire class configuration mode.

Step 28

encapsulation mpls

Example:

Device(config-pw)# encapsulation mpls

Specifies an encapsulation type for tunneling Layer 2 traffic over a pseudowire

Step 29

exit

Example:

Device (config-ecfm-srv)# exit

Exits Ethernet CFM configuration mode and returns to global configuration mode.

Step 30

interface type number

Example:

Device(config)# interface GigabitEthernet0/0/1

Specifies an interface and enters interface configuration mode.

Step 31

service instance id ethernet evc-id

Example:

Device(config-if)# service instance 100 ethernet evc100

Specifies an Ethernet service instance on an interface and enters service instance configuration mode.

Step 32

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to map 802.1Q frames on an ingress interface to the appropriate service instance.

Step 33

rewrite ingress tag pop 1 symmetric

Example:

Device(config-if-srv)#  rewrite ingress tag pop 1 symmetric

Specifies the encapsulation adjustment to be performed on a frame ingressing a service instance.

Step 34

xconnect peer-ip-addressvc-id pw-class pw-class-name

Example:

Device(config-if-srv)#  xconnect 10.1.1.2 100 pw-class vlan-xconnect

Specifies the encapsulation adjustment to be performed on a frame ingressing a service instance.

Step 35

cfm mep domain domain-name mpid mpid-value

Example:

Device(config-if-srv)# cfm mep domain CUSTOMER mpid 2222

Configures a MEP for a domain.

Configuring UP MEP over Port Channel in VPLS

Perform this task to configure up Maintenance End Point (MEP) over port channel in VPLS. This task shows configurations for Provider Edge (PE)1 and PE2 devices.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm ieee

4.    ethernet cfm global

5.    ethernet cfm domain domain-name level level-id

6.    service csi-id evc evc-name

7.    continuity-check [inteval time]

8.    exit

9.    ethernet evc evc-name

10.    exit

11.    l2vpn vfi context name

12.    vpn id vpn-id

13.    evc evc-name

14.    member ip-address encapsulation mpls

15.    exit

16.    interface type number

17.    service instance id ethernet evc-id

18.    encapsulation dot1q vlan-id

19.    rewrite ingress tag pop 1 symmetric

20.    cfm mep domain domain-name mpid mpid-value

21.    exit

22.    bridge-domain bridge-id

23.    member interface-type-number service-instance service-id

24.    member interface-type-number

25.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 4

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables Ethernet connectivity fault management (CFM) globally on a device.

Step 5

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain CUSTOMER level 7

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 6

service csi-id evc evc-name

Example:

Device(config-ether-cfm)# service customer100 evc evc100

Sets a universally unique ID for a customer service instance (CSI) within a maintenance domain.

Step 7

continuity-check [inteval time]

Example:

Device(config-ether-cfm)# continuity-check interval 1s

Enables the transmission of continuity check messages (CCMs)

Step 8

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 9

ethernet evc evc-name

Example:

Device(config)# ethernet evc evc100

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 10

exit

Example:

Device(config-evc)# exit

Returns to global configuration mode.

Step 11

l2vpn vfi context name

Example:

Device(config)# l2vpn vfi context vpls1

Establishes a Layer 2 VPN (L2VPN) virtual forwarding interface (VFI) between two or more separate networks and enters VFI configuration mode.

Step 12

vpn id vpn-id

Example:

Device(config-vfi)# vpn id 1

Updates a VPN ID on a Virtual Private LAN Services (VPLS) instance.

Step 13

evc evc-name

Example:

Device(config-vfi)# evc evc100

Configures an EVC on a VPLS instance.

Step 14

member ip-address encapsulation mpls

Example:

Device(config-vfi)# member 10.1.1.1 encapsulation mpls

Specifies the devices that form a point-to-point Layer 2 VPN (L2VPN) virtual forwarding interface (VFI) connection.

Step 15

exit

Example:

Device (config-vfi)# exit

Exits VFI configuration mode and returns to global configuration mode.

Step 16

interface type number

Example:

Device(config)# interface port-channel 10

Specifies an interface and enters interface configuration mode.

Step 17

service instance id ethernet evc-id

Example:

Device(config-if)# service instance 100 ethernet evc100

Specifies an Ethernet service instance on an interface and enters service instance configuration mode.

Step 18

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to map 802.1Q frames on an ingress interface to the appropriate service instance.

Step 19

rewrite ingress tag pop 1 symmetric

Example:

Device(config-if-srv)#  rewrite ingress tag pop 1 symmetric

Specifies the encapsulation adjustment to be performed on a frame ingressing a service instance.

Step 20

cfm mep domain domain-name mpid mpid-value

Example:

Device(config-if-srv)# cfm mep domain CUSTOMER mpid 1001

Configures a MEP for a domain.

Step 21

exit

Example:

Device (config-if-srv)# exit

Exits service instance configuration mode and returns to global configuration mode.

Step 22

bridge-domain bridge-id

Example:

Device(config)# bridge-domain 100

Configures the components on a bridge domain and enters bridge-domain configuration mode.

Step 23

member interface-type-number service-instance service-id

Example:

Device(config-bdomain)# member port-channel 10 service-instance 100

Binds a service instance to a bridge domain instance.

Step 24

member interface-type-number

Example:

Device(config-bdomain)# member vfi vpls1

Binds a service instance to a bridge domain instance.

Step 25

exit

Example:

Device (config-bdomain)# exit

Exits bridge domain configuration mode and returns to global configuration mode.

Configuring Down MEP over Port Channel

Perform this task to configure down MEP over port channel.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm ieee

4.    ethernet cfm global

5.    ethernet cfm domain domain-name level level-id

6.    service csi-id evc evc-name s vlan vlan-id direction down

7.    continuity-check [inteval time]

8.    exit

9.    ethernet evc evc-name

10.    exit

11.    interface type number

12.    service instance id ethernet evc-id

13.    encapsulation dot1q vlan-id

14.    bridge-domain bridge-id

15.    cfm mep domain domain-name mpid mpid-value

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 4

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables Ethernet connectivity fault management (CFM) globally on a device.

Step 5

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain CUSTOMER level 7

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 6

service csi-id evc evc-name s vlan vlan-id direction down

Example:

Device(config-ether-cfm)# service customer_100 evc evc_100 vlan 100 direction down

Configures a maintenance association within a maintenance domain and enter Ethernet connectivity fault management (CFM) service configuration mode.

Step 7

continuity-check [inteval time]

Example:

Device(config-ether-cfm)# continuity-check interval 1s

Enables the transmission of continuity check messages (CCMs)

Step 8

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 9

ethernet evc evc-name

Example:

Device(config)# ethernet evc evc_100

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 10

exit

Example:

Device (config-ecfm-srv)# exit

Exits Ethernet CFM configuration mode and returns to global configuration mode.

Step 11

interface type number

Example:

Device(config)# interface port-channel10

Specifies an interface and enters interface configuration mode.

Step 12

service instance id ethernet evc-id

Example:

Device(config-if)# service instance 100 ethernet evc_100

Specifies an Ethernet service instance on an interface and enters service instance configuration mode.

Step 13

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to map 802.1Q frames on an ingress interface to the appropriate service instance.

Step 14

bridge-domain bridge-id

Example:

Device(config-if-srv)#  bridge domain 100

Configures the components on a bridge domain.

Step 15

cfm mep domain domain-name mpid mpid-value

Example:

Device(config-if-srv)# cfm mep domain CUSTOMER mpid 2222

Configures a MEP for a domain.

Configuring CFM Offload

Perform this task to configure Connectivity Fault Management (CFM) offload.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm ieee

4.    ethernet cfm global

5.    ethernet cfm domain domain-name level level-id

6.    service csi-id evc evc-name

7.    continuity-check [inteval time]

8.    offload sampling sample

9.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the Ethernet Connectivity Fault Management 802.1ag Standard (CFM IEEE) version of CFM.

Step 4

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables Ethernet connectivity fault management (CFM) globally on a device.

Step 5

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain CUSTOMER level 7

Defines a CFM maintenance domain at a particular level and enters Ethernet CFM configuration mode.

Step 6

service csi-id evc evc-name

Example:

Device(config-ether-cfm)# service customer100 evc evc100

Sets a universally unique ID for a customer service instance (CSI) within a maintenance domain.

Step 7

continuity-check [inteval time]

Example:

Device(config-ether-cfm)# continuity-check interval 3.3s

Enables the transmission of continuity check messages (CCMs)

Step 8

offload sampling sample

Example:

Device(config-ether-cfm)# offload sampling 1000

Configured offload sampling.

Step 9

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Troubleshooting Tips

To verify and isolate a fault, start at the highest level maintenance domain and do the following:

- Check the device error status.

- When an error exists, perform a loopback test to confirm the error.

- Run a traceroute to the destination to isolate the fault.

- If the fault is identified, correct the fault.

- If the fault is not identified, go to the next lower maintenance domain and repeat these four steps at that maintenance domain level.

- Repeat the first four steps, as needed, to identify and correct the fault.

Configuring Ethernet OAM Interaction with CFM

For Ethernet OAM to function with CFM, you must configure an EVC and the OAM manager and associate the EVC with CFM. Additionally, you must use an inward facing MEP when you want interaction with the OAM manager.

- Configuring the OAM Manager

- Enabling Ethernet OAM

Configuring the OAM Manager

Note

If you configure, change, or remove a UNI service type, EVC, Ethernet service instance, or CE-VLAN configuration, all configurations are checked to ensure that UNI service types are matched with EVC configurations and Ethernet service instances are matched with CE-VLAN configurations. Configurations are rejected if the pairings do not match.

Perform this task to configure the OAM manager on a PE device.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id [direction outward]

4.    service csi-id vlan vlan-id

5.    exit

6.    ethernet evc evc-id

7.    oam protocol {cfm svlan svlan-id domain domain-name | ldp}

8.    exit

9.    Repeat Steps 3 through 8 to define other CFM domains that you want OAM manager to monitor.

10.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain cstmr1 level 3

Defines a CFM domain, sets the domain level, and enters Ethernet CFM configuration mode.

Step 4

service csi-id vlan vlan-id

Example:

Device(config-ether-cfm)# service csi2 vlan 10

Defines a universally unique customer service instance (CSI) and VLAN ID within the maintenance domain.

Step 5

exit

Example:

Device(config-ether-cfm)# exit

Returns to global configuration mode.

Step 6

ethernet evc evc-id

Example:

Device(config)# ethernet evc 50

Defines an EVC and enters EVC configuration mode.

Step 7

oam protocol {cfm svlan svlan-id domain domain-name | ldp}

Example:

Device(config-evc)# oam protocol cfm svlan 10 domain cstmr1

Configures the EVC OAM protocol.

Step 8

exit

Example:

Device(config-evc)# exit

Returns to global configuration mode.

Step 9

Repeat Steps 3 through 8 to define other CFM domains that you want OAM manager to monitor.

—

Step 10

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Enabling Ethernet OAM

The order in which the global and interface configuration commands are issued determines the configuration. The last command that is issued has precedence.

Perform this task to enable Ethernet OAM on a device or on an interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Specifies an interface and enters interface configuration mode.

Step 4

ethernet oam [max-rate oampdus | min-rate num-seconds| mode {active | passive} | timeout seconds]

Example:

Device(config-if)# ethernet oam max-rate 50

Enables Ethernet OAM on an interface.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuration Examples for Configuring Ethernet CFM in a Service Provider Network

- Example: Provisioning a Network

- Example: Provisioning Service

Example: Provisioning a Network

This configuration example shows only CFM-related commands. All commands that are required to set up the data path and configure the VLANs on the device are not shown. However, it should be noted that CFM traffic will not flow into or out of the device if the VLANs are not properly configured.

CE-A
!
ethernet cfm domain Customer level 7
!!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!!
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

U-PE A
!
ethernet cfm domain Customer level 7
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 1
!
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up
PE-AGG A
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
!
ethernet cfm global
!

ethernet cfm mip level 1
!

ethernet cfm mip level 1
N-PE A
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 1
!
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up
U-PE B
!
ethernet cfm domain Customer level 7
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 2
!
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up
PE-AGG B
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
!
ethernet cfm global
!

ethernet cfm mip level 2
!

ethernet cfm mip level 2
N-PE B
!
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 2
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up
CE-B
!
ethernet cfm domain Customer level 7
!!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!!
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

Example: Provisioning Service

This configuration example shows only CFM-related commands. All commands that are required to set up the data path and configure the VLANs on the device are not shown. However, it should be noted that CFM traffic will not flow into or out of the device if the VLANs are not properly configured.

CE-A
!
ethernet cfm domain Customer level 7
service Customer1 evc evc1 vlan 100

!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mep level 7 direction outward domain Customer1 mpid 701 vlan 100
!
ethernet cfm cc enable level 7 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
U-PE A
!
ethernet cfm domain Customer level 7
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
service MetroCustomer10pA evc evc1 vlan 100
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
service MetroCustomer10pA evc evc1 vlan 100
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 7
ethernet cfm mep level 4 mpid 401 vlan 100
ethernet cfm mep level 1 mpid 101 vlan 100
!

ethernet cfm mip level 1
!
ethernet cfm cc enable level 4 vlan 100
ethernet cfm cc enable level 1 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
PE-AGG A
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
service MetroCustomer10pA evc evc1 vlan 100
!
ethernet cfm global
!

ethernet cfm mip level 1
!

ethernet cfm mip level 1
N-PE A
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
service MetroCustomer1 evc evc1 vlan 100
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
service MetroCustomer10pA evc evc1 vlan 100
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 1
!

ethernet cfm mip level 4
ethernet cfm mep level 1 mpid 102 vlan 100
!
ethernet cfm cc enable level 1 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
U-PE B
!
ethernet cfm domain Customer level 7
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
service MetroCustomer1 evc evc1 vlan 100
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
service MetroCustomer10pB evc evc1 vlan 100
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 7
ethernet cfm mep level 4 mpid 402 vlan 100
ethernet cfm mep level 2 mpid 201 vlan 100
!

ethernet cfm mip level 2
!
ethernet cfm cc enable level 4 vlan 100
ethernet cfm cc enable level 2 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
PE-AGG B
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
service MetroCustomer10pB evc evc1 vlan 100
!
ethernet cfm global
!

ethernet cfm mip level 2
!

ethernet cfm mip level 2
N-PE B
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
service MetroCustomer1 evc evc1 vlan 100
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
service MetroCustomer10pB evc evc1 vlan 100
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mip level 2
!

ethernet cfm mip level 4
ethernet cfm mep level 2 mpid 202 vlan 100
!
ethernet cfm cc enable level 2 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3
CE-B
!
ethernet cfm domain Customer level 7
service Customer1 vlan 100
!
ethernet cfm global
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!

ethernet cfm mep level 7 direction outward domain Customer1 mpid 702 vlan 100
!
ethernet cfm cc enable level 7 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3

Glossary

CCM—continuity check message. A multicast CFM frame that a MEP transmits periodically to ensure continuity across the maintenance entities to which the transmitting MEP belongs, at the MA level on which the CCM is sent. No reply is sent in response to receiving a CCM.

EVC—Ethernet virtual connection. An association of two or more user-network interfaces.

fault alarm—An out-of-band signal, typically an SNMP notification, that notifies a system administrator of a connectivity failure.

inward-facing MEP—A MEP that resides in a bridge and transmits to and receives CFM messages from the direction of the bridge relay entity.

maintenance domain—The network or part of the network belonging to a single administration for which faults in connectivity are to be managed. The boundary of a maintenance domain is defined by a set of DSAPs, each of which may become a point of connectivity to a service instance.

maintenance domain name—The unique identifier of a domain that CFM is to protect against accidental concatenation of service instances.

MEP—maintenance endpoint. An actively managed CFM entity associated with a specific DSAP of a service instance, which can generate and receive CFM frames and track any responses. It is an endpoint of a single MA, and terminates a separate maintenance entity for each of the other MEPs in the same MA.

MEP CCDB—A database, maintained by every MEP, that maintains received information about other MEPs in the maintenance domain.

MIP—maintenance intermediate point. A CFM entity, associated with a specific pair of ISS SAPs or EISS Service Access Points, which reacts and responds to CFM frames. It is associated with a single maintenance association and is an intermediate point within one or more maintenance entities.

MIP CCDB—A database of information about the MEPs in the maintenance domain. The MIP CCDB can be maintained by a MIP.

MP—maintenance point. Either a MEP or a MIP.

MPID—maintenance endpoint identifier. A small integer, unique over a given MA, that identifies a specific MEP.

OAM—operations, administration, and maintenance. A term used by several standards bodies to describe protocols and procedures for operating, administrating, and maintaining networks. Examples are ATM OAM and IEEE Std. 802.3ah OAM.

operator—Entity that provides a service provider a single network of provider bridges or a single Layer 2 or Layer 3 backbone network. An operator may be identical to or a part of the same organization as the service provider. For purposes of IEEE P802.1ag, Draft Standard for Local and Metropolitan Area Networks, the operator and service provider are presumed to be separate organizations.

Terms such as “customer,” “service provider,” and “operator” reflect common business relationships among organizations and individuals that use equipment implemented in accordance with IEEE P802.1ag.

UNI—user-network interface. A common term for the connection point between an operator's bridge and customer equipment. A UNI often includes a C-VLAN-aware bridge component. The term UNI is used broadly in the IEEE P802.1ag standard when the purpose for various features of CFM are explained. UNI has no normative meaning.

Chapter 3. CFM CCM Extensions to Support the NSN Microwave 1+1 Hot Standby Protocol

The Nokia Siemens Networks (NSN) Microwave 1+1 Hot Standby (HSBY) protocol is a link-protection protocol that extends connectivity fault management (CFM) continuity check messages (CCMs) to enable 1:1 link redundancy in microwave devices. NSN Microwave 1+1 HSBY provides link-protection support for both indoor units (IDUs) and outdoor units (ODUs).

This document describes the extensions to the IEEE 802.1ag CFM component in Cisco IOS software that enable the detection and handling of microwave outdoor unit hardware failures.

- Finding Feature Information

- Restrictions for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- Information About CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- How to Configure CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- Configuration Examples for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- Additional References for CFM CCM Extensions to Support the NSN Microwave 1+1 Hot Standby Protocol

- Feature Information for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Restrictions for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- NSN Hot Standby supports only the ES+, ES20, and 6700 series line cards on the Cisco 7600 series router.

- To enable link-protection on a maintenance endpoint (MEP), the connectivity fault management (CFM) domain and MEP must adhere to the Nokia Siemens Networks (NSN) configuration requirements.

Information About CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- NSN Microwave 1+1 HSBY and CFM Integration

- Microwave 1+1 HSBY Configuration

NSN Microwave 1+1 HSBY and CFM Integration

- CFM Continuity Check Messages

- Monitoring Devices and Suspending CFM Traffic

- NSN Microwave 1+1 HSBY Protocol Monitoring of Maintenance Associations

CFM Continuity Check Messages

CFM CCMs are heartbeat messages exchanged periodically between maintenance association endpoints (MEPs). CCMs allow MEPs to discover each other within a maintenance association, and allow maintenance association intermediate points (MIPs) to discover MEPs. CCMs provide a means for detecting connectivity failures in a maintenance domain. CCMs are transmitted frequently enough so that consecutive messages can be lost without causing the information to time out in any of the receiving MEPs.

For detailed information about CFM, MEPs, MIPs, and maintenance associations, see "Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network".

Monitoring Devices and Suspending CFM Traffic

The NSN Microwave 1+1 HSBY Protocol has specified a proprietary time-to-live (TLV) field in CCMs for monitoring active and standby ODUs, and a flag to temporarily suspend CCM monitoring. Identified by an Organizational Unique Identifier (OUI) value of 0x000FBB, the TLV is attached to CCMs as an organization-specific TLV.

An IDU or an ODU may need to temporarily halt transmitting traffic, including CCMs, in circumstances such as a software upgrade or a reload. An IDU or ODUs can set the Suspend CC Monitor flag to signal a temporary pause in CFM traffic if a suspension is needed. Using this flag prevents the other two devices from triggering an unnecessary link-protection action. The Suspend CC Monitor time interval field, in conjunction with the flag, indicates the maximum amount of time the two devices must wait before expecting CCMs to resume from the suspended device.

NSN Microwave 1+1 HSBY Protocol Monitoring of Maintenance Associations

The NSN Microwave 1+1 HSBY protocol monitors three maintenance associations. One maintenance association is at Ethernet CFM level 4 and is called the ODU-to-ODU CCM (P-CCM) session, and two maintenance associations are at Ethernet CFM level 0 and are called the IDU-to-ODU CCM (E-CCM) sessions. The IDU is associated with only the two E-CCM sessions and has an outward-facing MEP configured in each session. The IDU is required to pass CFM traffic between the ODUs only in the P-CCM session; no additional monitoring of this maintenance association is needed.

The HSBY configuration shown in the figure below supports four separate traffic flows:

- CFM traffic between the IDU and ODU 1.

- CFM traffic between the IDU and ODU 2.

- CFM traffic between ODU 1 and ODU 2. This traffic passes through the IDU.

- Data traffic between the WAN and ODU 1. This traffic passes through the IDU.

HSBY Protocol and CFM Maintenance Associations

Microwave 1+1 HSBY Configuration

The NSN Microwave 1+1 HSBY link-protection function within the scope of CFM CCM extensions is provided through configuration of a single IDU connected to two ODUs for redundancy. The Cisco IOS device acts as the IDU. At a given time only one ODU is actively handling data traffic, but both the active and standby ODUs are processing and transmitting CFM traffic. The CFM traffic is composed of CCMs with NSN proprietary TLV fields that extend the CCMs’ detection of connectivity failures to IDUs and ODUs. Additionally, these extended CCMs passed between the IDU and ODUs are used to indicate which ODU is active and handling the data traffic. If a failure occurs, the standby ODU assumes the role of the active ODU. The figure below shows a sample physical topology.

HSBY Link Protection Physical Topology

- IDU Configuration Values

- ODU Configuration Values

IDU Configuration Values

The HSBY Protocol specifies that some IDU parameters are configurable and others are fixed values. The table below summarizes the permitted values for an IDU using the HSBY Protocol.

Note

The same maintenance association (MA) VLAN ID (MA VLAN-ID) can be used for all MAs configured on an IDU.

HSBY IDU Configuration Parameters

Parameter

Default Value

Permitted Values

CC Interval

100 milliseconds (ms)

10ms, 100ms, and 1000ms

Domain Level

0

Fixed

Domain Name

Null

Fixed

MA VLAN-ID (E-CCM)

None

1-15

MPID

1

Fixed

Short MA Name

None

0-65535

Suspend Interval

160 seconds

80s, 160s, 240s, and 320s

ODU Configuration Values

The HSBY Protocol specifies that some ODU parameters are configurable and others are fixed values. The table below summarizes the permitted values for an ODU using the HSBY Protocol.

Note

By default, an ODU learns the short MA name when it receives the first E-CCM from an IDU.

HSBY ODU Configuration Parameters

Parameter

Default Value

Permitted Values

MA VLAN-ID (E-CCM)

None

16-50

MPID

2

Fixed

Short MA Name

Learned

0-65535

How to Configure CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- Configuring NSN Microwave 1+1 HSBY Protocol and CFM CCM Extensions

Configuring NSN Microwave 1+1 HSBY Protocol and CFM CCM Extensions

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm global

4.    link-protection enable

5.    link-protection group management vlan vlan-id

6.    link-protection group group-number pccm vlan vlan-id

7.    ethernet cfm domain domain-name level level-id [direction outward]

8.    id {mac-address domain-number | dns dns-name | null}

9.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

10.    mep mpid mpid

11.    mep mpid mpid

12.    continuity-check [interval time | loss-threshold threshold | static rmep]

13.    exit

14.    exit

15.    ethernet cfm domain domain-name level level-id [direction outward]

16.    id {mac-address domain-number | dns dns-name | null}

17.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

18.    mep mpid mpid

19.    mep mpid mpid

20.    continuity-check [interval time | loss-threshold threshold | static rmep]

21.    exit

22.    exit

23.    interface type slot / port

24.    switchport mode {access | dot1q-tunnel| dynamic {auto | desirable} | private-vlan | trunk}

25.    spanning-tree portfast {disable | trunk}

26.    ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

27.    link-protection group group-number

28.    exit

29.    interface type slot / port

30.    switchport mode {access | dot1q-tunnel| dynamic {auto | desirable} | private-vlan | trunk}

31.    spanning-tree portfast {disable | trunk}

32.    ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

33.    link-protection group group-number

34.    end

35.    show ethernet cfm maintenance-points remote detail

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm global

Example:

Router(config)# ethernet cfm global

Enables Ethernet CFM globally.

Step 4

link-protection enable

Example:

Router(config)# link-protection enable

Enables link protection globally on the router.

Step 5

link-protection group management vlan vlan-id

Example:

Router(config)# link-protection group management vlan 51

Defines the management VLAN used for link protection.

- The Cisco 7600 series router supports 12 link-protection groups per router.

Step 6

link-protection group group-number pccm vlan vlan-id

Example:

Router(config)# link-protection group 2 pccm vlan 16

Specifies an ODU-to-ODU continuity check message (P-CCM) VLAN.

Step 7

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Router(config)# ethernet cfm domain eccm1 level 0

Configures the CFM domain for ODU 1 and enters Ethernet CFM configuration mode.

Step 8

id {mac-address domain-number | dns dns-name | null}

Example:

Router(config-ecfm)# id null

Configures a maintenance domain identifier (MDID).

Step 9

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Router(config-ecfm)# service 1 vlan 14 direction down

Defines a maintenance association for ODU 1 and enters Ethernet CFM service instance configuration mode.

Step 10

mep mpid mpid

Example:

Router(config-ecfm-srv)# mep mpid 1

Defines the local MEP ID.

Step 11

mep mpid mpid

Example:

Router(config-ecfm-srv)# mep mpid 2

Defines the remote MEP ID.

Step 12

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Router(config-ecfm-srv)# continuity-check interval 100ms

Enables transmission of continuity check messages (CCMs) within the ODU 1 maintenance association and defines a continuity-check interval.

Step 13

exit

Example:

Router(config-ecfm-srv)# exit

Exits Ethernet CFM service instance configuration mode.

Step 14

exit

Example:

Router(config-ecfm)# exit

Exits Ethernet CFM configuration mode.

Step 15

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Router(config)# ethernet cfm domain eccm2 level 0

Configures the CFM domain for ODU 2 and enters CFM configuration mode.

Step 16

id {mac-address domain-number | dns dns-name | null}

Example:

Router(config-ecfm)# id null

Configures a maintenance domain identifier (MDID).

Step 17

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Router(config-ecfm)# service 2 vlan 15 direction down

Defines a maintenance association for ODU 2 and enters Ethernet CFM service configuration mode.

Step 18

mep mpid mpid

Example:

Router(config-ecfm-srv)# mep mpid 1

Defines the local MEP ID.

Step 19

mep mpid mpid

Example:

Router(config-ecfm-srv)# mep mpid 2

Defines the remote MEP ID.

Step 20

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Router(config-ecfm-srv)# continuity-check interval 100ms

Enables transmission of CCMs within the ODU 2 maintenance association and defines a continuity-check interval.

Step 21

exit

Example:

Router(config-ecfm-srv)# exit

Exits Ethernet CFM service instance configuration mode.

Step 22

exit

Example:

Router(config-ecfm)# exit

Exits Ethernet CFM configuration mode.

Step 23

interface type slot / port

Example:

Router(config)# interface gigabitethernet 1/1

Configures the interface to be connected to ODU 1 and enters interface configuration mode.

Step 24

switchport mode {access | dot1q-tunnel| dynamic {auto | desirable} | private-vlan | trunk}

Example:

Router(config-if)# switchport mode trunk

Sets the switching characteristics of the Layer 2-switched interface.

Step 25

spanning-tree portfast {disable | trunk}

Example:

Router(config-if)# spanning-tree portfast trunk

Enables PortFast on the interface when it is in trunk mode.

Step 26

ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

Example:

Router(config-if)# ethernet cfm mep domain eccm1 mpid 1 vlan 14

Configures a CFM MEP domain for ODU 1.

Step 27

link-protection group group-number

Example:

Router(config-if)# link-protection group 1

Configures a link-protection group for ODU 2.

Step 28

exit

Example:

Router(config-if)# exit

Exits interface configuration mode.

Step 29

interface type slot / port

Example:

Router(config)# interface GigabitEthernet 3/2

Configures the interface to be connected to ODU 2 and enters interface configuration mode.

Step 30

switchport mode {access | dot1q-tunnel| dynamic {auto | desirable} | private-vlan | trunk}

Example:

Router(config-if)# switchport mode trunk

Sets the switching characteristics of the Layer 2-switched interface.

Step 31

spanning-tree portfast {disable | trunk}

Example:

Router(config-if)# spanning-tree portfast trunk

Enables PortFast on the interface when it is in trunk mode.

Step 32

ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

Example:

Router(config-if)# ethernet cfm mep domain eccm2 mpid 1 vlan 15

Configures a CFM MEP domain for ODU 2.

Step 33

link-protection group group-number

Example:

Router(config-if)# link-protection group 1

Configures a link-protection group for ODU 2.

Step 34

end

Example:

Router(config-if)# end

Returns the CLI to privileged EXEC mode.

Step 35

show ethernet cfm maintenance-points remote detail

Example:

Router# show ethernet cfm maintenance-points remote detail

(Optional) Displays remote maintenance endpoints in the continuity check database.

Configuration Examples for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

- CFM Domain and MEP Configuration

- Example 1+1 HSBY Protocol Configuration

CFM Domain and MEP Configuration

This example is a sample CFM domain and MEP configuration that follows the NSN requirements for monitoring ODUs. The link-protection command for configuring NSN-specific parameters is included. CFM configuration parameters for an IDU are shown within angle brackets (<>):

link-protection suspend-interval <80s, 160s, 240s, 320s>
link-protection management vlan <51-4094>
link-protection pccm vlan <16-50>
!
ethernet cfm ieee
ethernet cfm global
!
ethernet cfm domain <Domain for ODU1> level 0
id null
service number <number> vlan <1-15> direction down
continuity-check
continuity-check interval <10, 100, 1000ms>
!
ethernet cfm domain <Domain for ODU2> level 0
id null
service number <number> vlan <1-15> direction down
continuity-check
continuity-check interval <10, 100, 1000ms>
!
interface GigabitEthernet 0/3
ethernet cfm mep domain <Domain for ODU1> mpid 1 vlan <1-15>
link-protection group <group #>
!
interface GigabitEthernet 0/4
ethernet cfm mep domain <Domain for ODU2> mpid 1 vlan <1-15>
link-protection group <group #>
!

Example 1+1 HSBY Protocol Configuration

The following example shows a 1+1 HSBY protocol configuration on the Cisco 7600 series router:

Router> enable
Router# configure terminal
Router(config)# ethernet cfm global
Router(config)# link-protection enable
Router(config)# link-protection group management vlan 51
Router(config)# link-protection group 2 pccm vlan 16
Router(config)# ethernet cfm domain eccm1 level 0
Router(config-ecfm)# id null
Router(config-ecfm)# service 1 vlan 14 direction down
Router(config-ecfm-srv)# mep mpid 1
Router(config-ecfm-srv)# mep mpid 2
Router(config-ecfm-srv)# continuity-check interval 100ms
Router(config-ecfm-srv)# exit
Router(config-ecfm)# exit
Router(config)# ethernet cfm domain eccm2 level 0
Router(config-ecfm)# id null
Router(config-ecfm)# service 2 vlan 15 direction down
Router(config-ecfm-srv)# mep mpid 1
Router(config-ecfm-srv)# mep mpid 2
Router(config-ecfm-srv)# continuity-check interval 100ms
Router(config-ecfm-srv)# exit
Router(config-ecfm)# exit
Router(config)# interface gigabitethernet 1/1
Router(config-if)# switchport mode trunk
Router(config-if)# spanning-tree portfast trunk
Router(config-if)# ethernet cfm mep domain eccm1 mpid 1 vlan 14
Router(config-if)# link-protection group 1
Router(config-if)# exit
Router(config)# interface GigabitEthernet 3/2
Router(config-if)# switchport mode trunk
Router(config-if)# spanning-tree portfast trunk
Router(config-if)# ethernet cfm mep domain eccm2 mpid 1 vlan 15
Router(config-if)# link-protection group 1
Router(config-if)# end
Router# show ethernet cfm maintenance-points remote detail

Additional References for CFM CCM Extensions to Support the NSN Microwave 1+1 Hot Standby Protocol

Related Documents

Related Topic

Document Title

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Commands List, All Releases

Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Configuring IEEE Standard-Compliant Ethernet CFM

"Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network"

Configurations for Carrier Ethernet networks

Carrier Ethernet Configuration Guide, Cisco IOS Release 15.1S

Understanding and configuring Microwave 1+1 HSBY on the Cisco MWR 2941 Mobile Wireless Edge Router

“Configuring Ethernet Link Operations, Administration, and Maintenance” chapter of the Cisco MWR 2941 Mobile Wireless Edge Router Software Configuration Guide, Release 15.0(1)MR

Standards

Standard

Title

IEEE 802.1ag

Connectivity Fault Management

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

RFCs

RFC

Title

None

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

Feature Information for CFM CCM Extensions to Support the NSN Microwave 1+1 HSBY Protocol

Feature Name

Releases

Feature Information

CFM Extension for 1+1 Hot-Standby Support

Cisco IOS XE Release 3.9S

The NSN Microwave 1+1 HSBY protocol is a link-protection protocol that extends CFM CCMs to enable 1:1 link redundancy in microwave devices. NSN Microwave 1+1 HSBY provides link-protection support for both IDUs and ODUs.

In Cisco IOS XE Release 3.9S, support was added for the Cisco ASR 903 Router.

The following command was introduced or modified: show ethernet cfm maintenance-points remote detail.

Chapter 4. Configuring Ethernet CFM for the Cisco ASR 1000 Router

IEEE Connectivity Fault Management (CFM) is an end-to-end per-service Ethernet layer Operations, Administration, and Maintenance (OAM) protocol. CFM includes proactive connectivity monitoring, fault verification, and fault isolation for large Ethernet metropolitan-area networks (MANs) and WANs.

This document describes the implementation of IEEE 802.1ag Standard-Compliant CFM (IEEE CFM) and Y.1731 in Cisco IOS XE software for the Cisco ASR 1000 Series Aggregation Services Router. Y.1731 is an ITU-T recommendation for OAM functions in Ethernet-based networks. IEEE CFM and Y.1731 together will be called “Ethernet CFM” throughout this document.

- Finding Feature Information

- Prerequisites for Configuring Ethernet CFM for the Cisco ASR 1000 Router

- Restrictions for Configuring Ethernet CFM for the Cisco ASR 1000 Router

- Information About Configuring Ethernet CFM for the Cisco ASR 1000 Router

- How to Configure Ethernet CFM for the Cisco ASR 1000 Router

- Configuration Examples for Configuring Ethernet CFM for the Cisco ASR 1000 Router

- Additional References

- Feature Information for Configuring Ethernet CFM for the Cisco ASR 1000 Router

- Glossary

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Configuring Ethernet CFM for the Cisco ASR 1000 Router

- The network topology and network administration have been evaluated.

- Business and service policies have been established.

- EVC associated with CFM domain must be configured with the L2VFI interface command

- Before configuring CFM over L2VFI ensure EVC and Bridge Domain are configured.

- Bridge-domain under L2VFI must be configured prior to configuring CFM MEP

Restrictions for Configuring Ethernet CFM for the Cisco ASR 1000 Router

- Ethernet CFM on the Cisco ASR 1000 Series Aggregation Services Router is not compatible with prestandard CFM.

- Locked Signal (ETH-LCK) and Test Signal (ETH-Test) are not supported.

- Link Trace (ETH-LTM/ETH-LTR) over L2VFI is not supported.

- Configuring MIP/MEP under L2VFI is not supported.

- For Connectivity Performance Management functionalities, only single-ended delay (ETH-DM) is supported.

Information About Configuring Ethernet CFM for the Cisco ASR 1000 Router

- Ethernet CFM

- Maintenance Associations

- Maintenance Domains

- Maintenance Points

- Ethernet CFM Messages

- Cross-Check Function

- SNMP Traps

- HA Feature Support in Ethernet CFM

Ethernet CFM

IEEE CFM is an end-to-end per-service Ethernet layer OAM protocol that includes proactive connectivity monitoring, fault verification, and fault isolation. End to end can be provider edge to provider edge (PE to PE) or customer edge to customer edge (CE to CE).

Ethernet CFM is distinct from other metro-Ethernet OAM protocols by being an end-to-end technology. For example, Multiprotocol Label Switching (MPLS), ATM, and SONET OAM help in debugging Ethernet wires but are not always end to end. 802.3ah OAM is a single-hop and per-physical-wire protocol. It is not end to end or service aware. Ethernet Local Management Interface (E-LMI) is confined between the user-end provider edge (uPE) and CE and relies on CFM for reporting status of the metro-Ethernet network to the CE.

The benefits of Ethernet CFM are:

- End-to-end service-level OAM technology

- Reduced operating expense for service provider Ethernet networks

- Competitive advantage for service providers

- Benefits of Ethernet CFM

Benefits of Ethernet CFM

- End-to-end service-level OAM technology

- Reduced operating expense for service provider Ethernet networks

- Competitive advantage for service providers

Maintenance Associations

An MA identifies a service that can be uniquely identified within a maintenance domain. There can be many MAs within a domain. The MA direction is specified when the MA is configured. The short MA name must be configured on a domain before MEPs can be configured.

The CFM protocol runs for a specific MA.

Maintenance Domains

A maintenance domain is 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 ports internal to it and at its boundary. The figure below illustrates a typical maintenance domain.

A Typical Maintenance Domain

A unique maintenance level in the range of 0 to 7 is assigned to each domain by a network administrator. Levels and domain names are useful for defining the hierarchical relationship among domains. The hierarchical relationship of domains parallels that of customer, service provider, and operator. The larger the domain, the higher the level value. For example, a customer domain would be larger than an operator domain. The customer domain may have a maintenance level of 7 and the operator domain may have a maintenance level of 0. Typically, operators would have the smallest domains and customers the largest domains, with service provider domains between them in size. All levels of the hierarchy must operate together.

Domains should not intersect because intersecting would mean management by more than one entity, which is not allowed. Domains may nest or touch but when two domains nest, the outer domain must have a higher maintenance level than the domain nested within it. Nesting maintenance domains is useful in the business model where a service provider contracts with one or more operators to provide Ethernet service to a customer. Each operator would have its own maintenance domain and the service provider would define its domain--a superset of the operator domains. Furthermore, the customer has its own end-to-end domain, which is in turn a superset of the service provider domain. Maintenance levels of various nesting domains should be communicated among the administering organizations. For example, one management approach would be to have the service provider assign maintenance levels to operators.

Ethernet CFM exchanges messages and performs operations on a per-domain basis. For example, running CFM at the operator level does not allow discovery of the network by the higher provider and customer levels.

Network designers determine domain configurations.

The following characteristics of domains are supported:

- Name is a maximum of 154 characters in length.

- Direction is specified when the MA is configured.

- Down (toward the wire) MEPs.

A domain can be removed when all maintenance points within the domain have been removed and all remote MEP entries in the continuity check database (CCDB) for the domain have been purged.

The figure below illustrates service provider and customer domains and where the Cisco ASR 1000 router is in the network.

Service Provider and Customer Domains

Maintenance Points

A maintenance point (MIP) is a demarcation point on an interface or port that participates in Connectivity Fault Management (CFM) within a maintenance domain. Maintenance points on device ports act as filters that confine CFM frames within the bounds of a domain by dropping frames that do not belong to the correct level. Maintenance points must be explicitly configured on Cisco devices. Two classes of maintenance points exist, maintenance end points (MEPs) and MIPs. Support for MIPs varies by Cisco release.

- Maintenance Association Endpoints

Maintenance Association Endpoints

Maintenance association endpoints (MEPs) reside at the edge of a maintenance domain and confine Ethernet Connectivity Fault Management (CFM) messages within the domain via the maintenance domain level. MEPs periodically transmit and receive continuity check messages (CCMs) from other MEPs within the domain. At the request of an administrator, linktrace and loopback messages can also be transmitted. MEPs are either “Up” (toward the bridge) or “Down” (toward the wire). Support for Up MEPs varies by Cisco release.

When the continuity-check static rmep command is configured on a port MEP and continuity checking does not detect a removed MEP, the port is set to MAC operation down and the interface protocol is set to down. Normal traffic is stopped because the line protocol is down, but CFM packets still pass.

MEP configurations can be removed after all pending loopback and traceroute replies are removed and the service on the interface is set to transparent mode.

Down MEPs for Routed Ports

Down MEPs communicate through the wire.

Down MEPs use the port MAC address.

A Down MEP performs the following functions:

- Sends and receives Ethernet CFM frames at its level via the wire connected to the port where the MEP is configured.

- Processes all Ethernet CFM frames at its level coming from the direction of the wire.

- Drops all Ethernet CFM frames at a lower level coming from the direction of the wire.

- Transparently drops all Ethernet CFM frames at a higher level, independent of whether they came in from the bridge or wire.

Ethernet CFM Messages

Ethernet CFM uses standard Ethernet frames. Ethernet CFM frames are distinguishable by EtherType and for multicast messages by MAC address. Ethernet CFM frames are sourced, terminated, processed, and relayed by bridges. Routers can support only limited Ethernet CFM functions.

Bridges that cannot interpret Ethernet CFM messages forward them as normal data frames. All Ethernet CFM messages are confined to a maintenance domain and to an MA. Three types of messages are supported:

- Continuity Check

- Linktrace

- Loopback

Continuity Check Messages

Ethernet CFM continuity check messages (CCMs) are multicast heartbeat messages exchanged periodically among MEPs. They allow MEPs to discover other MEPs within a domain. CCMs are confined to a domain.

CFM CCMs have the following characteristics:

- Transmitted at a periodic interval by MEPs. The minimum interval is milliseconds (ms).

- Terminated by remote MEPs at the same maintenance level.

- Unidirectional and do not solicit a response.

- Indicate the status of the interface on which the MEP is configured.

Linktrace Messages

Ethernet CFM linktrace messages (LTMs) are multicast frames that a MEP transmits, at the request of an administrator, to track the path (hop-by-hop) to a destination MEP. They are similar to Layer 3 traceroute messages. LTMs allow the transmitting node to discover vital connectivity data about the path. LTMs are intercepted by maintenance points along the path and processed, transmitted, or dropped. At each hop where there is a maintenance point at the same level, a linktrace message reply (LTR) is transmitted back to the originating MEP. For each visible MIP, linktrace messages indicate ingress action, relay action, and egress action.

Linktrace messages include the destination MAC address, VLAN, and maintenance domain and they have Time To Live (TTL) to limit propagation within the network. They can be generated on demand using the CLI. LTMs are multicast and LTRs are unicast.

Loopback Messages

Ethernet CFM loopback messages (LBMs) are unicast frames that a MEP transmits, at the request of an administrator, to verify connectivity to a particular maintenance point. A reply to a loopback message (LBR) indicates whether a destination is reachable but does not allow hop-by-hop discovery of the path. A loopback message is similar in concept to an Internet Control Message Protocol (ICMP) Echo (ping) message.

Because LBMs are unicast, they are forwarded like normal data frames except with the maintenance level restriction. If the outgoing port is known in the bridge’s forwarding database and allows Ethernet CFM frames at the message’s maintenance level to pass through, the frame is sent out on that port. If the outgoing port is unknown, the message is broadcast on all ports in that domain.

An Ethernet CFM LBM can be generated on demand using the CLI. The source of a loopback message must be a MEP. Both Ethernet CFM LBMs and LBRs are unicast, and LBMs specify the destination MAC address or MEP identifier (MPID), VLAN, and maintenance domain.

Cross-Check Function

The cross-check function is a timer-driven postprovisioning service verification between dynamically discovered MEPs (via continuity check messages CCMs)) and expected MEPs (via configuration) for a service. The cross-check function verifies that all endpoints of a multipoint or point-to-point service are operational. The function supports notifications when the service is operational; otherwise it provides alarms and notifications for unexpected or missing endpoints.

The cross-check function is performed one time. You must initiate the cross-check function from the CLI every time you want a service verification.

SNMP Traps

The support provided by the Cisco IOS XE software implementation of Ethernet CFM traps is Cisco proprietary information. MEPs generate two types of Simple Network Management Protocol (SNMP) traps, continuity check (CC) traps and cross-check traps.

CC Traps

- MEP up--Sent when a new MEP is discovered, the status of a remote port changes, or connectivity from a previously discovered MEP is restored after interruption.

- MEP down--Sent when a timeout or last gasp event occurs.

- Cross-connect--Sent when a service ID does not match the VLAN.

- Loop--Sent when a MEP receives its own CCMs.

- Configuration error--Sent when a MEP receives a continuity check with an overlapping MPID.

Cross-Check Traps

- Service up--Sent when all expected remote MEPs are up in time.

- MEP missing--Sent when an expected MEP is down.

- Unknown MEP--Sent when a CCM is received from an unexpected MEP.

HA Feature Support in Ethernet CFM

In access and service provider networks using Ethernet technology, High availability (HA) is a requirement. End-to-end connectivity status information is critical and must be maintained on a hot standby Route Processor (RP).

Note

A hot standby RP has the same software image as the active RP and supports synchronization of line card, protocol, and application state information between RPs for supported features and protocols.

End-to-end connectivity status is maintained on the CE, PE, and access aggregation PE (uPE) network nodes based on information received by protocols such as Ethernet local management interface (LMI) and CFM, and 802.3ah. This status information is used to either stop traffic or switch to backup paths when an interface is down.

Every transaction involves either accessing or updating data among various databases. If the database is synchronized across active and standby modules, the modules are transparent to clients.

The Cisco infrastructure provides various component application program interfaces (APIs) that help to maintain a hot standby RP. Metro Ethernet HA clients CFM HA and in-service software upgrades (ISSU) interact with these components, update the database, and trigger necessary events to other components.

Benefits of CFM HA

- Elimination of network downtime for Cisco software image upgrades, allowing for faster upgrades that result in high availability.

- Elimination of resource scheduling challenges associated with planned outages and late night maintenance windows.

- Accelerated deployment of new services and applications and facilitation of faster implementation of new features, hardware, and fixes than if HA was not supported.

- Reduced operating costs due to outages while delivering high service levels.

- CFM updates its databases and controls its own HA messaging and versioning, and this control facilitates maintenance.

- NSF SSO Support in Ethernet CFM

- ISSU Support in Ethernet CFM

NSF SSO Support in Ethernet CFM

The redundancy configurations SSO and NSF are both supported in Ethernet CFM and are automatically enabled. A switchover from an active to a standby RP occurs when the active RP fails, is removed from the networking device, or is manually taken down for maintenance. NSF interoperates with the SSO feature to minimize network downtime following a switchover. The primary function of Cisco NSF is to continue forwarding packets following an RP switchover.

For detailed information about SSO, see the “Stateful Switchover” module of the Cisco IOS High Availability Configuration Guide. For detailed information about the NSF feature, see the “Cisco Nonstop Forwarding” module of the High Availability Configuration Guide.

ISSU Support in Ethernet CFM

In Service Upgrades (ISSU) allows you to perform a Cisco software upgrade or downgrade without disrupting packet flow. Ethernet Connectivity Fault Management (CFM) performs a bulk update and a runtime update of the continuity check database to the standby route processor (RP), including adding, deleting, or updating a row. This checkpoint data requires ISSU capability to transform messages from one release to another. All the components that perform active RP to standby RP updates using messages require ISSU support.

ISSU is automatically enabled in Ethernet CFM and lowers the impact that planned maintenance activities have on network availability by allowing software changes while the system is in service. For detailed information about ISSU, see the “Cisco IOS In Service Software Upgrade Process” module of the High Availability Configuration Guide.

How to Configure Ethernet CFM for the Cisco ASR 1000 Router

- Designing CFM Domains

- Configuring Ethernet CFM

Designing CFM Domains

Note

To have an operator, service provider, or customer domain is optional. A network may have a single domain or multiple domains. The steps listed here show the sequence when all three types of domains will be assigned.

Before You Begin

- Knowledge and understanding of the network topology.

- Understanding of organizational entities involved in managing the network; for example, operators, service providers, network operations centers (NOCs), and customer service centers.

- Understanding of the type and scale of services to be offered.

- Agreement by all organizational entities on the responsibilities, roles, and restrictions for each organizational entity.

- Determination of the number of maintenance domains in the network.

- Determination of the nesting and disjoint maintenance domains.

- Assignment of maintenance levels and names to domains based on agreement between the service provider and operator or operators.

- Determination of whether the domain should be inward or outward.

SUMMARY STEPS

1.    Determine operator level MIPs.

2.    Determine operator level MEPs.

3.    Determine service provider MIPs.

4.    Determine service provider MEPs.

5.    Determine customer MIPs.

6.    Determine customer MEPs.

DETAILED STEPS

Command or Action

Purpose

Step 1

Determine operator level MIPs.

Follow these steps:

- Starting at lowest operator level domain, assign a MIP at every interface internal to the operator network to be visible to CFM.

- Proceed to next higher operator level and assign MIPs.

- Verify that every port that has a MIP at a lower level does not have maintenance points at a higher level.

- Repeat steps a through d until all operator MIPs are determined.

Step 2

Determine operator level MEPs.

Follow these steps:

- Starting at the lowest operator level domain, assign a MEP at every UNI that is part of a service instance.

- Assign a MEP at the network to network interface (NNI) between operators, if there is more than one operator.

- Proceed to next higher operator level and assign MEPs.

- A port with a MIP at a lower level cannot have maintenance points at a higher level. A port with a MEP at a lower level should have either a MIP or MEP at a higher level.

Step 3

Determine service provider MIPs.

Follow these steps:

- Starting at the lowest service provider level domain, assign service provider MIPs at the NNI between operators (if more than one).

- Proceed to next higher service provider level and assign MIPs.

- A port with a MIP at a lower level cannot have maintenance points at a higher level. A port with a MEP at a lower level should not have either a MIP or a MEP at a higher level.

Step 4

Determine service provider MEPs.

Follow these steps:

- Starting at the lowest service provider level domain, assign a MEP at every UNI that is part of a service instance.

- Proceed to next higher service provider level and assign MEPs.

- A port with a MIP at a lower level cannot have maintenance points at a higher level. A port with a MEP at a lower level should have either a MIP or a MEP at a higher level.

Step 5

Determine customer MIPs.

Customer MIPs are allowed only on the UNIs at the uPEs if the service provider allows the customer to run CFM. Otherwise, the service provider can configure Cisco devices to block CFM frames.

- Configure a MIP on every uPE, at the UNI port, in the customer maintenance domain.

- Ensure the MIPs are at a maintenance level that is at least one higher than the highest level service provider domain.

Step 6

Determine customer MEPs.

Customer MEPs are on customer equipment. Assign an outward facing MEP within an outward domain at the appropriate customer level at the handoff between the service provider and the customer.

- Examples

Examples

The figure below shows an example of a network with a service provider and two operators, A and B. Three domains are to be established to map to each operator and the service provider. In this example, for simplicity we assume that the network uses Ethernet transport end to end. CFM, however, can be used with other transports.

Configuring Ethernet CFM

- Provisioning the Network (CE-A)

- Provisioning the Network (CE-B)

- Provisioning Service (CE-A)

- Provisioning Service (CE-B)

- Configuring and Enabling the Cross-Check Function (CE-A)

- Configuring and Enabling the Cross-Check Function (CE-B)

Provisioning the Network (CE-A)

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    mep archive-hold-time minutes

5.    exit

6.    ethernet cfm global

7.    ethernet cfm ieee

8.    ethernet cfm traceroute cache

9.    ethernet cfm traceroute cache size entries

10.    ethernet cfm traceroute cache hold-time minutes

11.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

12.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown] [mep-missing] [service-up]

13.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 5

exit

Example:

Device(config-ecfm)# exit

Returns the device to global configuration mode.

Step 6

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 7

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the CFM IEEE version of CFM.

- This command is automatically issued when the ethernet cfm global command is issued.

Step 8

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 9

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 10

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 11

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM continuity check events.

Step 12

snmp-server enable traps ethernet cfm crosscheck [mep-unknown] [mep-missing] [service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown

Enables SNMP trap generation for Ethernet CFM continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 13

end

Example:

Device(config)# end

Returns the device to privileged EXEC mode.

Provisioning the Network (CE-B)

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id [direction outward]

4.    mep archive-hold-time minutes

5.    exit

6.    ethernet cfm global

7.    ethernet cfm ieee

8.    ethernet cfm traceroute cache

9.    ethernet cfm traceroute cache size entries

10.    ethernet cfm traceroute cache hold-time minutes

11.    snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

12.    snmp-server enable traps ethernet cfm crosscheck [mep-unknown] [mep-missing] [service-up]

13.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain Customer level 7 direction outward

Defines an outward CFM maintenance domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 5

exit

Example:

Device(config-ecfm)# exit

Example:

Returns the device to global configuration mode.

Step 6

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 7

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the CFM IEEE version of CFM.

- This command is automatically issued when the ethernet cfm global command is issued.

Step 8

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 9

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 10

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 11

snmp-server enable traps ethernet cfm cc [mep-up] [mep-down] [config] [loop] [cross-connect]

Example:

Device(config)# snmp-server enable traps ethernet cfm cc mep-up mep-down config loop cross-connect

Enables SNMP trap generation for Ethernet CFM mep-up, mep-down, config, loop, and cross-connect events.

Step 12

snmp-server enable traps ethernet cfm crosscheck [mep-unknown] [mep-missing] [service-up]

Example:

Device(config)# snmp-server enable traps ethernet cfm crosscheck mep-unknown

Enables SNMP trap generation for Ethernet CFM mep-unknown, mep-missing, and service-up continuity check events in relation to the cross-check operation between statically configured MEPs and those learned via CCMs.

Step 13

end

Example:

Device(config)# end

Example:

Returns the device to privileged EXEC mode.

Provisioning Service (CE-A)

Perform this task to set up service for Ethernet CFM. Optionally, when this task is completed, you may configure and enable the cross-check function. To perform this optional task, see "Configuring and Enabling the Cross-Check Function (CE-A)".

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

5.    continuity-check [interval time | loss-threshold threshold | static rmep]

6.    continuity-check [interval time | loss-threshold threshold | static rmep]

7.    continuity-check [interval time | loss-threshold threshold | static rmep]

8.    exit

9.    mep archive-hold-time minutes

10.    exit

11.    ethernet cfm global

12.    ethernet cfm ieee

13.    ethernet cfm traceroute cache

14.    ethernet cfm traceroute cache size entries

15.    ethernet cfm traceroute cache hold-time minutes

16.    interface type number

17.    ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

18.    ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

19.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Router(config)# ethernet cfm domain Customer level 7

Defines a CFM maintenance domain at a specified maintenance level and enters Ethernet CFM configuration mode.

Step 4

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Router(config-ecfm)# service Customer1 vlan 101 direction down

Configures an MA within a maintenance domain and enters CFM service configuration mode.

- If a service is already configured and you configure a new MA name and also specify the direction down keyword, a second service is added that maps to the same VLAN. If you configure a new MA name and do not specify the direction down keyword, the service is renamed to the new MA name.

Step 5

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Router(config-ecfm-srv)# continuity-check

Enables the transmission of CCMs.

Step 6

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Router(config-ecfm-srv)# continuity-check interval 10s

Configures the time period between CCM transmissions.

- The values supported are platform dependent.

Step 7

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Router(config-ecfm-srv)# continuity-check loss-threshold 10

Sets the number of CCMs that should be missed before declaring that a remote MEP is down.

Step 8

exit

Example:

Router(config-ecfm-srv)# exit

Example:

Returns the device to Ethernet CFM configuration mode.

Step 9

mep archive-hold-time minutes

Example:

Router(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 10

exit

Example:

Router(config-ecfm)# exit

Returns the device to global configuration mode.

Step 11

ethernet cfm global

Example:

Router(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 12

ethernet cfm ieee

Example:

Router(config)# ethernet cfm ieee

Enables the CFM IEEE version of CFM.

- This command is automatically issued when the ethernet cfm global command is issued.

Step 13

ethernet cfm traceroute cache

Example:

Router(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 14

ethernet cfm traceroute cache size entries

Example:

Router(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 15

ethernet cfm traceroute cache hold-time minutes

Example:

Router(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 16

interface type number

Example:

Router(config)# interface ethernet 0/3

Specifies an interface and enters interface configuration mode.

Step 17

ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

Example:

Router(config-if)# ethernet cfm mep domain Customer mpid 701 vlan 100

Sets a port as internal to a maintenance domain and defines it as a MEP.

Step 18

ethernet cfm mep domain domain-name mpid mpid {port | vlan vlan-id}

Example:

Router(config-if)# ethernet cfm mep domain Customer mpid 701 vlan 100

Sets a port as internal to a maintenance domain and defines it as a MEP.

Step 19

end

Example:

Router(config-if)# end

Returns the device to privileged EXEC mode.

Provisioning Service (CE-B)

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id [direction outward]

4.    mep archive-hold-time minutes

5.    continuity-check [interval time | loss-threshold threshold | static rmep]

6.    continuity-check [interval time | loss-threshold threshold | static rmep]

7.    continuity-check [interval time | loss-threshold threshold | static rmep]

8.    exit

9.    exit

10.    ethernet cfm global

11.    ethernet cfm ieee

12.    ethernet cfm traceroute cache

13.    ethernet cfm traceroute cache size entries

14.    ethernet cfm traceroute cache hold-time minutes

15.    interface slot/subslot/port

16.    ethernet cfm mep level level-id [inward | outward domain domain-name] mpid id vlan {any | vlan-id | , vlan-id | vlan-id - vlan-id | , vlan-id - vlan-id}

17.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain Customer level 7 direction outward

Defines a CFM maintenance domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

mep archive-hold-time minutes

Example:

Device(config-ecfm)# mep archive-hold-time 60

Sets the amount of time that data from a missing MEP is kept in the continuity check database or that entries are held in the error database before they are purged.

Step 5

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Device(config-ecfm-srv)# continuity-check

Enables the transmission of CCMs.

Step 6

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Device(config-ecfm-srv)# continuity-check interval 10s

Configures the time period between CCM transmissions.

- The values supported are platform dependent.

Step 7

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Device(config-ecfm-srv)# continuity-check loss-threshold 10

Sets the number of CCMs that should be missed before declaring that a remote MEP is down.

Step 8

exit

Example:

Device(config-ecfm-srv)# exit

Returns the device to Ethernet CFM configuration mode.

Step 9

exit

Example:

Device(config-ecfm)# exit

Returns the device to global configuration mode.

Step 10

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables CFM processing globally on the device.

Step 11

ethernet cfm ieee

Example:

Device(config)# ethernet cfm ieee

Enables the CFM IEEE version of CFM.

- This command is automatically issued when the ethernet cfm global command is issued.

Step 12

ethernet cfm traceroute cache

Example:

Device(config)# ethernet cfm traceroute cache

Enables caching of CFM data learned through traceroute messages.

Step 13

ethernet cfm traceroute cache size entries

Example:

Device(config)# ethernet cfm traceroute cache size 200

Sets the maximum size for the CFM traceroute cache table.

Step 14

ethernet cfm traceroute cache hold-time minutes

Example:

Device(config)# ethernet cfm traceroute cache hold-time 60

Sets the amount of time that CFM traceroute cache entries are retained.

Step 15

interface slot/subslot/port

Example:

Specifies an interface and enters interface configuration mode.

Step 16

ethernet cfm mep level level-id [inward | outward domain domain-name] mpid id vlan {any | vlan-id | , vlan-id | vlan-id - vlan-id | , vlan-id - vlan-id}

Example:

Device(config-if)# ethernet cfm mep level 7 outward domain Customer mpid 701 vlan 100

Provisions an interface as a domain boundary.

Step 17

end

Example:

Device(config-if)# end

Example:

Device#

Returns the device to privileged EXEC mode.

Configuring and Enabling the Cross-Check Function (CE-A)

Perform this task to configure and enable cross-checking for a down MEP. This task requires you to configure and enable cross-checking on two devices. This task is optional.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    mep mpid mpid

6.    exit

7.    ethernet cfm mep crosscheck start-delay delay

8.    exit

9.    ethernet cfm mep crosscheck {enable | disable} domain domain-name {port | vlan {vlan-id | vlan-id - vlan-id | , vlan-id - vlan-id}}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines a CFM domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

mep mpid mpid

Example:

Device(config-ecfm)# mep mpid 702

Statically defines the MEPs within a maintenance association.

Step 6

exit

Example:

Device(config-ecfm)# exit

Returns the device to global configuration mode.

Step 7

ethernet cfm mep crosscheck start-delay delay

Example:

Device(config)# ethernet cfm mep crosscheck start-delay 60

Configures the maximum amount of time that the device waits for remote MEPs to come up before the cross-check operation is started.

Step 8

exit

Example:

Device(config)# exit

Returns the device to privileged EXEC mode.

Step 9

ethernet cfm mep crosscheck {enable | disable} domain domain-name {port | vlan {vlan-id | vlan-id - vlan-id | , vlan-id - vlan-id}}

Example:

Device# ethernet cfm mep crosscheck enable domain cust4 vlan 100

Enables cross-checking between the list of configured remote MEPs of a domain and MEPs learned through CCMs.

Configuring and Enabling the Cross-Check Function (CE-B)

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service short-ma-name evc evc-name vlan vlanid direction down

5.    mep mpid mpid

6.    exit

7.    ethernet cfm mep crosscheck start-delay delay

8.    exit

9.    ethernet cfm mep crosscheck {enable | disable} domain domain-name {port | vlan {vlan-id | vlan-id - vlan-id | , vlan-id - vlan-id}}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain Customer level 7

Defines an outward CFM domain at a specified level and enters Ethernet CFM configuration mode.

Step 4

service short-ma-name evc evc-name vlan vlanid direction down

Example:

Device(config-ecfm)# service s41 evc 41 vlan 41 direction down

Configures a maintenance association within a maintenance domain and enters Ethernet connectivity fault management (CFM) service configuration mode.

Step 5

mep mpid mpid

Example:

Device(config-ecfm)# mep mpid 702

Statically defines the MEPs within a maintenance association.

Step 6

exit

Example:

Device(config-ecfm)# exit

Returns the device to global configuration mode.

Step 7

ethernet cfm mep crosscheck start-delay delay

Example:

Device(config)# ethernet cfm mep crosscheck start-delay 60

Configures the maximum amount of time that the device waits for remote MEPs to come up before the cross-check operation is started.

Step 8

exit

Example:

Device(config)# exit

Returns the device to privileged EXEC mode.

Step 9

ethernet cfm mep crosscheck {enable | disable} domain domain-name {port | vlan {vlan-id | vlan-id - vlan-id | , vlan-id - vlan-id}}

Example:

Device# ethernet cfm mep crosscheck enable domain cust4 vlan 100

Enables cross-checking between the list of configured remote MEPs of a domain and MEPs learned through CCMs.

Configuration Examples for Configuring Ethernet CFM for the Cisco ASR 1000 Router

The following two examples show configurations for a network. Configurations are shown not only for the Carrier Ethernet Cisco ASR 1000 Series Aggregation Services Routers, but also for the devices used at the access and core of the service provider’s network.

- Example: Provisioning a Network

- Example: Provisioning Service

Example: Provisioning a Network

This configuration example shows only CFM-related commands. All commands that are required to set up the data path and configure the VLANs on the device are not shown. However, it should be noted that CFM traffic will not flow into or out of the device if the VLANs are not properly configured.

CE-A Configuration

!
ethernet cfm global
ethernet cfm ieee
!
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm mip auto-create level 7 vlan 1-4094
!
interface
ethernet cfm mip level 7 vlan 101   <<<< Manual MIP
ethernet cfm mep domain ServiceProvider-L4 mpid 401 vlan 101
ethernet cfm mep domain OperatorA-L1 mpid 101 vlan 101
!
interface
ethernet cfm mip level 1 vlan 101   <<<< Manual MIP
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

U-PE A Configuration

!
ethernet cfm global
ethernet cfm ieee
!
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm mip auto-create level 7 vlan 1-4094
!
interface
ethernet cfm mip level 7 vlan 101   <<<< Manual MIP
ethernet cfm mep domain ServiceProvider-L4 mpid 401 vlan 101
ethernet cfm mep domain OperatorA-L1 mpid 101 vlan 101
!
interface
ethernet cfm mip level 1 vlan 101   <<<< Manual MIP
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

PE-AGG A Configuration

ethernet cfm global
ethernet cfm ieee
ethernet cfm domain OperatorA-L1 level 1
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpA vlan 101
!
interface
ethernet cfm mip level 1 vlan 101   <<<< Manual MIP
!
interface
ethernet cfm mip level 1    <<<< Manual MIP

N-PE A Configuration

!
ethernet cfm global
ethernet cfm ieee
!
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain ServiceProvider-L4 level 4
mep archive-hold-time 60
mip auto-create
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpA vlan 101
continuity-check
!
interface
ethernet cfm mip level 1         <<<< manual MIP
!
interface
ethernet cfm mip level 4    <<<< manual MIP
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

U-PE B Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain Customer-L7 level 7
mip auto-create
service Customer1 vlan 101 direction down
!
ethernet cfm domain ServiceProvider-L4 level 4
mep archive-hold-time 60
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorB level 2
mip auto-create
mep archive-hold-time 65
service MetroCustomer1OpB vlan 101
continuity-check
!
interface
ethernet cfm mip level 7   <<<< manual MIP
!
interface
ethernet cfm mip level 2   <<<< manual MIP
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

PE-AGG B Configuration

ethernet cfm global
ethernet cfm ieee
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpB vlan 101
!
interface
ethernet cfm mip level 2   <<<< manual MIP
!
interface
ethernet cfm mip level 2   <<<< manual MIP

N-PE B Configuration

!
ethernet cfm global
ethernet cfm ieee
!
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
mip auto-create
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpB vlan 101
continuity-check
!
interface
ethernet cfm mip level 2    <<<< manual MIP
!
interface
ethernet cfm mip level 4   <<<< manual MIP
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

CE-B Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain Customer-L7 level 7
service Customer1 vlan 101 direction down
continuity-check
!
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up

Example: Provisioning Service

CE-A Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain Customer-L7 level 7
service Customer1 vlan 101 direction down
continuity-check
!
interface
ethernet cfm mep domain Customer-L7 mpid 701 vlan 101

U-PE A Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm mip auto-create level 7 vlan 1-4094
!
ethernet cfm domain ServiceProvider-L4 level 4
mep archive-hold-time 60
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorA-L1 level 1
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpA vlan 101
continuity-check
!
interface
ethernet cfm mip level 7 vlan 101   <<<< Manual MIP
ethernet cfm mep domain ServiceProvider-L4 mpid 401 vlan 101
ethernet cfm mep domain OperatorA-L1 mpid 101 vlan 101
!
interface
ethernet cfm mip level 1 vlan 101   <<<< Manual MIP

PE-AGG A Configuration

ethernet cfm global
ethernet cfm ieee
ethernet cfm domain OperatorA-L1 level 1
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpA vlan 101
!
interface
ethernet cfm mip level 1 vlan 101   <<<< Manual MIP
!
interface
ethernet cfm mip level 1    <<<< Manual MIP

N-PE A Configuration

!
ethernet cfm global
ethernet cfm ieee
!
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain ServiceProvider-L4 level 4
mep archive-hold-time 60
mip auto-create
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpA vlan 101
continuity-check
!
interface
ethernet cfm mip level 1    <<<< manual MIP
!
interface
ethernet cfm mip level 4    <<<< manual MIP
ethernet cfm mep domain OperatorA mpid 102 vlan 101

U-PE B Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain Customer-L7 level 7
mip auto-create
service Customer1 vlan 101 direction down
!
ethernet cfm domain ServiceProvider-L4 level 4
mep archive-hold-time 60
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
service MetroCustomer1OpB vlan 101
continuity-check
!
interface
ethernet cfm mip level 7   <<<< manual MIP
ethernet cfm mep domain ServiceProvider-L4 mpid 402 vlan 101
ethernet cfm mep domain OperatorB mpid 201 vlan 101
!
interface
ethernet cfm mip level 2   <<<< manual MIP

N-PE B Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
mip auto-create
service MetroCustomer1 vlan 101
continuity-check
!
ethernet cfm domain OperatorB level 2
mep archive-hold-time 65
mip auto-create
service MetroCustomer1OpB vlan 101
continuity-check
!
interface
ethernet cfm mip level 2      <<<< manual MIP
!
interface
ethernet cfm mip level 4     <<<< manual MIP
ethernet cfm mep domain OperatorB mpid 202 vlan 101

CE-B Configuration

!
ethernet cfm global
ethernet cfm ieee
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
ethernet cfm domain Customer-L7 level 7
service Customer1 vlan 101 direction down
continuity-check
!
interface
ethernet cfm mep domain Customer-L7 mpid 702 vlan 101

Additional References

Related Documents

Related Topic

Document Title

CFM commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network

"Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network"

IP SLAs for Metro Ethernet

"IP SLAs for Metro Ethernet"

ISSU feature and functions

"Cisco IOS Broadband High Availability In Service Software Upgrade"

Performing an ISSU

"Cisco IOS In Service Software Upgrade Process and Enhanced Fast Software Upgrade Process"

SSO

“Stateful Switchover” module of the High Availability Configuration Guide

Standards

Standard

Title

IEEE 802.1ag Standard

802.1ag - Connectivity Fault Management

IETF VPLS OAM

L2VPN OAM Requirements and Framework

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

MIBs

MIB

MIBs Link

CISCO-ETHER-CFM-MIB

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

RFCs

RFC

Title

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

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Configuring Ethernet CFM for the Cisco ASR 1000 Router

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Configuring Ethernet CFM for the Cisco ASR 1000 Router

Feature Name

Releases

Feature Information

IEEE 802.1ag-2007 Compliant CFM for ASR1000

Cisco IOS XE Release 3.2S

IEEE CFM is an end-to-end per-service Ethernet layer OAM protocol. CFM includes proactive connectivity monitoring, fault verification, and fault isolation for large Ethernet metropolitan-area networks (MANs) and WANs. Y.1731 is an ITU-T recommendation for OAM functions in Ethernet-based networks.

This feature is the implementation of IEEE 802.1ag Standard-Compliant CFM and Y.1731 in Cisco IOS XE software.

The following commands were introduced or modified: continuity-check, ethernet cfm domain level, ethernet cfm global, ethernet cfm ieee, ethernet cfm mep crosscheck, ethernet cfm mep crosscheck start-delay, ethernet cfm mep domain mpid, ethernet cfm traceroute cache, ethernet cfm traceroute cache hold-time, ethernet cfm traceroute cache size, mep archive-hold-time, mep mpid, service (cfm-srv), snmp-server enable traps ethernet cfm cc, and snmp-server enable traps ethernet cfm crosscheck.

E-OAM : Multiple port MAs under single MD

Cisco IOS XE Release 3.7S

Support for multiple MAs under a single maintenance domain was added.

The following commands were introduced or modified: clear ethernet cfm ais, ethernet cfm lck, ethernet cfm mep crosscheck, ethernet cfm mep domain mpid, ping ethernet, show ethernet cfm maintenance-points remote, show ethernet cfm maintenance-points remote crosscheck, show ethernet cfm maintenance-points remote detail, show ethernet cfm traceroute-cache, traceroute ethernet.

Glossary

CCM—continuity check message. A multicast CFM frame that a MEP transmits periodically to ensure continuity across the maintenance entities to which the transmitting MEP belongs, at the MA level on which the CCM is sent. No reply is sent in response to receiving a CCM.

EVC—Ethernet virtual connection. An association of two or more user-network interfaces.

fault alarm—An out-of-band signal, typically an SNMP notification, that notifies a system administrator of a connectivity failure.

inward-facing MEP—A MEP that resides in a bridge and transmits to and receives CFM messages from the direction of the bridge relay entity.

maintenance domain—The network or part of the network belonging to a single administration for which faults in connectivity are to be managed. The boundary of a maintenance domain is defined by a set of DSAPs, each of which may become a point of connectivity to a service instance.

maintenance domain name—The unique identifier of a domain that CFM is to protect against accidental concatenation of service instances.

MEP—maintenance endpoint. An actively managed CFM entity associated with a specific DSAP of a service instance, which can generate and receive CFM frames and track any responses. It is an endpoint of a single MA, and terminates a separate maintenance entity for each of the other MEPs in the same MA.

MEP CCDB—A database, maintained by every MEP, that maintains received information about other MEPs in the maintenance domain.

MIP—maintenance intermediate point. A CFM entity, associated with a specific pair of ISS SAPs or EISS Service Access Points, which reacts and responds to CFM frames. It is associated with a single maintenance association and is an intermediate point within one or more maintenance entities.

MIP CCDB—A database of information about the MEPs in the maintenance domain. The MIP CCDB can be maintained by a MIP.

MP—maintenance point. Either a MEP or a MIP.

MPID—maintenance endpoint identifier. A small integer, unique over a given MA, that identifies a specific MEP.

OAM—operations, administration, and maintenance. A term used by several standards bodies to describe protocols and procedures for operating, administrating, and maintaining networks. Examples are ATM OAM and IEEE Std. 802.3ah OAM.

operator—Entity that provides a service provider a single network of provider bridges or a single Layer 2 or Layer 3 backbone network. An operator may be identical to or a part of the same organization as the service provider. For purposes of IEEE P802.1ag, Draft Standard for Local and Metropolitan Area Networks, the operator and service provider are presumed to be separate organizations.

Terms such as “customer,” “service provider,” and “operator” reflect common business relationships among organizations and individuals that use equipment implemented in accordance with IEEE P802.1ag.

UNI—user-network interface. A common term for the connection point between an operator's bridge and customer equipment. A UNI often includes a C-VLAN-aware bridge component. The term UNI is used broadly in the IEEE P802.1ag standard when the purpose for various features of CFM are explained. UNI has no normative meaning.

Chapter 5. Configuring Ethernet Virtual Connections on the Cisco ASR 1000 Series Router

Ethernet virtual circuit (EVC) infrastructure is a Layer 2 platform-independent bridging architecture that supports Ethernet services. This document describes the infrastructure and the features it supports on the Cisco ASR 1000 Series Aggregation Services Router.

- Finding Feature Information

- Restrictions for Configuring EVCs on the Cisco ASR 1000 Series Router

- Information About Configuring EVCs on the Cisco ASR 1000 Series Router

- How to Configure EVCs on the Cisco ASR 1000 Series Router

- Configuration Examples for EVCs on the Cisco ASR 1000 Series Router

- Additional References

- Feature Information for Configuring EVCs on the Cisco ASR 1000 Series Router

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Restrictions for Configuring EVCs on the Cisco ASR 1000 Series Router

- Bridge domain configuration is supported only as part of the EVC service instance configuration.

- The following features are not supported:

- Service instance (Ethernet flow point [EFP]) group support

- EVC cross-connect and connect forwarding services

- Ethernet service protection (Ethernet Operations, Administration, and Maintenance [EOAM], connectivity fault management [CFM], Ethernet Local Management Interface [E-LMI]) on EVCs

- IPv6 access control lists (ACLs) are not supported.

Information About Configuring EVCs on the Cisco ASR 1000 Series Router

The following topics are described in this section and provide background information for configuring EVCs on the Cisco ASR 1000 Series Router:

In Cisco IOS XE Release 3.2S and later releases, the following features are supported in the EVC infrastructure:

In Cisco IOS XE Release 3.3S, Layer 3 and Layer 4 protocol support was added. This support is described in the "Layer 3 and Layer 4 ACL Support".

- EVCs

- Service Instances and Associated EFPs

- Encapsulation (Flexible Service Mapping)

- Layer 3 and Layer 4 ACL Support

- Advanced Frame Manipulation

- Egress Frame Filtering

- Bridge Domains

EVCs

An EVC is defined by the Metro-Ethernet Forum (MEF) as an association between two or more user network interfaces that identifies a point-to-point or multipoint-to-multipoint path within the service provider network. An EVC is a conceptual service pipe within the service provider network. A bridge domain is a local broadcast domain that is VLAN-ID-agnostic. An Ethernet flow point (EFP) service instance is a logical interface that connects a bridge domain to a physical port.

An EVC broadcast domain is determined by a bridge domain and the EFPs that are connected to it. You can connect multiple EFPs to the same bridge domain on the same physical interface, and each EFP can have its own matching criteria and rewrite operation. An incoming frame is matched against EFP matching criteria on the interface, learned on the matching EFP, and forwarded to one or more EFPs in the bridge domain. If there are no matching EFPs, the frame is dropped.

You can use EFPs to configure VLAN translation. For example, if there are two EFPs egressing the same interface, each EFP can have a different VLAN rewrite operation, which is more flexible than the traditional switch port VLAN translation model.

Service Instances and Associated EFPs

Configuring a service instance on a Layer 2 port creates a pseudoport or EFP on which you configure EVC features. Each service instance has a unique number per interface, but you can use the same number on different interfaces because service instances on different ports are not related.

An EFP classifies frames from the same physical port to one of the multiple service instances associated with that port, based on user-defined criteria. Each EFP can be associated with different forwarding actions and behavior.

When an EFP is created, the initial state is UP. The state changes to DOWN under the following circumstances:

- The EFP is explicitly shut down by a user.

- The main interface to which the EFP is associated is down or removed.

- If the EFP belongs to a bridge domain, the bridge domain is down.

- The EFP is forced down as an error-prevention measure of certain features.

Use the service instance ethernet interface configuration command to create an EFP on a Layer 2 interface and to enter service instance configuration mode. Service instance configuration mode is used to configure all management and control data plane attributes and parameters that apply to the service instance on a per-interface basis. The service instance number is the EFP identifier.

After the device enters service instance configuration mode, you can configure these options:

- default--Sets a command to its defaults

- description--Adds a service instance-specific description

- encapsulation--Configures Ethernet frame match criteria

- exit--Exits from service instance configuration mode

- no--Negates a command or sets its defaults

- shutdown--Takes the service instance out of service

Encapsulation (Flexible Service Mapping)

Encapsulation defines the matching criteria that map a VLAN, a range of VLANs, class of service (CoS) bits, Ethertype, or a combination of these to a service instance. VLAN tags and CoS can be a single value, a range, or a list. Ethertype can be a single type or a list of types.

Different types of encapsulations are default, dot1ad, dot1q, priority-tagged, and untagged. On the Cisco ASR 1000 Series Router, priority-tagged frames are always single-tagged. Valid Ethertypes (type) are ipv4, ipv6, pppoe-all, pppoe-discovery, and pppoe-session.

Encapsulation classification options also include:

- inner tag CoS

- inner tag VLAN

- outer tag CoS

- outer tag VLAN

- outer tag Ethertype (VLAN type)--VLAN type is always matched. If you do not specify an alternative, the default is 0x8100 for dot1q and 0x88a8 for dot1ad.

- payload Ethertype--Any Ethertype tag after the VLAN tag

When you configure an encapsulation method, you enable flexible service mapping, which allows you to map an incoming packet to an EFP based on the configured encapsulation.

The default behavior for flexible service mapping based on outer 802.1q and 802.1ad VLAN tag values is nonexact, meaning that when the EFP encapsulation configuration does not explicitly specify an inner (second) VLAN tag matching criterion, the software maps both single-tagged and double-tagged frames to the EFP as long as the frames fulfill the criteria of outer VLAN tag values. The command-line interface (CLI) does allow you to specify exact mapping with the exact keyword. If this keyword is specified, the EFP is designated as single-tagged-frame-only and double-tagged frames are not classified to that EFP.

Using the CLI encapsulation command in service-instance configuration mode, you can set encapsulation criteria. You must configure one encapsulation command per EFP (service instance). After you have configured an encapsulation method, these commands are available in service instance configuration mode:

- bridge-domain --Configures a bridge domain.

- rewrite --Configures Ethernet rewrite criteria.

The table below shows the supported encapsulation types.

Supported Encapsulation Types

Command

Description

encapsulation dot1q vlan-id [, vlan-id [- vlan-id]]

Defines the matching criteria to be used to map 802.1q frames ingressing on an interface to the appropriate EFP. The options are a single VLAN, a range of VLANs, or lists of VLANs or VLAN ranges. VLAN IDs are 1 to 4094.

- Enter a single VLAN ID for an exact match of the outermost tag.

- Enter a VLAN range for a ranged outermost match.

encapsulation dot1q vlan-id second-dot1q vlan-id [, vlan-id [- vlan-id]]

Double-tagged 802.1q encapsulation. Matching criteria to be used to map QinQ frames ingressing on an interface to the appropriate EFP. The outer tag is unique and the inner tag can be a single VLAN, a range of VLANs or lists of VLANs or VLAN ranges.

- Enter a single VLAN ID in each instance for an exact match of the outermost two tags.

- Enter a VLAN range for second-dot1q for an exact outermost tag and a range for a second tag.

encapsulation dot1q {any | vlan-id [, vlan-id[- vlan-id]]} etype ethertype

Ethertype encapsulation is the payload encapsulation type after VLAN encapsulation.

Ethertype encapsulation matches any or an exact outermost VLAN or VLAN range and a payload ethertype.

Valid values for ethertype are ipv4, ipv6, pppoe-discovery, pppoe-session, or pppoe-all.

encapsulation dot1q vlan-id cos cos-value second-dot1q vlan-id cos cos-value

CoS value encapsulation defines match criteria after including the CoS for the S-Tag and the C-Tag. The CoS value is a single digit between 1 and 7 for S-Tag and C-Tag.

You cannot configure CoS encapsulation with the encapsulation untagged command, but you can configure it with the encapsulation priority-tagged command. The result is an exact outermost VLAN and CoS match and second tag. You can also use VLAN ranges.

encapsulation dot1q any

Matches any packet with one or more VLANs.

encapsulation dot1q vlan-type

Specifies the value of the VLAN protocol type, which is the tag protocol identifier (TPID) of an 802.1q VLAN tag. If there is more than one tag, this command refers to the outermost tag. By default the TPID is assumed to be 0x8100. Use this command to set the TPID to other supported alternatives: 0x88A8, 0x9100, 0x9200.

encapsulation dot1ad

Defines the matching criteria to be used to map 802.1d frames ingressing on an interface to the appropriate EFP.

encapsulation untagged

Matching criteria to be used to map native Ethernet frames (without a dot1q tag) entering an interface to the appropriate EFP.

Only one EFP per port can have untagged encapsulation. However, a port that hosts EFP matching untagged traffic can also host other EFPs that match tagged frames.

encapsulation default

Configures the default EFP on an interface, acting as a catch-all encapsulation for all packets without a configured encapsulation. All packets are seen as native. If you enter the rewrite command with encapsulation default, the command is rejected.

Only one default EFP per interface can be configured. If you try to configure more than one default EFP, the command is rejected.

encapsulation priority-tagged

Specifies priority-tagged frames. A priority-tagged packet has VLAN ID 0 and a CoS value of 0 to 7.

If a packet entering or leaving a port does not match any of the encapsulations on that port, the packet is dropped, resulting in filtering on both ingress and egress. The encapsulation must match the packet on the wire to determine filtering criteria. On the wire refers to packets ingressing the router before any rewrites and to packets egressing the router after all rewrites.

Layer 3 and Layer 4 ACL Support

Beginning in Cisco IOS XE Release 3.3S, support was added for configuring IPv4 Layer 3 and Layer 4 ACLs on EFPs. Configuring an ACL on an EFP is the same as configuring an ACL on other types of interfaces; for example, Ethernet or asynchronous transfer mode (ATM). One exception is that ACLs are not supported for packets prefixed with a Multiprotocol Label Switching (MPLS) header, including when an MPLS packet contains either Layer 3 or Layer 4 headers of supported protocols.

An ACL configured on a main interface containing EFPs does not affect traffic through the EFPs.

To configure an IPv4 Layer 3 and Layer 4 ACL on an EFP, use the ip access-group command. An ACL configuration is shown in the "Configuring an ACL on an EFP".

Advanced Frame Manipulation

The Advanced Frame Manipulation feature allows you to specify the VLAN tag manipulation needed on both the incoming and outgoing frames of an EFP. These manipulations include PUSH, POP, and TRANSLATION of one or both VLAN tags.

The PUSH, POP, and TRANSLATION manipulations are as follows:

- PUSH Operations

- Add one VLAN tag

- Add two VLAN tags

- POP Operations

- Remove the outermost VLAN tag

- Remove the two outermost VLAN tags

- TRANSLATION Operations

- 1:1 VLAN Translation

- 1:2 VLAN Translation

- 2:1 VLAN Translation

- 2:2 VLAN Translation

When a VLAN tag exists and a new one is added, the CoS field of the new tag is set to the same value as the CoS field of the existing VLAN tag; otherwise, the CoS field is set to a default of 0. Using QoS marking configuration commands, you can change the CoS marking.

- EFPs and Layer 2 Protocols

EFPs and Layer 2 Protocols

On the Cisco ASR 1000 Series Router, EFPs treat the protocol data units (PDUs) of Layer 2 protocols as data frames. PDUs are forwarded as data frames.

Layer 2 protocols include Cisco Discovery Protocol, Dynamic Trunking Protocol (DTP), Link Aggregation Control Protocol (LACP), Link Layer Discovery Protocol (LLDP), Multiple Spanning Tree Protocol (MSTP), Port Aggregation Protocol (PAgP), Unidirectional Link Detection (UDLD), and VLAN Trunk Protocol (VTP).

Egress Frame Filtering

Egress frame filtering is performed to ensure that frames exiting an EFP contain a Layer 2 header that matches the encapsulation characteristics associated with the EFP. This filtering is done primarily to prevent unintended frame leaks and is always enabled on EFPs.

Bridge Domains

A bridge domain defines a broadcast domain internal to a platform and allows the decoupling of a broadcast domain from a VLAN. This decoupling enables per-port VLAN significance, thus removing the scalability limitations associated with a single per-device VLAN ID space. You can configure a maximum of 4096 EFPs per bridge domain.

A bridge domain interface (BDI) is used to support frame forwarding in a bridge domain at Layer 3. The BDI is a virtual interface that supports Layer 3 features. Each bridge domain can have only one BDI configuration.

If the destination MAC address in a frame received from one of the EFPs participating in a bridge domain matches the BDI MAC address, the frame is routed; otherwise, the frame is bridged. When the egress interface for a routed packet is the BDI interface, the frame is bridged using the destination MAC address.

Frames with broadcast and well-known multicast MAC addresses are also forwarded to the BDI.

The following sections describe support for bridge domains:

EFP, bridge domain, and BDI support based on the Cisco ASR 1000 Series Router forwarding processors are shown in the table in "EFP Bridge Domain and BDI Support Based on the Cisco ASR 1000 Series Router Forwarding Processors".

- Ethernet MAC Address Learning

- Flooding of Layer 2 Frames for Unknown MAC Multicast and Broadcast Addresses

- Layer 2 Destination MAC Address-Based Forwarding

- MAC Address Aging

- MAC Address Move

- MAC Address Table

- Split Horizon Group

- EFP Bridge Domain and BDI Support Based on the Cisco ASR 1000 Series Router Forwarding Processors

Ethernet MAC Address Learning

MAC address learning is always enabled and cannot be disabled.

Flooding of Layer 2 Frames for Unknown MAC Multicast and Broadcast Addresses

A Layer 2 frame with an unknown unicast or broadcast destination MAC address is flooded to all the EFPs in the bridge domain except to the originating EFP. A frame with a multicast MAC address is flooded to all the EFPs in the bridge domain. If the destination MAC address is a multicast MAC address, the frame is treated like a broadcast frame and sent to all the EFPs in the bridge domain.

When a frame with either a multicast or broadcast MAC address is flooded and a BDI is associated with the bridge domain, the frame is also flooded to the BDI.

Replication of frames involves recycling the frame several times. This recycling may have a negative effect on forwarding performance and reduce the packet forwarding rate for all features.

Layer 2 Destination MAC Address-Based Forwarding

When bridging is configured, a unicast frame received from an EFP is forwarded based on the destination Layer 2 MAC address. If the destination address is known, the frame is forwarded only to the EFP associated with the destination address.

Because bridge and EFP configurations are interrelated, bridging is supported only on EFPs. To support multiple bridge domains, MAC address entries are associated with the bridge domain of the EFP. Only unicast MAC addresses need to be dynamically learned.

EVC infrastructure does not modify frame contents. Each bridge domain can learn 1000 MAC addresses per second. The Layer 2 frame forwarding rate is 8 million packets per second (MPPS) if flooding is not involved.

MAC Address Aging

The dynamically learned MAC address entries in the MAC table are periodically aged out and entries that are inactive for longer than the configured time period are removed from the table. The supported range of aging-time values, in seconds, is 30 to 600 with a granularity of 1. The default is 5 minutes.

The aging-time parameter can be configured per bridge domain and is a relative value. The value is the aging time relative to the time a frame was received with that MAC address.

MAC Address Move

As stations (systems connected to the Cisco ASR 1000 Series Router through the EFP interface) move from one network to another, the interface associated with a MAC address changes.

MAC Address Table

The MAC address table is used to forward frames based on Layer 2 destination MAC addresses. The table consists of static MAC addresses downloaded from the route processor (RP) and the MAC addresses dynamically learned by the data path.

While the MAC Learning feature is enabled, an entry is added to the MAC table when a new unique MAC address is learned on the data path and an entry is deleted from the table when it is aged out.

Split Horizon Group

The split-horizon feature allows service instances in a bridge domain to join groups. Service instances in the same bridge domain and split-horizon group cannot pass data to each other but can forward data to other service instances that are in the same bridge domain and not in the same split-horizon group.

A service instance cannot join more than one split-horizon group. A service instance does not have to be in a split-horizon group. When a service instance does not belong to a group, it can send and receive data from all ports within the bridge domain.

One or more EFPs in a bridge domain may be configured for the same split horizon group, but when a frame is replicated to EFPs, that frame cannot be replicated to EFPs that are within the same split horizon group as the input interface. This restriction applies to MAC address frames that are either known or unknown unicast, broadcast, and multicast frames.

Two split horizon groups per bridge domain are supported on the Cisco ASR 1000 Series Router. You can configure a split horizon group using the bridge-domain CLI command with the split-horizon and group keywords. The group ID can be either 0 or 1.

All members of the bridge-domain that are configured with the same group ID are part of the same split-horizon group. EFPs that are not configured with an explicit group ID do not belong to any group.

EFP Bridge Domain and BDI Support Based on the Cisco ASR 1000 Series Router Forwarding Processors

The table below shows EFP, bridge domain, and BDI support based on the Cisco ASR 1000 Series Router forwarding processors.

EFP, Bridge Domain, and BDI Support on the Cisco ASR 1000 Series Router Forwarding Processors

Description

ASR1000-ESP5, ASR 1001, ASR 1002-F (ESP2.5)

ASR1000-ESP10, ASR1000-ESP10-N, ASR1000-ESP20,

ASR1000-ESP40

Maximum EFPs per router

8192

16384

24576

Maximum EFPs per bridge domain

4000

4000

4000

Maximum EFPs per interface

8000

8000

8000

Maximum bridge domains per router

4096

4096

4096

Maximum BDIs per router

4096

4096

4096

Maximum MAC table entries per router

65536

65536

65536

Maximum MAC table entries per bridge domain

16384

16384

16384

Maximum split horizon groups per bridge domain

2

2

2

How to Configure EVCs on the Cisco ASR 1000 Series Router

- Configuring an EFP and a Bridge Domain on the Cisco ASR 1000 Series Router

- Configuring an ACL on an EFP

Configuring an EFP and a Bridge Domain on the Cisco ASR 1000 Series Router

Configuring a service instance on a Layer 2 port creates an EFP on which you can configure EVC features. Perform this task to configure an EFP.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation encapsulation-type vlan-id

6.    rewrite ingress tag translate 1-to-1 dot1q vlan-id symmetric

7.    bridge-domain bridge-id

8.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Router(config)# interface gigabitethernet 0/1/1

Enters interface configuration mode.

- The example shows how to configure Gigabit Ethernet interface 0/1/1 and enter interface configuration mode.

Step 4

service instance id ethernet

Example:

Router(config-if)# service instance 1 ethernet

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

- The example shows how to configure Ethernet service instance 1.

Step 5

encapsulation encapsulation-type vlan-id

Example:

Router(config-if-srv)# encapsulation dot1q 1

Defines the encapsulation type.

- The example shows how to define dot1q as the encapsulation type.

Step 6

rewrite ingress tag translate 1-to-1 dot1q vlan-id symmetric

Example:

Router(config-if-srv)# rewrite ingress tag translate 1-to-1 dot1q 1 symmetric

(Optional) Specifies the encapsulation adjustment to be performed on a frame ingressing a service instance.

- The example shows how to specify translating a single tag defined by the encapsulation command to a single tag defined in the rewrite ingress tag command with reciprocal adjustment to be done in the egress direction.

Step 7

bridge-domain bridge-id

Example:

Router(config-if-srv)# bridge-domain 1

Configures the bridge domain.

- The example shows how to configure bridge domain 1.

Step 8

end

Example:

Router(config-if-srv)# end

Returns to privileged EXEC mode.

Configuring an ACL on an EFP

Perform this task to configure an ACL on an EFP.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ip access-group access-list-number | access-list-name} {in | out}

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Router(config)# interface gigabitethernet 0/1/1

Enters interface configuration mode.

- The example shows how to configure Gigabit Ethernet interface 0/1/1 and enter interface configuration mode.

Step 4

ip access-group access-list-number | access-list-name} {in | out}

Example:

Router(config-if)# ip access-group acl55 in

Applies an IP access list or object group access control list (OGACL) to an interface or a service policy map.

- The example shows how to configure an ACL named acl55 for inbound packets.

Step 5

end

Example:

Router(config-if)# end

Returns to privileged EXEC mode.

Configuration Examples for EVCs on the Cisco ASR 1000 Series Router

- Example Configuring EFPs on a Gigabit Ethernet Interface

Example Configuring EFPs on a Gigabit Ethernet Interface

interface GigabitEthernet0/0/1
no ip address
negotiation auto
service instance 1 ethernet
encapsulation dot1q 201
rewrite ingress tag translate 1-to-1 dot1q 300 symmetric
bridge-domain 1
!
service instance 2 ethernet
encapsulation default
bridge-domain 1
!
service instance 3 ethernet
encapsulation priority-tagged
bridge-domain 2
!

Additional References

Related Documents

Related Topic

Document Title

IEEE CFM

“Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network”

Using OAM

“Using Ethernet Operations, Administration, and Maintenance”

IEEE CFM and Y.1731 commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Standards

Standard

Title

IEEE 802.1ag

802.1ag - Connectivity Fault Management

IEEE 802.3ah

Ethernet in the First Mile

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Configuring EVCs on the Cisco ASR 1000 Series Router

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Configuring EVCs on the Cisco ASR 1000 Series Router

Feature Name

Releases

Feature Information

ASR1000 EVC Infrastructure

Cisco IOS XE Release 3.2S Cisco IOS XE Release 3.3S

EVC infrastructure is a Layer 2 platform-independent bridging architecture that supports Ethernet services.

In Cisco IOS XE Release 3.2S, this feature was introduced on the Cisco ASR 1000 Series Router.

The following commands are introduced or modified:rewrite egress tag, rewrite ingress tag, and shutdown (bdomain).

ASR1000 BD Infrastructure

Cisco IOS XE Release 3.2S

Bridge domain infrastructure is a Layer 2 platform-independent architecture that enables bridging.

In Cisco IOS XE Release 3.2S this feature was introduced on the Cisco ASR 1000 Series Router. The following sections provide information about support for this feature:

The following commands are introduced or modified:bridge- domain (service instance), mac aging-time.

ACL and QoS Enhancements to EVC Infrastructure in Cisco IOS XE Software

Cisco IOS XE Release 3.3S

Support for configuring Layer 3 and Layer 4 ACLs on EFPs was added in Cisco IOS XE Release 3.3S.

The following commands are introduced or modified:ip access-group.

Chapter 6. Using the IEEE 802.3ad Link Aggregation MIB

The IEEE 802.3ad Link Aggregation Control Protocol (LACP) enables the bundling of physical interfaces on a physical device to achieve more bandwidth than is available using a single interface. This feature introduces IEEE 802.3ad Link Aggregation (LAG) MIB support in Cisco IOS XE software. The LAG MIB supports the management of interfaces and ports that are part of an LACP port channel and is accessed by a Simple Network Management Protocol (SNMP) manager application.

- Finding Feature Information

- Prerequisites for Using the IEEE 802.3ad Link Aggregation MIB

- Information About Using the IEEE 802.3ad Link Aggregation MIB

- Additional References

- Feature Information for Using the IEEE 802.3ad Link Aggregation MIB

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Using the IEEE 802.3ad Link Aggregation MIB

- Link aggregation must be configured using the LACP command-line interface (CLI) commands before the MIB tables can be accessed.

- LACP must be supported in the image.

Information About Using the IEEE 802.3ad Link Aggregation MIB

- IEEE 802.3ad LAG MIB

- Configuration and Management of LACP bundles

- LAG MIB Table Object Definitions

IEEE 802.3ad LAG MIB

The IEEE 802.3ad LAG MIB supports the management of interfaces and ports that are part of an LACP port channel. No specific commands are used to enable the MIB; access is through an SNMP manager application. For information about using SNMP in Cisco IOS XE software, see the “Configuring SNMP Support” chapter of the Cisco IOS XE Network Management Configuration Guide, Release 2.

Configuration and Management of LACP bundles

To use the LAG MIB, it is important to know how LACP bundles are configured and managed. For more information about LACP bundles, see the "Configuring IEEE 802.3ad Link Bundling" feature guide.

LAG MIB Table Object Definitions

This section lists the MIB objects and tables that are supported as part of this feature.

- dot3adTablesLastChanged Object

- dot3adAggTable

- dot3adAggPortListTable

- dot3adAggPortTable

- dot3adAggPortStatsTable

dot3adTablesLastChanged Object

The dot3adTablesLastChanged object indicates the time of the most recent change to the dot3adAggTable, dot3adAggPortListTable, or dot3adAggPortTable.

dot3adAggTable

The dot3adAggTable (Aggregator Configuration table) contains information about every aggregator that is associated with a system. Each LACP channel in a device occupies an entry in the dot3adAggTable. Some objects in the table have restrictions, which are described with the object. The objects are described in the table below.

Aggregator Configuration Table Objects

Object

Maximum Access/Description

dot3adAggActorAdminKey

Cannot be changed via the SET operation.

dot3adAggActorOperKey

Write access not supported.

dot3adAggActorSystemID

Write access not supported.

dot3adAggActorSystemPriority

Write access not supported.

dot3adAggAggregateOrIndividual

Returns a value of TRUE if more than 1 port is configured in the channel; otherwise, returns a value of FALSE.

dot3adAggCollectorMaxDelay

Cannot be changed via the SET operation.

dot3adAggIndex

Write access not supported.

dot3adAggMACAddress

Write access not supported.

dot3adAggPartnerOperKey

Write access not supported.

dot3adAggPartnerSystemID

Write access not supported.

dot3adAggPartnerSystemPriority

Write access not supported.

dot3adAggPortListTable

The dot3adAggPortListTable (Aggregation Port List table) contains a list of all the ports associated with each aggregator. Each LACP channel in a device occupies an entry in the table. The objects are described in the table below.

Aggregation Port List Table Objects

Object

Maximum Access/Description

dot3adAggPortListPorts

Write access not supported.

dot3adAggPortTable

The dot3adAggPortTable (Aggregation Port table) contains LACP configuration information about every aggregation port associated with a device. Each physical port in a device occupies an entry in the dot3adAggPortTable. The objects are described in the table below.

Aggregation Port Table Objects

Object

Maximum Access/Description

dot3adAggPortActorAdminKey

Write access not supported.

dot3adAggPortActorAdminState

Write access not supported.

dot3adAggPortActorOperKey

Read-only access supported.

dot3adAggPortActorOperState

Write access not supported.

dot3adAggPortActorPort

Write access not supported.

dot3adAggPortActorPortPriority

Write access not supported.

dot3adAggPortActorSystemID

Write access not supported.

dot3adAggPortActorSystemPriority

Write access not supported.

dot3adAggPortAggregateOrIndividual

Indicates whether a port is attached to an LACP channel. If the port is attached to an LACP channel and the value of the dot3adAggPortAttachedAggID object in the same row is not zero, the value of this object is TRUE. Otherwise, the value is FALSE.

dot3adAggPortAttachedAggID

Write access not supported.

dot3adAggPortIndex

Write access not supported.

dot3adAggPortPartnerAdminKey

Cannot be changed via the SET operation.

dot3adAggPortPartnerAdminPort

Cannot be changed via the SET operation.

dot3adAggPortPartnerAdminPortPriority

Write access not supported.

dot3adAggPortPartnerAdminState

Cannot be changed via the SET operation.

dot3adAggPortPartnerAdminSystemID

Cannot be changed via the SET operation.

dot3adAggPortPartnerAdminSystemPriority

Cannot be changed via the SET operation.

dot3adAggPortPartnerOperKey

Write access not supported.

dot3adAggPortPartnerOperPort

Cannot be changed via the SET operation.

dot3adAggPortPartnerOperPortPriority

Write access not supported.

dot3adAggPortPartnerOperState

Write access is not supported.

dot3adAggPortPartnerOperSystemID

Write access not supported.

dot3adAggPortPartnerOperSystemPriority

Write access not supported.

dot3adAggPortSelectedAggID

Write access not supported.

dot3adAggPortStatsTable

The dot3adAggPortStatsTable (LACP Statistics table) contains link aggregation information about every port that is associated with a device. Each physical port occupies a row in the table. The objects are described in the table below.

LACP Statistics Table Objects

Object

Maximum Access/Description

dot3adAggPortStatsIllegalRx

Write access not supported.

dot3adAggPortStatsLACPDUsRx

Write access not supported.

dot3adAggPortStatsLACPDUsTx

Write access not supported.

dot3adAggPortStatsMarkerPDUsRx

Write access not supported.

dot3adAggPortStatsMarkerPDUsTx

Write access not supported.

dot3adAggPortStatsMarkerResponsePDUsRx

Write access not supported.

dot3adAggPortStatsMarkerResponsePDUsTx

Write access not supported.

dot3adAggPortStatsUnknownRx

Write access not supported.

Additional References

Related Documents

Related Topic

Document Title

Link aggregation configuration tasks

"Configuring IEEE 802.3ad Link Bundling" feature guide

Cisco IOS XE LACP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Configuring SNMP

“Configuring SNMP Support” chapter of the Cisco IOS XE Network Management Configuration Guide, Release 2

Cisco IOS XE SNMP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Network Management Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Commands List, All Releases

Standards

Standard

Title

IEEE 802.3ad

IEEE 802.3ad-2000 Link Aggregation

MIBs

MIB

MIBs Link

- IEEE 802.3ad MIB

- IF MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

RFCs

RFC

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 Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Using the IEEE 802.3ad Link Aggregation MIB

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Using the IEEE 802.3ad Link Aggregation MIB

Feature Name

Releases

Feature Information

IEEE 802.3ad MIB

Cisco IOS XE Release 2.5

This feature introduces LAG MIB support in Cisco IOS XE software. The LAG MIB supports the management of interfaces and ports that are part of an LACP port channel and is accessed by an SNMP manager application.

This feature uses no commands.

Chapter 7. Configuring IEEE 802.3ad Link Bundling

This document describes how the IEEE 802.3ad Link Bundling feature leverages the EtherChannel infrastructure within Cisco IOS XE software to manage the bundling of Ethernet links. The supported Ethernet link types for link bundling are Gigabit Ethernet and Ten Gigabit Ethernet.

- Finding Feature Information

- Prerequisites for Configuring IEEE 802.3ad Link Bundling

- Restrictions for Configuring IEEE 802.3ad Link Bundling

- Information About Configuring IEEE 802.3ad Link Bundling

- How to Configure IEEE 802.3ad Link Bundling

- Configuration Examples for IEEE 802.3ad Link Bundling

- Additional References Configuring IEEE 802.3ad Link Bundling

- Feature Information for Configuring IEEE 802.3ad Link Bundling

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Configuring IEEE 802.3ad Link Bundling

- Knowledge of how EtherChannels and Link Aggregation Control Protocol (LACP) function in a network

- Verification that both ends of the LACP link have the same baseline software version

Restrictions for Configuring IEEE 802.3ad Link Bundling

- The maximum number of Ethernet links per bundle that can be supported varies by platform. Some platforms support 4 while other platforms support a maximum a 16.

- All links must operate at the same link speed and in full-duplex mode (LACP does not support half-duplex mode).

- All links must be configured as either EtherChannel links or LACP links.

- Only physical interfaces can form aggregations. Aggregations of VLAN interfaces are not possible nor is an aggregation of aggregations.

- If a router is connected to a switch, the bundle terminates on the switch.

- An EtherChannel will not form if one of the LAN ports is a Switched Port Analyzer (SPAN) destination port.

- All ports in an EtherChannel must use the same EtherChannel protocol.

- Maximum of four bundled ports per Ethernet port channel are supported.

- The maximum number of bundled ports per Ethernet port channel that can be supported varies by platform. Some platforms support 4 while other platforms support 16.

- Maximum of 64 Ethernet port channels in a chassis are supported.

- Quality of service (QoS) is supported on individual bundled ports and not on Ethernet port channels.

Information About Configuring IEEE 802.3ad Link Bundling

- Gigabit EtherChannel

- Port-Channel and LACP-Enabled Interfaces

- IEEE 802.3ad Link Bundling

- LACP Enhancements

- LACP for Gigabit Interfaces

Gigabit EtherChannel

Gigabit EtherChannel (GEC) is high-performance Ethernet technology that provides Gigabit per second (Gb/s) transmission rates. A Gigabit EtherChannel bundles individual Ethernet links (Gigabit Ethernet or Ten Gigabit Ethernet) into a single logical link that provides the aggregate bandwidth of up to physical links. All LAN ports in each EtherChannel must be the same speed and all must be configured as either Layer 2 or Layer 3 LAN ports. Inbound broadcast and multicast packets on one link in an EtherChannel are blocked from returning on any other link in the EtherChannel.

When a link within an EtherChannel fails, traffic previously carried over the failed link switches to the remaining links within that EtherChannel. Also when a failure occurs, a trap is sent that identifies the device, the EtherChannel, and the failed link.

Port-Channel and LACP-Enabled Interfaces

Each EtherChannel has a numbered port-channel interface that must be manually created before interfaces can be added to the channel group. The configuration of a port-channel interface affects all LAN ports assigned to that port-channel interface.

To change the parameters of all ports in an EtherChannel, change the configuration of the port-channel interface; for example, if you want to configure Spanning Tree Protocol or configure a Layer 2 EtherChannel as a trunk. Any configuration or attribute changes you make to the port-channel interface are propagated to all interfaces within the same channel group as the port-channel; that is, configuration changes are propagated to the physical interfaces that are not part of the port-channel but are part of the channel group.

The configuration of a LAN port affects only that LAN port.

IEEE 802.3ad Link Bundling

The IEEE 802.3ad Link Bundling feature provides a method for aggregating multiple Ethernet links into a single logical channel based on the IEEE 802.3ad standard. This feature helps improve the cost effectiveness of a device by increasing cumulative bandwidth without necessarily requiring hardware upgrades. In addition, IEEE 802.3ad Link Bundling provides a capability to dynamically provision, manage, and monitor various aggregated links and enables interoperability between various Cisco devices and devices of third-party vendors.

LACP supports the automatic creation of EtherChannels by exchanging LACP packets between LAN ports. LACP packets are exchanged only between ports in passive and active modes. The protocol “learns” the capabilities of LAN port groups dynamically and informs the other LAN ports. After LACP identifies correctly matched Ethernet links, it facilitates grouping the links into an EtherChannel. Then the EtherChannel is added to the spanning tree as a single bridge port.

Both the passive and active modes allow LACP to negotiate between LAN ports to determine if they can form an EtherChannel, based on criteria such as port speed and trunking state. (Layer 2 EtherChannels also use VLAN numbers.) LAN ports can form an EtherChannel when they are in compatible LACP modes, as in the following examples:

- A LAN port in active mode can form an EtherChannel with another LAN port that is in active mode.

- A LAN port in active mode can form an EtherChannel with another LAN port in passive mode.

- A LAN port in passive mode cannot form an EtherChannel with another LAN port that is also in passive mode because neither port will initiate negotiation.

LACP uses the following parameters:

- LACP system priority—You must configure an LACP system priority on each device running LACP. The system priority can be configured automatically or through the command-line interface (CLI). LACP uses the system priority with the device MAC address to form the system ID and also during negotiation with other systems.

- LACP port priority—You must configure an LACP port priority on each port configured to use LACP. The port priority can be configured automatically or through the CLI. LACP uses the port priority to decide which ports should be put in standby mode when there is a hardware limitation that prevents all compatible ports from aggregating. LACP also uses the port priority with the port number to form the port identifier.

- LACP administrative key—LACP automatically configures an administrative key value on each port configured to use LACP. The administrative key defines the ability of a port to aggregate with other ports. A port’s ability to aggregate with other ports is determined by the following:

- Port physical characteristics such as data rate, duplex capability, and point-to-point or shared medium

- Configuration restrictions that you establish

On ports configured to use LACP, it tries to configure the maximum number of compatible ports in an EtherChannel, up to the maximum allowed by the hardware. To use the hot standby feature in the event a channel port fails, both ends of the LACP bundle must support the lacp max-bundle command.

As a control protocol, LACP uses the Slow Protocol Multicast address of 01-80-C2-00-00-02 to transmit LACP protocol data units (PDUs). Aside from LACP, the Slow Protocol linktype is to be utilized by operations, administration, and maintenance (OAM) packets, too. Subsequently, a subtype field is defined per the IEEE 802.3ad standard [1] (Annex 43B, section 4) differentiating LACP PDUs from OAM PDUs.

Note

LACP and Port Aggregation Control Protocol (PAgP) are not compatible. Ports configured for PAgP cannot form port channels on ports configured for LACP, and ports configured for LACP cannot form port channels on ports configured for PAgP.

- Benefits of IEEE 802.3ad Link Bundling

Benefits of IEEE 802.3ad Link Bundling

- Increased network capacity without changing physical connections or upgrading hardware

- Cost savings from the use of existing hardware and software for additional functions

- A standard solution that enables interoperability of network devices

- Port redundancy without user intervention when an operational port fails

LACP Enhancements

The following LACP enhancements are supported:

- Four member links per LACP bundle.

- Cisco nonstop forwarding (NSF), and nonstop routing (NSR) on Gigabit EtherChannel bundles.

- Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.

- Shutting down a port channel when the number of active links falls below the minimum threshold. In the port channel interface, a configurable option is provided to bring down the port channel interface when the number of active links falls below the minimum threshold. For the port-channel state to be symmetric on both sides of the channel, the peer must also be running LACP and have the same lacp min-bundle command setting.

- The IEEE Link Aggregation Group (LAG) MIB.

LACP for Gigabit Interfaces

The LACP (802.3ad) for Gigabit Interfaces feature bundles individual Ethernet links (Gigabit Ethernet or Ten Gigabit Ethernet) into a single logical link that provides the aggregate bandwidth of up to four physical links.

All LAN ports on a port channel must be the same speed and must all be configured as either Layer 2 or Layer 3 LAN ports. If a segment within a port channel fails, traffic previously carried over the failed link switches to the remaining segments within the port channel. Inbound broadcast and multicast packets on one segment in a port channel are blocked from returning on any other segment of the port channel.

Note

The network device may impose its own limits on the number of bundled ports per port channel.

- Features Supported on Gigabit EtherChannel Bundles

- Guidelines for LACP for Gigabit Interfaces Configuration

Features Supported on Gigabit EtherChannel Bundles

The table below lists the features that are supported on Gigabit EtherChannel (GEC) bundles.

Gigabit EtherChannel Bundle Features

Cisco IOS XE Release

Feature

Bundle Interface

2.5

Access control lists (ACLs) per bundle

Supported

All Ethernet routing protocols

Supported

Intelligent Service Gateway (ISG) IP sessions

Not Supported

Interface statistics

Supported

IP switching

Supported

IPv4: unicast and multicast

Supported

IPv6: unicast without load balancing across member links

Supported

IPv6: multicast

Layer 2 Tunneling Protocol Version 3 (L2TPv3), Generic Routing Encapsulation (GRE), IPinIP, Any Transport Over Multiprotocol Label Switching (MPLS) (AToM) tunnels

Supported

Layer 2 Tunneling Protocol Version 2 (L2TPv2)

Not Supported

MPLS (6PE)

Supported

Multicast VPN

Not Supported

VLANs

Supported

2.6

Virtual Private Network (VPN) Routing and Forwarding (VRF)

Supported

3.4

IPv6: unicast and multicast

Supported

3.6

Bidirectional Forwarding Detection (BFD) over GEC

Supported

3.7

Layer 2 Tunneling Protocol Version 2 (L2TPv2)

Supported

PPPoX (PPPoEoE, PPPoEoQinQ, PPPoVLAN)

Supported

3.7.6

Policy-based routing (PBR) over GEC

Supported

3.11

GEC over L2TPv3

Supported

3.12

MPLS TE (Traffic Engineering) over GEC

Supported

Guidelines for LACP for Gigabit Interfaces Configuration

Port channel interfaces that are configured improperly with LACP are disabled automatically to avoid network loops and other problems. To avoid configuration problems, observe these guidelines and restrictions:

- Every port added to a port channel must be configured identically. No individual differences in configuration are allowed.

- Bundled ports can be configured on different line cards in a chassis.

- Maximum transmission units (MTUs) must be configured on only port channel interfaces; MTUs are propagated to the bundled ports.

- QoS and committed access rate (CAR) are applied at the port level. Access control lists (ACLs) are applied on port channels.

- MAC configuration is allowed only on port channels.

- MPLS IP should be enabled on bundled ports using the mpls ip command.

- Unicast Reverse Path Forwarding (uRPF) should be applied on the port channel interface using the ip verify unicast reverse-path command in interface configuration mode.

- Cisco Discovery Protocol should be enabled on the port channel interface using the cdp enable command in interface configuration mode.

- All LAN ports in a port channel should be enabled. If you shut down a LAN port in a port channel, the shutdown is treated as a link failure and the traffic is transferred to one of the remaining ports in the port channel.

- Create a port channel interface using the interface port-channel command in global configuration mode.

- When an Ethernet interface has an IP address assigned, disable that IP address before adding the interface to the port channel. To disable an existing IP address, use the no ip address command in interface configuration mode.

- The hold queue in command is valid only on port channel interfaces. The hold queue out command is valid only on bundled ports.

How to Configure IEEE 802.3ad Link Bundling

- Enabling LACP

- Configuring a Port Channel

- Configuring LACP (802.3ad) for Gigabit Interfaces

- Setting LACP System Priority and Port Priority

- Adding and Removing Interfaces from a Link Bundle

- Removing a Channel Group from a Port

- Setting a Minimum Threshold of Active Links

- Monitoring LACP Status

- Displaying Gigabit EtherChannel Information

Enabling LACP

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface port-channel channel-number

4.    channel-group channel-group-number mode {active | passive}

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface port-channel channel-number

Example:

Device(config)# interface port-channel 10

Identifies the interface port channel and enters interface configuration mode.

Step 4

channel-group channel-group-number mode {active | passive}

Example:

Device(config-if)# channel-group 25 mode active

Configures the interface in a channel group and sets it as active.

In active mode, the port will initiate negotiations with other ports by sending LACP packets.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuring a Port Channel

You must manually create a port channel logical interface. Perform this task to configure a port channel.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface port-channel channel-number

4.    lacp max-bundle max-bundles

5.    ip address ip-address mask

6.    end

7.    show running-config interface port-channel group-number

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface port-channel channel-number

Example:

Device(config)# interface port-channel 10

Identifies the interface port channel and enters interface configuration mode.

Step 4

lacp max-bundle max-bundles

Example:

Device(config-if)# lacp max-bundle 3

Configures three active links on the port channel. The remaining links are in standby mode. Traffic is load-balanced among the active links.

Step 5

ip address ip-address mask

Example:

Device(config-if)# ip address 172.31.52.10 255.255.255.0

Assigns an IP address and subnet mask to the EtherChannel.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 7

show running-config interface port-channel group-number

Example:

Device# show running-config interface port-channel 10

Displays the port channel configuration.

Example

This example shows how to verify the configuration:

Device# show running-config interface port-channel 10

Building configuration...
Current configuration:
!
interface Port-channel10
ip address 172.31.52.10 255.255.255.0
no ip directed-broadcast
end

Configuring LACP (802.3ad) for Gigabit Interfaces

Perform this task to create a port channel with two bundled ports. You can configure a maximum of four bundled ports per port channel.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface port-channel number

4.    ip address ip-address mask

5.    interface type slot/subslot/ port

6.    no ip address

7.    channel-group channel-group-number mode {active | passive}

8.    exit

9.    interface type slot/subslot/ port

10.    no ip address

11.    channel-group channel-group-number mode {active | passive}

12.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface port-channel number

Example:

Device(config)# interface port-channel 1

Specifies the port channel interface and enters interface configuration mode.

- number —Valid range is from 1 to 64.

Step 4

ip address ip-address mask

Example:

Device(config-if)# ip address 10.1.1.1 255.255.255.0

Assigns an IP address and subnet mask to the port channel interface.

Step 5

interface type slot/subslot/ port

Example:

Device(config-if)# interface gigabitethernet

Specifies the port to bundle.

Step 6

no ip address

Example:

Device(config-if)# no ip address

Disables the IP address on the port channel interface.

Step 7

channel-group channel-group-number mode {active | passive}

Example:

Device(config-if)# channel-group 1 mode active

Assigns the interface to a port channel group and sets the LACP mode.

- channel-group-number —Valid range is 1 to 64.

- active —Places a port into an active negotiating state, in which the port initiates negotiations with other ports by sending LACP packets.

- passive —Places a port into a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP negotiation. In this mode, the channel group attaches the interface to the bundle.

Step 8

exit

Example:

Device(config-if)# exit

Returns to global configuration mode.

Step 9

interface type slot/subslot/ port

Example:

Device(config)# interface gigabitethernet

Specifies the next port to bundle and places the CLI in interface configuration mode.

Step 10

no ip address

Example:

Device(config-if)# no ip address

Disables the IP address on the port channel interface.

Step 11

channel-group channel-group-number mode {active | passive}

Example:

Device(config-if)# channel-group 1 mode active

Assigns the interface to the previously configured port channel group.

- channel-group-number —Valid range is 1 to 64.

- active —Places a port into an active negotiating state, in which the port initiates negotiations with other ports by sending LACP packets.

- passive —Places a port into a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP negotiation. In this mode, the channel-group attaches the interface to the bundle.

Step 12

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Example

Device> enable
Device# configure terminal
Device(config)# interface port-channel 1
Device(config-if)# ip address 10.1.1.1 255.255.255.0
Device(config-if)#
Device(config-if)# no ip address
Device(config-if)# channel-group 1 mode active
Device(config-if)# exit
Device(config)#
Device(config-if)# no ip address
Device(config-if)# channel-group 1 mode active
Device(config-if)# end

Setting LACP System Priority and Port Priority

Perform this task to set the LACP system priority and port priority. The system ID is the combination of the LACP system priority and the MAC address of a device. The port identifier is the combination of the port priority and port number.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    lacp system-priority priority

4.    interface slot/subslot/ port

5.    lacp port-priority priority

6.    end

7.    show lacp sys-id

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

lacp system-priority priority

Example:

Device(config)# lacp system-priority 200

Sets the system priority.

Step 4

interface slot/subslot/ port

Example:

Device(config)# interface gigabitethernet 0/1/1

Specifies the bundled port on which to set the LACP port priority and enters interface configuration mode.

Step 5

lacp port-priority priority

Example:

Device(config-if)# lacp port-priority 500

Specifies the priority for the physical interface.

- priority —Valid range is from 1 to 65535. The higher the number, the lower the priority.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Step 7

show lacp sys-id

Example:

Device# show lacp 200

Displays the system ID (a combination of the system priority and the MAC address of the device).

Examples

Device> enable
Device# configure terminal
Device(config)# lacp system-priority 200
Device(config)# interface gigabitethernet 0/1/1
Device(config-if)# lacp port-priority 500
Device(config-if)# end

This example shows how to verify the LACP configuration:

Device# show lacp 200
200.abcd.abcd.abcd.

Adding and Removing Interfaces from a Link Bundle

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type slot/subslot/port

4.    channel-group channel-group-number mode {active | passive}

5.    no channel-group channel-group-number mode {active | passive}

6.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type slot/subslot/port

Example:

Device(config)# interface gigabitethernet

Configures a Gigabit Ethernet interface.

Step 4

channel-group channel-group-number mode {active | passive}

Example:

Device(config-if)# channel-group 5 mode active

Adds an interface to a channel group and enters interface configuration mode.

- In this instance, the interface from Step 3 is added.

Step 5

no channel-group channel-group-number mode {active | passive}

Example:

Device(config-if)# no channel-group 5 mode active

Removes the Gigabit Ethernet interface from channel group.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Removing a Channel Group from a Port

Perform this task to remove a Gigabit Ethernet port channel group from a physical port.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    no interface port-channel number

4.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

no interface port-channel number

Example:

Device(config)# no interface port-channel 1

Removes the specified port channel group from a physical port.

- number—Valid range is from 1 to 16.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Example

Device> enable
Device# configure terminal
Device(config)# no interface port-channel 1
Device(config)# end

Setting a Minimum Threshold of Active Links

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    lacp min-bundle min-bundle

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface port-channel 1

Creates a port-channel virtual interface and enters interface configuration mode.

Step 4

lacp min-bundle min-bundle

Example:

Device(config-if)# lacp min-bundle 4

Sets the minimum threshold of active links to 4.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Monitoring LACP Status

SUMMARY STEPS

1.    enable

2.    show lacp {number | counters | internal | neighbor | sys-id}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show lacp {number | counters | internal | neighbor | sys-id}

Example:

Device# show lacp internal

Displays internal device information.

- Troubleshooting Tips

Troubleshooting Tips

To verify and isolate a fault, start at the highest level maintenance domain and do the following:

1. Check the device error status.

2. When a error exists, perform a loopback test to confirm the error.

3. Run a traceroute to the destination to isolate the fault.

4. If the fault is identified, correct the fault.

5. If the fault is not identified, go to the next lower maintenance domain and repeat steps 1 through 4 at that maintenance domain level.

6. Repeat the first four steps, as needed, to identify and correct the fault.

Displaying Gigabit EtherChannel Information

To display Gigabit Ethernet port channel information, use the show interfaces port-channel command in user EXEC mode or privileged EXEC mode. The following example shows information about port channels configured on ports 0/2 and 0/3. The default MTU is set to 1500 bytes.

Device# show interfaces port-channel 1
Port-channel1 is up, line protocol is up
Hardware is GEChannel, address is 0013.19b3.7748 (bia 0000.0000.0000)
MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
No. of active members in this channel: 2
Member 0 : GigabitEthernet , Full-duplex, 1000Mb/s Member 1 : GigabitEthernet , Full-duplex, 1000Mb/s
Last input 00:00:05, output never, output hang never
Last clearing of "show interface" counters 00:04:40
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Interface Port-channel1 queueing strategy: PXF First-In-First-Out
Output queue 0/8192, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
3 packets output, 180 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

The table below describes the significant fields shown in the display.

show interfaces port-channel Field Descriptions

Field

Description

Port-channel1 is up, line protocol is up

Indicates the bundle interface is currently active and can transmit and receive or it has been taken down by an administrator.

Hardware is

Hardware type (Gigabit EtherChannel).

address is

Address being used by the interface.

MTU

Maximum transmission unit of the interface.

BW

Bandwidth of the interface, in kilobits per second.

DLY

Delay of the interface, in microseconds.

reliability

Reliability of the interface as a fraction of 255 (255/255 is 100 percent reliability), calculated as an exponential average over 5 minutes.

tx load rxload

Transmit and receive load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes. The calculation uses the value from the bandwidth interface configuration command.

Encapsulation

Encapsulation type assigned to the interface.

loopback

Indicates if loopbacks are set.

keepalive

Indicates if keepalives are set.

ARP type

Address Resolution Protocol (ARP) type on the interface.

ARP Timeout

Number of hours, minutes, and seconds an ARP cache entry stays in the cache.

No. of active members in this channel

Number of bundled ports (members) currently active and part of the port channel group.

Member <no.> Gigabit Ethernet: <no. /no. /no. >

Number of the bundled port and associated Gigabit Ethernet port channel interface.

Last input

Number of hours, minutes, and seconds since the last packet was successfully received by an interface and processed locally on the Device. Useful for knowing when a dead interface failed. This counter is updated only when packets are process-switched, not when packets are fast-switched.

output

Number of hours, minutes, and seconds since the last packet was successfully transmitted by an interface. This counter is updated only when packets are process-switched, not when packets are fast-switched.

output hang

Number of hours, minutes, and seconds since the interface was last reset because of a transmission that took too long. When the number of hours in any of the “last” fields exceeds 24 hours, the number of days and hours is printed. If that field overflows, asterisks are printed.

last clearing

Time at which the counters that measure cumulative statistics (such as number of bytes transmitted and received) shown in this report were last reset to zero. Variables that might affect routing (for example, load and reliability) are not cleared when the counters are cleared.

*** indicates that the elapsed time is too long to be displayed.

0:00:00 indicates that the counters were cleared more than 231 ms and less than 232 ms ago.

Input queue

Number of packets in the input queue and the maximum size of the queue.

Queueing strategy

First-in, first-out queueing strategy (other queueing strategies you might see are priority-list, custom-list, and weighted fair).

Output queue

Number of packets in the output queue and the maximum size of the queue.

5 minute input rate 5 minute output rate

Average number of bits and packets received or transmitted per second in the last 5 minutes.

packets input

Total number of error-free packets received by the system.

bytes (input)

Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system.

no buffer

Number of received packets discarded because there was no buffer space in the main system. Broadcast storms on Ethernet lines and bursts of noise on serial lines are often responsible for no input buffer events.

broadcasts

Total number of broadcast or multicast packets received by the interface.

runts

Number of packets that are discarded because they are smaller than the minimum packet size for the medium.

giants

Number of packets that are discarded because they exceed the maximum packet size for the medium.

input errors

Total number of no buffer, runts, giants, cyclic redundancy checks (CRCs), frame, overrun, ignored, and abort counts. Other input-related errors can also increment the count, so that this sum might not balance with the other counts.

CRC

CRC generated by the originating LAN station or far-end device does not match the checksum calculated from the data received. On a LAN, this usually indicates noise or transmission problems on the LAN interface or the LAN bus. A high number of CRCs is usually the result of collisions or a station transmitting bad data. On a serial link, CRCs usually indicate noise, gain hits or other transmission problems on the data link.

frame

Number of packets received incorrectly having a CRC error and a noninteger number of octets. On a serial line, this is usually the result of noise or other transmission problems.

overrun

Number of times the serial receiver hardware was unable to pass received data to a hardware buffer because the input rate exceeded the receiver’s capacity for handling the data.

ignored

Number of received packets ignored by the interface because the interface hardware ran low on internal buffers. These buffers are different than the system buffers mentioned previously in the buffer description. Broadcast storms and bursts of noise can cause the ignored count to be incremented.

watchdog

Number of times the watchdog receive timer expired.

multicast

Number of multicast packets received.

packets output

Total number of messages transmitted by the system.

bytes (output)

Total number of bytes, including data and MAC encapsulation, transmitted by the system.

underruns

Number of times that the far-end transmitter has been running faster than the near-end Device’s receiver can handle.

output errors

Sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this might not balance with the sum of the enumerated output errors, as some datagrams can have more than one error, and others can have errors that do not fall into any of the specifically tabulated categories.

collisions

Number of messages retransmitted because of an Ethernet collision. A packet that collides is counted only once in output packets.

interface resets

Number of times an interface has been completely reset. This can happen if packets queued for transmission were not sent within a certain interval. If the system notices that the carrier detect line of an interface is up but the line protocol is down, the system periodically resets the interface in an effort to restart that interface. Interface resets can also occur when an unrecoverable interface processor error occurred, or when an interface is looped back or shut down.

babbles

The transmit jabber timer expired.

late collision

Number of late collisions. Late collision happens when a collision occurs after transmitting the preamble. The most common cause of late collisions is that your Ethernet cable segments are too long for the speed at which you are transmitting.

deferred

Indicates that the chip had to defer while ready to transmit a frame because the carrier was asserted.

lost carrier

Number of times the carrier was lost during transmission.

no carrier

Number of times the carrier was not present during the transmission.

PAUSE output

Not supported.

output buffer failures

Number of times that a packet was not output from the output hold queue because of a shortage of shared memory.

output buffers swapped out

Number of packets stored in main memory when the output queue is full; swapping buffers to main memory prevents packets from being dropped when output is congested. The number is high when traffic is bursty.

Configuration Examples for IEEE 802.3ad Link Bundling

- Example: Configuring LACP for Gigabit Interfaces

- Example Associating a Channel Group with a Port Channel

- Example Adding and Removing Interfaces from a Bundle

- Example Monitoring LACP Status

- Example: Displaying Port-Channel Interface Information

Example: Configuring LACP for Gigabit Interfaces

The following example shows how to configure Gigabit Ethernet ports into port channel 1 with LACP parameters.

Device> enable
Device# configure terminal
Device(config)# lacp system-priority 65535
Device(config)# interface port-channel 1
Device(config-if)# lacp max-bundle 1
Device(config-if)# ip address 10.1.1.1 255.255.255.0
Device(config-if)# exit
Device(config)#
Device(config-if)# no ip address
Device(config-if)# lacp port-priority 100
Device(config-if)# channel-group 1 mode passive
Device(config-if)# exit
Device(config)#
Device(config-if)# no ip address
Device(config-if)# lacp port-priority 200
Device(config-if)# channel-group 1 mode passive
Device(config-if)# end

Example Associating a Channel Group with a Port Channel

This example shows how to configure channel group number 5 and include it in the channel group.

Device1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Device1(config)# interface port 5
Device1(config-if)#
*Aug 20 17:06:14.417: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel5, changed state to down
*Aug 20 17:06:25.413: %LINK-3-UPDOWN: Interface Port-channel5, changed state to down
Device1(config-if)#
Device1(config-if)#
Device1(config-if)# channel-group 5 mode active
Device1(config-if)#
*Aug 20 17:07:43.713: %LINK-3-UPDOWN: Interface GigabitEthernet, changed state to down
*Aug 20 17:07:44.713: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet, changed state to down
*Aug 20 17:07:45.093: %C10K_ALARM-6-INFO: ASSERT CRITICAL GigE  Physical Port Link Down
*Aug 20 17:07:45.093: %C10K_ALARM-6-INFO: CLEAR CRITICAL GigE  Physical Port Link Down
*Aug 20 17:07:47.093: %LINK-3-UPDOWN: Interface GigabitEthernet, changed state to up
*Aug 20 17:07:48.093: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet, changed state to up
*Aug 20 17:07:48.957: GigabitEthernet added as member-1 to port-channel5

*Aug 20 17:07:51.957: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel5, changed state to up
Device1(config-if)# end
Device1#
*Aug 20 17:08:00.933: %SYS-5-CONFIG_I: Configured from console by console
Device1# show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
SA      bndl      32768         0x5       0x5     0x43        0x3D
Device1# show interface port 5
Port-channel5 is up, line protocol is up
Hardware is GEChannel, address is 0014.a93d.4aa8 (bia 0000.0000.0000)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
No. of active members in this channel: 1
Member 0 : GigabitEthernet , Full-duplex, 1000Mb/s
Last input 00:00:05, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Interface Port-channel5 queueing strategy: PXF First-In-First-Out
Output queue 0/8192, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
9 packets output, 924 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Example Adding and Removing Interfaces from a Bundle

The following example shows how to add an interface to a bundle:

Device1# show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
SA      bndl      32768         0x5       0x5     0x43        0x3D
Device1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Device1(config)#
Device1(config-if)# channel-group 5 mode active
Device1(config-if)#
*Aug 20 17:10:19.057: %LINK-3-UPDOWN: Interface GigabitEthernet, changed state to down
*Aug 20 17:10:19.469: %C10K_ALARM-6-INFO: ASSERT CRITICAL GigE  Physical Port Link Down
*Aug 20 17:10:19.473: %C10K_ALARM-6-INFO: CLEAR CRITICAL GigE  Physical Port Link Down
*Aug 20 17:10:21.473: %LINK-3-UPDOWN: Interface GigabitEthernet, changed state to up
*Aug 20 17:10:21.473: GigabitEthernet taken out of port-channel5
*Aug 20 17:10:23.413: GigabitEthernet added as member-1 to port-channel5

*Aug 20 17:10:23.473: %LINK-3-UPDOWN: Interface Port-channel5, changed state to up
Device1(config-if)# end
Device1#
*Aug 20 17:10:27.653: %SYS-5-CONFIG_I: Configured from console by console
*Aug 20 17:11:40.717: GigabitEthernet added as member-2 to port-channel5

Device1# show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
SA      bndl      32768         0x5       0x5     0x43        0x3D
SA      bndl      32768         0x5       0x5     0x42        0x3D
Device1#
Device1# show interface port 5
Port-channel5 is up, line protocol is up
Hardware is GEChannel, address is 0014.a93d.4aa8 (bia 0000.0000.0000)
MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
No. of active members in this channel: 2
Member 0 : GigabitEthernet , Full-duplex, 1000Mb/s  <---- added to port channel bundle
Member 1 : GigabitEthernet , Full-duplex, 1000Mb/s
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/150/0/0 (size/max/drops/flushes); Total output drops: 0
Interface Port-channel5 queueing strategy: PXF First-In-First-Out
Output queue 0/8192, 0 drops; input queue 0/150, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
104 packets output, 8544 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

The following example shows how to remove an interface from a bundle:

Device1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Device1(config)#
Device1(config-if)# no channel-group 5 mode active
Device1(config-if)#
*Aug 20 17:15:49.433: GigabitEthernet taken out of port-channel5
*Aug 20 17:15:49.557: %C10K_ALARM-6-INFO: ASSERT CRITICAL GigE  Physical Port Link Down
*Aug 20 17:15:50.161: %C10K_ALARM-6-INFO: CLEAR CRITICAL GigE  Physical Port Link Down
*Aug 20 17:15:51.433: %LINK-3-UPDOWN: Interface GigabitEthernet, changed state to down
*Aug 20 17:15:52.433: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet, changed state to down
Device1(config-if)# end
Device1#
*Aug 20 17:15:58.209: %SYS-5-CONFIG_I: Configured from console by console
Device1#
*Aug 20 17:15:59.257: %C10K_ALARM-6-INFO: ASSERT CRITICAL GigE  Physical Port Link Down
*Aug 20 17:15:59.257: %C10K_ALARM-6-INFO: CLEAR CRITICAL GigE  Physical Port Link Down
Device1#
*Aug 20 17:16:01.257: %LINK-3-UPDOWN: Interface GigabitEthernet, changed state to up
*Aug 20 17:16:02.257: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet, changed state to up
Device1# show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
SA      bndl      32768         0x5       0x5     0x42        0x3D

Example Monitoring LACP Status

The following example shows LACP activity that you can monitor by using the show lacp command.

Device1# show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
SA      bndl      32768         0x5       0x5     0x42        0x3D
Device1# show lacp 5 counters
LACPDUs         Marker      Marker Response    LACPDUs
Port       Sent   Recv     Sent   Recv     Sent   Recv      Pkts Err
---------------------------------------------------------------------
Channel group: 5
21     18       0      0        0      0         0
Device1# show lacp 5 internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
SA      bndl      32768         0x5       0x5     0x42        0x3D
Device1# show lacp 5 neighbor
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode
Channel group 5 neighbors
Partner's information:
Partner Partner   LACP Partner  Partner   Partner  Partner     Partner
Port      Flags   State     Port Priority Admin Key Oper Key Port Number Port State
SP      32768     0011.2026.7300  11s    0x1     0x14     0x3C
Device1# show lacp counters
LACPDUs         Marker      Marker Response    LACPDUs
Port       Sent   Recv     Sent   Recv     Sent   Recv      Pkts Err
---------------------------------------------------------------------
Channel group: 5
23     20       0      0        0      0         0
Device1# show lacp sys-id
32768,0014.a93d.4a00

Example: Displaying Port-Channel Interface Information

The following example shows how to display the configuration of port-channel interface 1.

Device# show interface port-channel 1
Port-channel1 is up, line protocol is up
Hardware is GEChannel, address is 0013.19b3.7748 (bia 0000.0000.0000)
MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
No. of active members in this channel: 2
Member 0 : GigabitEthernet , Full-duplex, 1000Mb/s Member 1 : GigabitEthernet , Full-duplex, 1000Mb/s
Last input 00:00:05, output never, output hang never
Last clearing of "show interface" counters 00:04:40
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Interface Port-channel1 queueing strategy: PXF First-In-First-Out
Output queue 0/8192, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
3 packets output, 180 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Additional References Configuring IEEE 802.3ad Link Bundling

Related Documents

Related Topic

Document Title

Configuring EtherChannels

“Configuring Layer 3 and Layer 2 EtherChannel” chapter of the Catalyst 6500 Release 12.2SXF Software Configuration Guide

LACP commands

Cisco IOS Carrier Ethernet Command Reference

LACP commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Network Management Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Commands List, All Releases

Standards

Standard

Title

IEEE 802.3ad-2000

IEEE 802.3ad-2000 Link Aggregation

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Configuring IEEE 802.3ad Link Bundling

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Configuring IEEE 802.3ad Link Bundling

Feature Name

Releases

Feature Information

EtherChannel Min-Links

Cisco IOS XE Release 2.5

Cisco IOS XE Release 3.8S

The EtherChannel Min-Links feature allows a port channel to be shut down when the number of active links falls below the minimum threshold. Using the lacp min-bundle command, you can configure the minimum threshold.

In Cisco IOS XE Release 3.8S, support was added for the Cisco ASR 903 Router.

The following commands were introduced or modified: lacp min-bundle.

IEEE 802.3ad Faster Link Switchover Time

Cisco IOS XE Release 2.5

The IEEE 802.3ad Faster Link Switchover Time feature provides a link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds. Also, port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.

The following commands were introduced or modified: lacp fast-switchover.

IEEE 802.3ad Link Aggregation (LACP)

Cisco IOS XE Release 2.4

The IEEE 802.3ad Link Aggregation feature provides a method for aggregating multiple Ethernet links into a single logical channel based on the IEEE 802.3ad standard. In addition, this feature provides a capability to dynamically provision, manage, and monitor various aggregated links and enables interoperability between various Cisco devices and devices of third-party vendors.

In Cisco IOS XE Release 2.4, this feature was implemented on the Cisco ASR1000 Series Router.

The following commands were introduced or modified: channel-group (interface), debug lacp, lacp max-bundle, lacp port-priority, lacp system-priority, show lacp.

Link Aggregation Control Protocol (LACP) (802.3ad) for Gigabit Interfaces

Cisco IOS XE Release 2.5

The LACP (802.3ad) for Gigabit Interfaces feature bundles individual Gigabit Ethernet links into a single logical link that provides the aggregate bandwidth of up to four physical links.

The following commands were introduced or modified: lacp max-bundle.

SSO - LACP

Cisco IOS XE Release 2.5

The SSO - LACP feature supports stateful switchover (SSO), in service software upgrade (ISSU), Cisco nonstop forwarding (NSF), and nonstop routing (NSR) on Gigabit EtherChannel bundles.

This feature uses no new or modified commands.

Chapter 8. ITU-T Y.1731 Performance Monitoring in a Service Provider Network

ITU-T Y.1731 performance monitoring provides standard-based Ethernet performance monitoring that encompasses the measurement of Ethernet frame delay, frame-delay variation, and throughput as outlined in the ITU-T Y.1731 specification and interpreted by the Metro Ethernet Forum (MEF). Service providers offer service level agreements (SLAs) that describe the level of performance customers can expect for services. This document describes the Ethernet performance management aspect of SLAs.

- Finding Feature Information

- Prerequisites for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

- Information About ITU-T Y.1731 Performance Monitoring in a Service Provider Network

- How to Configure ITU-T Y.1731 Performance Monitoring in a Service Provider Network

- Configuration Examples for Configuring ITU-T Y.1731 Performance Monitoring Functions

- Additional References

- Feature Information for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

- IEEE-compliant connectivity fault management (CFM) must be configured and enabled for Y.1731 performance monitoring to function.

Information About ITU-T Y.1731 Performance Monitoring in a Service Provider Network

- Frame Delay and Frame-Delay Variation

- Benefits of ITU-T Y.1731 Performance Monitoring

Frame Delay and Frame-Delay Variation

The Frame Delay parameter can be used for on-demand OAM measurements of frame delay and frame-delay variation. When a maintenance end point (MEP) is enabled to generate frames with frame-delay measurement (ETH-DM) information, it periodically sends frames with ETH-DM information to its peer MEP in the same maintenance entity. Peer MEPs perform frame-delay and frame-delay variation measurements through this periodic exchange during the diagnostic interval.

An MEP requires the following specific configuration information to support ETH-DM:

- MEG level—MEG level at which the MEP exists

- Priority

- Drop eligibility—marked drop ineligible

- Transmission rate

- Total interval of ETH-DM

- MEF10 frame-delay variation algorithm

A MEP transmits frames with ETH-DM information using the TxTimeStampf information element. TxTimeStampf is the time stamp for when the ETH-DM frame was sent. A receiving MEP can compare the TxTimeStampf value with the RxTimef value, which is the time the ETH-DM frame was received, and calculate one-way delay using the formula frame delay = RxTimef – TxTimeStampf.

One-way frame-delay measurement (1DM) requires that clocks at both the transmitting MEP and the receiving MEPs are synchronized. Measuring frame-delay variation does not require clock synchronization and the variation can be measured using 1DM or a frame-delay measurement message (DMM) and a frame-delay measurement reply (DMR) frame combination.

If it is not practical to have clocks synchronized, only two-way frame-delay measurements can be made. In this case, the MEP transmits a frame containing ETH-DM request information and the TxTimeStampf element, and the receiving MEP responds with a frame containing ETH-DM reply information and the TxTimeStampf valued copied from the ETH-DM request information.

Two-way frame delay is calculated as frame delay = RxTimeb – TxTimeStampf, where RxTimeb is the time that the frame with ETH-DM reply information was received. Two-way frame delay and variation can be measured using only DMM and DMR frames.

To allow more precise two-way frame-delay measurement, the MEP replying to a frame with ETH-DM request information can also include two additional time stamps in the ETH-DM reply information:

- RxTimeStampf—Time stamp of the time at which the frame with ETH-DM request information was received.

- TxTimeStampb—Time stamp of the time at which the transmitting frame with ETH-DM reply information was sent.

Note

Discard frame-delay and frame-delay variation measurements for continuity and availability faults or when known network topology changes occur.

An MIP is transparent to the frames with ETH-DM information; therefore, a MIP does not require information to support the ETH-DM function.

The figure below shows a functional overview of a typical network in which Y.1731 performance monitoring is used.

Y.1731 Performance Monitoring

Benefits of ITU-T Y.1731 Performance Monitoring

Combined with IEEE-compliant connectivity fault management (CFM), Y.1731 performance monitoring provides a comprehensive fault management and performance monitoring solution for service providers. This comprehensive solution in turn lessens service providers’ operating expenses, improves their service-level agreements (SLAs), and simplifies their operations.

How to Configure ITU-T Y.1731 Performance Monitoring in a Service Provider Network

- Configuring Performance Monitoring Parameters

Configuring Performance Monitoring Parameters

The following new commands were introduced that can be used to configure and display performance monitoring parameters: debug ethernet cfm pm, monitor loss counters, and show ethernet cfm pm.

For more information about CFM and Y.1731 performance monitoring commands, see the Cisco IOS Carrier Ethernet Command Reference. For more information about debug commands, see the Cisco IOS Debug Command Reference.

Configuration Examples for Configuring ITU-T Y.1731 Performance Monitoring Functions

- Example: Configuring Performance Monitoring

Example: Configuring Performance Monitoring

For Y.1731 performance monitoring configuration examples, see "Configuring IP SLAs Metro-Ethernet 3.0 ITU-T Y.1731 Operations" in the IP SLAs Configuration Guide.

Additional References

Related Documents

Related Topic

Document Title

MAC-in-MAC commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Commands List, All Releases

Standards

Standard

Title

IEEE 802.1ah

IEEE 802.1ah - Provider Backbone Bridges

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

RFCs

RFC

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 Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for ITU-T Y.1731 Performance Monitoring in a Service Provider Network

Feature Name

Releases

Feature Information

Y.1731 Performance Monitoring

Cisco IOS XE Release 3.5S

The Y.1731 Performance Monitoring feature describes the Ethernet performance monitoring aspect of SLAs such as frame loss, frame delay, and frame-delay variation.

In Cisco IOS XE Release 3.5S, support was added for the Cisco ASR 903 Router.

In Cisco IOS XE Release 3.6S, support for port channels and cross connect functionality was provided.

The following commands were introduced or modified: debug ethernet cfm pm, ethernet cfm distribution enable, monitor loss counters, show ethernet cfm pm.

Chapter 9. ICCP Multichassis VLAN Redundancy

Carrier Ethernet network high availability can be achieved by employing intra- and inter-chassis redundancy mechanisms. The Multichassis Link Aggregation Control Protocol (mLACP) solution addresses the latter, where a carrier wants dual-homed device (DHD) to two upstream points of attachment (PoA) for redundancy. Some carriers do not run loop prevention control protocols in their access networks, so an alternate redundancy scheme is necessary.

The implementation of mLACP supports DHD with an active/standby topology. Interchassis Communication Protocol (ICCP) Multichassis VLAN Redundancy, also known as Pseudo mLACP, provides a flexible dual-homing redundancy mechanism. It uses similar principles as mLACP. The Pseudo mLACP solution extends the mLACP functionality to support active/active PoAs deployments. This enables flexibility in network planning and efficient resource utilization.

Pseudo mLACP has the following advantages over mLACP:

- Pseudo mLACP supports per-VLAN active/active redundancy without any load-balancing requirements on the CE.

- Pseudo mLACP is independent of the access redundancy mechanism; therefore, it provides a network-based redundancy solution. It allows maximum flexibility for the Provider Edge (PE)-Customer Edge (CE) interoperability in terms of dual-homing redundancy and recovery.

- Finding Feature Information

- Prerequisites for ICCP Multichassis VLAN Redundancy

- Restrictions for ICCP Multichassis VLAN Redundancy

- Information About ICCP Multichassis VLAN Redundancy

- Pseudo mLACP Failover Operations

- How to Configure ICCP Multichassis VLAN Redundancy

- Configuration Examples for ICCP Multichassis VLAN Redundancy

- Additional References

- Feature Information for ICCP Multichassis VLAN Redundancy

- Glossary

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for ICCP Multichassis VLAN Redundancy

- mLACP support is required for Pseudo mLACP.

Restrictions for ICCP Multichassis VLAN Redundancy

- Max bundle should not be configured on a Pseudo mLACP enabled port channel.

- Pseudo mLACP does not work with most of the Layer 2 control protocols or Spanning Tree Protocol (STP) including Multiple Spanning Tree Protocol (MSTP) or VLAN Trunking Protocol (VTP).

- When a service instance is configured under a Pseudo mLACP port channel, all the outer tag VLANs of a service instance must be a part of either a primary VLAN list or a secondary VLAN list.

- Outer VLANs of one service instance cannot be mixed with the primary and secondary VLAN list on a Pseudo mLACP port channel.

- Brute-Force mode configuration is not supported.

- VLAN force-switchover configuration is applicable only for nonrevertive mode.

- The DHD nodes must support the LACP functionality.

- The DHD nodes must support MVRP MAC flush functionality in Pseudo mLACP topology.

- The Virtual Private LAN Services (VPLS)-Coupled mode is not supported.

- Hierarchical VPLS (H-VPLS) is not supported.

Information About ICCP Multichassis VLAN Redundancy

- Pseudo mLACP Multihoming Redundancy

- Pseudo mLACP Active/Active Support

- Failure Recovery

Pseudo mLACP Multihoming Redundancy

The provider edge (PE) ports are configured in such a way that they act as if connected to a virtual device over a Multichassis link aggregation group (MC-LAG) with mLACP. Points of Attachment (PoAs) can be placed in active/active mode with manual VLAN load balancing. DHD ports are configured into two individual port channels that are physically connected to each of the PoAs. Interchassis Communication Protocol (ICCP), with new extensions is used for interchassis communication to control the failover process. Multiple VLAN Registration Protocol (MVRP) lite is used for active VLAN notification and MAC flushing toward the access side. For MAC flushing notification toward the core, MVRP lite, Multiple I-SID Registration Protocol (MIRP) lite, or LDP MAC withdraw can be used.

Pseudo mLACP provides:

- The active/active mode redundancy of two PoAs in a redundancy group. This provides higher bandwidth utilization than mLACP and other active/standby link-level schemes. Pseudo mLACP eliminates the required wasted link bandwidth on the standby PoA.

- Flexible access network topologies, that is, access network dual-homing and access device dual-homing.

- Service provider control over the provisioning, role assignment, failover, and load sharing between PoAs.

- PE node redundancy for Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and native Ethernet aggregation.

The DHD is configured with two different port channels that are connected to a single multichassis LAG (mLAG) on the PoA side. The LACP module on the PoAs receives two different port keys from the two different port channels on the DHD. The mLAG on the PoA ignores the port keys from the DHD’s LACP PDUs to form a single bundle on the PoA side.

The mLACP module provides failover and recovery notifications to Pseudo mLACP. Reversion delay is processed by the mLACP module. mLACP provides a CLI interface for Pseudo mLACP VLANs and mode configuration. mLACP supports VLAN-based active/active redundancy, in addition to PoA-level active/standby redundancy. VLAN-based active/active redundancy allows you to bundle links on both the PoAs based on the Pseudo mLACP configuration. Pseudo mLACP and mLACP port-channels can be configured together on the same pair of PoAs, and both can use the same redundancy group.

After failover, the new active PoA activates the standby VLAN list on the port-channel. However, to receive traffic on the newly active VLAN’s DHD, networks must flush their MAC address table and learn the new MAC address of the new PoA port channel interface. The existing MVRP lite support is used for DHD-side MAC flushing.

Pseudo mLACP Active/Active Support

Pseudo mLACP supports active/active redundancy without the restriction of symmetric VLAN-based load sharing in both the Provider Edge (PE) and the Customer Edge (CE).

Active/Active Support

Pseudo mLACP provides VLAN-based redundancy by allowing you to specify one primary interface and one secondary interface or a PoA pair for each member VLAN. The configuration determines the PoA that will be initially active for a VLAN, by using the primary and secondary VLAN lists under the Pseudo mLACP interface. Only the active PoA will forward frames for the respective VLANs. The standby PoA will be in the blocking mode (bidirectional), dropping all the frames received on the standby VLANs. The failover will occur for all the VLANs in the active/standby list and not on a per-VLAN basis. Pseudo mLACP provides per-port-channel VLAN load balancing. You can statistically configure the primary and secondary VLAN list on each of the PoAs.

The DHD nodes are configured such that each of their uplinks to a PoA operates as an individual port channel. Each interface must be configured to forward all local VLANs on all uplinks belonging to the mLAG.

The data-path forwarding scheme causes the DHD to automatically learn which PoA or interface is active for a given VLAN. This learning occurs at an individual destination MAC address level.

Failure Recovery

Pseudo mLACP uses revertive behavior (which is the default behavior) after the failure recovery to support the active/active model. You can configure a nonrevertive mode.

Reversion occurs the same way that the original failover occurs. The reversion must be initiated by the new active PoA for the given VLANs, by signaling that the PoA is relinquishing its active role for the VLAN. This is done through an ICCP Pseudo mLACP port-state TLV, which indicates that it is no longer in the active mode for the affected VLANs. Upon a TLV receipt, the recovering PoA unblocks the affected VLANs, and triggers MAC flushes toward both the access side and the core side).

mLACP reversion delay applies for Pseudo mLACP operations. However, reversion occurs only for failed-over VLANs. The forced failover mechanism based on dynamic port-priority change cannot be used for Pseudo mLACP because all the member links will remain in the bundle state. Use the mlacp reversion-delay command to configure the mLACP reversion timer. Use the mlacp load-balance force-switchover portchannel command to configure forced VLAN switchover.

Pseudo mLACP Failover Operations

The Pseudo mLACP forces a PoA failover to the standby PoA when one of the following failures occurs:

Note

mLACP failover will not be triggered if Pseudo mLACP is not configured correctly. If the mLACP failover occurs before the peer PoA is configured with Pseudo mLACP, the failover will occur as long as the peer PoA meets the mLACP failover requirements.

- Access side link or port failure—This failure is triggered by a min-link failure. On receiving a min-link failure, all the active VLANs on the port-channel failover to the other PoA. This failover is initiated by sending a Pseudo mLACP PORT-STATE TLV message, indicating that the port state is DOWN.

- Node failure—The surviving PoA’s Pseudo mLACP receives notification of node failure and initiates failover of all VLANs that were in standby mode on all shared mLAGs. After recovery, both POAs synchronize again.

- PoA uplink failure—The failing PoA signals the peer about the core isolation using the Pseudo mLACP PORT-STATE TLV, indicating that the PoA is isolated. It places all the VLANs in the blocking mode.

How to Configure ICCP Multichassis VLAN Redundancy

- Configuring a Port Channel for Pseudo mLACP

Configuring a Port Channel for Pseudo mLACP

Perform this task to configure a port channel for Pseudo mLACP.

Before You Begin

Note

The redundancy group should be configured. Redundancy group configuration for Pseudo mLACP is the same as for mLACP.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface port-channel number

4.    mlacp interchassis group group-id

5.    mlacp mode active-active

6.    mlacp load-balance primary vlan vlan-id

7.    mlacp load-balance secondary vlan vlan-id

8.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

interface port-channel number

Example:

Router(config)# interface port-channel 1

Configures the port channel and enters interface configuration mode.

Step 4

mlacp interchassis group group-id

Example:

Router(config-if)# mlacp interchassis group 1

Specifies that the port channel is an mLACP port-channel .

Step 5

mlacp mode active-active

Example:

Router(config-if)# mlacp mode active-active

Enables pseudo mLACP operations on the PoA and allows the PoA to form an LACP bundle even if the partner receives an LACP PDU from two different port channels on a dual-homed network (DHN) or dual-homed device (DHD).

Step 6

mlacp load-balance primary vlan vlan-id

Example:

Router(config-if)# mlacp load-balance primary vlan 10,20

Configures the list of primary VLANs that will be active and inactive on the given PoA.

Step 7

mlacp load-balance secondary vlan vlan-id

Example:

Router(config-if)# mlacp load-balance secondary vlan 30,100

Configures the list of secondary VLANs that will be active and inactive on the given PoA.

Step 8

end

Example:

Router(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Configuration Examples for ICCP Multichassis VLAN Redundancy

- Example: Port Channel Configuration for Pseudo mLACP

Example: Port Channel Configuration for Pseudo mLACP

The following example shows how to configure the port channel on the active and standby PoA for Pseudo mLACP.

Active PoA-POA1

Router# configure terminal
Router(config)# interface port-channel1
Router(config-if)# mlacp interchassis group 1
Router(config-if)# mlacp mode active-active
Router(config-if)# mlacp load-balance primary vlan 10,20
Router(config-if)# mlacp load-balance secondary vlan 30,100
Router(config-if)# end

Standby PoA-POA2

Router# configure terminal
Router(config)# interface port-channel1
Router(config-if)# mlacp interchassis group 1
Router(config-if)# mlacp mode active-active
Router(config-if)# mlacp load-balance primary vlan 30,100
Router(config-if)# mlacp load-balance secondary vlan 10,20
Router(config-if)# end

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Carrier Ethernet commands

Cisco IOS Carrier Ethernet Command Reference

Standards and RFCs

Standard/RFC

Title

IEEE 802.3ad

Link Aggregation Control Protocol

IEEE 802.1ak

Multiple Registration Protocol

RFC 4447

Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)

RFC 4762

Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling

MIBs

MIB

MIBs Link

- Cisco-LAG-MIB

- IEEE 802.3ad-MIB

- IEEE8023-LAG-MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for ICCP Multichassis VLAN Redundancy

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for ICCP Multiichassis VLAN Redundancy

Feature Name

Releases

Feature Information

ICCP Multichassis VLAN Redundancy

15.1(3)S

Pseudo mLACP provides a flexible dual-homing redundancy mechanism. It uses similar principles as mLACP, but without the implementation of LACP between the PEs and CEs. The PE ports are configured in such a way that they act as if connected to a virtual device over an MC-LAG with mLACP. Ports can be placed in active/active mode with manual VLAN load balancing.

The following commands were introduced or modified: debug lacp, debug mvrp, mlacp load-balance, mlacp load-balance force-switchover, mlacp mode active-active, mlacp reversion-delay, show lacp.

Glossary

active attachment circuit—The link that is actively forwarding traffic between the DHD and the active PoA.

active PW—The pseudowire that is forwarding traffic on the active PoA.

BD—bridge domain.

BFD—bidirectional forwarding detection.

DHD—dual-homed device. A node that is connected to two switches over a multichassis link aggregation group for the purpose of redundancy.

DHN—dual-homed network. A network that is connected to two switches to provide redundancy.

H-VPLS—Hierarchical Virtual Private LAN Service.

ICC—Interchassis Communication Channel.

ICCP—Interchassis Communication Protocol.

ICPM—Interchassis Protocol Manager.

ICRM—Interchassis Redundancy Manager.

LACP—Link Aggregation Control Protocol.

LAG—link aggregation group.

LDP—Link Distribution Protocol.

MCEC—Multichassis EtherChannel.

mLACP—Multichassis LACP.

PoA—point of attachment. One of a pair of switches running multichassis link aggregation group with a DHD.

PW-RED—pseudowire redundancy.

standby attachment circuit—The link that is in standby mode between the DHD and the standby PoA.

standby PW—The pseudowire that is in standby mode on either an active or a standby PoA.

uPE—user-facing Provider Edge.

VPLS—Virtual Private LAN Service.

VPWS—Virtual Private Wire Service.

Chapter 10. Trunk EFP Support

The Trunk EFP Support feature provides support for Ethernet flow points (EFPs) on trunk ports. A trunk port allows a range of VLANs to be forwarded on a given interface while still maintaining data-plane segmentation between the VLANs.

- Finding Feature Information

- Restrictions for Trunk EFP Support

- Information About Trunk EFP Support

- How to Enable Trunk EFP Support

- Configuration Examples for Trunk EFP Support

- Additional References

- Feature Information for Trunk EFP Support

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Restrictions for Trunk EFP Support

- The rewrite ingress tag pop 1 symmetric command is the only rewrite command that is supported for trunk EFP configurations. The rewrite ingress tag pop 1 symmetric command must be included in the configuration when the Trunk EFP Support feature is enabled.

- A bridge-domain number that is part of a trunk EFP configuration cannot be shared by other EFPs under the same port or interface.

- Only one trunk EFP can be configured under one port or interface.

- All features configured on a trunk EFP (other than encapsulations and bridge-domain assignments) are applied uniformly to all VLANs and bridge domains. If a feature requires VLAN-specific or bridge-domain-specific configuration values, the feature cannot be applied on the trunk EFP. Those special VLANs or bridge domains must be removed from the EFP trunk to form individual EFPs.

Information About Trunk EFP Support

- Benefits of Trunk EFP Support

- Ethernet Flow Points

- Trunk Ports

Benefits of Trunk EFP Support

The Carrier Ethernet infrastructure supports the following types of Ethernet flow points (EFPs):

- Static EFPs that are user-configurable.

- Dynamic EFPs that are created and maintained during a Cisco Intelligent Services Gateway ( ISG) session.

With this feature, a new EFP type has been added that is intended for use on a trunk port.

A trunk port allows a range of VLANs to be forwarded on a given interface while maintaining data-plane segmentation between the VLANs.

Note

Like a static EFP, this new type of EFP is user-configurable via the service instance trunk command, the encapsulation command, and the bridge-domain from-encapsulation command when the Trunk EFP Support feature is enabled.

Ethernet Flow Points

An Ethernet flow point (EFP) is a forwarding decision point in the provider edge (PE) router, which gives network designers flexibility to make many Layer 2 flow decisions within the interface. Many EFPs can be configured on a single physical port. (The number varies from one device to another.) EFPs are the logical demarcation points of an Ethernet virtual connection (EVC) on an interface. An EVC that uses two or more user network interfaces (UNIs) requires an EFP on the associated ingress and egress interfaces of every device that the EVC passes through.

EFPs can be configured on any Layer 2 traffic port; however, they are usually configured on UNI ports. The following parameters (matching criteria) can be configured on the EFP:

- Frames of a specific VLAN, a VLAN range, or a list of VLANs (100-150 or 100,103,110)

- Frames with no tags (untagged)

- Frames with identical double-tags (VLAN tags) as specified

- Frames with identical Class of Service (CoS) values

A frame passes each configured match criterion until the correct matching point is found. If a frame does not fit any of the matching criteria, it is dropped. Default criteria can be configured to avoid dropping frames.

The following types of commands can be used in an EFP:

- Rewrite commands—In each EFP, VLAN tag management can be specified with the following actions:

- Pop—1) pops out a tag; 2) pops out two tags

- Push— pushes in a tag

- Translate—1 to 1) changes a tag value; 1 to 2) pops one tag and pushes two tags; 2 to 1) pops two tags and pushes one tag; 2 to 2) changes the value for two tags

- Forwarding commands—Each EFP specifies the forwarding command for the frames that enter the EFP. Only one forwarding command can be configured per EFP. The forwarding options are as follows:

- Layer 2 point-to-point forwarding to a pseudowire tunnel

- Multipoint bridge forwarding to a bridge domain entity

- Local switch-to-switch forwarding between two different interfaces

- Feature commands—In each EFP, the QoS features or parameters can be changed and the ACL can be updated.

Trunk Ports

An Ethernet interface can be configured as a trunk port (interface). A trunk port, also known as a trunk, is a point-to-point link between a networking device and another networking device. Trunks carry the traffic of multiple VLANs over a single link and allow you to extend VLANs across an entire network. A trunk port configured on the interface with two or more VLANs can carry traffic for several VLANs simultaneously.

To correctly deliver the traffic on a trunk port with several VLANs, the device uses the IEEE 802.1Q encapsulation or tagging method.

How to Enable Trunk EFP Support

- Enabling Trunk EFP Support

- Verifying the Trunk EFP Support Configuration

Enabling Trunk EFP Support

To enable Ethernet flow point (EFP) support on a trunk port or trunk interface, complete the following steps.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance trunk id ethernet

5.    encapsulation dot1q vlan-id [, vlan-id [- vlan-d]]

6.    rewrite ingress tag pop 1 symmetric

7.    bridge-domain from-encapsulation

8.    no shutdown

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Configures the interface and enters interface configuration mode.

Step 4

service instance trunk id ethernet

Example:

Device(config-if)# service instance trunk 1 ethernet

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 5

encapsulation dot1q vlan-id [, vlan-id [- vlan-d]]

Example:

Device(config-if-srv)# encapsulation dot1q 1-5, 7, 9-12

Defines the matching criteria to map 802.1Q frames ingress on an interface to the appropriate service instance.

Step 6

rewrite ingress tag pop 1 symmetric

Example:

Device(config-if-srv)# rewrite ingress tag pop 1 symmetric

Specifies the encapsulation adjustment to be performed on a frame that is entering a service instance.

Step 7

bridge-domain from-encapsulation

Example:

Device(config-if-srv)# bridge-domain from-encapsulation

Creates a list of bridge domains for an EFP trunk port using the bridge-domain IDs derived from the encapsulation VLAN numbers.

Step 8

no shutdown

Example:

Device(config-if-srv)# no shutdown

Disables shutdown and keeps the interface or port active.

Step 9

end

Example:

Device(config-if-srv)# end

Returns to privileged EXEC mode.

Verifying the Trunk EFP Support Configuration

Use one or more of the commands listed below to verify the Trunk EFP Support feature configuration.

SUMMARY STEPS

1.    enable

2.    show ethernet service instance

3.    show ethernet service instance interface [interface]

4.    show bridge-domain

5.    exit

DETAILED STEPS

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet service instance

Example:

Device# show ethernet service instance

Displays information about Ethernet service instances.

Step 3

show ethernet service instance interface [interface]

Example:

Device# show ethernet service instance interface gigabitethernet2/0/1

Displays interface-only information about Ethernet service instances for all interfaces or for a specified interface.

Step 4

show bridge-domain

Example:

Device# show bridge-domain

Displays bridge-domain information.

Step 5

exit

Example:

Device# exit

Exits privileged EXEC mode.

Configuration Examples for Trunk EFP Support

- Example: Configuring Trunk EFP Support

- Example: Verifying the Trunk EFP Support Configuration

Example: Configuring Trunk EFP Support

In the following example, EFP support has been configured on a trunk interface.

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet2/0/1
Device(config-if)# service instance trunk 1 ethernet
Device(config-if-srv)# encapsulation dot1q 1 - 5, 7, 9 - 12
Device(config-if-srv)# rewrite ingress tag pop 1 symmetric
Device(config-if-srv)# bridge-domain from-encapsulation
Device(config-if-srv)# no shutdown
Device(config-if-srv)# end

Example: Verifying the Trunk EFP Support Configuration

The following is sample output from the show ethernet service instance command. The output displays trunk as the service instance type and indicates that a bridge domain for VLANs in the range of 12 to 1900 (as specified by the encapsulation parameters) has been created for service instance 4000 on a trunk port (interface).

Device# show ethernet service instance id 4000 interface gigabitethernet0/0/5 detail

Service Instance ID: 4000
Service Instance Type: Trunk
Associated Interface: GigabitEthernet0/0/5
Associated EVC:
L2protocol drop
CE-Vlans:
Encapsulation: dot1q 12-1900 vlan protocol type 0x8100
Rewrite: ingress tag pop 1 symmetric
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
Pkts In   Bytes In   Pkts Out  Bytes Out
168729725 10798985220  160246675 10255787200
EFP Microblocks:
****************
Microblock type: Bridge-domain
Bridge-domain: 12-1900

Additional References

Related Documents

Related Topic

Document Title

Ethernet CFM

Configuring Ethernet Connectivity Fault Management in a Service Provider Network

IEEE 802.3ah

IEEE 802.3ah Ethernet in the First Mile

ITU-T Y.1731 fault management functions

Configuring ITU-T Y.1731 Fault Management Functions

Delivering and filtering syslog messages

Reliable Delivery and Filtering for Syslog

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Cisco IOS Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Standards

Standard

Title

IEEE P802.1ag/D1.0

Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management

IETF VPLS OAM

L2VPN OAM Requirements and Framework

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

MIBs

MIB

MIBs Link

- CISCO-ETHER-CFM-MIB

- CISCO-IEEE-CFM-MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

RFCs

RFC

Title

RFC 3164

The BSD syslog Protocol

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Trunk EFP Support

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Trunk EFP Support

Feature Name

Releases

Feature Information

Trunk EFP Support

Cisco IOS XE Release 3.5S

This feature provides support for Ethernet Flow Points (EFPs) on trunk ports (interfaces).

In Cisco IOS XE Release 3.5S, support was added for the Cisco ASR 903 Router.

The following commands were introduced or modified: bridge-domain from-encapsulation, encapsulation dot1q (service instance), rewrite ingress tag,service instance ethernet, show bridge-domain, show ethernet service instance, and show ethernet service interface.

Chapter 11. ITU-T G.8032 Ethernet Ring Protection Switching

The ITU-T G.8032 Ethernet Ring Protection Switching feature implements protection switching mechanisms for Ethernet layer ring topologies. This feature uses the G.8032 Ethernet Ring Protection (ERP) protocol, defined in ITU-T G.8032, to provide protection for Ethernet traffic in a ring topology, while ensuring that no loops are within the ring at the Ethernet layer. The loops are prevented by blocking traffic on either a predetermined link or a failed link.

- Finding Feature Information

- Prerequisites for Configuring ITU-T G.8032 Ethernet Ring Protection Switching

- About ITU-T G.8032 Ethernet Ring Protection Switching

- How to Configure ITU-T G.8032 Ethernet Ring Protection Switching

- Configuration Examples for ITU-T G.8032 Ethernet Ring Protection Switching

- Additional References for ITU-T G.8032 Ethernet Ring Protection Switching

- Feature Information For ITU-T G.8032 Ethernet Ring Protection Switching

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Configuring ITU-T G.8032 Ethernet Ring Protection Switching

- The Ethernet Flow Points (EFPs) must be configured.

About ITU-T G.8032 Ethernet Ring Protection Switching

- Ring Protection Links

- ITU-T G.8032 Ethernet Ring Protection Switching Functionality

- R-APS Control Messages

- CFM Protocols and Link Failures

- G.8032 Ring-Supported Commands and Functionality

- G.8032 ERP Timers

- Protection Switching Functionality in a Single Link Failure and Recovery

- Ethernet Flow Points

- Service Instances and Associated EFPs

Ring Protection Links

An Ethernet ring consists of multiple Ethernet ring nodes. Each Ethernet ring node is connected to adjacent Ethernet ring nodes using two independent ring links. A ring link prohibits formation of loops that affect the network. The Ethernet ring uses a specific link to protect the entire Ethernet ring. This specific link is called the Ring Protection Link (RPL). A ring link is bound by two adjacent Ethernet ring nodes and a port for a ring link (also known as a ring port). There must be at least two Ethernet ring nodes in a Ethernet ring.

ITU-T G.8032 Ethernet Ring Protection Switching Functionality

The Ethernet ring protection functionality includes the following:

- Loop avoidance

- The use of learning, forwarding, and Filtering Database (FDB) mechanisms

Loop avoidance in an Ethernet ring is achieved by ensuring that, at any time, traffic flows on all but the Ring Protection Link (RPL).

The following is a list of RPL types (or RPL nodes) and their functions:

- RPL owner—Responsible for blocking traffic over the RPL so that no loops are formed in the Ethernet traffic. There can be only one RPL owner in a ring.

- RPL neighbor node—An Ethernet ring node adjacent to the RPL. It is responsible for blocking its end of the RPL under normal conditions. This node type is optional and prevents RPL usage when protected.

- RPL next-neighbor node—Next-neighbor node is an Ethernet ring node adjacent to an RPL owner node or RPL neighbor node. It is mainly used for FDB flush optimization on the ring. This node is also optional.

The following figure illustrates the G.8032 Ethernet ring topology.

G.8032 Ethernet Ring Topology

R-APS Control Messages

Nodes on the ring use control messages called Ring Automatic Protection Switching (R-APS) messages to coordinate the activities of switching the ring protection link (RPL) on and off. Any failure along the ring triggers a R-APS Signal Failure (R-APS SF) message in both directions of the nodes adjacent to the failed link, after the nodes have blocked the port facing the failed link. On obtaining this message, the RPL owner unblocks the RPL port.

Note

A single link failure in the ring ensures a loop-free topology.

CFM Protocols and Link Failures

Connectivity Fault Management (CFM) and line status messages are used to detect ring link and node failure. During the recovery phase, when the failed link is restored, the nodes adjacent to the restored link send Ring Automatic Protection Switching (R-APS) No Request (R-APS NR) messages. On obtaining this message, the ring protection link (RPL) owner blocks the RPL port and sends R-APS NR and R-APS RPL (R-APS NR, RB) messages. These messages cause all other nodes, other than the RPL owner in the ring, to unblock all blocked ports. The Ethernet Ring Protection (ERP) protocol works for both unidirectional failure and multiple link failure scenarios in a ring topology.

Note

The G.8032 Ethernet Ring Protection (ERP) protocol uses CFM Continuity Check Messages (CCMs) at an interval of 3.3 milliseconds (ms). At this interval (which is supported only on selected platforms), SONET-like switching time performance and loop-free traffic can be achieved.

G.8032 Ring-Supported Commands and Functionality

A G.8032 ring supports these basic operator administrative commands:

- Force switch (FS)—Allows the operator to forcefully block a particular ring port. Note the following points about FS commands:

- Effective even if there is an existing SF condition

- Multiple FS commands for ring are supported

- May be used to allow immediate maintenance operations

- Manual switch (MS)—Allows the operator to manually block a particular ring port. Note the following points about MS commands:

- Ineffective in an existing FS or signal failure (SF) condition

- Overridden by new FS or SF conditions

- Multiple MS commands cancel all MS commands

- Clear—Cancels an existing FS or MS command on the ring port. The Clear command is used at the ring protection link (RPL) owner to clear a nonrevertive mode condition.

A G.8032 ring can support multiple instances. An instance is a logical ring running over a physical ring. Such instances are used for various reasons, such as load-balancing VLANs over a ring. For example, odd-numbered VLANs may go in one direction of the ring, and even-numbered VLANs may go in the other direction. Specific VLANs can be configured under only one instance. They cannot overlap multiple instances. Otherwise, data traffic or Ring Automatic Protection Switching (R-APS) messages may cross logical rings, which is not desirable.

G.8032 ERP Timers

The G.8032 Ethernet Ring Protection (ERP) protocol specifies the use of different timers to avoid race conditions and unnecessary switching operations:

- Delay timers—Used by the Ring Protection Link (RPL) owner to verify that the network has stabilized before blocking the RPL. Note the following points about delay timers.

- After a signal failure (SF) condition, a Wait-to-Restore (WTR) timer is used to verify that the SF is not intermittent.

- The WTR timer can be configured by the operator. The default time interval is 5 minutes; the time interval ranges from 1 to 12 minutes.

- After a force switch (FS) or a manual switch (MS) command is issued, a Wait-to-Block (WTB) timer is used to verify that no background condition exists.

Note

The WTB timer interval may be shorter than the WTR timer interval.

- Guard timer—Used by all nodes when changing state; the guard timer blocks latent outdated messages from causing unnecessary state changes. The guard timer can be configured. The default time interval is 500 ms; the time interval ranges from 10 to 2000 ms.

- Hold-off timers—Used by the underlying Ethernet layer to filter out intermittent link faults. The hold-off timer can be configured. The default time interval is 0 seconds; the time interval ranges from 0 to 10 seconds. Faults are reported to the ring protection mechanism only if this timer expires.

Protection Switching Functionality in a Single Link Failure and Recovery

The following figure illustrates protection switching functionality in a single-link failure.

G.8032 Ethernet Ring Protection Switching in a Single-Link Failure

The figure represents an Ethernet ring topology consisting of seven Ethernet ring nodes. The ring protection link (RPL) is the ring link between Ethernet ring nodes A and G. In this topology, both ends of the RPL are blocked. Ethernet ring node G is the RPL owner node, and Ethernet ring node A is the RPL neighbor node.

The following sequence describes the steps followed in the single-link failure:

1. A link operates in the normal condition.

2. A failure occurs.

3. Ethernet ring nodes C and D detect a local signal failure (SF) condition and after the hold-off time interval, block the failed ring port and perform the FDB flush.

4. Ethernet ring nodes C and D start sending Ring Automatic Protection Switching (R-APS) SF messages periodically along with the (node ID and bidirectional path-protected ring (BPR) identifier pair) on both ring ports while the SF condition persists.

5. All Ethernet ring nodes receiving an R-APS SF message perform the FDB flush. When the RPL owner node G and RPL neighbor node A receive an R-APS SF message, the Ethernet ring node unblocks its end of the RPL and performs the FDB flush.

6. All Ethernet ring nodes receiving a second R-APS SF message perform the FDB flush again; the additional FDB flush is because of the node ID and BPR-based configuration.

7. R-APS SF messages are detected on the Ethernet Ring indicating a stable SF condition. Further R-APS SF messages trigger no further action.

The following figure illustrates the steps taken in a revertive operation in a single-link failure.

Single-Link Failure Recovery (Revertive Operation)

The following sequence describes the steps followed in the single-link failure revertive (recovery) operation:

1. A link operates in the stable SF condition.

2. Recovery of link failure occurs.

3. Ethernet ring nodes C and D detect clearing of the SF condition, start the guard timer, and initiate periodic transmission of the R-APS No Request (NR) messages on both ring ports. (The guard timer prevents the reception of R-APS messages.)

4. When the Ethernet ring nodes receive an R-APS NR message, the node ID and BPR identifier pair of a receiving ring port is deleted and the RPL owner node starts the Wait-to-Restore (WTR) timer.

5. When the guard timer expires on Ethernet ring nodes C and D, the nodes may accept the new R-APS messages, if any. Ethernet ring node D receives an R-APS NR message with a higher node ID from Ethernet ring node C, and unblocks its nonfailed ring port.

6. When the WTR timer expires, the RPL owner node blocks its end of the RPL, sends R-APS (NR or route blocked [RB]) message with the (node ID and BPR identifier pair), and performs the FDB flush.

7. When Ethernet ring node C receives an R-APS (NR or RB) message, the node removes the block on its blocked ring ports, and stops sending R-APS NR messages. On the other hand, when the RPL neighbor node A receives an R-APS NR or RB message, the node blocks its end of the RPL. In addition, Ethernet ring nodes A to F perform the FDB flush when receiving an RAPS NR or RB message because of the node ID and BPR-based configuration.

Ethernet Flow Points

An Ethernet flow point (EFP) is a forwarding decision point in the provider edge (PE) router, which gives network designers flexibility to make many Layer 2 flow decisions within the interface. Many EFPs can be configured on a single physical port. (The number varies from one device to another.) EFPs are the logical demarcation points of an Ethernet virtual connection (EVC) on an interface. An EVC that uses two or more user network interfaces (UNIs) requires an EFP on the associated ingress and egress interfaces of every device that the EVC passes through.

EFPs can be configured on any Layer 2 traffic port; however, they are usually configured on UNI ports. The following parameters (matching criteria) can be configured on the EFP:

- Frames of a specific VLAN, a VLAN range, or a list of VLANs (100-150 or 100,103,110)

- Frames with no tags (untagged)

- Frames with identical double-tags (VLAN tags) as specified

- Frames with identical Class of Service (CoS) values

A frame passes each configured match criterion until the correct matching point is found. If a frame does not fit any of the matching criteria, it is dropped. Default criteria can be configured to avoid dropping frames.

The following types of commands can be used in an EFP:

- Rewrite commands—In each EFP, VLAN tag management can be specified with the following actions:

- Pop—1) pops out a tag; 2) pops out two tags

- Push— pushes in a tag

- Translate—1 to 1) changes a tag value; 1 to 2) pops one tag and pushes two tags; 2 to 1) pops two tags and pushes one tag; 2 to 2) changes the value for two tags

- Forwarding commands—Each EFP specifies the forwarding command for the frames that enter the EFP. Only one forwarding command can be configured per EFP. The forwarding options are as follows:

- Layer 2 point-to-point forwarding to a pseudowire tunnel

- Multipoint bridge forwarding to a bridge domain entity

- Local switch-to-switch forwarding between two different interfaces

- Feature commands—In each EFP, the QoS features or parameters can be changed and the ACL can be updated.

Service Instances and Associated EFPs

Configuring a service instance on a Layer 2 port creates a pseudoport or EFP on which you configure EVC features. Each service instance has a unique number per interface, but you can use the same number on different interfaces because service instances on different ports are not related.

An EFP classifies frames from the same physical port to one of the multiple service instances associated with that port, based on user-defined criteria. Each EFP can be associated with different forwarding actions and behavior.

When an EFP is created, the initial state is UP. The state changes to DOWN under the following circumstances:

- The EFP is explicitly shut down by a user.

- The main interface to which the EFP is associated is down or removed.

- If the EFP belongs to a bridge domain, the bridge domain is down.

- The EFP is forced down as an error-prevention measure of certain features.

Use the service instance ethernet interface configuration command to create an EFP on a Layer 2 interface and to enter service instance configuration mode. Service instance configuration mode is used to configure all management and control data plane attributes and parameters that apply to the service instance on a per-interface basis. The service instance number is the EFP identifier.

After the device enters service instance configuration mode, you can configure these options:

- default--Sets a command to its defaults

- description--Adds a service instance-specific description

- encapsulation--Configures Ethernet frame match criteria

- exit--Exits from service instance configuration mode

- no--Negates a command or sets its defaults

- shutdown--Takes the service instance out of service

How to Configure ITU-T G.8032 Ethernet Ring Protection Switching

- Configuring the Ethernet Ring Profile

- Configuring Ethernet CFM MEPs

- Enabling Ethernet Fault Detection for a Service

- Configuring the Ethernet Protection Ring

- Configuring Topology Change Notification Propagation

- Configuring a Service Instance

- Verifying the Ethernet Ring Protection (ERP) Switching Configuration

Configuring the Ethernet Ring Profile

To configure the Ethernet ring profile, complete the following steps.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet ring g8032 profile profile-name

4.    timer {guard seconds | hold-off seconds | wtr minutes}

5.    non-revertive

6.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet ring g8032 profile profile-name

Example:

Device(config)# ethernet ring g8032 profile profile1

Creates the Ethernet ring profile and enters Ethernet ring profile configuration mode.

Step 4

timer {guard seconds | hold-off seconds | wtr minutes}

Example:

Device(config-erp-profile)# timer hold-off 5

Specifies the time interval for the guard, hold-off, and Wait-to-Restore (WTR) timers.

Step 5

non-revertive

Example:

Device(config-erp-profile)# non-revertive

Specifies a nonrevertive Ethernet ring instance.

- By default, Ethernet ring instances are revertive.

Step 6

end

Example:

Device(config-erp-profile)# end

Returns to user EXEC mode.

Configuring Ethernet CFM MEPs

Configuring Ethernet Connectivity Fault Management (CFM) maintenance endpoints (MEPs) is optional although recommended for fast failure detection and CFM monitoring. When CFM monitoring is configured, note the following points:

- Static remote MEP (RMEP) checking should be enabled.

- The MEPs should be configured to enable Ethernet fault detection.

For information about configuring Ethernet Connectivity Fault Management (CFM) maintenance endpoints (MEPs), see the “Configuring Ethernet Connectivity Fault Management in a Service Provider Network” module of the Carrier Ethernet Configuration Guide.

Enabling Ethernet Fault Detection for a Service

To enable Ethernet Fault Detection (EFD) for a service to achieve fast convergence, complete the following steps

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm global

4.    link-protection enable

5.    link-protection group management vlan vlan-id

6.    link-protection group group-number pccm vlan vlan-id

7.    ethernet cfm domaindomain-name level level-id [direction outward]

8.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

9.    continuity-check [interval time | loss-threshold threshold | static rmep]

10.    efd notify g8032

11.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm global

Example:

Device(config)# ethernet cfm global

Enables Ethernet CFM globally.

Step 4

link-protection enable

Example:

Device(config)# link-protection enable

Enables link protection globally on the router.

Step 5

link-protection group management vlan vlan-id

Example:

Device(config)# link-protection group management vlan 51

Defines the management VLAN used for link protection.

Step 6

link-protection group group-number pccm vlan vlan-id

Example:

Device(config)# link-protection group 2 pccm vlan 16

Specifies an ODU-to-ODU continuity check message (P-CCM) VLAN.

Step 7

ethernet cfm domaindomain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain G8032 level 4

Configures the CFM domain for ODU 1 and enters Ethernet CFM configuration mode.

Step 8

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Device(config-ecfm)# service 8032_service evc 8032-evc vlan 1001 direction down

Defines a maintenance association for ODU 1 and enters Ethernet CFM service instance configuration mode.

Step 9

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Device(config-ecfm-srv)# continuity-check interval 3.3ms

Enables the transmission of continuity check messages (CCMs).

Step 10

efd notify g8032

Example:

Device(config-ecfm-srv)# efd notify g8032

Enables CFM to notify registered protocols when a defect is detected or cleared, which matches the current fault alarm priority.

Step 11

end

Example:

Device(config-ecfm-srv)# end

Returns to user EXEC mode.

Configuring the Ethernet Protection Ring

To configure the Ethernet Protection Ring (EPR), complete the following steps.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet ring g8032 ring-name

4.    port0 interface type number

5.    monitor service instance instance-id

6.    exit

7.    port1 {interfacetype number | none}

8.    monitor service instance instance-id

9.    exit

10.    exclusion-list vlan-ids vlan-id

11.    open-ring

12.    instance instance-id

13.    description descriptive-name

14.    profile profile-name

15.    rpl {port0 | port1} {owner | neighbor | next-neighbor }

16.    inclusion-list vlan-ids vlan-id

17.    aps-channel

18.    level level-value

19.    port0 service instance instance-id

20.    port1 service instance {instance-id | none }

21.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet ring g8032 ring-name

Example:

Device(config)# ethernet ring g8032 ring1

Specifies the Ethernet ring and enters Ethernet ring port configuration mode.

Step 4

port0 interface type number

Example:

Device(config-erp-ring)# port0 interface fastethernet 0/1/0

Connects port0 of the local node of the interface to the Ethernet ring and enters Ethernet ring protection mode.

Step 5

monitor service instance instance-id

Example:

Device(config-erp-ring-port)# monitor service instance 1

Assigns the Ethernet service instance to monitor the ring port (port0) and detect ring failures.

Step 6

exit

Example:

Device(config-erp-ring-port)# exit

Exits Ethernet ring port configuration mode.

Step 7

port1 {interfacetype number | none}

Example:

Device(config-erp-ring)# port1 interface fastethernet 0/1/1

Connects port1 of the local node of the interface to the Ethernet ring and enters Ethernet ring protection mode.

Step 8

monitor service instance instance-id

Example:

Device(config-erp-ring-port)# monitor service instance 2

Assigns the Ethernet service instance to monitor the ring port (port1) and detect ring failures.

- The interface (to which port1 is attached) must be a subinterface of the main interface.

Step 9

exit

Example:

Device(config-erp-ring-port)# exit

Exits Ethernet ring port configuration mode.

Step 10

exclusion-list vlan-ids vlan-id

Example:

Device(config-erp-ring)# exclusion-list vlan-ids 2

Specifies VLANs that are unprotected by the Ethernet ring protection mechanism.

Step 11

open-ring

Example:

Device(config-erp-ring)# open-ring

Specifies the Ethernet ring as an open ring.

Step 12

instance instance-id

Example:

Device(config-erp-ring)# instance 1

Configures the Ethernet ring instance and enters Ethernet ring instance configuration mode.

Step 13

description descriptive-name

Example:

Device(config-erp-inst)# description cisco_customer_instance

Specifies a descriptive name for the Ethernet ring instance.

Step 14

profile profile-name

Example:

Device(config-erp-inst)# profile profile1

Specifies the profile associated with the Ethernet ring instance.

Step 15

rpl {port0 | port1} {owner | neighbor | next-neighbor }

Example:

Device(config-erp-inst)# rpl port0 neighbor

Specifies the Ethernet ring port on the local node as the RPL owner, neighbor, or next neighbor.

Step 16

inclusion-list vlan-ids vlan-id

Example:

Device(config-erp-inst)# inclusion-list vlan-ids 11

Specifies VLANs that are protected by the Ethernet ring protection mechanism.

Step 17

aps-channel

Example:

Device(config-erp-inst)# aps-channel

Enters Ethernet ring instance aps-channel configuration mode.

Step 18

level level-value

Example:

Device(config-erp-inst-aps)# level 5

Specifies the Automatic Protection Switching (APS) message level for the node on the Ethernet ring.

- All nodes in the Ethernet ring must be configured with the same level.

Step 19

port0 service instance instance-id

Example:

Device(config-erp-inst-aps)# port0 service instance 100

Associates APS channel information with port0.

Step 20

port1 service instance {instance-id | none }

Example:

Device(config-erp-inst-aps)# port1 service instance 100

Associates APS channel information with port1.

Step 21

end

Example:

Device(config-erp-inst-aps)# end

Returns to user EXEC mode.

Configuring Topology Change Notification Propagation

To configure topology change notification (TCN) propagation, complete the following steps.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet tcn-propagation G8032 to {REP | G8032}

4.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet tcn-propagation G8032 to {REP | G8032}

Example:

Device(config)# ethernet tcn-propagation G8032 to G8032

Allows topology change notification (TCN) propagation from a source protocol to a destination protocol.

- Source and destination protocols vary by platform and release.

Step 4

end

Example:

Device(config)# end

Returns to user EXEC mode.

Configuring a Service Instance

To configure a service instance, complete the following steps.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance instance-id ethernet [evc-id]

5.    encapsulation dot1q vlan-id [native]

6.    bridge-domain bridge-id [split-horizon [group group-id]]

7.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface fastethernet 4/0/0

Specifies the interface type and number.

Step 4

service instance instance-id ethernet [evc-id]

Example:

Device(config-if)# service instance 101 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id [native]

Example:

Device(config-if-srv)# encapsulation dot1q 13

Defines the matching criteria to be used in order to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id [split-horizon [group group-id]]

Example:

Device(config-if-srv)# bridge-domain 12

Binds the service instance to a bridge domain instance.

Step 7

end

Example:

Device(config-if-srv)# end

Exits service instance configuration mode.

Verifying the Ethernet Ring Protection (ERP) Switching Configuration

To verify the ERP switching configuration, use one or more of the following commands in any order.

SUMMARY STEPS

1.    enable

2.    show ethernet ring g8032 status [ring-name] [instance [instance-id]]

3.    show ethernet ring g8032 brief [ring-name] [instance [instance-id]]

4.    show ethernet ring g8032 summary

5.    show ethernet ring g8032 statistics [ring-name] [instance [instance-id]]

6.    show ethernet ring g8032 profile [profile-name]

7.    show ethernet ring g8032 port status interface [type number]

8.    show ethernet ring g8032 configuration [ring-name] instance [instance-id]

9.    show ethernet ring g8032 trace {ctrl [ring-name instance instance-id] | sm}

10.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet ring g8032 status [ring-name] [instance [instance-id]]

Example:

Device# show ethernet ring g8032 status RingA instance 1

Displays a status summary for the ERP instance.

Step 3

show ethernet ring g8032 brief [ring-name] [instance [instance-id]]

Example:

Device# show ethernet ring g8032 brief

Displays a brief description of the functional state of the ERP instance.

Step 4

show ethernet ring g8032 summary

Example:

Device# show ethernet ring g8032 summary

Displays a summary of the number of ERP instances in each state of the ERP switching process.

Step 5

show ethernet ring g8032 statistics [ring-name] [instance [instance-id]]

Example:

Device# show ethernet ring g8032 statistics RingA instance 1

Displays the number of events and Ring Automatic Protection Switching (R-APS) messages received for an ERP instance.

Step 6

show ethernet ring g8032 profile [profile-name]

Example:

Device# show ethernet ring g8032 profile gold

Displays the settings for one or more ERP profiles.

Step 7

show ethernet ring g8032 port status interface [type number]

Example:

Device# show ethernet ring g8032 port status interface fastethernet 0/0/1

Displays Ethernet ring port status information for the interface.

Step 8

show ethernet ring g8032 configuration [ring-name] instance [instance-id]

Example:

Device# show ethernet ring g8032 configuration RingA instance 1

Displays the details of the ERP instance configuration manager.

Step 9

show ethernet ring g8032 trace {ctrl [ring-name instance instance-id] | sm}

Example:

Device# show ethernet ring g8032 trace sm

Displays information about ERP traces.

Step 10

end

Example:

Device# end

Returns to privileged EXEC mode.

Configuration Examples for ITU-T G.8032 Ethernet Ring Protection Switching

- Example: Configuring Ethernet Ring Protection Switching

- Example: Enabling Ethernet Fault Detection for a Service

- Example: Verifying the Ethernet Ring Protection Configuration

Example: Configuring Ethernet Ring Protection Switching

The following is an example of an Ethernet Ring Protection (ERP) switching configuration:

ethernet ring g8032 profile profile_ABC
timer wtr 1
timer guard 100
timer hold-off  1

ethernet ring g8032 major_ring_ABC
exclusion-list vlan-ids 1000
port0 interface FastEthernet 0/0/0
monitor service instance 103
port1 interface FastEthernet 0/1/0
monitor service instance 102
instance 1
profile profile_ABC
rpl port0 owner
inclusion-list vlan-ids 100
aps-channel
port0 service instance 100
port1 service instance 100
!
interface FastEthernet 0/0/0
no ip address
service instance 100 ethernet
encapsulation dot1q 100
bridge-domain 100
service instance 200 ethernet
encapsulation dot1q 200
bridge-domain 200

!
!
interface FastEthernet 0/1/1
no ip address
service instance 100 ethernet
encapsulation dot1q 100
bridge-domain 100
service instance 200 ethernet
encapsulation dot1q 200
bridge-domain 200

!
!

Example: Enabling Ethernet Fault Detection for a Service

ethernet cfm domain G8032 level 4
service 8032_service evc 8032-evc vlan 1001 direction down
continuity-check
continuity-check interval 3.3ms
offload sampling 1000
efd notify g8032
ethernet ring g8032 profile TEST
timer wtr 1
timer guard 100
ethernet ring g8032 open
open-ring
port0 interface GigabitEthernet0/1/3
monitor service instance 1001
port1 none
instance 1
profile TEST
inclusion-list vlan-ids 2-500,1001
aps-channel
port0 service instance 1001
port1 none
!
!
instance 2
profile TEST
rpl port0 owner
inclusion-list vlan-ids 1002,1005-2005
aps-channel
port0 service instance 1002
port1 none
!

interface GigabitEthernet0/1/3
no ip address
load-interval 30
shutdown
negotiation auto
storm-control broadcast level 10.00
storm-control multicast level 10.00
storm-control unicast level 90.00
service instance 1 ethernet
encapsulation untagged
l2protocol peer lldp
bridge-domain 1
!
service instance trunk 10 ethernet
encapsulation dot1q 2-500,1005-2005
rewrite ingress tag pop 1 symmetric
bridge-domain from-encapsulation
!
service instance 1001 ethernet 8032-evc
encapsulation dot1q 1001
rewrite ingress tag pop 1 symmetric
bridge-domain 1001
cfm mep domain G8032 mpid 20
!
service instance 1002 ethernet 8032-evc-1
encapsulation dot1q 1002
rewrite ingress tag pop 1 symmetric
bridge-domain 1002
!
End

Example: Verifying the Ethernet Ring Protection Configuration

The following is sample output from the show ethernet ring g8032 configuration command. Use this command to verify if the configuration entered is valid and to check for any missing configuration parameters.

Device# show ethernet ring g8032 configuration

ethernet ring ring0
Port0: GigabitEthernet0/0/0 (Monitor: GigabitEthernet0/0/0)
Port1: GigabitEthernet0/0/4 (Monitor: GigabitEthernet0/0/4)
Exclusion-list VLAN IDs: 4001-4050
Open-ring: no
Instance 1
Description:
Profile:     opp
RPL:
Inclusion-list VLAN IDs: 2,10-500
APS channel
Level: 7
Port0: Service Instance 1
Port1: Service Instance 1
State: configuration resolved

Additional References for ITU-T G.8032 Ethernet Ring Protection Switching

Related Documents

Related Topic

Document Title

Ethernet Connectivity Fault Management (CFM)

Configuring Ethernet Connectivity Fault Management in a Service Provider Network

G.8032 Ethernet Ring Protection (ERP) administrative procedures

Click Here

Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Commands List, All Releases

Standards

Standard

Title

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information For ITU-T G.8032 Ethernet Ring Protection Switching

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for ITU-T G.8032 Ethernet Ring Protection Switching

Feature Name

Releases

Feature Information

ITU-T G.8032 Ethernet Ring Protection Switching

15.2(4)S

15.3(1)S

The ITU-T G.8032 Ethernet Ring Protection Switching feature implements protection switching mechanisms for Ethernet layer ring topologies. This feature uses the G.8032 Ethernet Ring Protection (ERP) protocol, defined in ITU-T G.8032, to provide protection for Ethernet traffic in a ring topology, while ensuring that no loops are within the ring at the Ethernet layer. The loops are prevented by blocking traffic on either a predetermined link or a failed link.

The following commands were introduced or modified: aps-channel, clear ethernet ring g8032 statistics, debug ethernet ring g8032 errors, debug ethernet ring g8032 events, debug ethernet ring g8032 fsm, debug ethernet ring g8032 packets, description (Ethernet ring), ethernet ring g8032, ethernet ring g8032 profile, ethernet tcn-propagation, exclusion-list, inclusion-list, instance (Ethernet ring), level, monitor service instancenon-revertiveopen-ring, port0, port0 service instance, port1, port1 service instance, profile, rpl, show ethernet cfm domain, show ethernet cfm errors,show ethernet cfm maintenance-points remote, show ethernet cfm maintenance-points remote crosscheck, show ethernet ring g8032 brief, show ethernet ring g8032 configuration, show ethernet ring g8032 port status, show ethernet ring g8032 profile, show ethernet ring g8032 statistics, show ethernet ring g8032 status, show ethernet ring g8032 summary , show ethernet ring g8032 trace,show ethernet service instance and timer (Ethernet ring).

Chapter 12. Layer 2 Access Control Lists on EVCs

The ability to filter packets in a modular and scalable way is important for both network security and network management. Access Control Lists (ACLs) provide the capability to filter packets at a fine granularity. In Metro Ethernet networks, ACLs are directly applied on Ethernet virtual circuits (EVCs).

Layer 2 Access Control Lists on EVCs is a security feature that allows packet filtering based on MAC addresses. This module describes how to implement ACLs on EVCs.

- Finding Feature Information

- Prerequisites for Layer 2 Access Control Lists on EVCs

- Restrictions for Layer 2 Access Control Lists on EVCs

- Information About Layer 2 Access Control Lists on EVCs

- How to Configure Layer 2 Access Control Lists on EVCs

- Configuration Examples for Layer 2 Access Control Lists on EVCs

- Additional References

- Feature Information for Layer 2 Access Control Lists on EVCs

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Layer 2 Access Control Lists on EVCs

- Knowledge of how service instances must be configured.

- Knowledge of extended MAC ACLs and how they must be configured.

Restrictions for Layer 2 Access Control Lists on EVCs

- A maximum of 16 access control entries (ACEs) are allowed for a given ACL.

- Only 256 different or unique Layer 2 ACLs can be configured on a line card. (More than 256 ACLs can be configured on a router.)

- Layer 2 ACLs function inbound only.

- Current Layer 2 ACLs provide Layer 3 filtering options in permit and deny rules. Options that are not relevant to service instances are ignored.

Information About Layer 2 Access Control Lists on EVCs

- EVCs

- Relationship Between ACLs and Ethernet Infrastructure

EVCs

An Ethernet virtual circuit (EVC) as defined by the Metro Ethernet Forum is a port-level point-to-point or multipoint-to-multipoint Layer 2 circuit. It is an end-to-end representation of a single instance of a Layer 2 service being offered by a provider to a customer. An EVC contains the different parameters on which the service is being offered. A service instance is the instantiation of an EVC on a specified port.

Service instances are configured under a port channel. The traffic carried by the service instance is load balanced across member links. Service instances under a port channel are grouped and each group is associated with one member link. Ingress traffic for a single EVC can arrive on any member of the bundle. All egress traffic for a service instance uses only one of the member links. Load balancing is achieved by grouping service instances and assigning them to a member link.

Ethernet virtual connection services (EVCS) uses the EVCs and service instances to provide Layer 2 switched Ethernet services. EVC status can be used by a customer edge (CE) device either to find an alternative path to the service provider network or in some cases, to fall back to a backup path over Ethernet or over another alternative service such as ATM.

For information about the Metro Ethernet Forum standards, see the Standards table in the “Additional References” section.

Relationship Between ACLs and Ethernet Infrastructure

The following points capture the relationship between ACLs and Ethernet Infrastructure (EI):

- ACLs can be directly applied on an EVC using the command-line interface (CLI). An ACL is applied to a service instance, which is the instantiation of an EVC on a given port.

- One ACL can be applied to more than one service instance at any time.

- One service instance can have one ACL at most applied to it at any time. If a Layer 2 ACL is applied to a service instance that already has a Layer 2 ACL, the new one replaces the old one.

- Only named ACLs can be applied to service instances. The command syntax ACLs is retained; the mac access-list extended command is used to create an ACL.

- The show ethernet service instance command can be used to provide details about ACLs on service instances.

How to Configure Layer 2 Access Control Lists on EVCs

- Creating a Layer 2 ACL

- Applying a Layer 2 ACL to a Service Instance

- Configuring a Layer 2 ACL with ACEs on a Service Instance

- Verifying the Presence of a Layer 2 ACL on a Service Instance

Creating a Layer 2 ACL

Perform this task to create a Layer 2 ACL with a single ACE.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    mac access-list extended name

4.    permit {{src-mac mask | any} {dest-mac mask | any} [protocol [vlan vlan] [cos value]]}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

mac access-list extended name

Example:

Device(config)# mac access-list extended test-12-acl

Defines an extended MAC ACL and enters mac access list control configuration mode.

Step 4

permit {{src-mac mask | any} {dest-mac mask | any} [protocol [vlan vlan] [cos value]]}

Example:

Device(config-ext-macl)# permit 00aa.00bb.00cc 0.0.0 any

Allows forwarding of Layer 2 traffic if the conditions are matched. Creates an ACE for the ACL.

Applying a Layer 2 ACL to a Service Instance

Perform this task to apply a Layer 2 ACL to a service instance. Note that packet filtering takes place only after the ACL has been created and applied to the service instance.

Before You Begin
Before applying an ACL to a service instance, you must create it using the mac access-list extended command. See the “Creating a Layer 2 ACL” section on page 3 .

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    mac access-group access-list-name in

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet 1/0/0

Specifies the type and location of the interface to configure, where:

- type --Specifies the type of the interface.

- number --Specifies the location of the interface.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used in order to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

mac access-group access-list-name in

Example:

Device(config-if-srv)# mac access-group test-12-acl in

Applies a MAC ACL to control incoming traffic on the interface.

Configuring a Layer 2 ACL with ACEs on a Service Instance

Perform this task to configure the same ACL with three ACEs and stop all other traffic on a service instance.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    mac access-list extended name

4.    permit {src-mac mask | any} {dest-mac mask | any}

5.    permit {src-mac mask | any} {dest-mac mask | any}

6.    permit {src-mac mask | any} {dest-mac mask} | any}

7.    deny any any

8.    exit

9.    interface type number

10.    service instance id ethernet

11.    encapsulation dot1q vlan-id

12.    mac access-group access-list-name in

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

mac access-list extended name

Example:

Device(config)# mac access list extended test-12-acl

Defines an extended MAC ACL and enters mac access control list configuration mode.

Step 4

permit {src-mac mask | any} {dest-mac mask | any}

Example:

Device(config-ext-macl)# permit 00aa.bbcc.ddea 0.0.0 any

Allows forwarding of Layer 2 traffic if the conditions are matched. This creates an ACE for the ACL.

Step 5

permit {src-mac mask | any} {dest-mac mask | any}

Example:

Device(config-ext-macl)# permit 00aa.bbcc.ddeb 0.0.0 any

Allows forwarding of Layer 2 traffic if the conditions are matched. This creates an ACE for the ACL.

Step 6

permit {src-mac mask | any} {dest-mac mask} | any}

Example:

Device(config-ext-macl)# permit 00aa.bbcc.ddec 0.0.0 any

Allows forwarding of Layer 2 traffic if the conditions are matched. This creates an ACE for the ACL.

Step 7

deny any any

Example:

Device(config-ext-macl)# deny any any

Prevents forwarding of Layer 2 traffic except for the allowed ACEs.

Step 8

exit

Example:

Device(config-ext-macl)# exit

Exits the current command mode and returns to global configuration mode.

Step 9

interface type number

Example:

Device(config)# interface gigabitethernet 1/0/0

Specifies the interface.

Step 10

service instance id ethernet

Example:

Device(config-if)# service instance 200 ethernet

Configures an Ethernet service instance on an interface and enters service instance configuration mode.

Step 11

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used to map ingress dot1q frames on an interface to the appropriate service instance.

Step 12

mac access-group access-list-name in

Example:

Device(config-if-srv)# mac access-group test-12-acl in

Applies a MAC ACL to control incoming traffic on the interface.

Verifying the Presence of a Layer 2 ACL on a Service Instance

Perform this task to verify that a Layer 2 ACL is present on an EVC. This verification task can be used after an ACL has been configured to confirm its presence.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    show ethernet service instance id id interface type number detail

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# show ethernet service instance id 100 interface gigabitethernet 3/0/1 detail

Enters global configuration mode.

Step 3

show ethernet service instance id id interface type number detail

Example:

Device# show ethernet service instance id 100 interface gigabitethernet 3/0/1 detail

Displays detailed information about Ethernet customer service instances.

Configuration Examples for Layer 2 Access Control Lists on EVCs

- Example Applying a Layer 2 ACL to a Service Instance

- Example Applying a Layer 2 ACL to Three Service Instances on the Same Interface

- Example Creating a Layer 2 ACL with ACEs

- Example Displaying the Details of a Layer 2 ACL on a Service Instance

Example Applying a Layer 2 ACL to a Service Instance

The following example shows how to apply a Layer 2 ACL called mac-20-acl to a service instance. The ACL has five permitted ACEs and all other traffic is not allowed.

enable
configure terminal
mac access-list extended mac-20-acl

permit 00aa.bbcc.adec 0.0.0 any

permit 00aa.bbcc.bdec 0.0.0 any

permit 00aa.bbcc.cdec 0.0.0 any

permit 00aa.bbcc.edec 0.0.0 any

permit 00aa.bbcc.fdec 0.0.0 any

deny any any
exit
interface gigabitethernet 10/0/0
service instance 100 ethernet
encapsulation dot1q 100
mac access-group mac-20-acl in

Example Applying a Layer 2 ACL to Three Service Instances on the Same Interface

The following example shows how to apply a Layer 2 ACL called mac-07-acl to three service instances on the same interface:

enable
configure terminal
mac access-list extended mac-07-acl

permit 00aa.bbcc.adec 0.0.0 any

permit 00aa.bbcc.bdec 0.0.0 any

permit 00aa.bbcc.cdec 0.0.0 any

deny any any
exit
interface gigabitethernet 10/0/0
service instance 100 ethernet
encapsulation dot1q 100
mac access-group mac-07-acl in
service instance 101 ethernet
encapsulation dot1q 101
mac access-group mac-07-acl in
service instance 102 ethernet
encapsulation dot1q 102
mac access-group mac-07-acl in

Example Creating a Layer 2 ACL with ACEs

The following example shows how to create a Layer 2 ACL called mac-11-acl with two permitted ACEs:

enable
configure terminal
mac access-list extended mac-11-acl
permit 00aa.00bb.00cc 1a11.0101.11c1 any
permit 00aa.00bb.00cc 1a11.0101.11c2 any

Example Displaying the Details of a Layer 2 ACL on a Service Instance

The following sample output displays the details of a Layer 2 ACL called test-acl on a service instance.

Device# show ethernet service instance id 100 interface ethernet0/0 detail
Service Instance ID: 100
L2 ACL (inbound): test-acl
Associated Interface: Ethernet0/0
Associated EVC: test
L2protocol drop
CEVlans:
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
L2 ACL permit count: 10255
L2 ACL deny count: 53

The table below describes the significant fields in the output.

show ethernet service instance Field Descriptions

Field

Description

Service Instance ID

Displays the service instance ID.

L2 ACL (inbound):

Displays the ACL name.

Associated Interface:

Displays the interface details of the service instance.

Associated EVC:

Displays the EVC with which the service instance is associated.

CEVlans:

Displays details of the associated VLAN ID.

State:

Displays whether the service instance is in an up or down state.

L2 ACL permit count:

Displays the number of packet frames allowed to pass on the service instance by the ACL.

L2 ACL deny count

Displays the number of packet frames not permitted to pass on the service instance by the ACL.

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Configuring CFM over an EFP Interface with the Cross Connect feature on the Cisco ASR 903 Router.

Configuring the CFM over EFP Interface with Cross Connect Feature

Configuring Ethernet Virtual Connections on the Cisco ASR 903 Router

Configuring Ethernet Virtual Connections on the Cisco ASR 903 Router

Standards

Standard

Title

MEF 6.1

Metro Ethernet Services Definitions Phase 2 (PDF 6/08)

MEF 10.1

Ethernet Services Attributes Phase 2 (PDF 10/06)

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Layer 2 Access Control Lists on EVCs

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Layer 2 Access Control Lists on EVCs

Feature Name

Releases

Feature Information

Layer 2 Access Control Lists on EVCs

Cisco IOS XE Release 3.6S

The Layer 2 Access Control Lists on EVCs feature introduces ACLs on EVCs.

- The following commands were introduced or modified: interface, mac access-group in, mac access-list extended, show ethernet service instance.

Chapter 13. Configuring MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

The MAC Address Limiting on Service Instances, Bridge Domains, and EVC Port Channels feature addresses port security with service instances by providing the capability to control and filter MAC address learning behavior at the granularity of a per-service instance. When a violation requires a shutdown, only the customer who is assigned to a given service instance is affected and--not all customers who are using the port.

MAC address limiting is a type of MAC security and is also referred to as a MAC security component or element.

- Finding Feature Information

- Prerequisites for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- Restrictions for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- Information About MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- How to Configure MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- Configuration Examples for MAC Address Limiting on Service Instances and Bridge Domains and EVC Port Channels

- Additional References

- Feature Information for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- An understanding of service instances and bridge domains.

- An understanding of how port channels and EtherChannels work in a network.

Restrictions for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

MAC address limiting for service instances and bridge domains is configured under a service instance and is permitted only after the service instance is configured under a bridge domain. If a service instance is removed from a bridge domain, all the MAC address limiting commands under it are also removed. If a bridge domain is removed from a service instance, all the MAC address limiting commands are also removed.

Information About MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- Ethernet Virtual Circuits, Service Instances, and Bridge Domains

- EVCs on Port Channels

- MAC Security and MAC Addressing

- MAC Address Permit List

- MAC Address Deny List

- MAC Address Limiting and Learning

- Violation Response Configuration

- MAC Address Aging Configuration

- Sticky MAC Address Configurations

- Transitions

Ethernet Virtual Circuits, Service Instances, and Bridge Domains

An Ethernet virtual circuit (EVC) as defined by the Metro Ethernet Forum is a port-level point-to-point or multipoint-to-multipoint Layer 2 circuit. It is an end-to-end representation of a single instance of a Layer 2 service being offered by a provider to a customer. An EVC embodies the different parameters on which the service is being offered. A service instance is the instantiation of an EVC on a given port.

Support for Ethernet bridging is an important Layer 2 service that is offered on a router as part of an EVC. Ethernet bridging enables the association of a bridge domain with a service instance.

Service instances are configured under a port channel. The traffic carried by service instances is load-balanced across member links. Service instances under a port channel are grouped and each group is associated with one member link. Ingress traffic for a single service instance can arrive on any member of the bundle. All egress traffic for a service instance uses only one of the member links. Load-balancing is achieved by grouping service instances and assigning them to a member link.

For information about the Metro Ethernet Forum standards, see the “Standards” table in the “Additional References” section.

EVCs on Port Channels

An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate bandwidth of up to eight physical links. The Ethernet Virtual Connection Services (EVCS) EtherChannel feature provides support for EtherChannels on service instances.

Note

The MAC Address Security on EVC Port Channel services is supported only on bridge domains over Ethernet and is not supported on xconnect services.

EVCS uses the concepts of EVCs and service instances.

Load balancing is done on an Ethernet flow point (EFP) basis where a number of EFPs exclusively pass traffic through member links.

MAC Security and MAC Addressing

MAC security is enabled on a service instance by configuring the mac security command. Various MAC security elements can be configured or removed regardless of whether the mac security command is presently configured, but these configurations become operational only when the mac security command is applied.

In this document, the term “secured service instance” is used to describe a service instance on which MAC security is configured. The MAC addresses on a service instance on which MAC security is configured are referred to as “secured MAC addresses.” Secured MAC addresses can be either statically configured (as a permit list) or dynamically learned.

MAC Address Permit List

A permit list is a set of MAC addresses that are permitted on a service instance. Permitted addresses permanently configured into the MAC address table of the service instance.

On a service instance that is a member of a bridge domain, the operator is permitted to configure one or more permitted MAC addresses.

For each permitted address, eligibility tests are performed and after the address passes these tests, it is either:

- Programmed into the MAC address table of the bridge domain, if MAC security is enabled on the service instance or,

- Stored in an area of memory referred to as “MAC table cache” if MAC security is not enabled on the service instance. When MAC security is enabled, the addresses from the MAC table cache are added to the MAC address table as secure addresses.

The eligibility tests performed when a user tries to add a MAC address to the permit list on a service instance are as follows:

- If the address is already a denied address on the service instance, the configuration is rejected with an appropriate error message.

- If the acceptance of this address would increase the secure address count on the service instance beyond the maximum number allowed, an attempt is made to make room by removing an existing address from the MAC address table. The only candidate for removal is a dynamically learned address on the service instance. If sufficient room cannot be made, the configuration is rejected. If the acceptance of this address would increase the secure address count on the bridge domain beyond the maximum number allowed, an attempt is made to make room by removing an existing address from the MAC address table. The only candidate for removal is a dynamically learned address on the service instance. If room cannot be made, the configuration is rejected.

- If the address is already permitted on another service instance in the same bridge domain, one of the following actions occur:

- If the conflicting service instance has MAC security configured, the configuration is rejected with an appropriate error message.

- If the conflicting service instance does not have MAC security configured, the configuration is accepted silently. (If the operator attempts to enable MAC security on the conflicting service instance, that attempt fails.)

MAC Address Deny List

A deny list is a set of MAC addresses that are not permitted on a service instance. An attempt to learn a denied MAC address will fail. On a service instance that is a member of a bridge domain, the operator is permitted to configure one or more denied MAC addresses. The arrival of a frame with a source MAC address that is part of a deny list will trigger a violation response.

Before a denied address can be configured, the following test is performed:

- If the address is already configured as a permitted address on the specific service instance or if the address has been learned and saved as a sticky address on the service instance, the configuration is rejected with an appropriate error message.

In all other cases, the configuration of the denied address is accepted. Typical cases include:

- The address is configured as a permitted address on another service instance in the same bridge domain, or the address has been learned and saved as a sticky address on another service instance.

- The address is present in the MAC table of the bridge domain as a dynamically learned address on the specific service instance and is deleted from the MAC table before the configuration is accepted.

MAC Address Limiting and Learning

An upper limit for the number of secured MAC addresses allowed on a bridge domain service instance can be configured. This limit includes addresses added as part of a permit list and dynamically learned MAC addresses.

Before an unknown MAC address is learned, a series of checks are run against a set of configured and operational constraints. If any of these checks fails, the address is not learned, and a configured violation response is triggered.

- Static and Dynamic MAC Addresses

- Dynamic MAC Address Learning

- MAC Address Limiting on Service Instances

- MAC Address Limiting for Bridge Domains

- Relationship Between the MAC Address Limit on a Bridge Domain and on a Service Instance

- MAC Move and MAC Locking

Static and Dynamic MAC Addresses

A static MAC address is specified as permitted on a service instance, by a mac security permitcommand. A dynamic MAC address is a source MAC address encountered by the service instance that is not present in the MAC table but is allowed into and learned by the MAC address table.

Dynamic MAC Address Learning

Dynamic MAC address learning occurs when the bridging data path encounters an ingress frame whose source address is not present in the MAC address table for the ingress secured service instance.

The MAC security component is responsible for permitting or denying the addition of the new source address into the MAC table. The following constraints apply:

- If a MAC address is to be learned, a check is performed to determine whether the number of secured MAC addresses exceed the maximum number that are permitted to be learned on the individual service instance and on the bridge domain.

- A check is performed to determine if the MAC address on an another service instance is learned on a secured service instance in the same bridge domain.

- A check is performed to verify if the new dynamic MAC address is in a deny list.

MAC Address Limiting on Service Instances

The user can configure the maximum number of MAC addresses that can exist in the MAC table that is associated with a service instance. This number includes statically configured and dynamically learned (including sticky) addresses.

On a service instance that has MAC security enabled and that does not have the maximum number of MAC addresses configured, the number of addresses allowed is one. This means that if the service instance has an associated permit list, that permit list can have only one address, and no addresses are learned dynamically. If the service instance does not have an associated permit list, one MAC address may be learned dynamically.

MAC Address Limiting for Bridge Domains

An upper limit for the number of MAC addresses that can reside in the MAC address table of a bridge domain can be set. This is set independently of the upper limit of secured MAC addresses on the service instance. An attempted violation of this bridge domain MAC address limit will cause the MAC address learn attempt to fail, and the frame to be dropped.

If the bridge domain MAC address limit is not configured, then by default, the maximum number of MAC addresses allowed on a bridge domain is the maximum number that can be supported by that platform.

Relationship Between the MAC Address Limit on a Bridge Domain and on a Service Instance

You can specify the maximum count of MAC table entries on a bridge domain and on a service instance simultaneously. However, there are no restrictions on the count that is configured on the service instance.

The table below shows an example of an initial configuration where three service instances are configured on a bridge domain:

Bridge-Domain and Service-Instance MAC Address Limit

Bridge-Domain / Service-Instance Number

MAC Address Limit

Bridge Domain 1000

20

Service Instance 1001

5

Service Instance 1002

10

Service Instance 1003

To be configured

If you wish to configure MAC security on service instance 1003, any value can be configured for the maximum count. For example:

service instance 1003 ethernet
bridge-domain 1
mac security
mac security maximum addresses 35

service instance 1003 ethernet
bridge-domain 1
mac limit maximum addresses 35

A MAC address limit of 35 is permitted, even though the total MAC address limit for the three service instances (5 + 10 + 35) would exceed the count (20) configured on the bridge domain. Note that during actual operation, the bridge domain limit of 20 is in effect. The dynamic secure address count cannot exceed the lowest count applicable, so it is not possible for service instance 1003 to learn 35 addresses.

MAC Move and MAC Locking

If a MAC address is present in the MAC address table for a service instance (for example, service instance 1) on which MAC security is configured, the same MAC address cannot be learned on another service instance (for example, service instance 2) in the same bridge domain.

If service instance 2 attempts to learn the same MAC address, the violation response configured on service instance 2 is triggered. If MAC security is not configured on service instance 2 and a violation response is not configured, the “shutdown” response sequence is triggered on service instance 2.

If MAC security is not enabled on service instance 1, the violation is not triggered. service instance 2 learns the MAC address and moves it from service instance 1.

For some platforms, MAC address moves are allowed but moves between secured service instances and nonsecured service instances cannot be detected.

For example, if you do not configure MAC security on service instance 2 because of a hardware limitation, a MAC move from secured service instance 1 to service instance 2 is accepted. Therefore, it is recommended that all service instances within the same bridge-domain be configured as secured service instances.

Violation Response Configuration

A violation response is a response to a MAC security violation or a failed attempt to dynamically learn a MAC address due to an address violation. MAC security violations are of two types:

Type 1 Violation --The address of the ingress frame cannot be dynamically learned due to a deny list, or because doing so would cause the maximum number of secure addresses to be exceeded (see the MAC Address Limiting and Learning).

Type 2 Violation --The address of the ingress frame cannot be dynamically learned because it is already “present” on another secured service instance (see the MAC Move and MAC Locking).

There are three possible sets of actions that can be taken in response to a violation:

1. Shutdown

2. The ingress frame is dropped.

3. The service instance on which the offending frame arrived is shut down.

4. The violation count is incremented, and the violating address is recorded for later CLI display.

5. The event and the response are logged to SYSLOG.

6. Restrict

7. The ingress frame is dropped.

8. The violation count is incremented, and the violating address is recorded for display.

9. The event and the response are logged to SYSLOG.

10. Protect

11. The ingress frame is dropped.

If a violation response is not configured, the default response mode is shutdown. The violation response can be configured to protect or restrict mode. A “no” form of a violation response, sets the violation response to the default mode of shutdown.

You are allowed to configure the desired response for a Type 1 and Type 2 violations on a service instance. For a Type 1 violation on a bridge domain (that is, if the learn attempt conforms to the policy configured on the service instance, but violates the policy configured on the bridge domain), the response is always “Protect.” This is not configurable.

In Restrict mode, the violation report is sent to SYSLOG at level LOG_WARNING.

Support for the different types of violation responses depends on the capabilities of the platform. The desired violation response can be configured on the service instance. The configured violation response does not take effect unless and until MAC security is enabled using the mac security command.

MAC Address Aging Configuration

A specific time scheduler can be set to age out secured MAC addresses that are dynamically learned or statically configured on both service instances and bridge domains, thus freeing up unused addresses from the MAC address table for other active subscribers.

The set of rules applied to age out secured MAC addresses is called secure aging. By default, the entries in the MAC address table of a secured service instance are never aged out. This includes permitted addresses and dynamically learned addresses.

The mac security aging time aging-time command sets the aging time of the addresses in the MAC address table to <n > minutes. By default, this affects only dynamically learned (not including sticky) addresses--permitted addresses and sticky addresses are not affected by the application of this command.

By default, the aging time <n> configured via the mac security aging time aging-time command is an absolute time. That is, the age of the MAC address is measured from the instant that it was first encountered on the service instance. This interpretation can be modified by using the mac security aging time aging-time inactivity command, which specifies that the age <n> be measured from the instant that the MAC address was last encountered on the service instance.

The mac security aging staticand mac security aging sticky commands specify that the mac security aging timeaging-time command must be applicable to permitted and sticky MAC addresses, respectively. In the case of permitted MAC addresses, the absolute aging time is measured from the time the address is entered into the MAC address table (for example, when it is configured or whenever the mac security command is entered--whichever is later).

If the mac security aging time command is not configured, the mac security aging static command has no effect.

Sticky MAC Address Configurations

The ability to make dynamically learned MAC addresses on secured service instances permanent even after interface transitions or device reloads can be set up and configured. A dynamically learned MAC address that is made permanent on a secured service instance is called a “sticky MAC address”. The mac security sticky command is used to enable the sticky MAC addressing feature on a service instance.

With the “sticky” feature enabled on a secured service instance, MAC addresses learned dynamically on the service instance are kept persistent across service instance line transitions and device reloads.

The sticky feature has no effect on statically configured MAC addresses. The sticky addresses are saved in the running configuration. Before the device is reloaded, it is the responsibility of the user to save the running configuration to the startup configuration. Doing this will ensure that when the device comes on, all the MAC addresses learned dynamically previously are immediately populated into the MAC address table.

The mac security sticky address mac-address command can configure a specific MAC address as a sticky MAC address. The use of this command is not recommended for the user because configuring a MAC address as a static address does the same thing. When sticky MAC addressing is enabled by the mac security sticky command, the dynamically learned addresses are marked as sticky and a mac security sticky address mac-address command is automatically generated and saved in the running configuration for each learned MAC address on the service instances.

- Aging for Sticky Addresses

Aging for Sticky Addresses

MAC addresses learned on a service instance that has the sticky behavior enabled are subject to aging as configured by the mac security aging time and mac security aging sticky commands. In other words, for the purpose of aging functionality, sticky addresses are treated the same as dynamically learned addresses.

Transitions

This section contains a description of the expected behavior of the different MAC security elements when various triggers are applied; for example, configuration changes or link state transitions.

- MAC Security Enabled on a Service Instance

- MAC Security Disabled on a Service Instance

- Service Instance Moved to a New Bridge Domain

- Service Instance Removed from a Bridge Domain

- Service Instance Shut Down Due to Violation

- Interface Service Instance Down Linecard OIR Removed

- Interface Service Instance Re-activated Linecard OIR Inserted

- MAC Address Limit Decreased

- Sticky Addresses Added or Removed on a Service Instance

MAC Security Enabled on a Service Instance

When MAC security is enabled on a service instance, all existing MAC table entries for the service instance are purged. Then, permitted MAC address entries and sticky addresses are added to the MAC table, subject to the prevailing MAC address limiting constraints on the bridge domain.

If MAC address limits are exceeded, any MAC address that fails to get added is reported via an error message to the console, the attempt to enable MAC security on the service instance fails, and the already added permitted entries are backed out or removed.

The aging timer for all entries is updated according to the secure aging rules.

MAC Security Disabled on a Service Instance

The existing MAC address table entries for this service instance are purged.

Service Instance Moved to a New Bridge Domain

This transition sequence applies to all service instances, whether or not they have MAC security configured. All the MAC addresses on this service instance in the MAC address table of the old bridge domain are removed. The count of dynamically learned addresses in the old bridge domain is decremented. Then, all the MAC security commands are permanently erased from the service instance.

Service Instance Removed from a Bridge Domain

All the MAC addresses in the MAC address table that attributable to this service instance are removed, and the count of dynamically learned addresses in the bridge domain is decremented. Since MAC security is applicable only on service instances that are members of a bridge domain, removing a service instance from a bridge domain causes all the MAC security commands to be erased permanently.

Service Instance Shut Down Due to Violation

All dynamically learned MAC addresses in the MAC address table are removed, and all the other MAC security state values are left unchanged. The only change is that no traffic is forwarded, and therefore no learning can take place.

Interface Service Instance Down Linecard OIR Removed

The MAC tables of all the affected bridge domains are cleared of all the entries attributable to the service instances that are down.

Interface Service Instance Re-activated Linecard OIR Inserted

The static and sticky address entries in the MAC tables of the affected bridge domains are re-created to the service instances that are activated.

MAC Address Limit Decreased

When the value of the MAC address limit on the service instance is changed initially, a sanity check is performed to ensure that the new value of <n> is greater than or equal to the number of permitted entries. If not, the command is rejected. The MAC table is scanned for addresses that are attributable to this service instance, and dynamically learned MAC addresses are removed when the new MAC address limit is less than the old MAC address limit.

When the value of <n> on a bridge domain is changed initially, a sanity check is performed to ensure that the new value of <n> is greater than or equal to the sum of the number of permitted entries on all the secured service instances on the bridge domain. If this sanity test fails, the command is rejected. The bridge domain MAC address table (regardless of service instance) is scanned for dynamically learned (or sticky) addresses. All dynamically learned addresses are removed when the new MAC address limit is less than the old MAC address limit.

Sticky Addresses Added or Removed on a Service Instance

Existing dynamically learned MAC addresses remain unchanged. All new addresses learned become “sticky” addresses.

Disabling sticky addresses causes all sticky secure MAC addresses on the service instance to be removed from the MAC address table. All new addresses learned become dynamic addresses on the service instance and are subject to aging.

How to Configure MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

- Enabling MAC Security on a Service Instance

- Enabling MAC Security on an EVC Port Channel

- Configuring a MAC Address Permit List

- Configuring a MAC Address Deny List

- Configuring MAC Address Limiting on a Bridge Domain

- Configuring MAC Address Limiting on a Service Instance

- Configuring a MAC Address Violation

- Configuring MAC Address Aging

- Configuring a Sticky MAC Address

- Displaying the MAC Security Status of a Specific Service Instance

- Displaying the Service Instances with MAC Security Enabled

- Displaying the Service Instances with MAC Security Enabled on a Specific Bridge Domain

- Showing the MAC Addresses of All Secured Service Instances

- Showing the MAC Addresses of a Specific Service Instance

- Showing the MAC Addresses of All Service Instances on a Specific Bridge Domain

- Showing the MAC Security Statistics of a Specific Service Instance

- Showing the MAC Security Statistics of All Service Instances on a Specific Bridge Domain

- Showing the Last Violation Recorded on Each Service Instance on a Specific Bridge Domain

- Clearing All Dynamically Learned MAC Addresses on a Service Instance

- Clearing All Dynamically Learned MAC Addresses on a Bridge Domain

- Bringing a Specific Service Instance Out of the Error-Disabled State

Enabling MAC Security on a Service Instance

Perform this task to enable MAC address security on a service instance.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security

8.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used in order to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-idis the identifier for the bridge- domain instance.

Step 7

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 8

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Enabling MAC Security on an EVC Port Channel

Before You Begin

Note

- Bridge-domain, xconnect, and Ethernet virtual circuits (EVCs) are allowed only over the port channel interface and the main interface.

- If you configure a physical port as part of a channel group, you cannot configure EVCs under that physical port.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface port-channel channel-group

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security

8.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface port-channel channel-group

Example:

Device(config)# interface port-channel 2

Specifies the port channel group number and enters interface configuration mode.

- Acceptable values are integers from 1 to 64.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used in order to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-idis the identifier for the bridge- domain instance.

Step 7

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 8

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuring a MAC Address Permit List

Perform this task to configure permitted MAC addresses on a service instance that is a member of a bridge domain.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security address permit mac-address

8.    mac security address permit mac-address

9.    mac security address permit mac-address

10.    mac security address permit mac-address

11.    mac security address permit mac-address

12.    mac security

13.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used for mapping ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-id is the identifier for the bridge- domain instance.

Step 7

mac security address permit mac-address

Example:

Device(config-if-srv)# mac security address permit a2aa.aaaa.aaaa

Adds the specified MAC address as a permit MAC address for the service instance.

Step 8

mac security address permit mac-address

Example:

Device(config-if-srv)# mac security address permit a2aa.aaaa.aaab

Adds the specified MAC address as a permitted MAC address for the service instance.

Step 9

mac security address permit mac-address

Example:

Device(config-if-srv)# mac security address permit a2aa.aaaa.aaac

Adds the specified MAC address as a permitted MAC address for the service instance.

Step 10

mac security address permit mac-address

Example:

Device(config-if-srv)# mac security address permit a2aa.aaaa.aaad

Adds the specified MAC address as a permitted MAC address for the service instance.

Step 11

mac security address permit mac-address

Example:

Device(config-if-srv)# mac security address permit a2aa.aaaa.aaae

Adds the specified MAC address as a permitted MAC address for the service instance.

Step 12

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 13

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuring a MAC Address Deny List

Perform this task to configure a list of MAC addresses that are not allowed on a service instance that is a member of a bridge domain.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security address deny mac-address

8.    mac security address deny mac-address

9.    mac security address deny mac-address

10.    mac security address deny mac-address

11.    mac security address deny mac-address

12.    mac security

13.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used in order to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-id is the identifier for the bridge- domain instance.

Step 7

mac security address deny mac-address

Example:

Device(config-if-srv)# mac security address deny a2aa.aaaa.aaaa

Adds the specified MAC address as a denied MAC address for the service instance.

Step 8

mac security address deny mac-address

Example:

Device(config-if-srv)# mac security address deny a2aa.aaaa.aaab

Adds the specified MAC address as a denied MAC address for the service instance.

Step 9

mac security address deny mac-address

Example:

Device(config-if-srv)# mac security address deny a2aa.aaaa.aaac

Adds the specified MAC address as a denied MAC address for the service instance.

Step 10

mac security address deny mac-address

Example:

Device(config-if-srv)# mac security address deny a2aa.aaaa.aaad

Adds the specified MAC address as a denied MAC address for the service instance.

Step 11

mac security address deny mac-address

Example:

Device(config-if-srv)# mac security address deny a2aa.aaaa.aaae

Adds the specified MAC address as a denied MAC address for the service instance.

Step 12

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 13

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuring MAC Address Limiting on a Bridge Domain

Perform this task to configure an upper limit for the number of secured MAC addresses that reside in a bridge domain.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    bridge-domain bridge-id

4.    mac limit maximum addresses maximum-addresses

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

bridge-domain bridge-id

Example:

Device(config)# bridge-domain 100

Configures components on a bridge domain and enters bridge-domain configuration mode.

Step 4

mac limit maximum addresses maximum-addresses

Example:

Device(config-bdomain)# mac limit maximum addresses 200

Sets the MAC limit maximum addresses.

Step 5

end

Example:

Device(config-bdomain)# end

Returns to user EXEC mode.

Configuring MAC Address Limiting on a Service Instance

Perform this task to configure an upper limit for the number of secured MAC addresses allowed on a service instance. This number includes addresses added as part of a permit list as well as dynamically learned MAC addresses. If the upper limit is decreased, all learned MAC entries are removed.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security maximum addresses

8.    mac limit maximum addresses maximum-addresses

9.    mac security

10.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-id is the identifier for the bridge- domain instance.

Step 7

mac security maximum addresses

Example:

Device(config-if-srv)# mac security maximum addresses 500

Sets the maximum number of secure addresses permitted on the service instance.

Step 8

mac limit maximum addresses maximum-addresses

Example:

Device(config-if-srv)# mac limit maximum address maximum-address

Sets the maximum number of secure addresses permitted on the service instance.

Step 9

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 10

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuring a MAC Address Violation

Perform this task to specify the expected behavior of a device when an attempt to dynamically learn a MAC address fails because the configured MAC security policy on the service instance was violated.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    Do one of the following:

- mac security violation restrict

- mac security violation protect

8.    mac security

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 100

Binds the service instance to a bridge- domain instance where bridge-id is the identifier for the bridge- domain instance.

Step 7

Do one of the following:

- mac security violation restrict

- mac security violation protect

Example:

Device(config-if-srv)# mac security violation restrict

Example:

Device(config-if-srv)# mac security violation protect

Sets the violation mode (for Type 1 and 2 violations) to restrict.

or

Sets the violation mode (for Type 1 and 2 violations) to protect.

- If a MAC security violation response is not specified, by default, the violation mode is shutdown.

Step 8

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 9

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuring MAC Address Aging

Perform this task to configure the aging of secured MAC addresses under MAC security. Secured MAC addresses are not subject to the normal aging of MAC table entries. If aging is not configured, secured MAC addresses are never aged out.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security aging time aging-time [ inactivity ]

8.    mac security

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used in order to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-id is the identifier for the bridge- domain instance.

Step 7

mac security aging time aging-time [ inactivity ]

Example:

Device(config-if-srv)# mac security aging time 200 inactivity

Sets the aging time for secure addresses, in minutes. The optional inactivity keyword specifies that the aging out of addresses is based on inactivity of the sending hosts (as opposed to absolute aging).

Step 8

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 9

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuring a Sticky MAC Address

If sticky MAC addressing is configured on a secured service instance, MAC addresses that are learned dynamically on the service instance are retained during a link-down condition. Perform this task to configure sticky MAC addresses on a service instance.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security sticky

8.    mac security

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge- domain instance where bridge-id is the identifier for the bridge- domain instance.

Step 7

mac security sticky

Example:

Device(config-if-srv)# mac security sticky

Enables sticky behavior on the service instance.

Step 8

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 9

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Displaying the MAC Security Status of a Specific Service Instance

Perform this task to display the MAC security status of a service instance.

SUMMARY STEPS

1.    enable

2.    show ethernet service instance id id interface type number mac security

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet service instance id id interface type number mac security

Example:

Device# show ethernet service instance id 100 interface gigabitethernet1/1 mac security

Displays the MAC security status of a specific service instance.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Displaying the Service Instances with MAC Security Enabled

Perform this task to display all the service instances with MAC security enabled.

SUMMARY STEPS

1.    enable

2.    show ethernet service instance mac security

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet service instance mac security

Example:

Device# show ethernet service instance mac security

Displays all the service instances with MAC security enabled.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Displaying the Service Instances with MAC Security Enabled on a Specific Bridge Domain

Perform this task to display the service instances on a specific bridge domain that have MAC security enabled.

SUMMARY STEPS

1.    enable

2.    show bridge-domain id mac security

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show bridge-domain id mac security

Example:

Device# show bridge-domain 100 mac security

Displays all the service instances with MAC security enabled on a specific bridge domain.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Showing the MAC Addresses of All Secured Service Instances

SUMMARY STEPS

1.    enable

2.    show ethernet service instance mac security address

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet service instance mac security address

Example:

Device# show ethernet service instance mac security address

Displays the secured addresses on all the service instances.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Showing the MAC Addresses of a Specific Service Instance

SUMMARY STEPS

1.    enable

2.    show ethernet service instance id id interface type number mac security address

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet service instance id id interface type number mac security address

Example:

Device# show ethernet service instance id 200 interface GigabitEthernet 1/0 mac security address

Displays the addresses of a specific service instance.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Showing the MAC Addresses of All Service Instances on a Specific Bridge Domain

SUMMARY STEPS

1.    enable

2.    show bridge-domain id mac security address

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show bridge-domain id mac security address

Example:

Device# show bridge-domain 100 mac security address

Displays the secured addresses of all the service instances on a specified bridge domain.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Showing the MAC Security Statistics of a Specific Service Instance

This section describes how to display the MAC security statistics of a specific service instance.

SUMMARY STEPS

1.    enable

2.    show ethernet service instance id id interface type number mac security statistics

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet service instance id id interface type number mac security statistics

Example:

Device# show ethernet service instance id 100 interface gigabitethernet1/1 mac security statistics

Displays the MAC security statistics of a specific service instance.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Showing the MAC Security Statistics of All Service Instances on a Specific Bridge Domain

Perform this task to display the MAC security statistics of all the service instances on a specific bridge domain.

SUMMARY STEPS

1.    enable

2.    show bridge-domain bridge-id mac security statistics

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show bridge-domain bridge-id mac security statistics

Example:

Device# show bridge-domain 100 mac security statistics

Displays the MAC security statistics of all service instances that belong to a specific bridge domain.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Showing the Last Violation Recorded on Each Service Instance on a Specific Bridge Domain

Perform this task to display the last violation recorded on each service instance on a specific bridge domain. Service instances on which there have been no violations are excluded from the output.

SUMMARY STEPS

1.    enable

2.    show bridge-domain bridge-id mac security last violation

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show bridge-domain bridge-id mac security last violation

Example:

Device# show bridge-domain 100 mac security last violation

Displays information about the last violation recorded on each of the service instances that belong to the bridge domain.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Clearing All Dynamically Learned MAC Addresses on a Service Instance

Perform this task to clear all dynamically learned MAC addresses on a service instance.

SUMMARY STEPS

1.    enable

2.    clear ethernet service instance id id interface type number mac table

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

clear ethernet service instance id id interface type number mac table

Example:

Device# clear ethernet service instance id 100 interface gigabitethernet1/1 mac table

Clears all the dynamically learned MAC addresses on the specified service instance.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Clearing All Dynamically Learned MAC Addresses on a Bridge Domain

Perform this task to clear all dynamically learned MAC addresses on a bridge domain.

SUMMARY STEPS

1.    enable

2.    clear bridge-domain bridge-id mac table

3.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

clear bridge-domain bridge-id mac table

Example:

Device# clear bridge-domain 100 mac table

Clears all dynamically learned MAC addresses on the specified bridge domain.

Step 3

end

Example:

Device# end

Returns to user EXEC mode.

Bringing a Specific Service Instance Out of the Error-Disabled State

Perform this task to bring a specific service instance out of the error-disabled state.

Note

The clear ethernet service instance id id interface type number errdisablecommand can also be used to bring a service instance out of an error disabled state. For more information about this command, see the Cisco IOS Carrier Ethernet Command Reference.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    service instance id ethernet

5.    encapsulation dot1q vlan-id

6.    bridge-domain bridge-id

7.    mac security

8.    errdisable recovery cause mac-security interval

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface gigabitethernet2/0/1

Specifies the interface type and number, and enters interface configuration mode.

Step 4

service instance id ethernet

Example:

Device(config-if)# service instance 100 ethernet

Creates a service instance (an instance of an EVC) on an interface and enters service instance configuration mode.

Step 5

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 100

Defines the matching criteria to be used to map ingress dot1q frames on an interface to the appropriate service instance.

Step 6

bridge-domain bridge-id

Example:

Device(config-if-srv)# bridge-domain 200

Binds the service instance to a bridge-domain instance where bridge-id is the identifier for the bridge-domain instance.

Step 7

mac security

Example:

Device(config-if-srv)# mac security

Enables MAC security on the service instance.

Step 8

errdisable recovery cause mac-security interval

Example:

Device(config-if-srv)# errdisable recovery cause mac-security 50

Brings a specific service instance out of an error-disabled state and specifies a time interval to recover.

Step 9

end

Example:

Device(config-if-srv)# end

Returns to user EXEC mode.

Configuration Examples for MAC Address Limiting on Service Instances and Bridge Domains and EVC Port Channels

- Example Enabling MAC Security on a Service Instance

- Example Enabling MAC Security on an EVC Port Channel

- Example Configuring a MAC Address Permit List

- Example Configuring a MAC Address Deny List

- Example Configuring MAC Address Limiting on a Bridge Domain

- Example Configuring a MAC Address Limit on a Service Instance

- Example Configuring a MAC Address Violation Response

- Example Configuring MAC Address Aging

- Example Configuring a Sticky MAC Address

- Example Displaying the MAC Addresses on a Specific Secure Service Instance

- Example Displaying the Last Violation on a Specific Service Instance

- Example Displaying the MAC Security Status of a Specific Service Instance

- Example Displaying the MAC Addresses of All Secured Service Instances

- Example Displaying the MAC Security Statistics of All Service Instances

- Example: Displaying the MAC Addresses on All Service Instances for a Bridge Domain

- Example Displaying the Secured Service Instances for a Specific Bridge Domain

Example Enabling MAC Security on a Service Instance

The following example shows how to enable MAC security on a service instance:

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Example Enabling MAC Security on an EVC Port Channel

The following example shows how to enable MAC Security on an EVC port channel:

Device> enable
Device# configure terminal
Device(config)# interface port-channel 2
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Example Configuring a MAC Address Permit List

The following example shows how to configure a MAC address permit list:

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security address permit a2aa.aaaa.aaaa
Device(config-if-srv)# mac security address permit a2aa.aaaa.aaab
Device(config-if-srv)# mac security address permit a2aa.aaaa.aaac
Device(config-if-srv)# mac security address permit a2aa.aaaa.aaad
Device(config-if-srv)# mac security address permit a2aa.aaaa.aaae
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Example Configuring a MAC Address Deny List

The following example shows how to configure a MAC address deny list:

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security address deny a2aa.aaaa.aaaa
Device(config-if-srv)# mac security address deny a2aa.aaaa.aaab
Device(config-if-srv)# mac security address deny a2aa.aaaa.aaac
Device(config-if-srv)# mac security address deny a2aa.aaaa.aaad
Device(config-if-srv)# mac security address deny a2aa.aaaa.aaae
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Example Configuring MAC Address Limiting on a Bridge Domain

Device> enable
Device# configure terminal
Device(config)# bridge-domain 100
Device(config-bdomain)# mac limit maximum addresses 1000
Device(config-bdomain)# end

Example Configuring a MAC Address Limit on a Service Instance

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security maximum addresses 10
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac limit maximum addresses 10
Device(config-if-srv)# end

Example Configuring a MAC Address Violation Response

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security address permit a2aa.aaaa.aaaa
Device(config-if-srv)# mac security violation protect
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Example Configuring MAC Address Aging

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 4/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security aging time 10
Device(config-if-srv)# mac security
Device(config-if-srv)# end

Example Configuring a Sticky MAC Address

Device> enable
Device# configure terminal
Device(config)# interface gigabitethernet 3/0/1
Device(config-if)# service instance 100 ethernet
Device(config-if-srv)# encapsulation dot1Q 100
Device(config-if-srv)# bridge-domain 100
Device(config-if-srv)# mac security sticky
Device(config-if-srv)# mac security

Example Displaying the MAC Addresses on a Specific Secure Service Instance

Example Displaying the Last Violation on a Specific Service Instance

Example Displaying the MAC Security Status of a Specific Service Instance

Example Displaying the MAC Addresses of All Secured Service Instances

Device# show ethernet service instance mac security address
Port                   Bridge-domain    MAC Address       Type      Rem. Age(min)
Gi1/0/0 ServInst 1     10               0001.0001.0001    static    82
Gi1/0/0 ServInst 1     10               0001.0001.0002    static    82
Gi1/0/0 ServInst 1     10               0001.0001.aaaa    dynamic   82
Gi1/0/0 ServInst 1     10               0001.0001.aaab    dynamic   82
Gi1/0/0 ServInst 2     10               0002.0002.0002    static    -
Gi1/0/0 ServInst 2     10               0002.0002.0003    static    -
Gi1/0/0 ServInst 2     10               0002.0002.0004    static    -
Gi1/0/0 ServInst 2     10               0002.0002.aaaa    dynamic   -
Gi1/0/0 ServInst 2     10               0002.0002.bbbb    dynamic   -
Gi1/0/0 ServInst 2     10               0002.0002.cccc    dynamic   -
Gi3/0/5 ServInst 10    30               0003.0003.0001    static    200
Gi3/0/5 ServInst 10    30               0003.0003.0002    static    200

Example Displaying the MAC Security Statistics of All Service Instances

In the following example, the numbers of allowed and actual secured addresses recorded on the service instance are displayed.

Example: Displaying the MAC Addresses on All Service Instances for a Bridge Domain

Router# show bridge-domain 730 mac security address
Port                  MAC Address       Type      Rem. Age(min)
Gi1/0/0 ServInst 1    0001.0001.0001    static    74
Gi1/0/0 ServInst 1    0001.0001.0002    static    74
Gi1/0/0 ServInst 1    0001.0001.aaaa    dynamic   74
Gi1/0/0 ServInst 1    0001.0001.aaab    dynamic   74
Gi1/0/0 ServInst 2    0002.0002.0002    static    -
Gi1/0/0 ServInst 2    0002.0002.0003    static    -
Gi1/0/0 ServInst 2    0002.0002.0004    static    -
Gi1/0/0 ServInst 2    0002.0002.aaaa    dynamic   -
Gi1/0/0 ServInst 2    0002.0002.bbbb    dynamic   -
Gi1/0/0 ServInst 2    0002.0002.cccc    dynamic   -

Example Displaying the Secured Service Instances for a Specific Bridge Domain

Router# show bridge-domain 730 mac security
Gi1/0/0 ServInst 1
MAC Security enabled: yes
Gi1/0/0 ServInst 2
MAC Security enabled: yes

Additional References

Related Documents

Related Topic

Document Title

CFM commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Configuring Ethernet connectivity fault management in a service provider network (Cisco pre-Standard CFM Draft 1)

"Configuring Ethernet Connectivity Fault Management in a Service Provider Network” module in the Cisco IOS Carrier Ethernet Configuration Guide

Ethernet Local Management Interface on a provider edge device

"Configuring Ethernet Local Management Interface on a Provider Edge Device” module in the Cisco IOS Carrier Ethernet Configuration Guide

IP SLAs for Metro Ethernet

"IP SLAs for Metro Ethernet"

NSF/SSO and MPLS

"NSF/SSO - MPLS LDP and LDP Graceful Restart"

ISSU feature and functions

"Cisco IOS Broadband High Availability In Service Software Upgrade"

Performing an ISSU

"Cisco IOS In Service Software Upgrade Process and Enhanced Fast Software Upgrade Process"

SSO

“Stateful Switchover” chapter of the Cisco IOS High Availability Configuration Guide

Standards

Standard

Title

IEEE 802.1ag Standard

802.1ag - Connectivity Fault Management

IEEE 802.3ah

IEEE 802.3ah Ethernet in the First Mile

IETF VPLS OAM

L2VPN OAM Requirements and Framework

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

MIBs

MIB

MIBs Link

CISCO-ETHER-CFM-MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

RFCs

RFC

Title

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

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for MAC Address Limiting on Service Instances Bridge Domains and EVC Port Channels

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for MAC Address Limiting on Service Instances, Bridge Domains, and EVC Port Channels

Feature Name

Releases

Feature Information

MAC Address Limiting on Service Instances and Bridge Domains

Cisco IOS XE 3.7S

The MAC Address Limiting on Service Instances and Bridge Domains feature addresses port security with service instances by providing the capability to control and filter MAC address learning behavior at the granularity of a per-service instance. When a violation requires a shutdown, only the customer that is assigned to a given service instance is affected. MAC address limiting is a type of MAC security and is also referred to as a MAC security component or element.

The following commands were introduced or modified: bridge-domain (global), bridge-domain (service instance), clear bridge-domain mac-table, clear ethernet service instance, errdisable recovery cause mac-security, interface, mac limit maximum addresses, security,show bridge-domain, show ethernet service instance.

Chapter 14. Configuring Ethernet Local Management Interface at a Provider Edge

The advent of Ethernet as a metropolitan-area network (MAN) and WAN technology imposes a new set of Operation, Administration, and Management (OAM) requirements on Ethernet's traditional operations, which had centered on enterprise networks only. The expansion of Ethernet technology into the domain of service providers, where networks are substantially larger and more complex than enterprise networks and the user-base is wider, makes operational management of link uptime crucial. More importantly, the timeliness in isolating and responding to a failure becomes mandatory for normal day-to-day operations, and OAM translates directly to the competitiveness of the service provider.

The “Configuring Ethernet Local Management Interface at a Provide Edge” module provides general information about configuring an Ethernet Local Management Interface (LMI), an OAM protocol, on a provider edge (PE) device.

- Finding Feature Information

- Prerequisites for Configuring Ethernet Local Management Interface at a Provider Edge

- Restrictions for Configuring Ethernet Local Management Interface at a Provider Edge

- Information About Configuring Ethernet Local Management Interface at a Provider Edge

- How to Configure Ethernet Local Management Interface at a Provider Edge

- Configuration Examples for Ethernet Local Management Interface at a Provider Edge

- Additional References for Configuring Ethernet Local Management Interface at a Provider Edge

- Feature Information for Configuring Ethernet Local Management Interface at a Provider Edge

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Configuring Ethernet Local Management Interface at a Provider Edge

- Ethernet Operation, Administration, and Management (OAM) must be operational in the network.

- For Ethernet OAM to operate, the provider edge (PE) side of a connection must be running Ethernet Connectivity Fault Management (CFM) and Ethernet Local Management Interface (LMI).

- All VLANs used on a PE device to connect to a customer edge (CE) device must also be created on that CE device.

- To use nonstop forwarding (NSF) and In Service Software Upgrade (ISSU), stateful switchover (SSO) must be configured and working properly.

Restrictions for Configuring Ethernet Local Management Interface at a Provider Edge

- Ethernet Local Management Interface (LMI) is not supported on routed ports, EtherChannel port channels, ports that belong to an EtherChannel, private VLAN ports, IEEE 802.1Q tunnel ports, Ethernet over Multiprotocol Label Switching (MPLS) ports, or Ethernet Flow Points (EFPs) on trunk ports.

- Ethernet LMI cannot be configured on VLAN interfaces.

Information About Configuring Ethernet Local Management Interface at a Provider Edge

- Ethernet Virtual Circuits Overview

- Ethernet LMI Overview

- Ethernet CFM Overview

- OAM Manager Overview

- Benefits of Ethernet LMI at a Provider Edge

- HA Features Supported by Ethernet LMI

- NSF SSO Support in Ethernet LMI

- ISSU Support in Ethernet LMI

Ethernet Virtual Circuits Overview

An Ethernet virtual circuit (EVC) as defined by the Metro Ethernet Forum is a port level point-to-point or multipoint-to-multipoint Layer 2 circuit. EVC status can be used by a customer edge (CE) device to find an alternative path in to the service provider network or in some cases to fall back to a backup path over Ethernet or another alternative service such as ATM.

Ethernet LMI Overview

Ethernet Local Management Interface (LMI) is an Ethernet Operation, Administration, and Management (OAM) protocol between a customer edge (CE) device and a provider edge (PE) device. Ethernet LMI provides CE devices with the status of Ethernet virtual circuits (EVCs) for large Ethernet metropolitan-area networks (MANs) and WANs and provides information that enables CE devices to autoconfigure. Specifically, Ethernet LMI runs on the PE-CE User-Network Interface (UNI) link and notifies a CE device of the operating state of an EVC and the time when an EVC is added or deleted. Ethernet LMI also communicates the attributes of an EVC.

Ethernet LMI interoperates with Ethernet Connectivity Fault Management (CFM), an OAM protocol that runs within the provider network to collect OAM status. Ethernet CFM runs at the provider maintenance level (user provider edge [UPE] to UPE at the UNI). Ethernet LMI relies on the OAM Ethernet Infrastructure (EI) to interwork with CFM to learn the end-to-end status of EVCs across CFM domains.

Ethernet LMI is disabled globally by default. When Ethernet LMI is enabled globally, all interfaces are automatically enabled. Ethernet LMI can also be enabled or disabled at the interface to override the global configuration. The last Ethernet LMI command issued is the command that has precedence. No EVCs, Ethernet service instances, or UNIs are defined, and the UNI bundling service is bundling with multiplexing.

Ethernet CFM Overview

Ethernet Connectivity Fault Management (CFM) is an end-to-end per-service-instance (per VLAN) Ethernet layer Operation, Administration, and Management (OAM) protocol that includes proactive connectivity monitoring, fault verification, and fault isolation. End-to-end CFM can be from provider edge (PE) device to PE device or from customer edge (CE) device to CE device. For more information about Ethernet CFM, see “Configuring Ethernet Connectivity Fault Management in a Service Provider Network” in the Carrier Ethernet Configuration Guide.

OAM Manager Overview

The OAM manager is an infrastructure element that streamlines interaction between Operation, Administration, and Management (OAM) protocols. The OAM manager requires two interworking OAM protocols, Ethernet Connectivity Fault Management (CFM) and Ethernet Local Management Interface (LMI). No interactions are required between Ethernet LMI and the OAM manager on the customer edge (CE) side. On the User Provider-Edge (UPE) side, the OAM manager defines an abstraction layer that relays data collected from Ethernet CFM to the Ethernet LMI device.

Ethernet LMI and the OAM manager interaction is unidirectional, from the OAM manager to Ethernet LMI on the UPE side of the device. An information exchange results from an Ethernet LMI request or is triggered by the OAM manager when it receives notification from the OAM protocol that the number of UNIs has changed. A change in the number of UNIs may cause a change in Ethernet virtual circuit (EVC) status.

The OAM manager calculates EVC status given the number of active user network interfaces (UNIs) and the total number of associated UNIs. You must configure CFM to notify the OAM manager of all changes to the number of active UNIs or to the remote UNI ID for a given service provider VLAN (S-VLAN) domain.

The information exchanged is as follows:

- EVC name and availability status (active, inactive, partially active, or not defined)

- Remote UNI name and status (up, disconnected, administratively down, excessive frame check sequence [FCS] failures, or not reachable)

- Remote UNI counts (the total number of expected UNIs and the number of active UNIs)

Benefits of Ethernet LMI at a Provider Edge

- Communication of end-to-end status of the Ethernet virtual circuit (EVC) to the customer edge (CE) device

- Communication of EVC and user network interface (UNI) attributes to a CE device

- Competitive advantage for service providers

HA Features Supported by Ethernet LMI

In access and service provider networks using Ethernet technology, high availability (HA) is a requirement, especially on Ethernet operations, administration, and management (OAM) components that manage Ethernet virtual circuit (EVC) connectivity. End-to-end connectivity status information is critical and must be maintained on a hot standby Route Processor (RP) (a standby RP that has the same software image as the active RP and supports synchronization of line card, protocol, and application state information between RPs for supported features and protocols).

End-to-end connectivity status is maintained on the customer edge (CE), provider edge (PE), and access aggregation PE (uPE) network nodes based on information received by protocols such as Ethernet Local Management Interface (LMI), Connectivity Fault Managment (CFM), and 802.3ah. This status information is used to either stop traffic or switch to backup paths when an EVC is down.

Metro Ethernet clients (E-LMI, CFM, 802.3ah) maintain configuration data and dynamic data, which is learned through protocols. Every transaction involves either accessing or updating data in the various databases. If the database is synchronized across active and standby modules, the modules are transparent to clients.

The Cisco infrastructure provides component application programming interfaces (APIs) that are helpful in maintaining a hot standby RP. Metro Ethernet HA clients (E-LMI, HA/ISSU, CFM HA/ISSU, 802.3ah HA/ISSU) interact with these components, update the database, and trigger necessary events to other components.

- Benefits of Ethernet LMI HA

Benefits of Ethernet LMI HA

- Elimination of network downtime for Cisco software image upgrades, resulting in higher availability.

- Elimination of resource scheduling challenges associated with planned outages and late night maintenance windows

- Accelerated deployment of new services and applications and faster implementation of new features, hardware, and fixes due to the elimination of network downtime during upgrades

- Reduced operating costs due to outages while the system delivers higher service levels due to the elimination of network downtime during upgrades

NSF SSO Support in Ethernet LMI

The redundancy configurations stateful switchover (SSO) and nonstop forwarding (NSF) are supported in Ethernet Local Management Interface (LMI) and are automatically enabled. A switchover from an active to a standby Route Processor (RP) or a standby Route Switch Processor (RSP) occurs when the active RP or RSP fails, is removed from the networking device, or is manually taken down for maintenance. The primary function of Cisco NSF is to continue forwarding IP packets following an RP or RSP switchover. NSF also interoperates with the SSO feature to minimize network downtime following a switchover.

For detailed information about the SSO and NSF features, see the High Availability Configuration Guide.

ISSU Support in Ethernet LMI

In Service Software Upgrade (ISSU) allows you to perform a Cisco software upgrade or downgrade without disrupting packet flow. Ethernet Local Management Interface (LMI) performs updates of the parameters within the Ethernet LMI database to the standby route processor (RP) or standby route switch processor (RSP). This checkpoint data requires ISSU capability to transform messages from one release to another. All the components that perform active processor to standby processor updates using messages require ISSU support. ISSU is automatically enabled in Ethernet LMI.

ISSU lowers the impact that planned maintenance activities have on network availability by allowing software changes while the system is in service. For detailed information about ISSU, see the High Availability Configuration Guide.

How to Configure Ethernet Local Management Interface at a Provider Edge

- Configuring Ethernet LMI Interaction with CFM

- Displaying Ethernet LMI and OAM Manager Information

Configuring Ethernet LMI Interaction with CFM

For Ethernet Local Management Interface (LMI) to function with Connectivity Fault Management (CFM), you must configure Ethernet virtual circuits (EVCs), Ethernet service instances including untagged Ethernet flow points (EFPs), and Ethernet LMI customer VLAN mapping. Most of the configuration occurs on the provider edge (PE) device on the interfaces connected to the customer edge (CE) device. On the CE device, you need only enable Ethernet LMI on the connecting interface. Also, you must configure operations, administration, and management (OAM) parameters; for example, EVC definitions on PE devices on both sides of a metro network.

CFM and OAM interworking requires an inward facing Maintenance Entity Group End Point (MEP).

- Configuring the OAM Manager

- Enabling Ethernet LMI

Configuring the OAM Manager

Note

If you configure, change, or remove a user network interface (UNI) service type, Ethernet virtual circuit (EVC), Ethernet service instance, or customer edge (CE)-VLAN configuration, all configurations are checked to ensure that the configurations match (UNI service type with EVC or Ethernet service instance and CE-VLAN configuration). The configuration is rejected if the configurations do not match.

Perform this task to configure the OAM manager on a provider edge (PE) device.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id

4.    service csi-id evc evc-name vlan vlan-id

5.    continuity-check

6.    continuity-check interval time

7.    exit

8.    exit

9.    ethernet evc evc-id

10.    oam protocol {cfm domain domain-name | ldp}

11.    uni count value [multipoint]

12.    exit

13.    Repeat Steps 3 through 12 to define other CFM domains that you want OAM manager to monitor.

14.    interface type number

15.    service instance id ethernet [evc-id]

16.    ethernet lmi ce-vlan map {vlan-id [untagged] | any | default | untagged}

17.    ethernet lmi interface

18.    encapsulation dot1q vlan-id

19.    bridge-domain domain-number

20.    cfm mep domain domain-name mpid mpid-id

21.    exit

22.    service instance service-instance-id ethernet

23.    encapsulation untagged

24.    l2protocol peer

25.    bridge-domain bridge-domain-number

26.    exit

27.    ethernet uni [bundle [all-to-one] | id uni-id | multiplex]

28.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id

Example:

Device(config)# ethernet cfm domain cstmr1 level 3

Defines a Connectivity Fault Management (CFM) domain, sets the domain leve,l and enters Ethernet CFM configuration mode.

Step 4

service csi-id evc evc-name vlan vlan-id

Example:

Device(config-ecfm)# service csi2 evc evc_1 vlan 10

Defines a universally unique customer service instance (CSI) and VLAN ID within the maintenance domain, and enters Ethernet CFM service configuration mode.

Step 5

continuity-check

Example:

Device(config-ecfm-srv)# continuity-check

Enables the transmission of continuity check messages (CCMs).

Step 6

continuity-check interval time

Example:

Device(config-ecfm-srv)# continuity-check interval 1s/10s/1m/10m

Enables the transmission of continuity check messages (CCMs) at specific intervals.

Step 7

exit

Example:

Device(config-ecfm-srv)# exit

Returns to Ethernet CFM configuration mode.

Step 8

exit

Example:

Device(config-ecfm)# exit

Returns to global configuration mode.

Step 9

ethernet evc evc-id

Example:

Device(config)# ethernet evc 50

Defines an EVC and enters EVC configuration mode.

Step 10

oam protocol {cfm domain domain-name | ldp}

Example:

Device(config-evc)# oam protocol cfm domain cstmr1

Configures the Ethernet virtual circuit (EVC) operations, administration, and management (OAM) protocol as CFM for the CFM domain maintenance level as configured in Steps 3 and 4.

Note:
If the CFM domain does not exist, this command is rejected, and an error message is displayed.

Step 11

uni count value [multipoint]

Example:

Device(config-evc)# uni count 3

(Optional) Sets the User Network Interface (UNI) count for the EVC.

- If this command is not issued, the service defaults to a point-to-point service. If a value of 2 is entered, point-to-multipoint service becomes an option. If a value of 3 or greater is entered, the service is point-to-multipoint.

Note:
If you enter a number greater than the number of endpoints, the UNI status is partially active even if all endpoints are up. If you enter a UNI count less than the number of endpoints, status might be active, even if all endpoints are not up.

Step 12

exit

Example:

Device(config-evc)# exit

Returns to global configuration mode.

Step 13

Repeat Steps 3 through 12 to define other CFM domains that you want OAM manager to monitor.

Example:

—

Step 14

interface type number

Example:

Specifies a physical interface connected to the CE device and enters interface configuration mode.

Step 15

service instance id ethernet [evc-id]

Example:

Device(config-if)# service instance 400 ethernet 50

Configures an Ethernet service instance on the interface and enters Ethernet service configuration mode.

- The Ethernet service instance identifier is a per-interface service identifier and does not map to a VLAN.

Step 16

ethernet lmi ce-vlan map {vlan-id [untagged] | any | default | untagged}

Example:

Device(config-if-srv)# ethernet lmi ce-vlan map 30

Configures an Ethernet LMI customer VLAN-to-EVC map for a particular UNI.

Note:
To specify both VLAN IDs and untagged VLANs in the map, specify the VLAN IDs first and then specify the untagged keyword as follows: ethernet lmi ce-vlan map 100,200,300,untagged. Also, if the untagged keyword is not specified in the map configuration, the main interface line protocol on the Customer Edge (CE) device will be down.

Step 17

ethernet lmi interface

Example:

Device(config-if-srv)# ethernet lmi interface

Enables Ethernet local management interface (LMI) on a UNI.

Step 18

encapsulation dot1q vlan-id

Example:

Device(config-if-srv)# encapsulation dot1q 2

Defines the matching criteria to map 802.1Q frames ingress on an interface to the appropriate service instance.

Step 19

bridge-domain domain-number

Example:

Device(config-if-srv)# bridge-domain 1

Binds a service instance to a bridge domain instance.

Step 20

cfm mep domain domain-name mpid mpid-id

Example:

Device(config-if-srv)# cfm mep domain provider mpid 10

Configures a maintenance endpoint (MEP) for a domain.

Step 21

exit

Example:

Device(config-if-srv)# exit

Returns to interface configuration mode.

Step 22

service instance service-instance-id ethernet

Example:

Device(config-if)# service instance 22 ethernet

Configures an Ethernet service instance on an interface and enters Ethernet service configuration mode.

Step 23

encapsulation untagged

Example:

Device(config-if-srv)# encapsulation untagged

Defines the matching criteria to map untagged ingress Ethernet frames on an interface to the appropriate service instance.

Step 24

l2protocol peer

Example:

Device(config-if-srv)# l2protocol peer

Configures transparent Layer 2 protocol peering on the interface.

Step 25

bridge-domain bridge-domain-number

Example:

Device(config-if-srv)# bridge-domain 1

Binds a service instance to a bridge domain instance.

Step 26

exit

Example:

Device(config-if)# exit

Returns to interface configuration mode.

Step 27

ethernet uni [bundle [all-to-one] | id uni-id | multiplex]

Example:

Device(config-if)# ethernet uni bundle

Sets UNI bundling attributes.

Step 28

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Enabling Ethernet LMI

The order in which the global and interface configuration commands are issued determines the configuration. The last command that is issued has precedence.

Perform this task to enable Ethernet Local Management Interface (LMI) on a device or on an interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    ethernet lmi interface

5.    ethernet lmi {n393 value | t392 value}

6.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface ethernet 1/3

Defines an interface to configure as an Ethernet LMI interface and enters interface configuration mode.

Step 4

ethernet lmi interface

Example:

Device(config-if)# ethernet lmi interface

Configures Ethernet LMI on the interface.

- When Ethernet LMI is enabled globally, it is enabled on all interfaces unless you disable it on specific interfaces. If Ethernet LMI is disabled globally, you can use this command to enable it on specified interfaces.

Step 5

ethernet lmi {n393 value | t392 value}

Example:

Device(config-if)# ethernet lmi n393 10

Configures Ethernet LMI parameters for the UNI.

Step 6

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Displaying Ethernet LMI and OAM Manager Information

Perform this task to display Ethernet Local Management Interface (LMI) or Operation, Administration, and Management (OAM) manager information. After step 1, all the steps are optional and can be performed in any order.

SUMMARY STEPS

1.    enable

2.    show ethernet lmi {{evc [detail evc-id [interface type number] | map interface type number]} | {parameters | statistics} interface type number | uni map [interface type number]}

3.    show ethernet service evc [detail | id evc-id [detail] | interface type number [detail]]

4.    show ethernet service instance [detail | id id | interface type number | policy-map | stats]

5.    show ethernet service interface [type number] [detail]

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show ethernet lmi {{evc [detail evc-id [interface type number] | map interface type number]} | {parameters | statistics} interface type number | uni map [interface type number]}

Example:

Device# show ethernet lmi evc

Displays information that was sent to the customer edge (CE).

Step 3

show ethernet service evc [detail | id evc-id [detail] | interface type number [detail]]

Example:

Device# show ethernet service evc

Displays information about all Ethernet virtual circuits (EVCs) or about a specified EVC.

Step 4

show ethernet service instance [detail | id id | interface type number | policy-map | stats]

Example:

Device# show ethernet service instance detail

Displays information about customer service instances.

Step 5

show ethernet service interface [type number] [detail]

Example:

Device# show ethernet service interface ethernet 1/3 detail

Displays interface-only information about Ethernet customer service instances for all interfaces or for a specified interface.

Examples

The following example shows sample output from the show ethernet lmi command using the evc keyword:

Device# show ethernet lmi evc

St  EVC Id                                                       Port
--- ------------------------------------------------------------ --------------
A  EVC_MP2MP_101                                                Gi0/1
A  EVC_P2P_110                                                  Gi0/1

The following example is sample output from the show ethernet service evc command:

Device# show ethernet service evc

Identifier                     Type  Act-UNI-cnt Status
50                             MP-MP     0       NotDefined

The following is sample output from the show ethernet service interface command using the detail keyword:

Device#

Interface: Gigabitethernet
ID: uni2
CE-VLANS: 30
EVC Map Type: Bundling
Associated EVCs:
EVC-ID                         CE-VLAN
50                             30
Associated Service Instances:
Service-Instance-ID CE-VLAN
400                 30

The following is sample output from the show ethernet service instance command using the detail keyword:

Device# show ethernet service instance detail

Service Instance ID: 400
Associated Interface: GigabitEthernet
Associated EVC: 50
CE-Vlans: 30
State: AdminDown
EFP Statistics:
Pkts In   Bytes In   Pkts Out  Bytes Out
0          0          0          0

Configuration Examples for Ethernet Local Management Interface at a Provider Edge

- Example: Ethernet OAM Manager on a PE Device Configuration

- Example: Ethernet LMI on a CE Device Configuration

Example: Ethernet OAM Manager on a PE Device Configuration

This example shows a sample configuration of Operation, Administration, and Management (OAM) manager, Connectivity Fault Management (CFM), and Ethernet Local Management Interface (LMI) on a provider edge (PE) device. In this example, a bridge domain is specified.

Device> enable
Device# configure terminal
Device(config)# ethernet cfm global
Device(config)# ethernet cfm domain provider level 4
Device(config-ecfm)# service customer_1 evc test1 vlan 10
Device(config-ecfm-srv)# continuity-check
Device(config-ecfm-srv)# continuity-check interval 1s/10s/1m/10m
Device(config-ecfm-srv)# exit
Device(config-ecfm)# exit
Device(config)# ethernet evc test1
Device(config-evc)# uni count 3
Device(config-evc)# oam protocol cfm domain provider
Device(config-evc)# exit
Device(config)#
Device(config-if)# ethernet lmi interface
Device(config-if)# ethernet uni id CISCO
Device(config-if)# service instance 1 ethernet
Device(config-if-srv)# encapsulation untagged
Device(config-if-srv)# l2protocol peer
Device(config-if-srv)# bridge-domain 1
Device(config-if-srv)# exit
Device(config-if)# service instance 2 ethernet1
Device(config-if-srv)# ethernet lmi ce-vlan map 101
Device(config-if-srv)# encapsulation dot1q 2
Device(config-if-srv)# bridge-domain 2
Device(config-if-srv)# cfm mep domain provider mpid 10
Device(config-if-srv-ecfm-mep)# end

This example shows a configuration of OAM manager, CFM, and Ethernet LMI over an Xconnect configuration:

Device> enable
Device# configure terminal
Device(config)# ethernet cfm global
Device(config)# ethernet cfm domain provider level 4
Device(config-ecfm)# service customer_1 evc test1
Device(config-ecfm-srv)# continuity-check
Device(config-ecfm-srv)# continuity-check interval 1s,10s,1m,10m
Device(config-ecfm-srv)# exit
Device(config-ecfm)# exit
Device(config)# ethernet evc test1
Device(config-evc)# oam protocol cfm domain provider
Device(config-evc)# exit
Device(config)#
Device(config-if)# ethernet lmi interface
Device(config-if)# ethernet uni id CISCO
Device(config-if)# service instance 1 ethernet
Device(config-if-srv)# encapsulation untagged
Device(config-if-srv)# l2protocol peer
Device(config-if-srv)# bridge-domain 1
Device(config-if-srv)# exit
Device(config-if)# service instance 2 ethernet
Device(config-if-srv)# ethernet lmi ce-vlan map 101
Device(config-if-srv)# encapsulation dot1q 2
Device(config-if-srv)# xconnect 10.1.1.1 100 encapsulation mpls
Device(cfg-if-ether-vc-xconn)# exit
Device(config-if-srv)# cfm mep domain provider mpid 10
Device(config-if-srv-ecfm-mep)# end

Example: Ethernet LMI on a CE Device Configuration

This example shows how to configure Ethernet Local Management Interface (LMI) globally on a customer edge (CE) device:

Device# configure terminal
Device(config)# ethernet lmi global
Device(config)# ethernet lmi ce
Device(config)# exit

Additional References for Configuring Ethernet Local Management Interface at a Provider Edge

Related Documents

Related Topic

Document Title

Ethernet Connectivity Fault Management (CFM)

“Configuring Ethernet Connectivity Fault Management in a Service Provider Network” in the Carrier Ethernet Configuration Guide

Ethernet Local Management Interface (LMI)

“Enabling Ethernet Local Management Interface” in the Carrier Ethernet Configuration Guide

Remote Port Shutdown feature

“Configuring Remote Port Shutdown” in the Carrier Ethernet Configuration Guide

IEEE 802.3ah

IEEE 802.3ah Ethernet in the First Mile

Cisco high availability (HA) configuration information

High Availability Configuration Guide

Ethernet LMI commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Standards

Standard

Title

IEEE P802.1ag/D5.2

Draft Standard for Local and Metropolitan Area Networks

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

IETF VPLS OAM

L2VPN OAM Requirements and Framework

Metro Ethernet Forum 16 Technical Specification

Technical Specification MEF 16- Ethernet Local Management Interface

ITU-T Q.3/13

Liaison statement on Ethernet OAM (Y.17ethoam)

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Configuring Ethernet Local Management Interface at a Provider Edge

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Configuring Ethernet Local Management Interface at a Provider Edge

Feature Name

Releases

Feature Information

Ethernet Local Management Interface at a Provider Edge

12.2(33)SRB 12.2(33)SXI

Ethernet LMI is an Ethernet OAM protocol between a CE device and a PE device. Ethernet LMI provides CE devices with the status of EVCs for large Ethernet MANs and WANs and provides information that enables CE devices to autoconfigure. Specifically, Ethernet LMI runs on the PE-CE UNI link and notifies a CE device of the operating state of an EVC and when an EVC is added or deleted. Ethernet LMI also communicates the attributes of an EVC.

In Cisco IOS Release 12.2(33)SRB, this feature was introduced on the Cisco 7600 series router.

The following commands were introduced or modified: debug ethernet lmi, debug ethernet service, ethernet evc, ethernet lmi ce-vlan map, ethernet uni, oam protocol, service instance ethernet, show ethernet service evc, show ethernet service instance, show ethernet service interface, uni count.

ISSU Support in E-LMI

12.2(33)SRD 15.0(1)S

ISSU allows you to perform a Cisco IOS software upgrade or downgrade without disrupting packet flow. ISSU lowers the impact that planned maintenance activities have on network availability by allowing software changes while the system is in service.

In Cisco IOS Release 12.2(33)SRD, this feature was introduced on the Cisco 7600 series router.

The following commands were introduced or modified: debug ethernet lmi.

NSF/SSO Support in E-LMI

12.2(33)SRD 15.0(1)S

The redundancy configurations SSO and NSF are supported in Ethernet LMI and are automatically enabled. A switchover from an active to a standby RP occurs when the active RP fails, is removed from the networking device, or is manually taken down for maintenance. The primary function of Cisco NSF is to continue forwarding IP packets following an RP switchover. NSF also interoperates with the SSO feature to minimize network downtime following a switchover.

In Cisco IOS Release 12.2(33)SRD, this feature was introduced on the Cisco 7600 series router.

The following commands were introduced or modified: debug ethernet lmi.

Chapter 15. Using Link Layer Discovery Protocol in Multivendor Networks

Link Layer Discovery Protocol (LLDP), standardized by the IEEE as part of 802.1ab, enables standardized discovery of nodes, which in turn facilitates future applications of standard management tools such as Simple Network Management Protocol (SNMP) in multivendor networks. Using standard management tools makes physical topology information available and helps network administrators detect and correct network malfunctions and inconsistencies in configuration.

Media Endpoint Discovery (MED) is an LLDP enhancement that was formalized by the Telecommunications Industry Association (TIA) for voice over IP (VoIP) applications.

The Cisco implementation of LLDP is based on the IEEE 802.1ab standard. This document describes LLDP and LLDP-MED and how they are supported in Cisco software.

- Finding Feature Information

- Prerequisites for Using Link Layer Discovery Protocol in Multivendor Networks

- Restrictions for Using Link Layer Discovery Protocol in Multivendor Networks

- Information About Using Link Layer Discovery Protocol in Multivendor Networks

- How to Configure Link Layer Discovery Protocol in Multivendor Networks

- Configuration Examples for Link Layer Discovery Protocol in Multivendor Networks

- Additional References for Using Link Layer Discovery Protocol in Multivendor Networks

- Feature Information for Link Layer Discovery Protocol in Multivendor Networks

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Using Link Layer Discovery Protocol in Multivendor Networks

- Type-Length-Value (TLV) types 0 through 127

- To support LLDP-MED, the following organizationally specific TLVs must be implemented:

- Extended Power-via-Media Dependent Interface (MDI)

- Inventory

- LLDP-MED Capabilities

- MAC/PHY Configuration Status

- Network Policy

- Port VLAN ID

Restrictions for Using Link Layer Discovery Protocol in Multivendor Networks

- Use of LLDP is limited to 802.1 media types such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) networks.

- The maximum number of neighbor entries per chassis is limited on MED-capable network connectivity devices.

Information About Using Link Layer Discovery Protocol in Multivendor Networks

- IEEE 802.1ab LLDP

- LLDP-MED

- TLV Elements

- Benefits of LLDP

IEEE 802.1ab LLDP

IEEE 802.1ab Link Layer Discovery Protocol (LLDP) is an optional link layer protocol for network topology discovery in multivendor networks. Discovery information includes device identifiers, port identifiers, versions, and other details. As a protocol that aids network management, LLDP provides accurate network mapping, inventory data, and network troubleshooting information.

LLDP is unidirectional, operating only in an advertising mode. LLDP does not solicit information or monitor state changes between LLDP nodes. LLDP periodically sends advertisements to a constrained multicast address. Devices supporting LLDP can send information about themselves while they receive and record information about their neighbors. Additionally, devices can choose to turn off the send or receive functions independently. Advertisements are sent out and received on every active and enabled interface, allowing any device in a network to learn about all devices to which it is connected. Applications that use this information include network topology discovery, inventory management, emergency services, VLAN assignment, and inline power supply.

Note

LLDP and Cisco Discovery Protocol can operate on the same interface.

The figure below shows a high-level view of LLDP operating in a network node.

When you configure LLDP or Cisco Discovery Protocol location information on a per-port basis, remote devices can send Cisco medianet location information to the switch. For more information, see the Using Cisco Discovery Protocol module.

LLDP-MED

LLDP-MED operates between several classes of network equipment such as IP phones, conference bridges, and network connectivity devices such as routers and switches. By default, a network connectivity device sends out only LLDP packets until it receives LLDP-MED packets from an endpoint device. The network device then sends out LLDP-MED packets until the remote device to which it is connected ceases to be LLDP-MED capable.

- Classes of Endpoints

- Types of Discovery Supported

- Benefits of LLDP-MED

Classes of Endpoints

LLDP-MED network connectivity devices provide IEEE 802 network access to LLDP-MED endpoints. LLDP-MED supports the following three classes of endpoints:

- Generic (class 1)—Basic participant endpoints; for example, IP communications controllers.

- Media (class 2)—Endpoints that support media streams; for example, media gateways and conference bridges.

- Communication Device (class 3)—Endpoints that support IP communications end users; for example, IP phones and Softphone.

The figure below shows an LLDP-MED-enabled LAN.

Types of Discovery Supported

LLDP-MED provides support to discover the following types of information, which are crucial to efficient operation and management of endpoint devices and the network devices supporting them:

- Capabilities —Endpoints determine the types of capabilities that a connected device supports and which ones are enabled.

- Inventory —LLDP-MED support exchange of hardware, software, and firmware versions, among other inventory details.

- LAN speed and duplex —Devices discover mismatches in speed and duplex settings.

- Location identification —An endpoint, particularly a telephone, learns its location from a network device. This location information may be used for location-based applications on the telephone and is important when emergency calls are placed.

- Network policy —Network connectivity devices notify telephones about the VLANs they should use.

- Power —Network connectivity devices and endpoints exchange power information. LLDP-MED provides information about how much power a device needs and how a device is powered. LLDP-MED also determines the priority of the device for receiving power.

Benefits of LLDP-MED

- Follows an open standard

- Supports E-911 emergency service, which is aided by location management

- Provides fast start capability

- Supports interoperability between multivendor devices

- Supports inventory management (location, version, etc.)

- Provides MIB support

- Supports plug and play installation

- Provides several troubleshooting (duplex, speed, network policy) mechanisms

TLV Elements

Link Layer Discovery Protocol (LLDP) and LLDP-Media Endpoint Discovery (MED) use Type-Length-Values (TLVs) to exchange information between network and endpoint devices. TLV elements are embedded in communications protocol advertisements and used for encoding optional information. The size of the type and length fields is fixed at 2 bytes. The size of the value field is variable. The type is a numeric code that indicates the type of field that this part of the message represents, and the length is the size of the value field, in bytes. The value field contains the data for this part of the message.

LLDP-MED supports the following TLVs:

- LLDP-MED capabilities TLV—Allows LLDP-MED endpoints to determine the capabilities that the connected device supports and has enabled.

- Network policy TLV—Allows both network connectivity devices and endpoints to advertise VLAN configurations and associated Layer 2 and Layer 3 attributes for the specific application on that port. For example, the switch can notify a phone of the VLAN number that it should use. The phone can connect to any switch, obtain its VLAN number, and then start communicating with the call control.

By defining a network-policy profile TLV, you can create a profile for voice and voice signalling by specifying the values for VLAN, class of service (CoS), differentiated services code point (DSCP), and tagging mode. These profile attributes are then maintained centrally on the switch and propagated to the phone.

- Power management TLV—Enables advanced power management between LLDP-MED endpoint and network connectivity devices. Allows switches and phones to convey power information, such as how the device is powered, power priority, and how much power the device needs. Supports advertisement of fractional wattage power requirements, endpoint power priority, and endpoint and network connectivity-device power status but does not provide for power negotiation between the endpoint and the network connectivity devices. When LLDP is enabled and power is applied to a port, the power TLV determines the actual power requirement of the endpoint device so that the system power budget can be adjusted accordingly. The switch processes the requests and either grants or denies power based on the current power budget. If the request is granted, the switch updates the power budget. If the request is denied, the switch turns off power to the port, generates a syslog message, and updates the power budget. If LLDP-MED is disabled or if the endpoint does not support the LLDP-MED power TLV, the initial allocation value is used throughout the duration of the connection.

Note

A system power budget is the default power allocated to a device based on its device class. However, the total power that can be sourced from a switch is finite, and there will be some power budgeting done by the power module based on the number of ports already being served, total power that can be served, and how much new ports are requesting.

- Inventory management TLV—Allows an endpoint to send detailed inventory information about itself to the switch, including information hardware revision, firmware version, software version, serial number, manufacturer name, model name, and asset ID TLV.

- Location TLV—Provides location information from the switch to the endpoint device. The location TLV can send this information:

- Civic location information—Provides the civic address information and postal information. Examples of civic location information are street address, road name, and postal community name information.

- ELIN location information—Provides the location information of a caller. The location is determined by the Emergency location identifier number (ELIN), which is a phone number that routes an emergency call to the local public safety answering point (PSAP) and which the PSAP can use to call back the emergency caller.

Benefits of LLDP

- Follows IEEE 802.1ab standard.

- Enables interoperability among multivendor devices.

- Facilitates troubleshooting of enterprise networks and uses standard network management tools.

- Provides extension for applications such as VoIP.

How to Configure Link Layer Discovery Protocol in Multivendor Networks

- Enabling and Disabling LLDP Globally

- Disabling and Enabling LLDP on a Supported Interface

- Setting LLDP Packet Hold Time

- Setting LLDP Packet Frequency

- Monitoring and Maintaining LLDP in Multivendor Networks

- Enabling and Disabling LLDP TLVs

- Enabling and Disabling LLDP-MED TLVs

Enabling and Disabling LLDP Globally

LLDP is disabled globally by default. This section describes the tasks for enabling and disabling LLDP globally.

- Enabling LLDP Globally

Enabling LLDP Globally

Perform this task to enable LLDP globally.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    lldp run

4.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

lldp run

Example:

Device(config)# lldp run

Enables LLDP globally.
Note:
To disable LLDP globally, use the no lldp run command.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Disabling and Enabling LLDP on a Supported Interface

LLDP is enabled by default on all supported interfaces. This section describes the tasks for disabling and enabling LLDP on a supported interface.

- Disabling LLDP on a Supported Interface

Disabling LLDP on a Supported Interface

Perform this task to disable LLDP on a supported interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    no lldp {med-tlv-select tlv | receive | transmit}

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface ethernet 0/1

Specifies the interface type and number and enters interface configuration mode.

Step 4

no lldp {med-tlv-select tlv | receive | transmit}

Example:

Device(config-if)# no lldp receive

Disables an LLDP-MED TLV or LLDP packet reception on a supported interface.
Note:
To enable LLDP on a Supported Interface, use the lldp {med-tlv-select tlv | receive | transmit command.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Setting LLDP Packet Hold Time

Hold time is the duration that a receiving device should maintain LLDP neighbor information before aging it. Perform this task to define a hold time for an LLDP-enabled device.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    lldp holdtime seconds

4.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

lldp holdtime seconds

Example:

Device(config)# lldp holdtime 100

Specifies the hold time.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Setting LLDP Packet Frequency

Perform this task to specify an interval at which the Cisco software sends LLDP updates to neighboring devices.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    lldp timer rate

4.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

lldp timer rate

Example:

Device(config)# lldp timer 75

Specifies the rate at which LLDP packets are sent every second.

Step 4

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Monitoring and Maintaining LLDP in Multivendor Networks

Perform this task to monitor and maintain LLDP in multivendor networks. This task is optional, and Steps 2 and 3 can be performed in any sequence.

SUMMARY STEPS

1.    enable

2.    show lldp [entry {* | word} | errors | interface [ethernet number]| neighbors [ethernet number| detail]| traffic]

3.    clear lldp {counters | table}

4.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

show lldp [entry {* | word} | errors | interface [ethernet number]| neighbors [ethernet number| detail]| traffic]

Example:

Device# show lldp entry *

Displays summarized and detailed LLDP information.

Note:
When the show lldp neighbors command is issued, if the device ID has more than 20 characters, the ID is truncated to 20 characters in command output because of display constraints.

Step 3

clear lldp {counters | table}

Example:

Device# clear lldp counters

Resets LLDP traffic counters and tables to zero.

Step 4

end

Example:

Device# end

Returns to user EXEC mode.

Enabling and Disabling LLDP TLVs

LLDP TLV support is enabled by default if LLDP is enabled globally and locally on a supported interface. Specific TLVs, however, can be enabled and suppressed.

- Enabling LLDP TLVs

Enabling LLDP TLVs

Perform this task to enable an LLDP TLV on a supported interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    lldp tlv-select tlv

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface ethernet 0/1

Specifies the interface type and number on which to enable LLDP-MED and enters interface configuration mode.

Step 4

lldp tlv-select tlv

Example:

Device(config-if)# lldp tlv-select system-description

Enables a specific LLDP TLV on a supported interface.
Note:
To disable LLDP TLVs, use the no lldp tlv-select tlv

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Enabling and Disabling LLDP-MED TLVs

LLDP-MED TLV support is enabled by default if LLDP is enabled globally and locally on a supported interface. Specific TLVs, however, can be enabled and suppressed.

- Enabling LLDP-MED TLVs

Enabling LLDP-MED TLVs

Perform this task to enable a specific LLDP-MED TLV on a supported interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type number

4.    lldp med-tlv-select tlv

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type number

Example:

Device(config)# interface ethernet 0/1

Specifies the interface type and number on which to enable LLDP-MED and enters interface configuration mode.

Step 4

lldp med-tlv-select tlv

Example:

Device(config-if)# lldp med-tlv-select inventory-management

Enables a specific LLDP-MED TLV on a supported interface.
Note:
To disable LLDP-MED TLVs, use the no lldp med-tlv-select tlv command.

Step 5

end

Example:

Device(config-if)# end

Returns to privileged EXEC mode.

Configuration Examples for Link Layer Discovery Protocol in Multivendor Networks

- Example: Configuring Voice VLAN

- Example Configuring LLDP on Two Devices

Example: Configuring Voice VLAN

The following example shows how to configure voice VLAN and verify

Device1> enable
Device1# configure terminal
Device1(config)# interface GigabitEthernet0/1/7
Device1(config-if)# switchport voice vlan 10
Device1(config-if)# no ip address
Device1(config-if)# end

The following example displays the updated running configuration on Device 2. LLDP is enabled with hold time, timer, and TLV options configured.

Device1# show lldp neighbors detail

Local Intf: Gi0/1/7
Chassis id: 10.10.0.1
Port id: C8F9F9D61BC2:P1
Port Description: SW PORT
System Name: SEPC8F9F9D61BC2

System Description:
Cisco IP Phone 7962G,V12, SCCP42.9-3-1ES27S

Time remaining: 127 seconds
System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses:
IP: 10.10.0.1
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(HD)
1000baseX(FD)
Symm, Asym Pause(FD)
Symm Pause(FD)
Media Attachment Unit type: 16
Vlan ID: - not advertised

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

H/W revision: 12
F/W revision: tnp62.8-3-1-21a.bin
S/W revision: SCCP42.9-3-1ES27S
Serial number: FCH1610A5S5
Manufacturer: Cisco Systems, Inc.
Model: CP-7962G
Capabilities: NP, PD, IN
Device type: Endpoint Class III
Network Policy(Voice): VLAN 10, tagged, Layer-2 priority: 5, DSCP: 46
Network Policy(Voice Signal): VLAN 10, tagged, Layer-2 priority: 4, DSCP: 32
PD device, Power source: Unknown, Power Priority: Unknown, Wattage: 6.3
Location - not advertised

The following example shows how to configure LLDP timer, hold time, and TLVs options on Device 2.

Device> enable
Device# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Device(config)# lldp run
Device(config)# lldp holdtime 150
Device(config)# lldp timer 15
Device(config)# lldp tlv-select port-vlan
Device(config)# lldp tlv-select mac-phy-cfg
Device2(config)# interface ethernet 0/0
Device2(config-if)# lldp transmit
Device2(config-if)# end
00:08:32: %SYS-5-CONFIG_I: Configured from console by console

The following example shows that voice vlan has been configured on the IP phone.

Device1# show lldp traffic
LLDP traffic statistics:
Total frames out: 20
Total entries aged: 0
Total frames in: 15
Total frames received in error: 0
Total frames discarded: 0
Total TLVs unrecognized: 0
Device1# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Device2             Et0/0          150        R               Et0/0
Total entries displayed: 1
Device2# show lldp traffic
LLDP traffic statistics:
Total frames out: 15
Total entries aged: 0
Total frames in: 17
Total frames received in error: 0
Total frames discarded: 2
Total TLVs unrecognized: 0
Device2# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Device1             Et0/0          150        R               Et0/0
Total entries displayed: 1

Example Configuring LLDP on Two Devices

The following example shows how to configure LLDP timer, hold time, and TLVs on two devices in a network. In each case we assume that the Ethernet interfaces being configured are in the UP state.

! Configure LLDP on Device 1 with hold time, timer, and TLV options.

Device1> enable
Device1# configure terminal
Device1(config)# lldp run
Device1(config)# lldp holdtime 150
Device1(config)# lldp timer 15
Device1(config)# lldp tlv-select port-vlan
Device1(config)# lldp tlv-select mac-phy-cfg
Device1(config)# interface ethernet 0/0
Device1(config-if)# end
00:08:32: %SYS-5-CONFIG_I: Configured from console by console
! Show the updated running configuration. LLDP is enabled with hold time, timer, and TLV options configured.

Device1# show running-config

Building configuration...
Current configuration : 1397 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Device1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
clock timezone PST -8
ip subnet-zero
!
!
lldp timer 15
lldp holdtime 150
!

! Configure LLDP on Device 2 with hold time, timer, and TLV options.

Device2> enable
Device2# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Device2(config)# lldp run
Device2(config)# lldp holdtime 150
Device2(config)# lldp timer 15
Device2(config)# lldp tlv-select port-vlan
Device2(config)# lldp tlv-select mac-phy-cfg
Device2(config)# interface ethernet 0/0
Device2(config-if)# end
00:08:32: %SYS-5-CONFIG_I: Configured from console by console

! Show the updated running configuration on Device 2. LLDP is enabled with hold time, timer, and TLV options configured.

Device2# show running-config
Building configuration...
Current configuration : 1412 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
clock timezone PST -8
ip subnet-zero
!
!
lldp timer 15
lldp holdtime 150
!

! After both devices are configured for LLDP, issue the show
command from each device to view traffic and device information.

Device1# show lldp traffic
LLDP traffic statistics:
Total frames out: 20
Total entries aged: 0
Total frames in: 15
Total frames received in error: 0
Total frames discarded: 0
Total TLVs unrecognized: 0
Device1# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Device2             Et0/0          150        R               Et0/0
Total entries displayed: 1
Device2# show lldp traffic
LLDP traffic statistics:
Total frames out: 15
Total entries aged: 0
Total frames in: 17
Total frames received in error: 0
Total frames discarded: 2
Total TLVs unrecognized: 0
Device2# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Device1             Et0/0          150        R               Et0/0
Total entries displayed: 1

Additional References for Using Link Layer Discovery Protocol in Multivendor Networks

Related Documents

Related Topic

Document Title

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

LLDP

Link Layer Discovery Protocol

Per Port Location configurations

Per Port Location Configuration

Comparison of LLDP Media Endpoint Discovery (MED) and Cisco Discovery Protocol

LLDP-MED and Cisco Discovery Protocol

Standards and RFCs

Standards/RFCs

Title

IEEE 802.1ab

Station and Media Access Control Connectivity Discovery

RFC 2922

Physical Topology MIB

MIBs

MIB

MIBs Link

PTOPO MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Link Layer Discovery Protocol in Multivendor Networks

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Using Link Layer Discovery Protocol in Multivendor Networks

Feature Name

Releases

Feature Information

IEEE 802.1ab LLDP (Link Layer Discovery Protocol)

Cisco IOS XE Release 3.8S

Cisco IOS XE Release 3.9S

LLDP, standardized by the IEEE as part of 802.1ab, enables standardized discovery of nodes, which in turn facilitates future applications of standard management tools such as SNMP in multivendor networks.

In Cisco IOS XE Release 3.9S, support was added for the Cisco ASR 903 Router.

The following commands were introduced or modified: clear lldp, lldp and show lldp.

ANSI TIA-1057 LLDP-MED Support

15.2(3)T

12.2(33)SXH

MED is an LLDP enhancement that was formalized by the TIA for VoIP applications. The Cisco implementation of LLDP is based on the IEEE 802.1ab standard.

The following commands were introduced or modified: lldp and lldp (interface).

IEEE 802.1ab LLDP (Link Layer Discovery Protocol)

Cisco IOS XE 3.2E

IEEE 802.3ad link bundling and load balancing leverages the EtherChannel infrastructure within Cisco software to manage the bundling of various links. The network traffic load-balancing features help minimize network disruption that results when a port is added or deleted from a link bundle.

MED is an LLDP enhancement that was formalized by the TIA for VoIP applications.

In Cisco IOS XE Release 3.2SE, this feature is supported on the following platforms:

- Cisco 5700 Series Wireless LAN Controllers

- Cisco Catalyst 3850 Series Switches

In Cisco IOS XE Release 3.3SE, this feature is supported on the following platforms:

- Cisco Catalyst 3650 Series Switches

LLDP MED Support on ISRG2

Cisco IOS Release 15.5(3)M

The LLDP MED feature is supported on Cisco Integrated Services Routers Generation 2 (ISR G2).

No commands were introduced or modified.

Chapter 16. Configuring ITU-T Y.1731 Fault Management Functions in IEEE CFM

This document describes the implementation of the ITU-Y.1731 fault management functions Ethernet Alarm Indication Signal (ETH-AIS) and Ethernet Remote Defect Indication (ETH-RDI) as part of the IEEE Ethernet Connectivity Fault Management (CFM) protocol.

- Finding Feature Information

- Prerequisites for Configuring ITU-T Y.1731 Fault Management Functions

- Restrictions for Configuring ITU-T Y.1731 Fault Management Functions

- Information About Configuring ITU-T Y.1731 Fault Management Functions

- How to Configure ITU-T Y.1731 Fault Management Functions

- Configuration Examples for Configuring ITU-T Y.1731 Fault Management Functions

- Additional References

- Feature Information for Configuring ITU-T Y.1731 Fault Management Functions

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for Configuring ITU-T Y.1731 Fault Management Functions

Business Requirements

- Business and service policies have been established.

- Network topology and network administration have been evaluated.

Technical Requirements

- CFM must be configured and enabled for Y.1731 fault management features to function.

- A server maintenance endpoint (SMEP) is needed to support the ETH-AIS function.

- Maintenance intermediate points (MIPs) must be configured to support AIS messages; they are generated only on an interface on which a MIP is configured.

Restrictions for Configuring ITU-T Y.1731 Fault Management Functions

- Because of a port-ASIC hardware limitation, IEEE CFM cannot coexist with the Per VLAN Spanning Tree (PVST) protocol, and IEEE CFM cannot operate with the following line cards on the same system:

- FI_WS_X6196_RJ21

- FI_WS_X6196_RJ45

- FI_WS_X6548_RJ21

- FI_WS_X6548_RJ45

- CFM loopback messages are not confined within a maintenance domain according to their maintenance level. The impact of not having CFM loopback messages confined to their maintenance levels occurs at these levels:

- Architecture--CFM layering is violated for loopback messages.

- Deployment--A user may misconfigure a network and have loopback messages succeed.

- Security--A malicious device that recognizes devices’ MAC addresses and levels may explore a network topology that should be transparent.

- Routed interfaces are supported only in Cisco IOS Release 12.4(11)T.

- IEEE CFM is not fully supported on a Multiprotocol Label Switching (MPLS) provider edge (PE) device. There is no interaction between IEEE CFM and an Ethernet over MPLS (EoMPLS) pseudowire. A CFM packet can be transparently passed like regular data packets only via pseudowire, with the following restriction:

- For policy feature card (PFC)-based EoMPLS, which uses a Cisco Catalyst LAN card as the MPLS uplink port, a CFM packet can be transparently passed via an EoMPLS pseudowire the same way regular data packets are passed. The EoMPLS endpoint interface, however, cannot be a maintenance endpoint (MEP) or an MIP, although a CFM MEP or MIP can be supported on regular Layer 2 switchport interfaces.

- CFM configuration is not supported on an EtherChannel in FastEthernet Channel (FEC) mode.

Information About Configuring ITU-T Y.1731 Fault Management Functions

- Continuity Check Messages

- Server MEPs

- Defect Conditions Detected by a MEP

- ETH-AIS Function

- ETH-RDI Function

Continuity Check Messages

CFM continuity check messages (CCMs) are multicast heartbeat messages exchanged periodically among MEPs. CCMs allow MEPs to discover other MEPs within a domain and allow MIPs to discover MEPs. CCMs are confined to a domain.

For more information about CCMs, see the “Continuity Check Messages” section of the "Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network" configuration module.

Server MEPs

Server MEPs (SMEPs) are virtual MEPs that perform two functions--server layer termination for CFM maintenance associations defined at a link or at the transport layer and server-Ethernet adaptation. When a SMEP detects a defect at the server layer, it issues frames containing ETH-AIS information.

Defect Conditions Detected by a MEP

The defect conditions that a MEP detects and subsequently acts upon are the following:

- AIS condition--A MEP receives an AIS frame.

- Dying gasp--An unrecoverable and vendor-specific condition. Dying gasp is generated in the following conditions:

- Administratively disabling 802.3ah

- Link down caused by administration down

- Power failure

- Reload

Note

Administratively disabling 802.3ah does not disrupt traffic and should not generate an AIS. If a Reason field is empty, however, disabling always generates an AIS when Cisco routers and non-Cisco routers are interworking.

A notification about the defect condition may be sent immediately and continuously.

- Loss of continuity (LOC) condition--A MEP stops receiving CCMs from a peer MEP. An LOC condition is a MEP down error.

LOC results when a remote MEP lifetime timer expires and causes an AIS condition for the local MEP. The LOC condition is cleared when connectivity is restored.

- Mismerge condition--A CCM with a correct maintenance level but incorrect maintenance ID indicates that frames from a different service instance are merged with the service instance represented by the receiving MEP’s maintenance ID. A mismerge condition is a cross-connect error.

- RDI condition--A MEP receives a CCM with the RDI field set.

- Signal fail condition--Declared by a MEP or the server layer termination function to notify the SMEP about a defect condition in the server layer. Signal fail conditions are as follows:

- Configuration error

- Cross-connect error

- LOC

- Loop error

- MEP missing

- MEP unknown (same as unexpected MEP)

Signal fail conditions cause AIS defect conditions for the MEP, resulting in the MEP receiving an AIS frame.

A MEP that detects a signal fail condition sends AIS frames to each of the client layer or sublayer maintenance associations.

- Unexpected MEP condition--A CCM with a correct maintenance level, correct maintenance ID, and an unexpected maintenance point ID (MPID) that is the same as the receiving MEP’s MPID. An unexpected MEP condition is either a cross-check error or a configuration error.

Determination of an unexpected MPID is possible when a MEP maintains a list of its peer MPIDs. Peer MPIDs must be configured on each MEP during provisioning.

ETH-AIS Function

The ETH-AIS function suppresses alarms when a defect condition is detected at either the server layer or the server sublayer (virtual MEP). Transmission of frames carrying ETH-AIS information can be either enabled or disabled on either a MEP or a SMEP and can be sent at the client maintenance level by either a MEP or SMEP when a defect condition is detected.

SMEPs monitor the entire physical link so that an AIS is generated for each VLAN or server on the network. MEPs monitor VLANs, Ethernet virtual circuits (EVCs), and SMEPs where link up or link down and 802.3ah interworking are supported. A MEP that detects a connectivity fault at a specific level multicasts an AIS in the direction opposite the detected failure at the client maintenance association (MA) level.

An AIS causes a receiving MEP to suppress traps to prevent the network management system (NMS) from receiving an excessive number of redundant traps and also so that clients are asynchronously informed about faults.

In a point-to-point topology, a MEP has a single peer MEP and there is no ambiguity regarding the peer MEP for which it should suppress alarms when it receives ETH-AIS information.

In a multipoint Ethernet topology, a MEP that receives a frame with ETH-AIS information cannot determine which remote peer lost connectivity. The MEP also cannot determine the associated subset of peer MEPs for which it should suppress alarms because the ETH-AIS information does not include that MEP information. Because the MEP cannot determine the affected peer MEPs, it suppresses alarms for all peer MEPs whether or not there is connectivity.

Due to independent restoration capabilities within Spanning Tree Protocol (STP) environments, ETH-AIS is not expected to be applied in these environments; however, ETH-AIS transmission is configurable in STP environments by a network administrator.

- ETH-AIS Transmission Reception and Processing

- AIS and 802.3ah Interworking

ETH-AIS Transmission Reception and Processing

Only a MEP or a SMEP can be configured to send frames with ETH-AIS information. When a MEP detects a defect condition, it immediately begins transmitting frames with ETH-AIS information at the configured client maintenance level, which is the level at which the MIP is configured on the interface. Frames are transmitted to peer MEPs in the direction opposite the fault. The first AIS frame must always be transmitted immediately following the detection of a defect condition, but thereafter frames are transmitted at a frequency based on the configured AIS transmission period. The transmitting MEP continues to transmit frames with ETH-AIS information until the defect condition is removed. The period flag in the frame’s header indicates the transmission interval. The default is that a MEP clears a defect condition only if no AIS frames are received within a time period equal to 3.5 times the configured transmission interval.

Note

An AIS transmission period of one second is recommended; however, an AIS transmission period of one minute is supported to enable ETH-AIS across all VLANs supported by IEEE CFM.

When a MEP receives a frame with ETH-AIS information, it examines the frame to ensure that the maintenance association level corresponds to its own maintenance association level. The MEP detects the AIS condition and suppresses loss-of-continuity alarms associated with all its peer MEPs. Peer MEPs can resume generating loss-of-continuity alarms only when the receiving MEP exits the AIS condition.

The client layer or client sublayer may consist of multiple maintenance associations that should also be notified to suppress alarms when either a server layer or server sublayer MEP detects a defect condition. The first AIS frame for all client layer or sublayer maintenance associations must be transmitted within one second after the defect condition is detected.

AIS and 802.3ah Interworking

The following conditions impact SMEP AIS conditions:

- By default, link down events cause the SMEP to enter the AIS condition and generate AIS frames for all services at the immediate client maintenance association level.

- Link up events cause the SMEP to exit the AIS state and stop generating AIS frames.

- Local fault detection results from dying gasp, link fault, or critical 802.3ah Remote Fault Indication (RFI). When 802.3ah is reestablished, the SMEP exits the AIS state and stops generating AIS frames.

- Local fault detection due to crossing of a high threshold with a configurable action of error disabling the interface.

- RFI received from a dying gasp, link fault, or critical event.

If a detected fault is due to dying gasp, the link goes down in both directions, creating AIS and RDI frame flow as shown in the figure below.

ETH-RDI Function

The ETH-RDI function is used by a MEP to communicate to its peer MEPs that a defect condition has been encountered. ETH-RDI is used only when ETH-CC transmission is enabled.

ETH-RDI has the following two applications:

- Single-ended fault management--A receiving MEP detects an RDI defect condition, which is correlated with other defect conditions in the MEP and may become the cause of a fault. If ETH-RDI information is not received by a single MEP, there are no defects in the entire MA.

- Contribution to far-end performance monitoring--A defect condition in the far end is used as an input to the performance monitoring process.

A MEP in a defect condition transmits CCMs with ETH-RDI information. A MEP that receives a CCM examines it to ensure that its maintenance association level corresponds to its configured maintenance association level and detects the RDI condition if the RDI field is set. The receiving MEP sets the RDI field in CCMs for the duration of a defect condition, and if the MEP is enabled for CCM transmission, transmits CCMs based on the configured transmission interval. When the defect condition clears, the MEP clears the RDI field in CCMs for subsequent transmissions.

In a point-to-point Ethernet connection, a MEP can clear an RDI condition when it receives the first CCM with the RDI field cleared from its peer MEP. In a multipoint Ethernet connection, a MEP cannot determine the peer MEP with the default condition and can clear an RDI condition only when it receives a CCM with the RDI field cleared from each of its peer MEPs.

The ETH-RDI function is part of continuity checking and is enabled by default. For more information about continuity checking, see the "Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network" configuration module.

How to Configure ITU-T Y.1731 Fault Management Functions

ETH-AIS and ETH-RDI both are enabled by default when CFM is configured, but each can also be manually enabled by a separate command during CFM configuration. Perform these tasks to either disable or enable the functions.

- Disabling the ETH-AIS Function

- Enabling ETH-AIS for a Single Interface SMEP and Disabling ETH-AIS for All Other Ports

Disabling the ETH-AIS Function

Perform this task to disable the ETH-AIS function.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm ais link-status global

4.    disable

5.    exit

6.    ethernet cfm domain domain-name level level-id [direction outward]

7.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

8.    no ais [expiry-threshold | level | period | suppress-alarms]

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm ais link-status global

Example:

Device(config)# ethernet cfm ais link-status global

Globally enables AIS generation and enters CFM SMEP AIS configuration mode.

Step 4

disable

Example:

Device(config-ais-link-cfm)# disable

Disables AIS transmission.

Step 5

exit

Example:

Device(config-ais-link-cfm)# exit

Returns the CLI to global configuration mode.

Step 6

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain PROVIDERDOMAIN level 4

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 7

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Device(config-ecfm)# service customer101provider evc customer101provider@101 vlan 101

Configures a maintenance association within a maintenance domain and enters Ethernet CFM service configuration mode.

Step 8

no ais [expiry-threshold | level | period | suppress-alarms]

Example:

Device(config-ecfm-srv)# no ais

Disables the AIS function for a specific maintenance association.

Step 9

end

Example:

Device(config-ecfm-srv)# end

Returns the CLI to privileged EXEC mode.

Enabling ETH-AIS for a Single Interface SMEP and Disabling ETH-AIS for All Other Ports

Perform this task to manually enable the ETH-AIS function.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ethernet cfm domain domain-name level level-id [direction outward]

4.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

5.    continuity-check [interval time | loss-threshold threshold | static rmep]

6.    ais [expiry-threshold threshold | level level-id | period seconds| suppress-alarms]

7.    ais [expiry-threshold threshold | level level-id | period seconds| suppress-alarms]

8.    exit

9.    service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

10.    continuity-check [interval time | loss-threshold threshold | static rmep]

11.    ethernet cfm ais link-status global

12.    disable

13.    interface type number

14.    ethernet oam remote-loopback {supported | timeout seconds}

15.    ethernet cfm mip level level-id [vlan {vlan-id| vlan-id - vlan-id| , vlan-id - vlan-id}]

16.    ethernet cfm ais link-status [level level-id| period seconds]

17.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm domain domain-name level level-id [direction outward]

Example:

Device(config)# ethernet cfm domain PROVIDERDOMAIN level 4

Defines a CFM maintenance domain at a particular maintenance level and enters Ethernet CFM configuration mode.

Step 4

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Device(config-ecfm)# service customer101provider evc customer101provider@101 vlan 101

Configures a maintenance association within a maintenance domain and enters Ethernet CFM service configuration mode.

Step 5

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Device(config-ecfm-srv)# continuity-check

Enables the transmission of CCMs.

Step 6

ais [expiry-threshold threshold | level level-id | period seconds| suppress-alarms]

Example:

Device(config-ecfm-srv)# ais period 1

Enables the AIS function for a specific maintenance association.

Step 7

ais [expiry-threshold threshold | level level-id | period seconds| suppress-alarms]

Example:

Device(config-ecfm-srv)# ais level 7

Enables the AIS function for a specific maintenance association.

Step 8

exit

Example:

Device(config-ecfm-srv)# exit

Returns the CLI to Ethernet CFM configuration mode.

Step 9

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:

Device(config-ecfm)# service customer110provider evc customer110provider@110 vlan 110

Configures a maintenance association within a maintenance domain and enters Ethernet CFM service configuration mode.

Step 10

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:

Device(config-ecfm-srv)# continuity-check

Enables the transmission of CCMs.

Step 11

ethernet cfm ais link-status global

Example:

Device(config-ecfm-srv)# ethernet cfm ais link-status global

Globally enables AIS generation and places the CLI in CFM SMEP AIS configuration mode (config-ais-link-cfm) to configure AIS commands for a SMEP.

Step 12

disable

Example:

Device(config-ais-link-cfm)# disable

Disables the generation of AIS frames resulting from a link-status change.

Step 13

interface type number

Example:

Device(config-ais-link-cfm)# interface ethernet 0/1

Configures an interface type and enters interface configuration mode.

Step 14

ethernet oam remote-loopback {supported | timeout seconds}

Example:

Device(config-if)# ethernet oam remote-loopback supported

Enables the support of Ethernet OAM remote loopback operations on an interface or sets a remote loopback timeout period.

Step 15

ethernet cfm mip level level-id [vlan {vlan-id| vlan-id - vlan-id| , vlan-id - vlan-id}]

Example:

Device(config-if)# ethernet cfm mip level 4 vlan 101

Provisions a MIP at a specified maintenance level on an interface.

Step 16

ethernet cfm ais link-status [level level-id| period seconds]

Example:

Device(config-if)# ethernet cfm ais link-status

Enables AIS generation from a SMEP.

Step 17

end

Example:

Device(config-if)# end

Returns the CLI to privileged EXEC mode.

Configuration Examples for Configuring ITU-T Y.1731 Fault Management Functions

- Example: Enabling IEEE CFM on an Interface

- Example: Enabling AIS

- Example: Show Commands Output

Example: Enabling IEEE CFM on an Interface

The following example shows how to enable IEEE CFM on an interface:

!
ethernet cfm domain ServiceProvider level 4
mep archive-hold-time 60
service MetroCustomer1 vlan 100
!
ethernet cfm domain OperatorA level 1
mep archive-hold-time 65
service MetroCustomer1OpA vlan 100
!
ethernet cfm enable
ethernet cfm traceroute cache
ethernet cfm traceroute cache size 200
ethernet cfm traceroute cache hold-time 60
!
interface gigabitethernet3/0
ethernet cfm mip level 1
!
interface gigabitethernet4/0
ethernet cfm mip level 4
ethernet cfm mep level 1 mpid 102 vlan 100
!
ethernet cfm cc enable level 1 vlan 100
ethernet cfm cc level any vlan any interval 20 loss-threshold 3

Example: Enabling AIS

The following example shows how to enable AIS:

!
ethernet cfm domain PROVIDER_DOMAIN level 4
service customer101provider evc customer101provider@101 vlan 101
continuity-check
ais period 1
ais level 7
service customer110provider evc customer110provider@110 vlan 110
continuity-check
!
ethernet cfm ais link-status global
disable
!
!
interface Ethernet 0/1
no ip address
ethernet oam remote-loopback supported
ethernet oam
ethernet cfm mip level 4 vlan 1,101,110
ethernet cfm ais link-status
!

Example: Show Commands Output

The following sample output from the show ethernet cfm maintenance-point local detail command shows the settings for the local MEP:

Device# show ethernet cfm maintenance-points local detail

MEP Settings:
-------------
MPID: 2101
DomainName: PROVIDERDOMAIN
Level: 4
Direction: I
Vlan: 101
Interface: Et0/1
CC-Status: Enabled
MAC: aabb.cc03.8410
Defect Condition: AIS
presentRDI: TRUE
AIS-Status: Enabled
AIS Period: 1000(ms)
AIS Expiry Threshold: 3.5
Level to transmit AIS: Default
Suppress Alarm configuration: Enabled
Suppressing Alarms: Yes

The following sample output from the show ethernet cfm smep command shows the settings for a SMEP:

Device# show ethernet cfm smep
SMEP Settings:
--------------
Interface: Ethernet0/0
AIS-Status: Enabled
AIS Period: 60000 (ms)
Level to transmit AIS: 4
Defect Condition: No Defect

The following sample output from the show ethernet cfm smep interface command shows the settings for a specific interface on a SMEP:

Device# show ethernet cfm smep interface ethernet 0/1
SMEP Settings:
--------------
Interface: Ethernet0/1
LCK-Status: Enabled
LCK Period: 60000 (ms)
Level to transmit LCK: Default
AIS-Status: Enabled
AIS Period: 60000 (ms)
Level to transmit AIS: Default
Defect Condition: No Defect
Router#

The following sample output from the show ethernet cfm errors command shows the Ethernet CFM errors on a device:

Device# show ethernet cfm errors
Level    Vlan    MPID    Remote MAC        Reason         Service ID
5        102     -       aabb.cc00.ca10    Receive AIS    service test

The following sample output from the show ethernet cfm maintenance-points remote detail command shows the detailed information about a specific remote MEP:

Device# show ethernet cfm maintenance-points remote detail mpid 66
MAC Address: aabb.cc00.ca10
Domain/Level: PROVIDERDOMAIN/4
EVC: test
MPID: 66 (Can ping/traceroute)
Incoming Port(s): Ethernet0/2
CC Lifetime(sec): 75
Age of Last CC Message(sec): 8
Receive RDI: TRUE
Frame Loss: 0%
CC Packet Statistics: 2/0 (Received/Error)
R1#MAC Address: aabb.cc00.ca10
Domain/Level: PROVIDERDOMAIN/4
EVC: test
MPID: 66 (Can ping/traceroute)
Incoming Port(s): Ethernet0/2
CC Lifetime(sec): 75
Age of Last CC Message(sec): 8
Receive RDI: TRUE
Frame Loss: 0%
CC Packet Statistics: 2/0 (Received/Error)

Additional References

Related Documents

Related Topic

Document Title

IEEE CFM

“Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network”

Using OAM

“Using Ethernet Operations, Administration, and Maintenance”

IEEE CFM and Y.1731 commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Standards

Standard

Title

IEEE 802.1ag

802.1ag - Connectivity Fault Management

IEEE 802.3ah

Ethernet in the First Mile

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Configuring ITU-T Y.1731 Fault Management Functions

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for Configuring ITU-T Y.1731 Fault Management Functions

Feature Name

Releases

Feature Information

Configuring ITU-T Y.1731 Fault Management Functions

15.0(1)XA 12.2(33)SRE 15.1(1)T

Cisco IOS XE Release 3.8S

The ITU-Y.1731 Fault Management Functions feature adds to IEEE CFM the ETH-AIS and ETH-RDI functions for fault detection, fault verification, and fault isolation in large MANs and WANs.

The following commands were introduced or modified: ais, clear ethernet cfm ais, disable(CFM-AIS-link), ethernet cfm ais link-status, ethernet cfm ais link-status global, level(cfm-ais-link), period(cfm-ais-link), show ethernet cfm errors, show ethernet cfm maintenance-points local, show ethernet cfm maintenance-points remote detail, show ethernet cfm smep.

Chapter 17. G.8032 and CFM Support for Microwave Adaptive Bandwidth

The G.8032 and CFM Support for Microwave Adaptive Bandwidth feature enables the G.8032 Ethernet Protection Ring (ERP) mechanism to be used as a trigger in response to bandwidth degradation occurrences (such as a signal degradation [SD] indicator) on microwave links. Ethernet Connectivity Fault Management (CFM) interacts with the microwave transceiver to continuously check the quality and the bandwidth of the microwave link. When microwave link degradation (based on the configured service level agreement [SLA] in use) is detected, CFM notifies the Embedded Event Manager (EEM), which in turn notifies a mechanism such as, G.8032 ERP. G.8032 ERP ensures that the degraded microwave link is bypassed and no longer used. The degraded microwave link can still be used by one or more of the G.8032 ERP instances. Only the affected G.8032 ERP instances are switched to alternate link.

- Finding Feature Information

- Prerequisites for G.8032 and CFM Microwave Adaptive Bandwidth Support

- Additional References for G.8032 and CFM Support for Microwave Adaptive Bandwidth

- Feature Information for G.8032 and CFM Support for Microwave Adaptive Bandwidth

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for G.8032 and CFM Microwave Adaptive Bandwidth Support

- The microwave transceiver in the network topology must support adaptive bandwidth modulation, and the microwave transceiver must support the Ethernet Connectivity Fault Management (CFM) extension for microwave devices as defined by Cisco.

- All devices connected directly to the microwave transceiver must support signal degradation (SD) functions. Devices not connected directly to the microwave transceiver can be standard-compliant nodes or enhanced SD-capable nodes.

- In any homogeneous ring topology, all links must be microwave links and all devices must support microwave SD-based ring protection.

- A ring topology with multiple microwave links can experience a signal degradation condition on one or more of the microwave links. Only one signal degradation condition per ring instance is supported. This support is provided on a first-come, first-serve basis, per ring instance.

Microwave Adaptive Bandwidth Feature Functionality

The G.8032 and CFM Support for Microwave Adaptive Bandwidth feature extends the functionality of the G.8032 Ethernet Protection Ring (ERP) mechanism and Ethernet Connectivity Fault Management (CFM).

This feature enables the G.8032 ERP mechanism to be used as a trigger in response to bandwidth degradation occurrences (such as a signal degradation [SD] indicator) on microwave links. Ethernet CFM interacts with the microwave transceiver to continuously check the quality and the bandwidth of the microwave link. When microwave link degradation (based on the configured service level agreement [SLA] in use) is detected, CFM notifies the Embedded Event Manager (EEM), which in turn notifies a mechanism such as, G.8032 ERP. G.8032 ERP ensures that the degraded microwave link is bypassed and no longer used. Depending upon the severity of the signal degradation and the configured threshold, G.8032 protection switching occurs on a per-instance basis.

For more information about Ethernet CFM, see the “Configuring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network” module or the “Configuring Ethernet Connectivity Fault Management in a Service Provider Network” module.

For more information about G.8032 ERP, see the “ITU-T G.8032 Ethernet Ring Protection Switching” module.

Fixed Versus Adaptive Bandwidth Modulation and the Microwave Adaptive Bandwidth Feature

Traditional microwave radios use fixed modulation schemes whereby any degradation in the wave propagation conditions (for example, due to adverse weather conditions such as heavy fog or rain) led to complete loss of the signal and a disruption of traffic. In a fixed modulation scheme, the microwave radio link had a binary state of either “'available” (on) or “unavailable” (off).

More technologically advanced microwave radios use an adaptive modulation scheme. In an adaptive modulation scheme, when the microwave link degrades due to adverse weather conditions, the radio changes its modulation scheme to a more robust scheme. The radio continues to broadcast but with less capacity. As a result, the radio can be in several capacity or bandwidth states, and not just on or off.

In the case of microwave links with adaptive modulation, the control Operation, Administration, and Maintenance (OAM) protocols are unable to make best use of the available bandwidth due of the following OAM characteristics:

- If the protocol used for failure detection is tagged as high-priority traffic, the OAM frames bypass the degraded (congested) microwave links and no protection switching is triggered.

- If the protocol used for failure detection is tagged as low-priority traffic, then momentary congestion over the native Ethernet (that is, the nonmicrowave) links could lead to loss of continuity and spurious protection switching.

Even though the network topology must be provisioned with enough redundant bandwidth to handle a complete failure, in certain situations where the service committed information rate (CIR) is very low, forwarding as much excess traffic (above the CIR) as possible is important. Therefore, for those situations, treating bandwidth degradation as a complete failure is not desirable.

Creating the Ethernet Microwave Event and Using G.8032 to Specify Appropriate Actions

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    event manager applet applet-name

4.    action action-id switch ring g8032 ring-name instance instance-id

5.    event ethernet microwave clear-sd {interface type number}

6.    action action-id switch ring g8032 clear ring-name instance {instance-id | all}

7.    Repeat steps 4 through 7 for each Ethernet microwave event you want to create. Then proceed to step 9.

8.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

event manager applet applet-name

Example:

Device(config)# event manager applet mw_ring_sd1

Registers an applet with the Embedded Event Manager (EEM) and enters applet configuration mode.

Step 4

action action-id switch ring g8032 ring-name instance instance-id

Example:

Device(config-applet)# action 1 switch ring g8032 ringA instance 1

Specifies the protocol switch action for an instance on a link of a G.8032 Ethernet Protection Ring (ERP).

Step 5

event ethernet microwave clear-sd {interface type number}

Example:

Device(config-applet)# event ethernet microwave clear-sd interface gigabitethernet0/0/0

Creates the Ethernet microwave event to be associated with bandwidth SD occurrences.

- After the event is created, use the action switch ring g8032 clear instance command at step 7 to clear the SD occurrence and bring the ring back to the normal (idle) state.

Step 6

action action-id switch ring g8032 clear ring-name instance {instance-id | all}

Example:

Device(config-applet)# action 1 switch ring g8032 clear ringA instance 1

Specifies the action of clearing an SD occurrence on a link of a G.8032 Ethernet Protection Ring (ERP) topology.

Step 7

Repeat steps 4 through 7 for each Ethernet microwave event you want to create. Then proceed to step 9.

Example:

—

Step 8

exit

Example:

Device(config-applet)# exit

Exits applet configuration mode.

Modifying Ethernet Microwave Event Settings

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface type name

4.    ethernet event microwave hold-off seconds

5.    ethernet event microwave loss-threshold number-of-messages

6.    ethernet event microwave wtr seconds

7.    exit

8.    show ethernet event microwave status [interface type number]

9.    show ethernet event microwave statistics [interface type number]

10.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface type name

Example:

Device(config)# interface gigabitethernet0/0/0

Specifies an interface and enters interface configuration mode.

Step 4

ethernet event microwave hold-off seconds

Example:

Device(config-if)# ethernet event microwave hold-off 30

Specifies the microwave bandwidth degradation hold-off time, in seconds.

- This time is used to prevent changes in the state of the network node as a result of signal degradation (SD) occurrences.

Step 5

ethernet event microwave loss-threshold number-of-messages

Example:

Device(config-if)# ethernet event microwave loss-threshold 3

Specifies the number of bandwidth Vendor-Specific Messages (VSM) sent from the microwave transceiver to the Cisco device.

Once the link experiences signal degradation, the microwave transceiver sends periodic bandwidth VSM messages to the Cisco device until the bandwidth is fully restored. The interval of these messages is controlled by the microwave transceiver.

This configuration specifies the continuous bandwidth VSM messages the Cisco device misses before declaring a signal recovery event.

Step 6

ethernet event microwave wtr seconds

Example:

Device(config-if)# ethernet event microwave wtr 45

Specifies the wait-to-restore (WTR) time, in seconds.

- This time is used to prevent changes in the state of the network node as a result of recovery events after an SD occurrence.

Step 7

exit

Example:

Device(config-if)# exit

Exits interface configuration mode.

Step 8

show ethernet event microwave status [interface type number]

Example:

Device# show ethernet event microwave status GigabitEthernet 0/0/2

(Optional) Displays the microwave event status.

Step 9

show ethernet event microwave statistics [interface type number]

Example:

Device# show ethernet event microwave statistics GigabitEthernet 0/0/2

(Optional) Displays the microwave event statistics.

Step 10

end

Example:

Device# end

Returns to user EXEC mode.

Example: Configuring the Ethernet Microwave Event

In this example, two Ethernet microwave events have been created, mw_ring_sdl1 and mw_ring_sd_2:

Device> enable
Device> configure terminal
Device(config)# event manager applet mw_ring_sd1
Device(config-applet)# event ethernet microwave sd interface gigabitethernet0/0/0 threshold 400
Device(config-applet)# action 1 switch ring g8032 ringA instance 1
Device(config-applet)# exit
Device(config)# event manager applet mw_ring_sd2
Device(config-applet)# event ethernet microwave sd interface gigabitethernet0/0/0 threshold 400
Device(config-applet)# action 1 switch ring g8032 ringA instance 2
Device(config-applet)# exit

In this example, a microwave event has been configured that clears all the signal degradation (SD) events, as defined by the action switch ring g8032 clear instance all command:

Device> enable
Device> configure terminal
Device(config)# event manager applet mw_ring_clear_sd
Device(config-applet)# event ethernet microwave clear-sd interface gigabitethernet0/0/0
Device(config-applet)# action 1 switch ring g8032 clear ringA instance all
Device(config-applet)# exit

Example: Verifying the Ethernet Microwave Event Configuration

The following is sample output from the show ethernet event microwave status command where GigabitEthernet interface 0/0/2 has been specified. Use the command to confirm that the configuration is performing as intended.

The following is sample output from the show ethernet event microwave statistics command where GigabitEthernet interface 0/0/2 has been specified:

Additional References for G.8032 and CFM Support for Microwave Adaptive Bandwidth

Related Documents

Related Topic

Document Title

Ethernet Connectivity Fault Management (CFM)

Configuring Ethernet Connectivity Fault Management in a Service Provider Network or Cofiguring IEEE Standard-Compliant Ethernet CFM in a Service Provider Network”

G.8032 Ethernet Ring Protection (ERP) administrative information and wiki

ITU-T G.8032 Ethernet Ring Protection Switching

Click Here

Operations, Administration, and Maintenance (OAM)

Using Ethernet Operations, Administration, and Maintenance

Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Master Command List, All Releases

Standards

Standard

Title

ITU-T

ITU-T Y.1731 OAM Mechanisms for Ethernet-Based Networks

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for G.8032 and CFM Support for Microwave Adaptive Bandwidth

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for G.8032 and CFM Support for Microwave Adaptive Bandwidth

Feature Name

Releases

Feature Information

G.8032 and CFM Support for Microwave Adaptive Bandwidth

15.3(2)S

The G.8032 and CFM Support for Microwave Adaptive Bandwidth feature extends the functionality of the G.8032 Ethernet Protection Ring (ERP) mechanism and Ethernet Connectivity Fault Management (CFM).

This feature enables the G.8032 ERP mechanism to be used as a trigger in response to bandwidth degradation occurrences (such as a signal degradation [SD] indicator) on microwave links. Ethernet CFM interacts with the microwave transceiver to continuously check the quality and the bandwidth of the microwave link. When microwave link degradation (based on the configured service level agreement [SLA] in use) is detected, CFM notifies the G.8032 ERP mechanism, which in turn ensures that the degraded microwave link is bypassed and no longer used. The degraded microwave link can still be used by one or more of the G.8032 ERP instances. Only the affected G.8032 ERP instances are switched to alternate link.

In Cisco IOS Release 15.3(2)S, support was added for the Cisco ASR 901 series Aggregation Services Router.

The following commands were introduced or modified: action switch ring g8032 clear instance, action switch switch ring g8032 instance, clear ethernet event microwave data, clear ethernet event microwave statistics, debug ethernet event microwave, ethernet event microwave, event ethernet microwave clear-sd, event ethernet microwave sd, show ethernet event microwave statistics, and show ethernet event microwave status.

Chapter 18. Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

This module describes how to configure an IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) operation to gather the following performance measurements for Ethernet service:

- Ethernet Delay

- Ethernet Delay Variation

- Ethernet Frame Loss Ratio

- Finding Feature Information

- Prerequisites for ITU-T Y.1731 Operations

- Restrictions for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731)

- Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for ITU-T Y.1731 Operations

IEEE-compliant Connectivity Fault Management (CFM) must be configured and enabled for Y.1731 performance monitoring to function.

Restrictions for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731)

- Depending on your Cisco software release, SNMP is not supported for reporting threshold events or collecting performance statistics for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) operations.

- Continuity Check Message (CCM)-based dual-ended Ethernet frame loss operations are not supported.

- In a single-ended Ethernet operation, performance measurement statistics can be retrieved only at the device on which the sender Ethernet Connectivity Fault Management (CFM) Maintenance End Point (MEP) is configured.

- Frame Loss Measurement is not supported on Cisco ME 3600X Series and 3800X Series Ethernet Access Switches.

- P2 IMs are to be used for CFM and Y1731

- Do not configure rewrite on the EFPs throughout the l2 circuit to avoid losing the cos value.

- CFMoXconnect on ASR903 works only if the control-word is switched on. To start DM timestamping, switch on the control-word if the remote end is not switched on.

- To avoid errors in RX and TX timestamping, ensure to have Y1731 sender as PTP master, and the Y1731 responder as PTP slave.

- Reconfigure IP SLA Y1731 while doing online insertion removal (OIR) of IM or router reload because local MEP is deleted during the course.

Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

This module describes how to configure an IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) operation to gather the following performance measurements for Ethernet service:

- Ethernet Delay

- Ethernet Delay Variation

- Ethernet Frame Loss Ratio

- How to Configure IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

- Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

- Additional References for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

- Feature Information for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

How to Configure IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

- Configuring a Dual-Ended Ethernet Delay or Delay Variation Operation

- Configuring a Sender MEP for a Single-Ended Ethernet Delay or Delay Variation Operation

- Configuring a Sender MEP for a Single-Ended Ethernet Frame Loss Ratio Operation

- Scheduling IP SLAs Operations

Configuring a Dual-Ended Ethernet Delay or Delay Variation Operation

Perform the tasks for configuring a dual-ended operation in the order presented.

Note

To remove the MEP configurations in an already-configured dual-ended operation, always remove the MEPs in the reverse order in which they were configured. That is, remove the scheduler first, then the threshold monitoring configuration, and then the sender MEP configuration on the source device before removing the scheduler, proactive threshold monitoring, and receiver MEP configuration on the destination device.

- Configuring a Receiver MEP on the Destination Device

- Configuring the Sender MEP on the Source Router

Configuring a Receiver MEP on the Destination Device

Before You Begin
Time synchronization is required between the source and destination devices in order to provide accurate one-way delay (latency) or delay-variation measurements. Configure either Precision Time Protocol (PTP) or Network Time Protocol (NTP) on both the source and destination devices.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip sla operation-number

4.    ethernet y1731 delay receive 1DM domain domain-name {evc evc-id | vlan vlan-id} cos cos {mpid source-mp-id | mac-address source-address}

5.    aggregate interval seconds

6.    distribution {delay | delay-variation} one-way number-of-bins boundary[,...,boundary]

7.    frame offset offset-value

8.    history interval intervals-stored

9.    max-delay milliseconds

10.    owner owner-id

11.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

ip sla operation-number

Example:

Router(config-term)# ip sla 501

Begins configuring an IP SLAs operation and enters IP SLA configuration mode.

Step 4

ethernet y1731 delay receive 1DM domain domain-name {evc evc-id | vlan vlan-id} cos cos {mpid source-mp-id | mac-address source-address}

Example:

Router(config-ip-sla)# ethernet y1731 delay receive 1DM domain xxx evc yyy cos 3 mpid 101

Begins configuring the receiver on the responder and enters IP SLA Y.1731 delay configuration mode.

- The source-mp-id or source-address configured by this command corresponds to that of the MEP being configured.

Step 5

aggregate interval seconds

Example:

Router(config-sla-y1731-delay)# aggregate interval 900

(Optional) Configures the length of time during which the performance measurements are conducted and the results stored.

Step 6

distribution {delay | delay-variation} one-way number-of-bins boundary[,...,boundary]

Example:

Router(config-sla-y1731-delay)# distribution delay-variation one-way 5 5000,10000,15000,20000,-1

(Optional) Specifies measurement type and configures bins for statistics distributions kept.

Step 7

frame offset offset-value

Example:

Router(config-sla-y1731-delay)# frame offset 1

(Optional) Sets the value for calculating delay variation rates.

Step 8

history interval intervals-stored

Example:

Router(config-sla-y1731-delay)# history interval 2

(Optional) Sets the number of statistics distributions kept during the lifetime of an IP SLAs Ethernet operation.

Step 9

max-delay milliseconds

Example:

Router(config-sla-y1731-delay)# max-delay 5000

(Optional) Sets the amount of time an MEP waits for a frame.

Step 10

owner owner-id

Example:

Router(config-sla-y1731-delay)# owner admin

(Optional) Configures the owner of an IP SLAs operation.

Step 11

end

Example:

Router(config-sla-y1731-delay)# end

Exits to privileged EXEC mode.

What to Do Next

To add proactive threshold conditions and reactive triggering for generating traps, see the "Configuring Proactive Threshold Monitoring" module of the IP SLAs Configuration Guide.

When you are finished configuring proactive threshold monitoring for this MEP, see the "Scheduling IP SLAs Operations" section to schedule the operation.

Configuring the Sender MEP on the Source Router

Before You Begin

- Time synchronization is required between the source and destination devices in order to provide accurate one-way delay (latency) or delay-variation measurements. Configure either Precision Time Protocol (PTP) or Network Time Protocol (NTP) on both the source and destination devices.

- The receiver MEP must be configured, including proacive threshold monitoring, and scheduled before you configure the sender MEP.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip sla operation-number

4.    ethernet y1731 delay 1DM domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} cos cos {source {mpid source-mp-id | mac-address source-address}}

5.    aggregate interval seconds

6.    frame interval milliseconds

7.    frame size bytes

8.    history interval intervals-stored

9.    owner owner-id

10.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

ip sla operation-number

Example:

Router(config)# ip sla 500

Begins configuring an IP SLAs operation and enters IP SLA configuration mode.

Step 4

ethernet y1731 delay 1DM domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} cos cos {source {mpid source-mp-id | mac-address source-address}}

Example:

Router(config-ip-sla)# ethernet y1731 delay 1DM domain xxx evc yyy mpid 101 cos 3 source mpid 100

Begins configuring a dual-ended Ethernet delay operation and enters IP SLA Y.1731 delay configuration mode.

Step 5

aggregate interval seconds

Example:

Router(config-sla-y1731-delay)# aggregate interval 900

(Optional) Configures the length of time during which the performance measurements are conducted and the results stored.

Step 6

frame interval milliseconds

Example:

Router(config-sla-y1731-delay)# frame interval 100

(Optional) Sets the gap between successive frames.

Step 7

frame size bytes

Example:

Router(config-sla-y1731-delay)# frame size 64

(Optional) Sets the padding size for frames.

Step 8

history interval intervals-stored

Example:

Router(config-sla-y1731-delay)# history interval 2

(Optional) Sets the number of statistics distributions kept during the lifetime of an IP SLAs Ethernet operation.

Step 9

owner owner-id

Example:

Router(config-sla-y1731-delay)# owner admin

(Optional) Configures the owner of an IP SLAs operation.

Step 10

end

Example:

Router(config-sla-y1731-delay)# end

Exits to privileged EXEC mode.

What to Do Next

To add proactive threshold conditions and reactive triggering for generating traps, see the "Configuring Proactive Threshold Monitoring" module of the IP SLAs Configuration Guide.

When you are finished configuring proactive threshold monitoring for this MEP, see the "Scheduling IP SLAs Operations" section to schedule the operation.

Configuring a Sender MEP for a Single-Ended Ethernet Delay or Delay Variation Operation

Perform this task to configure a sender MEP on the source device.

Before You Begin

- Time synchronization is required between the source and destination devices in order to provide accurate one-way delay (latency) or delay-variation measurements. Configure either Precision Time Protocol (PTP) or Network Time Protocol (NTP) on both the source and destination devices.

Note

To display information about remote (target) MEPs on destination devices, use the show ethernet cfm maintenance-points remote command.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip sla operation-number

4.    ethernet y1731 delay {DMM | DMMv1} [burst] domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} cos cos {source {mpid source-mp-id | mac-address source-address}}

5.    clock sync

6.    aggregate interval seconds

7.    distribution {delay | delay-variation} one-way number-of-bins boundary[,...,boundary]

8.    frame interval milliseconds

9.    frame offset offset-value

10.    frame size bytes

11.    history interval intervals-stored

12.    max-delay milliseconds

13.    owner owner-id

14.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip sla operation-number

Example:

Device(config-term)# ip sla 10

Begins configuring an IP SLAs operation and enters IP SLA configuration mode.

Step 4

ethernet y1731 delay {DMM | DMMv1} [burst] domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} cos cos {source {mpid source-mp-id | mac-address source-address}}

Example:

Device(config-ip-sla)# ethernet y1731 delay dmm domain xxx evc yyy mpid 101 cos 4 source mpid 100

Begins configuring a single-ended Ethernet delay operation and enters IP SLA Y.1731 delay configuration mode.

- To configure concurrent operations, use the DMMv1 keyword with this command. Repeat the preceding two steps to each concurrent operation, to be added to a single IP SLA operation number. Concurrent operations are supported for a given EVC, CoS, and remote MEP combination, or for multiple MEPs for a given multipoint EVC.

Step 5

clock sync

Example:

Device(config-sla-y1731-delay)# clock sync

(Optional) Indicates that the end points are synchronized and thus allows the operation to calculate one-way delay measurements.

Step 6

aggregate interval seconds

Example:

Device(config-sla-y1731-delay)# aggregate interval 900

(Optional) Configures the length of time during which the performance measurements are conducted and the results stored.

Step 7

distribution {delay | delay-variation} one-way number-of-bins boundary[,...,boundary]

Example:

Device(config-sla-y1731-delay)# distribution delay-variation one-way 5 5000, 10000,15000,20000,-1

(Optional) Specifies measurement type and configures bins for statistics distributions kept.

Step 8

frame interval milliseconds

Example:

Device(config-sla-y1731-delay)# frame interval 100

(Optional) Sets the gap between successive frames.

Step 9

frame offset offset-value

Example:

Device(config-sla-y1731-delay)# frame offset 1

(Optional) Sets value for calculating delay variation values.

Step 10

frame size bytes

Example:

Device(config-sla-y1731-delay)# frame size 32

(Optional) Configures padding size for frames.

Step 11

history interval intervals-stored

Example:

Device(config-sla-y1731-delay)# history interval 2

(Optional) Sets the number of statistics distributions kept during the lifetime of an IP SLAs Ethernet operation.

Step 12

max-delay milliseconds

Example:

Device(config-sla-y1731-delay)# max-delay 5000

(Optional) Sets the amount of time an MEP waits for a frame.

Step 13

owner owner-id

Example:

Device(config-sla-y1731-delay)# owner admin

(Optional) Configures the owner of an IP SLAs operation.

Step 14

end

Example:

Device(config-sla-y1731-delay)# end

Exits to privileged EXEC mode.

What to Do Next

To add proactive threshold conditions and reactive triggering for generating traps, see the "Configuring Proactive Threshold Monitoring" module of the IP SLAs Configuration Guide.

When you are finished configuring proactive threshold monitoring for this operation, see the "Scheduling IP SLAs Operations" section to schedule the operation.

Configuring a Sender MEP for a Single-Ended Ethernet Frame Loss Ratio Operation

Note

To display information about remote (target) MEPs on destination devices, use the show ethernet cfm maintenance-points remote command.

Perform this task to configure a sender MEP on the source device.

Before You Begin

- Class of Service (CoS)-level monitoring must be enabled on MEPs associated to the Ethernet frame loss operation by using the monitor loss counter command on the devices at both ends of the operation. See the Cisco IOS Carrier Ethernet Command Reference for command information. See the "Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations" section for configuration information.

Note

Cisco IOS Y.1731 implementation allows monitoring of frame loss for frames on an EVC regardless of the CoS value (any CoS or Aggregate CoS cases). See the "Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations" section for configuration information.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    ip sla operation-number

4.    ethernet y1731 loss {LMM | SLM} [burst] domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} CoS CoS {source {mpid source-mp-id | mac-address source-address}}

5.    aggregate interval seconds

6.    availability algorithm {sliding-window | static-window}

7.    frame consecutive value

8.    frame interval milliseconds

9.    history interval intervals-stored

10.    owner owner-id

11.    exit

12.    exit

13.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

ip sla operation-number

Example:

Device(config-term)# ip sla 11

Begins configuring an IP SLAs operation and enters IP SLA configuration mode.

Step 4

ethernet y1731 loss {LMM | SLM} [burst] domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} CoS CoS {source {mpid source-mp-id | mac-address source-address}}

Example:

Device(config-ip-sla)# ethernet y1731 loss LMM domain xxx vlan 12 mpid 34 CoS 4 source mpid 23

Begins configuring a single-ended Ethernet frame loss ratio operation and enters IP SLA Y.1731 loss configuration mode.

- To configure concurrent operations, use the SLM keyword with this command. Repeat the preceding two steps to configure each concurrent operation to be added to a single IP SLA operation number. Concurrent operations are supported for a given EVC, CoS, and remote-MEP combination, or for multiple MEPs for a given multipoint EVC.

Step 5

aggregate interval seconds

Example:

Device(config-sla-y1731-loss)# aggregate interval 900

(Optional) Configures the length of time during which performance measurements are conducted and the results stored.

Step 6

availability algorithm {sliding-window | static-window}

Example:

Device(config-sla-y1731-loss)# availability algorithm static-window

(Optional) Specifies availability algorithm used.

Step 7

frame consecutive value

Example:

Device(config-sla-y1731-loss)# frame consecutive 10

(Optional) Specifies number of consecutive measurements to be used to determine availability or unavailability status.

Step 8

frame interval milliseconds

Example:

Device(config-sla-y1731-loss)# frame interval 100

(Optional) Sets the gap between successive frames.

Step 9

history interval intervals-stored

Example:

Device(config-sla-y1731-loss)# history interval 2

(Optional) Sets the number of statistics distributions kept during the lifetime of an IP SLAs Ethernet operation.

Step 10

owner owner-id

Example:

Device(config-sla-y1731-delay)# owner admin

(Optional) Configures the owner of an IP SLAs operation.

Step 11

exit

Example:

Device(config-sla-y1731-delay)# exit

Exits to IP SLA configuration mode.

Step 12

exit

Example:

Device(config-ip-sla)# exit

Exits to global configuration mode.

Step 13

exit

Example:

Device(config)# exit

Exits to privileged EXEC mode.

What to Do Next

When you are finished configuring this MEP, see the "Scheduling IP SLAs Operations" section to schedule the operation.

Scheduling IP SLAs Operations

Before You Begin

- All IP Service Level Agreements (SLAs) operations to be scheduled must be already configured.

- The frequency of all operations scheduled in a multioperation group must be the same.

- The list of one or more operation ID numbers to be added to a multioperation group must be limited to a maximum of 125 characters in length, including commas (,).

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    Enter one of the following commands:

- ip sla schedule operation-number [life {forever | seconds}] [start-time {[hh:mm:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

- ip sla group schedule group-operation-number operation-id-numbers {schedule-period schedule-period-range | schedule-together} [ageout seconds] [frequency group-operation-frequency] [life {forever | seconds}] [start-time {hh:mm [:ss] [month day | day month] | pending | now | after hh:mm [:ss]}]

4.    end

5.    show ip sla group schedule

6.    show ip sla configuration

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

Enter one of the following commands:

- ip sla schedule operation-number [life {forever | seconds}] [start-time {[hh:mm:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

- ip sla group schedule group-operation-number operation-id-numbers {schedule-period schedule-period-range | schedule-together} [ageout seconds] [frequency group-operation-frequency] [life {forever | seconds}] [start-time {hh:mm [:ss] [month day | day month] | pending | now | after hh:mm [:ss]}]

Example:

Device(config)# ip sla schedule 10 life forever start-time now

Device(config)# ip sla schedule 10 schedule-period frequency

Device(config)# ip sla group schedule 1 3,4,6-9 life forever start-time now

Device(config)# ip sla schedule 1 3,4,6-9 schedule-period 50 frequency range 80-100

- Configures the scheduling parameters for an individual IP SLAs operation.

- Specifies an IP SLAs operation group number and the range of operation numbers for a multioperation scheduler.

Step 4

end

Example:

Device(config)# end

Exits global configuration mode and returns to privileged EXEC mode.

Step 5

show ip sla group schedule

Example:

Device# show ip sla group schedule

(Optional) Displays IP SLAs group schedule details.

Step 6

show ip sla configuration

Example:

Device# show ip sla configuration

(Optional) Displays IP SLAs configuration details.

Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

- Example: Dual-Ended Ethernet Delay Operation

- Example: Frame Delay and Frame Delay Variation Measurement Configuration

- Example: Sender MEP for a Single-Ended Ethernet Delay Operation

- Example: Sender MEP for a Single-Ended Ethernet Frame Loss Operation

Example: Dual-Ended Ethernet Delay Operation

The following sample output shows the configuration, including default values, of a receiver MEP on the responder device for a dual-ended Ethernet delay or delay variation operation:

Device# show ip sla configuration 501

IP SLAs Infrastructure Engine-III
Entry number: 501
Owner: admin
Tag:
Operation timeout (milliseconds): 5000
Ethernet Y1731 Delay Operation
Frame Type: 1DM
Domain: xxx
ReceiveOnly: TRUE
Evc: yyy
Local Mpid: 101
CoS: 3
Max Delay: 5000
Threshold (milliseconds): 5000
.
.
.
Statistics Parameters
Aggregation Period: 900
Frame offset: 1
Distribution Delay One-Way:
Number of Bins 10
Bin Boundaries: 5000,10000,15000,20000,25000,30000,35000,40000,45000,-1
Distribution Delay-Variation One-Way:
Number of Bins 10
Bin Boundaries: 5000,10000,15000,20000,25000,30000,35000,40000,45000,-1
History
Number of intervals: 2

The following sample output shows the configuration, including default values, of the sender MEP for a dual-ended IP SLAs Ethernet delay or delay variation operation:

Device# show ip sla configuration 500

IP SLAs Infrastructure Engine-III
Entry number: 500
Owner:
Tag:
Operation timeout (milliseconds): 5000
Ethernet Y1731 Delay Operation
Frame Type: 1DM
Domain: yyy
ReceiveOnly: FALSE
Evc: xxx
Target Mpid: 101
Source Mpid: 100
CoS: 3
Request size (Padding portion): 64
Frame Interval: 1000
Threshold (milliseconds): 5000
.
.
.
Statistics Parameters
Aggregation Period: 900
Frame offset: 1
History
Number of intervals: 22

Example: Frame Delay and Frame Delay Variation Measurement Configuration

The following sample output shows the performance monitoring session summary:

Device# show ethernet cfm pm session summary

Number of Configured Session : 2
Number of Active Session: 2
Number of Inactive Session: 0

The following sample output shows the active performance monitoring session:

Device# show ethernet cfm pm session active

Display of Active Session
--------------------------------------------------------------------------------
EPM-ID   SLA-ID    Lvl/Type/ID/Cos/Dir     Src-Mac-address Dst-Mac-address
--------------------------------------------------------------------------------
0     10           3/BD-V/10/2/Down     d0c2.8216.c9d7  d0c2.8216.27a3
1     11           3/BD-V/10/3/Down     d0c2.8216.c9d7  d0c2.8216.27a3
Total number of Active Session: 2

Device# show ethernet cfm pm session db 0

----------------------------------------------------------------------------
TX Time FWD                   RX Time FWD
TX Time BWD                   RX Time BWD              Frame Delay
Sec:nSec                      Sec:nSec                  Sec:nSec
----------------------------------------------------------------------------
Session ID: 0
****************************************************************************
234:526163572                  245:305791416
245:306761904                  234:527134653            0:593
****************************************************************************
235:528900628                  246:308528744
246:309452848                  235:529825333            0:601
****************************************************************************
236:528882716                  247:308511128
247:309450224                  236:529822413            0:601
****************************************************************************
237:526578788                  248:306207432
248:307157936                  237:527529885            0:593
****************************************************************************
238:527052156                  249:306681064
249:307588016                  238:527959717            0:609
****************************************************************************
239:526625044                  250:306254200
250:307091888                  239:527463325            0:593
****************************************************************************
240:528243204                  251:307872648
251:308856880                  240:529228021            0:585

Example: Sender MEP for a Single-Ended Ethernet Delay Operation

The following sample output shows the configuration, including default values, of the sender MEP for a single-ended IP SLAs Ethernet delay operation:

Router# show ip sla configuration 10

IP SLAs Infrastructure Engine-III
Entry number: 10
Owner:
Tag:
Operation timeout (milliseconds): 5000
Ethernet Y1731 Delay Operation
Frame Type: DMM
Domain: xxx
Vlan: yyy
Target Mpid: 101
Source Mpid: 100
CoS: 4
Max Delay: 5000
Request size (Padding portion): 64
Frame Interval: 1000
Clock: Not In Sync
Threshold (milliseconds): 5000
.
.
.
Statistics Parameters
Aggregation Period: 900
Frame offset: 1
Distribution Delay Two-Way:
Number of Bins 10
Bin Boundaries: 5000,10000,15000,20000,25000,30000,35000,40000,45000,-1
Distribution Delay-Variation Two-Way:
Number of Bins 10
Bin Boundaries: 5000,10000,15000,20000,25000,30000,35000,40000,45000,-1
History
Number of intervals: 2

Example: Sender MEP for a Single-Ended Ethernet Frame Loss Operation

The following output shows the configuration, including default values, of the sender MEP in a basic single-ended IP SLAs Ethernet frame loss ratio operation with a start-time of now:

Router# show ip sla configuration 11

IP SLAs Infrastructure Engine-III
Entry number: 11
Owner:
Tag:
Operation timeout (milliseconds): 5000
Ethernet Y1731 Loss Operation
Frame Type: LMM
Domain: xxx
Vlan: 12
Target Mpid: 34
Source Mpid: 23
CoS: 4
Request size (Padding portion): 0
Frame Interval: 1000
Schedule:
Operation frequency (seconds): 60  (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): 3600
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): ActiveThreshold (milliseconds): 5000
Statistics Parameters
Aggregation Period: 900
Frame consecutive: 10
Availability algorithm: static-window
History
Number of intervals: 2

Additional References for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Cisco IOS Carrier Ethernet commands

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS IP SLAs commands

Cisco IOS IP SLAs Command Reference

Ethernet CFM

“Configuring Ethernet Connectivity Fault Management in a Service Provider Network” module of the Cisco IOS Carrier Ethernet Configuration Guide

Network Time Protocol (NTP)

“Configuring NTP” module of the Cisco IOS Network Management Configuration Guide

Proactive threshold monitoring for Cisco IOS IP SLAs

“Configuring Proactive Threshold Monitoring of IP SLAs Operations” module of the Cisco IOS IP SLAs Configuration Guide

Standards and RFCs

Standard/RFC

Title

ITU-T Y.1731

OAM functions and mechanisms for Ethernet-based networks

No specific RFCs are supported by the features in this document.

--

MIBs

MIB

MIBs Link

- CISCO-IPSLA-ETHERNET-MIB

- CISCO-RTTMON-MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731)

Feature Name

Releases

Feature Information

IP SLA Support for ETH-SLM (Ethernet Synthetic Loss Measurement in Y1731)

Cisco IOS XE Release 3.8S

Y.1731 Performance Monitoring (PM) provides a standard Ethernet PM function that includes measurement of Ethernet frame delay, frame delay variation, frame loss, and frame throughput measurements specified by the ITU-T Y-1731 standard and interpreted by the Metro Ethernet Forum (MEF) standards group.

In Cisco IOS XE Release 3.8S, support was added for Cisco ASR 900 Series.

Y1731 MIB Support through existing IPSLA MIBs

Cisco IOS XE Release 3.8S

Support was added for reporting threshold events and collecting performance statistics for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) operations using SNMP.

Chapter 19. IPSLA Y1731 On-Demand and Concurrent Operations

This module describes how to configure the IPSLA Y1731 SLM Feature Enhancements feature for enabling real-time Ethernet service troubleshooting for users without configuration privileges. This feature supports on-demand Synthetic Loss Measurement (SLM) operations that can be run by issuing a single command in privileged EXEC mode.

- Finding Feature Information

- Prerequisites for ITU-T Y.1731 Operations

- Restrictions for IP SLAs Y.1731 On-Demand Operations

- Additional References for IP SLAs Y.1731 On-Demand and Concurrent Operations

- Feature Information for IP SLAs Y.1731 On-Demand and Concurrent Operations

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for ITU-T Y.1731 Operations

IEEE-compliant Connectivity Fault Management (CFM) must be configured and enabled for Y.1731 performance monitoring to function.

Restrictions for IP SLAs Y.1731 On-Demand Operations

- SNMP is not supported for reporting threshold events or collecting performance statistics for on-demand operations.

- On-demand operation statistics are not stored and are not supported by the statistic history and aggregation functions.

IPSLA Y1731 SLM Feature Enhancements

On-demand IP SLAs Synthetic Loss Measurement (SLM) operations, in the IPSLA Y1731 SLM Feature Enhancements feature, enable users without configuration access to perform real-time troubleshooting of Ethernet services. There are two operational modes for on-demand operations: direct mode that creates and runs an operation immediately and referenced mode that starts and runs a previously configured operation.

- In the direct mode, a single command can be used to create multiple pseudo operations for a range of class of service (CoS) values to be run, in the background, immediately. A single command in privileged EXEC mode can be used to specify frame size, interval, frequency, and duration for the direct on-demand operation. Direct on-demand operations start and run immediately after the command is issued.

- In the referenced mode, you can start one or more already-configured operations for different destinations, or for the same destination, with different CoS values. Issuing the privileged EXEC command creates a pseudo version of a proactive operation that starts and runs in the background, even while the proactive operation is running.

- Once an on-demand operation is completed, statistical output is displayed on the console. On-demand operation statistics are not stored and are not supported by the statistic history and aggregation functions.

- After an on-demand operation is completed, and the statistics handled, the direct and referenced on-demand operation is deleted. The proactive operations are not deleted and continue to be available to be run in referenced mode, again.

A concurrent operation consists of a group of operations, all configured with the same operation ID number, that run concurrently. Concurrent operations are supported for a given Ethernet Virtual Circuit (EVC), CoS, and remote Maintenance End Point (MEP) combination, or for multiple MEPs for a given multipoint EVC, for delay or loss measurements. A new keyword was added to the appropriate commands to specify that concurrent Ethernet frame Delay Measurement (ETH-DM) synthetic frames are sent during the operation.

The IPSLA Y.1731 SLM Feature Enhancements feature also supports burst mode for concurrent operations, one-way dual-ended, and single-ended delay and delay variation operations, as well as for single-ended loss operations. A new keyword was added to the appropriate commands to support bursts of PDU transmission during an aggregation interval. The maximum number of services monitored is 50 every 30 minutes, with an average of 25 services every 2 hours.

Configuring a Direct On-Demand Operation on a Sender MEP

Before You Begin
Class of Service (CoS)-level monitoring must be enabled on MEPs associated to the Ethernet frame loss operation by using the monitor loss counter command on the devices at both ends of the operation. See the Cisco IOS Carrier Ethernet Command Reference for command information. See the “Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations” section for configuration information.

Note

The Cisco IOS Y.1731 implementation allows monitoring of frame loss on an EVC regardless of the CoS value (any CoS or aggregate CoS cases). See the “Configuration Examples for IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations” section for configuration information.

SUMMARY STEPS

1.    enable

2.    ip sla on-demand ethernet {DMMv1 | SLM} domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} cos cos {source {mpid source-mp-id | mac-address source-address}} {continuous [interval milliseconds] | burst [interval milliseconds] [number number-of-frames] [frequency seconds]} [size bytes] aggregation seconds {duration seconds | max number-of-packets}

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

ip sla on-demand ethernet {DMMv1 | SLM} domain domain-name {evc evc-id | vlan vlan-id} {mpid target-mp-id | mac-address target-address} cos cos {source {mpid source-mp-id | mac-address source-address}} {continuous [interval milliseconds] | burst [interval milliseconds] [number number-of-frames] [frequency seconds]} [size bytes] aggregation seconds {duration seconds | max number-of-packets}

Example:

Device# ip sla on-demand ethernet SLM domain xxx vlan 12 mpid 34 cos 4 source mpid 23 continuous aggregation 10 duration 60

Creates and runs an on-demand operation in direct mode.

- To create and run concurrent on-demand operations, configure this command using the DMMv1 keyword.

- Statistical output is posted on the console after the operation is finished.

- Repeat this step for each on-demand operation to be run.

- After an on-demand operation is finished and the statistics handled, the operation is deleted.

Configuring a Referenced On-Demand Operation on a Sender MEP

Note

After an on-demand operation is finished and the statistics handled, the on-demand version of the operation is deleted.

Before You Begin

- Single-ended and concurrent Ethernet delay, or delay variation, and frame loss operations to be referenced must be configured. See the “Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations” module of the IP SLAs Configuration Guide.

SUMMARY STEPS

1.    enable

2.    ip sla on-demand ethernet [dmmv1 | slm] operation-number {duration seconds | max number-of-packets

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

ip sla on-demand ethernet [dmmv1 | slm] operation-number {duration seconds | max number-of-packets

Example:

Device# ip sla on-demand ethernet slm 11 duration 38

Creates and runs a pseudo operation of the operation being referenced, in the background.

- Statistical output is posted on the console after the operation is finished.

- Repeat this step for each on-demand operation to be run.

Configuring an IP SLAs Y.1731 Concurrent Operation on a Sender MEP

To configure concurrent Ethernet delay, delay variation, and frame loss operations, see the “Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations” module of the
IP SLAs Configuration Guide.

Example: On-Demand Operation in Direct Mode

Device# ip sla on-demand ethernet SLM domain xxx vlan 10 mpid 3 cos 1 source mpid 1 continuous aggregation 35 duration 38

Loss Statistics for Y1731 Operation 2984884426
Type of operation: Y1731 Loss Measurement
Latest operation start time: *20:17:41.535 PST Wed May 16 2012
Latest operation return code: OK
Distribution Statistics:

Interval 1
Start time:  *20:17:41.535 PST Wed May 16 2012
End time:  *20:18:16.535 PST Wed May 16 2012
Number of measurements initiated: 35
Number of measurements completed: 35
Flag: OK

Forward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps forward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012
Backward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps backward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012
Loss Statistics for Y1731 Operation 2984884426
Type of operation: Y1731 Loss Measurement
Latest operation start time: *20:17:41.535 PST Wed May 16 2012
Latest operation return code: OK
Distribution Statistics:

Interval 1
Start time:  *20:17:41.535 PST Wed May 16 2012
End time:  *20:18:16.535 PST Wed May 16 2012
Number of measurements initiated: 35
Number of measurements completed: 35
Flag: OK

Forward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps forward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012
Backward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps backward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012

Example: On-Demand Operation in Referenced Mode

Device(config)# ip sla 11
Device(config-ip-sla)# ethernet y1731 loss SLM domain xxx vlan 10 mpid 3 cos 1 source mpid 1
Device(config-sla-y1731-loss)# end
Device# ip sla on-demand ethernet slm 11 duration 38

Loss Statistics for Y1731 Operation 2984884426
Type of operation: Y1731 Loss Measurement
Latest operation start time: *20:17:41.535 PST Wed May 16 2012
Latest operation return code: OK
Distribution Statistics:

Interval 1
Start time:  *20:17:41.535 PST Wed May 16 2012
End time:  *20:18:16.535 PST Wed May 16 2012
Number of measurements initiated: 35
Number of measurements completed: 35
Flag: OK

Forward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps forward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012
Backward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps backward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012
Loss Statistics for Y1731 Operation 2984884426
Type of operation: Y1731 Loss Measurement
Latest operation start time: *20:17:41.535 PST Wed May 16 2012
Latest operation return code: OK
Distribution Statistics:

Interval 1
Start time:  *20:17:41.535 PST Wed May 16 2012
End time:  *20:18:16.535 PST Wed May 16 2012
Number of measurements initiated: 35
Number of measurements completed: 35
Flag: OK

Forward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps forward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012
Backward
Number of Observations 3
Available indicators: 0
Unavailable indicators: 3
Tx frame count: 30
Rx frame count: 30
Min/Avg/Max - (FLR % ): 0:9/000.00%/0:9
Cumulative - (FLR % ): 000.00%
Timestamps backward:
Min - *20:18:10.586 PST Wed May 16 2012
Max - *20:18:10.586 PST Wed May 16 2012

Additional References for IP SLAs Y.1731 On-Demand and Concurrent Operations

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Cisco IOS Carrier Ethernet commands

Cisco IOS Carrier Ethernet Command Reference

Cisco IOS IP SLAs commands

Cisco IOS IP SLAs Command Reference

Ethernet CFM for ITU-T Y.1731

“ITU-T Y.1731 Performance Monitoring in a Service Provider Network” module of the Carrier Ethernet Configuration Guide

Ethernet operations

“Configuring IP SLAs Metro-Ethernet 3.0 (ITU-T Y.1731) Operations” module of the IP SLAs Configuration Guide

Network Time Protocol (NTP)

“Configuring NTP” module of the Network Management Configuration Guide

Standards and RFCs

Standard/RFC

Title

ITU-T Y.1731

OAM functions and mechanisms for Ethernet-based networks

MIBs

MIB

MIBs Link

- CISCO-IPSLA-ETHERNET-MIB

- CISCO-RTTMON-MIB

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

Click Here

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for IP SLAs Y.1731 On-Demand and Concurrent Operations

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for IP SLAs Y.1731 On-Demand and Concurrent Operations

Feature Name

Releases

Feature Information

IPSLA Y1731 SLM Feature Enhancements

Cisco IOS XE Release 3.8S

This feature enhancement allows you to run on-demand Synthetic Loss Measurement (SLM) operations, independent from previously scheduled operations, for the purpose of troubleshooting Etherent services in your network.

The following commands were introduced or modified: ethernet y1731 delay, ethernet y1737 loss, ip sla on-demand ethernet.

Chapter 20. VXLAN-MCLAG Active-Active High Availability Support

The VXLAN-MCLAG Active-Active High Availability Support feature implements dual-home device with pseudo Multichassis Link Aggregation Control Protocol (pMLACP) redundancy mode and layer 2 VxLAN on the Cisco ASR1000 Series Aggregation Services Routers.

- Finding Feature Information

- Restrictions for VXLAN-MCLAG Active-Active High Availability Support

- Information About VXLAN-MCLAG Active-Active High Availability Support

- How to Configure VXLAN-MCLAG Active-Active High Availability Support

- Configuration Examples for VXLAN-MCLAG Active-Active High Availability Support

- Additional References for VXLAN-MCLAG Active-Active High Availability Support

- Feature Information for VXLAN-MCLAG Active-Active High Availability Support

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Restrictions for VXLAN-MCLAG Active-Active High Availability Support

- The loopback interface configured for this feature cannot be used for another feature.

- The loopback interface of NVE interface must be shut down before configuring pmLACP, VxLAN and routing protocol.

- Bridge domain supports one VXLAN Network Identifier (VNI) Ethernet flow point (EFP) member only.

- Shutting the bridge domain affects status of the NVE interface, not the pseudo mLACP status.

Information About VXLAN-MCLAG Active-Active High Availability Support

- Virtual Extensible LAN

- Multichassis Link Aggregation Group

Virtual Extensible LAN

Virtual Extensible LAN (VXLAN) is a network virtualization overlay technology that provides Layer 2 connectivity for workloads residing at noncontiguous points in the data center network. VXLAN enables flexibility by allowing workloads to be placed anywhere, along with the traffic separation required in a multitenant environment. VXLAN is an industry-standard protocol and uses underlay IP networks. It extends Layer 2 segments over a Layer 3 infrastructure to build Layer 2 overlay logical networks. It encapsulates Ethernet frames into IP User Data Protocol (UDP) headers and transports the encapsulated packets through the underlay network to the remote VXLAN tunnel endpoints (VTEPs) using the normal IP routing and forwarding mechanism.

Multichassis Link Aggregation Group

Multichassis Link Aggregation Group (MC-LAG) and Inter-chassis Communication Protocol (ICCP) enable a switch/router to use standard Ethernet Link Aggregation for device dual-homing, with active/standby redundancy. MC-LAG provides a mean to dual home a device (the dual homed device (DHD)) to two different peer devices (the Point of Attachment), allowing to have the benefits of node redundancy. Point of Attachment (PoA) nodes run Inter-chassis Communication Protocol (ICCP) to synchronize state & form a Redundancy Group (RG).

In VXLAN - MCLAG Active-Active High Availability support, both the PoA ports are placed in active/active mode with manual VLAN load balancing. It provides higher bandwidth utilization than Multichassis Link Aggregation Control Protocol (mLACP). It also allows maximum flexibility for the Provider Edge-Customer Edge (PE-CE) inter-operability for dual-homing redundancy and failover recovery. Active and standby PoA nodes are configured on the identical interfaces, that is, the same loopback IP address and interface as VTEP source interface, VLAN and VNI mapping, and so on.

How to Configure VXLAN-MCLAG Active-Active High Availability Support

- Configuring Interchassis Redundancy Groups on PoA

- Configuring Port Channel on PoA

- Configuring Vxlan Unicast Core Configuration on POA

- Configuring Vxlan Multicast Core Configuration on POA

- Configuring Dual-homed Device

- Verifying VXLAN-MCLAG Active-Active High Availability Support

Configuring Interchassis Redundancy Groups on PoA

To configure interchassis redundancy groups on PoA, perform the steps below.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    redundancy

4.    interchassis group group-id

5.    member ip peer ip address

6.    monitor peer [bfd | track]

7.    mlacp node-id node id

8.    backbone interface backbone if

9.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

redundancy

Example:

Device(config)# redundancy

Configures the redundancy group.

Step 4

interchassis group group-id

Example:

Device(config-red)# interchassis group 2

Configures interchassis group.

Step 5

member ip peer ip address

Example:

Device(config-r-ic)# member ip 172.168.40.24

Specifies IP address to be assigned to a remote peer dialing in to the interface.

Step 6

monitor peer [bfd | track]

Example:

Device(config-r-ic)# monitor peer bfd

Specifies the the peer monitoring method.

Step 7

mlacp node-id node id

Example:

Device(config-r-ic)# mlacp node-id 2

Configures mLACP node ID.

Step 8

backbone interface backbone if

Example:

Device(config-r-ic)# backbone interface Gi0/0/2

Configures a backbone interface for the redundancy group.

Step 9

end

Example:

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring Port Channel on PoA

To configure port channel on PoA, perform the steps below.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface Port-channel port channel number

4.    negotiation

5.    lacp fast-switchover

6.    mlacp interchassis group rg id

7.    mlacp mode active-active

8.    mlacp load-balance primary vlan vlan-id

9.    mlacp load-balance secondary vlan vlan-id

10.    service instance id ethernet

11.    encapsulation dot1q

12.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface Port-channel port channel number

Example:

Device(config-if)# interface Port-channel 2

Configures the interface for port channel.

Step 4

negotiation

Example:

Device(config-if)# negotiation

Configures auto negotiation mode.

Step 5

lacp fast-switchover

Example:

Device(config-if)# lacp fast-switchover

Specifies LACP Port Channel interface.

Step 6

mlacp interchassis group rg id

Example:

Device(config-if)# mlacp interchassis group 2

Configures mLACP peer PoA RG ID.

Step 7

mlacp mode active-active

Example:

Device(config-if)# mlacp mode active-active

Enables mLACP active-active POA redundancy.

Step 8

mlacp load-balance primary vlan vlan-id

Example:

Device(config-if)# mlacp load-balance primary vlan 40

Configures the list of primary VLANs that will be active and inactive on the given PoA.

Step 9

mlacp load-balance secondary vlan vlan-id

Example:

Device(config-if)# mlacp load-balance secondary vlan 20

Configures the list of secondary VLANs that will be active and inactive on the given PoA.

Step 10

service instance id ethernet

Example:

Device(config-if-srv)# service instance 20 ethernet

Configures service instance identifier.

Step 11

encapsulation dot1q

Example:

Device(config-if-srv)# encapsulation dot1q 20

Configures ethernet frame match criteria.

Step 12

end

Example:

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring Vxlan Unicast Core Configuration on POA

To configure Vxlan Unicast Core Configuration on POA, perform the steps below.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    bridge-domain id

4.    member vni number

5.    member Port-channel number service-instance id

6.    exit

7.    interface Loopback number

8.    ip address

9.    exit

10.    interface nve

11.    member vni number

12.    ingress-replication IPV4 address

13.    exit

14.    source-interface Loopback id

15.    no shutdown

16.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

bridge-domain id

Example:

Device(config)# bridge-domain 20

Configures the bridge domain ID.

Step 4

member vni number

Example:

Device(config-bdomain)# member vni 7777

Configures member virtual network identifier (VNI).

Step 5

member Port-channel number service-instance id

Example:

Device(config-bdomain)# member Port-channel1 service-instance 20

Configures port channel and service instance.

Step 6

exit

Example:

Device(config-bdomain)# exit

Exits bridge domain mode and returns to global configuration mode.

Step 7

interface Loopback number

Example:

Device(config-if)# interface Loopback10

Specifies a loopback interface.

Step 8

ip address

Example:

Device(config-if)# ip address 77.1.1.1 255.255.255.255

Configures IP address.

Step 9

exit

Example:

Device(config-if)# exit

Exits interface configuration mode and returns to global configuration mode.

Step 10

interface nve

Example:

Device(config)# interface nve1

Configures network virtualization endpoint interface.

Step 11

member vni number

Example:

Device(config-if)# member vni 7777

Configures VNI information.

Step 12

ingress-replication IPV4 address

Example:

Device(config-if-nve-vni)# ingress-replication 99.1.1.1

Configures remote Peer IPV4 Address.

Step 13

exit

Example:

Device(config-if-nve-vni)# exit

Exits network virtualization endpoint interface configuration mode and returns to global configuration mode.

Step 14

source-interface Loopback id

Example:

Device(config-if)# source-interface Loopback10

Configures interface loopback.

Step 15

no shutdown

Example:

Device(config-if)# no shutdown

Restarts the interface.

Step 16

end

Example:

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring Vxlan Multicast Core Configuration on POA

To configure Vxlan Multicast Core Configuration on POA, perform the steps below.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    bridge-domain id

4.    member vni number

5.    member Port-channel number service-instance id

6.    exit

7.    interface Loopback number

8.    ip address

9.    ip pim sparse-dense-mode

10.    exit

11.    interface nve

12.    member vni number mcast-group address

13.    source-interface Loopback

14.    no shutdown

15.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

bridge-domain id

Example:

Device(config)# bridge-domain 20

Configures the bridge domain ID.

Step 4

member vni number

Example:

Device(config-bdomain)# member vni 7777

Configures member virtual network identifier (VNI).

Step 5

member Port-channel number service-instance id

Example:

Device(config-bdomain)# member Port-channel1 service-instance 20

Configures port channel and service instance.

Step 6

exit

Example:

Device(config-bdomain)# exit

Exits bridge domain mode and returns to global configuration mode.

Step 7

interface Loopback number

Example:

Device(config-if)# interface Loopback10

Specifies a loopback interface.

Step 8

ip address

Example:

Device(config-if)# ip address 77.1.1.1 255.255.255.255

Configures IP address.

Step 9

ip pim sparse-dense-mode

Example:

Device(config-if)# ip pim sparse-dense-mode

Enables PIM to operate in sparse or dense mode.

Step 10

exit

Example:

Device(config-if)# exit

Exits interface configuration mode and returns to global configuration mode.

Step 11

interface nve

Example:

Device(config)# interface nve1

Configures network virtualization endpoint interface.

Step 12

member vni number mcast-group address

Example:

Device(config-if)# member vni 7777 mcast-group 232.1.1.1

Configures VNI information.

Step 13

source-interface Loopback

Example:

Device(config-if)# source-interface Loopback10

Configures interface loopback.

Step 14

no shutdown

Example:

Device(config-if)# no shutdown

Restarts the interface.

Step 15

end

Example:

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Configuring Dual-homed Device

To configure dual-homed device, perform the steps below:

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    interface Port-channel number

4.    switchport group-id

5.    switchport trunk encapsulation dot1q

6.    switchport trunk allowed vlan 20-50

7.    switchport mode trunk

8.    exit

9.    interface GigabitEthernet3/1

10.    switchport

11.    switchport trunk encapsulation dot1q

12.    switchport trunk allowed vlan 20-50

13.    switchport mode trunk

14.    channel-group number mode

15.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

interface Port-channel number

Example:

Device(config)# interface Port-channel1

Configures ethernet channel of interfaces.

Step 4

switchport group-id

Example:

Device(config-if)# switchport

Sets the interface as an Ethernet interface.

Step 5

switchport trunk encapsulation dot1q

Example:

Device(config-r-ic)# switchport trunk encapsulation dot1q

Defines the encapsulation format as IEEE 802.1Q (dot1q) for the specified interface.

Step 6

switchport trunk allowed vlan 20-50

Example:

Device(config-r-ic)# switchport trunk allowed vlan 20-50

Specifies that only certain VLANs are allowed on the specified trunk.

Step 7

switchport mode trunk

Example:

Device(config-r-ic)# switchport mode trunk

Sets the interface as an Ethernet trunk port.

Step 8

exit

Example:

Device(config-r-ic)# exit

Exits interface mode and returns to global configuration mode

Step 9

interface GigabitEthernet3/1

Example:

Device(config-if)# interface GigabitEthernet3/1

Enters the interface configuration mode on the Gigabit Ethernet interface.

Step 10

switchport

Example:

Device(config-if)# switchport

Configures the interface port.

Step 11

switchport trunk encapsulation dot1q

Example:

Device(config-if)# switchport trunk encapsulation dot1q

Defines the encapsulation format as IEEE 802.1Q (dot1q) for the specified interface.

Step 12

switchport trunk allowed vlan 20-50

Example:

Device(config-if)# switchport trunk allowed vlan 20-50

Specifies that only certain VLANs are allowed on the specified trunk.

Step 13

switchport mode trunk

Example:

Device(config-if)# switchport mode trunk

Sets the interface as an Ethernet trunk port.

Step 14

channel-group number mode

Example:

Device(config-if)# channel-group 1 mode active

Configures the port in a channel group and sets the mode.

Step 15

end

Example:

Device(config-if)# end

Exits interface configuration mode and returns to privileged EXEC mode.

Verifying VXLAN-MCLAG Active-Active High Availability Support

To verify, perform the steps below.

SUMMARY STEPS

1.    show lacp internal

2.    show nve interface nve1

3.    show nve peers

4.    show platform software ethernet fp ac bridge-domain binding

5.    show bridge-domain 20

6.    show lacp multi-chassis load-balance port-channel

7.    show nve vni 11111 detail

8.    show lacp multi load group

DETAILED STEPS

Step 1

show lacp internal

Example:

Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode       P - Device is in Passive mode

Channel group 1
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Gi0/0/0   SA      bndl      32768         0x1       0x1     0x1         0x3D

Channel group 2
LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Gi0/0/1   SA      susp      32768         0x2       0x2     0x2         0x7D

Step 2

show nve interface nve1

Example:

Interface: nve1, State: Admin Up, Oper Up Encapsulation: Vxlan
source-interface: Loopback10 (primary:77.1.1.1 vrf:0)

Step 3

show nve peers

Example:

Interface  Peer-IP          VNI        Peer state
nve1    99.1.1.1         7777

Step 4

show platform software ethernet fp ac bridge-domain binding

Example:

Forwarding Manager Bridge Domain Bindings

BD    Interface                      EFP DPIDB  SHG   STP  AOM id
-----------------------------------------------------------------------------
20    Port-channel1.EFP20            16908305   None FRWD 182, (created)
20    nve1.VNI7777                   16908307   None FRWD 268, (created)
40    Port-channel1.EFP40            16908306   None BLCK 258, (created)
40    nve2.VNI8888                   16908308   None FRWD 285, (created)

Step 5

show bridge-domain 20

Example:

FBridge-domain 20 (2 ports in all)
State: UP                    Mac learning: Enabled
Aging-Timer: 300 second(s)
Port-channel1 service instance 20
vni 7777
AED MAC address    Policy  Tag       Age  Pseudoport
0   0000.6177.0003 forward dynamic   300  nve1.VNI7777, VxLAN
src: 77.1.1.1 dst: 99.1.1.1
0   0000.6177.0009 forward dynamic   300  nve1.VNI7777, VxLAN
src: 77.1.1.1 dst: 99.1.1.1
0   0000.6177.0000 forward dynamic   300  nve1.VNI7777, VxLAN
src: 77.1.1.1 dst: 99.1.1.1
0   0000.1577.0009 forward dynamic   300  Port-channel1.EFP20

Step 6

show lacp multi-chassis load-balance port-channel

Example:

Interface Port-Channel 1
Local Configuration:
P-mLACP Enabled:      Yes
Redundancy Group:     1
Revertive Mode:       Revertive
Primary VLANs:        20
Secondary VLANs:      40
Local Interface State:
Interface ID: 1
Port State:           Up
Primary VLAN State:   Active
Secondary VLAN State: Standby
Peer Interface State:
Interface ID: 1
Primary VLAN State:   Active
Secondary VLAN State: Standby

Step 7

show nve vni 11111 detail

Example:

IInterface  VNI        Multicast-group  VNI state
nve1       11111      N/A              Up
VNI Detailed statistics:
Pkts In   Bytes In   Pkts Out  Bytes Out
1682112875 107655224000 1681321674 107604587136

Step 8

show lacp multi load group

Example:

Interchassis Redundancy Group 1

RG State:       Synchronized
ICCP Version:   0
Backbone Uplink Status: Connected
Local Configuration:
Node-id:        0

Peer Information:
State:          Up
Node-id:        1
ICCP Version:   0

States:      Active     - ACT           Standby    - SBY
Down       - DN            AdminDown  - ADN
Unknown    - UN            Reverting  - REV

P-mLACP Interfaces
Interface    Port State     Local VLAN State      Peer VLAN State
ID          Local       Primary/Secondary     Primary/Secondary
1             UP             ACT/SBY               ACT/SBY

Configuration Examples for VXLAN-MCLAG Active-Active High Availability Support

- Example: Configuring VXLAN HA on Multicast Mode

- Example: Configuring VXLAN HA on Unicast Mode

Example: Configuring VXLAN HA on Multicast Mode

The following example shows how to configure the VXLAN-MCLAG Active-Active High Availability Support feature on a multicast mode with two points of attachments (POA) connected to branch devices. The following is the configuration on the first POA—POA1.

ip multicast-routing distributed
ip pim bidir-enable
ip pim rp-address 4.4.4.4 bidir

redundancy
mode sso
interchassis group 1
monitor peer bfd
member ip 9.9.9.9
backbone interface GigabitEthernet0/1/0
mlacp system-priority 200
mlacp node-id 0

bridge-domain 20
member vni 7777
member Port-channel1 service-instance 20
!

bridge-domain 40
member vni 8888
member Port-channel1 service-instance 40
!
interface Loopback10
ip address 77.1.1.1 255.255.255.255
ip pim sparse-dense-mode
!
interface Loopback11
ip address 88.1.1.1 255.255.255.255
ip pim sparse-dense-mode
!
interface Port-channel1
no ip address
negotiation auto
lacp fast-switchover
mlacp interchassis group 1
mlacp mode active-active
mlacp load-balance primary vlan 40
mlacp load-balance secondary vlan 20
service instance 20 ethernet
encapsulation dot1q 20
!
service instance 40 ethernet
encapsulation dot1q 40
!
!
interface nve1
no ip address
member vni 7777 mcast-group 225.1.1.1
source-interface Loopback10
!
interface nve2
no ip address
member vni 8888 mcast-group 226.1.1.1
source-interface Loopback11
!

interface GigabitEthernet0/1/0
ip address 192.168.20.1 255.255.255.0
ip pim sparse-dense-mode
negotiation auto
!

router ospf 10
router-id 3.3.3.3
network 0.0.0.0 255.255.255.255 area 10
!

The following is the configuration on the second POA—POA2.

ip multicast-routing distributed
ip pim bidir-enable
ip pim rp-address 4.4.4.4 bidir

redundancy
mode sso
interchassis group 1
monitor peer bfd
member ip 3.3.3.3
backbone interface GigabitEthernet0/0/1
mlacp system-priority 200
mlacp node-id 1

bridge-domain 20
member vni 7777
member Port-channel1 service-instance 20
!

bridge-domain 40
member vni 8888
member Port-channel1 service-instance 40
!

interface Loopback10
ip address 77.1.1.1 255.255.255.255
ip pim sparse-dense-mode
!
interface Loopback11
ip address 88.1.1.1 255.255.255.255
ip pim sparse-dense-mode
!
interface Port-channel1
no ip address
negotiation auto
no keepalive
lacp fast-switchover
mlacp interchassis group 1
mlacp mode active-active
mlacp load-balance primary vlan 20
mlacp load-balance secondary vlan 40
service instance 20 ethernet
encapsulation dot1q 20
!
service instance 40 ethernet
encapsulation dot1q 40
!
!
interface nve1
no ip address
member vni 7777 mcast-group 225.1.1.1
source-interface Loopback10
!
interface nve2
no ip address
member vni 8888 mcast-group 226.1.1.1
source-interface Loopback11
!

interface GigabitEthernet0/1/0
ip address 192.168.20.1 255.255.255.0
ip pim sparse-dense-mode
negotiation auto
!

interface GigabitEthernet0/0/1
ip address 192.168.4.1 255.255.255.0
ip pim sparse-dense-mode
negotiation auto
end

router ospf 10
router-id 9.9.9.9
network 0.0.0.0 255.255.255.255 area 10
!

The following is the configuration on the first branch—Branch1.

ip multicast-routing distributed
ip pim bidir-enable
ip pim rp-address 4.4.4.4 bidir
!
bridge-domain 20
member vni 7777
member GigabitEthernet0/0/0 service-instance 20
!
interface Loopback10
ip address 99.1.1.1 255.255.255.255
ip pim sparse-dense-mode
!
interface nve1
no ip address
member vni 7777 mcast-group 225.1.1.1
source-interface Loopback10
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service instance 20 ethernet
encapsulation dot1q 20
!
!
interface GigabitEthernet0/0/0
ip address 192.168.3.1 255.255.255.0
ip pim sparse-dense-mode
!
router ospf 10
network 0.0.0.0 255.255.255.255 area 10
!

The following is the configuration on the second branch—Branch2.

ip multicast-routing distributed
ip pim bidir-enable
ip pim rp-address 4.4.4.4 bidir
!
bridge-domain 40
member vni 8888
member GigabitEthernet0/0/0 service-instance 40
!
interface Loopback11
ip address 100.1.1.1 255.255.255.255
ip pim sparse-dense-mode
!
interface nve1
no ip address
member vni 8888 mcast-group 226.1.1.1
source-interface Loopback11
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service instance 40 ethernet
encapsulation dot1q 40
!
!
interface GigabitEthernet0/0/1
ip address 192.168.21.1 255.255.255.0
ip pim sparse-dense-mode
negotiation auto
!
router ospf 10
network 0.0.0.0 255.255.255.255 area 10
!

Example: Configuring VXLAN HA on Unicast Mode

The following example shows how to configure the VXLAN-MCLAG Active-Active High Availability Support feature on an unicast mode with two points of attachments (POA) connected to branch devices. The following is the configuration on the first POA—POA1.

redundancy
mode sso
interchassis group 1
monitor peer bfd
member ip 9.9.9.9
backbone interface GigabitEthernet0/1/0
mlacp system-priority 200
mlacp node-id 0

bridge-domain 20
member vni 7777
member Port-channel1 service-instance 20
!

bridge-domain 40
member vni 8888
member Port-channel1 service-instance 40
!
interface Loopback10
ip address 77.1.1.1 255.255.255.255
!
interface Loopback11
ip address 88.1.1.1 255.255.255.255
!
interface Port-channel1
no ip address
negotiation auto
lacp fast-switchover
mlacp interchassis group 1
mlacp mode active-active
mlacp load-balance primary vlan 40
mlacp load-balance secondary vlan 20
service instance 20 ethernet
encapsulation dot1q 20
!
service instance 40 ethernet
encapsulation dot1q 40
!
!
interface nve1
no ip address
member vni 7777
ingress-replication 99.1.1.1
!
source-interface Loopback10
!
interface nve2
no ip address
member vni 8888
ingress-replication 100.1.1.1
!
source-interface Loopback11
!

router ospf 10
router-id 3.3.3.3
network 0.0.0.0 255.255.255.255 area 10
!

The following is the configuration on the second POA—POA2.

redundancy
mode sso
interchassis group 1
monitor peer bfd
member ip 3.3.3.3
backbone interface GigabitEthernet0/0/1
mlacp system-priority 200
mlacp node-id 1

bridge-domain 20
member vni 7777
member Port-channel1 service-instance 20
!

bridge-domain 40
member vni 8888
member Port-channel1 service-instance 40
!

interface Loopback10
ip address 77.1.1.1 255.255.255.255
!
interface Loopback11
ip address 88.1.1.1 255.255.255.255
!
interface Port-channel1
no ip address
negotiation auto
no keepalive
lacp fast-switchover
mlacp interchassis group 1
mlacp mode active-active
mlacp load-balance primary vlan 20
mlacp load-balance secondary vlan 40
service instance 20 ethernet
encapsulation dot1q 20
!
service instance 40 ethernet
encapsulation dot1q 40
!
!
interface nve1
no ip address
member vni 7777
ingress-replication 99.1.1.1
!
source-interface Loopback10
!
interface nve2
no ip address
member vni 8888
ingress-replication 100.1.1.1
!
source-interface Loopback11
!

router ospf 10
router-id 9.9.9.9
network 0.0.0.0 255.255.255.255 area 10
!

The following is the configuration on the first branch—Branch1.

bridge-domain 20
member vni 7777
member GigabitEthernet0/0/0 service-instance 20
!
interface Loopback10
ip address 99.1.1.1 255.255.255.255
!
interface nve1
no ip address
member vni 7777
ingress-replication 77.1.1.1
source-interface Loopback10
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service instance 20 ethernet
encapsulation dot1q 20
!
!
router ospf 10
network 0.0.0.0 255.255.255.255 area 10
!

The following is the configuration on the second branch—Branch2.

bridge-domain 40
member vni 8888
member GigabitEthernet0/0/0 service-instance 40
!
interface Loopback11
ip address 100.1.1.1 255.255.255.255
!
interface nve1
no ip address
member vni 8888
ingress-replication 88.1.1.1
source-interface Loopback11
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service instance 40 ethernet
encapsulation dot1q 40
!
!
router ospf 10
network 0.0.0.0 255.255.255.255 area 10
!

Additional References for VXLAN-MCLAG Active-Active High Availability Support

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Carrier Ethernet commands

Cisco IOS Carrier Ethernet Command Reference

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for VXLAN-MCLAG Active-Active High Availability Support

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for VXLAN-MCLAG Active-Active High Availability Support

Feature Name

Releases

Feature Information

VXLAN-MCLAG Active-Active High Availability Support

Cisco IOS XE 3.16S

The VXLAN-MCLAG Active-Active High Availability Support feature implements dual-home device with pseudo Multichassis Link Aggregation Control Protocol (pMLACP) redundancy mode and layer 2 VXLAN on the Cisco ASR 1000 Series Aggregation Services Routers.

The following commands were introduced by this feature: show lacp internal, show nve interface nve1, show nve peersshow platform software ethernet fp ac bridge-domain binding, show bridge-domain 20, show lacp multi-chassis load-balance port-channel, show nve vni 11111 detail, show lacp multi load group

Chapter 21. Cisco ASR 1000 VxLAN Support

This module contains information about VxLAN (Virtual eXtensible Local Area Network) Layer 2 gateway feature support on the Cisco ASR 1000 Series Routers. VxLAN is a technology that provides a Layer 2 overlay network, allowing for network isolation. The standard 802.1q VLAN implementation limits the number of tags to 4096. However, cloud service providers may want to operate more than 4096 virtual networks. VxLAN uses a 24-bit network ID, which allows for a much larger number of individual i networks to be operated.

- Introduction

- Prerequisites for Cisco ASR 1000 Series Routers VxLAN Support

- Limitations of Cisco ASR 1000 Series Routers VxLAN Support

- New Scale Number after Enhancements

- Configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 Gateway with Multicast

- Configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 Gateway with Unicast

- Feature Information for Cisco ASR 1000 Series Routers VxLAN Support

- Technical Assistance

Introduction

This feature enables the Cisco ASR 1000 Series Routers to act as a Layer 2 VxLAN gateway to provide support to bridge traffic across VxLAN segments in a hypervisor and on VLANs on physical servers. The operation of a VxLAN Layer 2 gateway is based on the data plane MAC address learning and flooding of multidestination traffic (such as unknown unicast, multicast, or broadcast frames) using IP multicast.

Acting as a VxLAN Layer 2 gateway, the Cisco ASR 1000 Routers can send and receive packets on multiple VxLAN networks, and provide connectivity between the hosts in a VLAN network and the virtual machines operating on a VxLAN network.

A VXLAN supports different modes for flood traffic:

- Multicast Mode—A VXLAN uses an IP multicast network to send broadcast, multicast, and unknown unicast flood frames. Each multicast mode VXLAN has an assigned multicast group IP address. When a new VM joins a host in a multicast mode VXLAN, a Virtual Ethernet Module (VEM) joins the assigned multicast group IP address by sending IGMP join messages. Flood traffic, broadcast, multicast and unknown unicast from the VM is encapsulated and is sent using the assigned multicast group IP address as the destination IP address. Packets sent to known unicast MAC addresses are encapsulated and sent directly to the destination server Virtual Tunnel Endpoint (VTEP) IP addresses.

- Unicast-Only Mode—A VXLAN uses each VEM's single unicast IP address as the destination IP address to send broadcast, multicast, and unknown unicast flood frames of the designated VTEP on each VEM that has at least one VM in the corresponding VXLAN. When a new VM joins the host in a unicast-mode VXLAN, a designated VTEP is selected for receiving flood traffic on that host. This designated VTEP is communicated to all other hosts through the Virtual Supervisor Module (VSM). Flood traffic (broadcast, multicast, and unknown unicast) is replicated on each VEM's designated VTEP in that VXLAN by encapsulating it with a VXLAN header. Packets are sent only to VEMs with a VM in that VXLAN. Packets that have a unicast MAC address are encapsulated and sent directly to the destination server's VTEP IP address.

- MAC Distribution Mode (supported only in unicast mode)—In this mode, unknown unicast flooding in the network is eliminated. The VSM learns all the MAC addresses from the VEMs in all the VXLANs and distributes those MAC addresses with VTEP IP mappings to other VEMs. Therefore, no unknown unicast MAC address exists in the network when the VMs on the VEMs are communicating and controlled by the same VSM.

The VxLAN Layer 2 gateway performs the following functions:

- Provides support to bridge traffic between a host in a VLAN domain and VMs behind a virtual switch (vSwitch) in a VxLAN domain. The VLAN and the virtual network identifier (VNI) on the VxLAN should be configured as member ports in the same bridge domain.

- Implements the Virtual Tunnel Endpoint (VTEP) function, which encapsulates the Layer 2 packet on the IP/UDP tunnel with the VxLAN header (VNI) information before sending it to a multicast group or particular virtual switch on the VxLAN domain.

- The VTEP function removes the VxLAN header, identifies the bridge domain under which the VNI is configured and then bridges the inner L2 packet to the VLAN side. The bridge function also learns the remote MAC address (the VM's MAC address behind the virtual switch).

- The Layer 2 gateway carries the inner payload of non-IP (Layer 2 traffic), IPv4, and IPv6 traffic over the VxLAN VNI member.

Prerequisites for Cisco ASR 1000 Series Routers VxLAN Support

The following are the prerequisites to configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 gateway:

1. Configure the loopback interface.

2. Configure the IP unicast reachability to remote VTEP's.

3. Configure Bidirectional Protocol Independent Multicast (PIM).

For more information, see the IP Multicast: PIM Configuration Guide, Cisco IOS XE Release 3S .

Limitations of Cisco ASR 1000 Series Routers VxLAN Support

1. Platforms that support a new scale number (8192 or 16000) require an 8G RP memory. Scale number for RP memory that is less than 8G is unchanged.

2. Scale number on platform RP+ESP5 and ASR1002F is unchanged.

3. Scale numbers on ISR4000 serial platforms are unchanged because VxLAN is not supported on these platforms.

4. The maximum NVE interface number is unchanged on all platforms.

5. The scale enhancement is applicable only for the VxLAN layer 2 and layer 3 gateway feature. Other bridge-domain related features are not impacted.

6. RP switchover for VxLAN is not supported on these platforms.

New Scale Number after Enhancements

The following table lists new VxLAN scale numbers on different platforms after enhancements. All platforms that support a new scale number (8192 or 16000) require an 8G RP memory.

Platform

MAX BD per system

MAX BDI interface per system

MAX VNI per system

RP+ESP200

16000

16000

16000

RP+ESP100

16000

16000

16000

RP+ESP40

16000

16000

16000

RP+ESP20

16000

16000

16000

RP+ESP10

16000

16000

16000

ASR1002-X

16000

16000

16000

ASR1001-X

16000

16000

16000

ASR 1001

8192

8192

8192

CSR1000v

8192

8192

8192

Configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 Gateway with Multicast

- Configuring the VxLAN UDP Destination Port (Optional)

- Creating the Network Virtualization Endpoint (NVE) Interface

- Creating the Access Ethernet Flow Point (EFP)

- Mapping the VLAN to the Bridge Domain

- Configuring the VxLAN UDP Destination Port (Optional)

- Creating the Network Virtualization Endpoint (NVE) Interface

- Creating the Access Ethernet Flow Point (EFP)

- Mapping the VLAN to the Bridge Domain

Configuring the VxLAN UDP Destination Port (Optional)

The default VxLAN UDP destination is 8472. If you want to change the VxLAN UDP destination port value, you must change it before configuring the network virtualization endpoint (NVE) interface.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    vxlan udp port number

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

router> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

router# configure terminal

Enters global configuration mode.

Step 3

vxlan udp port number

Example:

Router(config)# vxlan udp port 1000

Configures the VxLAN UDP destination port number. The default value is 8472.

Creating the Network Virtualization Endpoint (NVE) Interface

You create the network virtualization endpoint (NVE) interface and then assign member virtual network identifiers (VNIs) to it. The mapping between the VNI range and the multicast group range is either one-to-one or many-to-one.

SUMMARY STEPS

1.    interface nve number

2.    source-interface loopback number

3.    member vni {range | startnumber-endnumber} multicast-group startip-address endip-address

4.    no shutdown

DETAILED STEPS

Command or Action

Purpose

Step 1

interface nve number

Example:

Router(config)# interface nve 1

Creates a network virtualization endpoint (NVE) interface and enters NVE interface configuration mode.

Step 2

source-interface loopback number

Example:

Router(config-if)# source-interface loopback 0

Assigns the previously-created loopback interface to the NVE interface.

Step 3

member vni {range | startnumber-endnumber} multicast-group startip-address endip-address

Example:

Router(config-if)# member vni 7115 multicast-group 225.1.1.1

Creates a VNI member or a range of VNI members. Repeat this step for each VNI to be added to the NVE interface. The valid values for the VNI number are from 4096 to 16777215.

Step 4

no shutdown

Example:

Router(config-if)# no shutdown

Enables the NVE interface.

Creating the Access Ethernet Flow Point (EFP)

After the member VNI is created, you must create the access Ethernet Flow Point (EFP) for the VLAN interface.

SUMMARY STEPS

1.    interface GigabitEthernet number

2.    service instance id ethernet

3.    encapsulation dot1q vlan-ID

4.    rewrite ingress tag pop 1 symmetric

DETAILED STEPS

Command or Action

Purpose

Step 1

interface GigabitEthernet number

Example:

Router(config)# interface GigabitEthernet1

Enters interface configuration mode.

Step 2

service instance id ethernet

Example:

Router(config-if)# service instance 20 ethernet

Configures an Ethernet service instance on the overlay interface being configured and enters service instance configuration mode.

- The service instance identifier range is from 1 to 8000.

Step 3

encapsulation dot1q vlan-ID

Example:

Router(config-if-srv)# encapsulation dot1q 100

Defines the VLAN encapsulation format as IEEE 802.1Q and specifies the VLAN identifier.

Step 4

rewrite ingress tag pop 1 symmetric

Example:

Router(config-if-srv)# rewrite ingress tag pop 1 symmetric

Removes the VLAN tag in the Layer 2 traffic before switching to the outgoing VxLAN interface.

Note:   This command is required to remove the VLAN tag before sending the VLAN traffic to VxLAN and adding the VLAN tag in the reverse direction.

Mapping the VLAN to the Bridge Domain

You must map the VLAN created in the previous procedure to the bridge domain.

SUMMARY STEPS

1.    bridge-domain bridge-id

2.    member interface service-instance id

3.    member vni vni-id

DETAILED STEPS

Command or Action

Purpose

Step 1

bridge-domain bridge-id

Example:

Router(config)# bridge-domain 10

Creates a bridge domain and enters bridge domain configuration mode.

The valid range for bridge-id is 1-4096.

Step 2

member interface service-instance id

Example:

Router(config-bdomain)# member
gigabitEthernet 1 service-instance 1

Binds the bridge domain to the service instance.

Step 3

member vni vni-id

Example:

Router(config-bdomain)# member vni 1010

Maps the VNI to the bridge domain.

What to Do Next

The following example displays the NVE VNIs configured on the router:

Router# show nve vni

Interface  VNI          mcast       VNI state
nve1       1010        239.0.0.0      UP
nve2       2010        239.0.0.0      UP

The following example displays the NVE VNIs assigned to NVE interface 1:

Router(config)# show nve vni interface nve1
Interface  VNI          mcast       VNI state
nve1       1010        239.0.0.0      UP
nve1       1110        239.0.0.0      UP

The following example shows the status of NVE interface 1:

Router(config)# show nve interface nve1
Interface: nve1, State: Admin Up, Oper Up Encapsulation: Vxlan
source-interface: Loopback0 (primary:11.11.11.11 vrf:0)

The following example shows a detailed display for NVE interface 1:

Router(config)# show nve interface nve1 detail
Interface: nve1, State: Admin Up, Oper Up Encapsulation: Vxlan
source-interface: Loopback0 (primary:11.11.11.11 vrf:0)
Pkts In   Bytes In   Pkts Out  Bytes Out
0          0          0          0

The following example shows the NVE peers configured on the router:

Router(config)# show nve peers
Interface Peer-IP         VNI      Up Time
nve1       1.1.1.2        1010      10h
nve2       1.1.1.3        2030      20h

The following example shows the bridge domain configuration with the entry in bold displaying the VM’s MAC address that was learned on the VxLAN VNI:

Router# show bridge-domain 1000
Bridge-domain 1000 (3 ports in all)
State: UP                    Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet1 service instance 1000
GigabitEthernet3 service instance 1000
vni 7639335
MAC address    Policy  Tag      Age  Pseudoport
0050.56A4.ECD2 forward dynamic  297  nve1.VNI7639335 VxLAN
src:10.0.0.1  dst:10.0.0.2
0050.56A4.257A forward dynamic  297  GigabitEthernet3.EFP1000

Configuring the Cisco ASR 1000 Routers as a VxLAN Layer 2 Gateway with Unicast

The following example shows VxLAN with unicast ingress-replication which is a point-to-point (unicast) configuration.

interface Loopback0
ip address 11.11.11.11 255.255.255.255
!
interface nve1
no ip address
member vni 5001
ingress-replication 22.22.22.22  < Remote L2 GW loopback ip>
!
source-interface Loopback0
!
bridge-domain 1
member vni 5001
member GigabitEthernet0/2/0 service-instance 1
interface GigabitEthernet0/2/0
service instance 1 ethernet
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric

Feature Information for Cisco ASR 1000 Series Routers VxLAN Support

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Feature Information for ASR 1000 Series Routers VxLAN Support

Feature Name

Releases

Feature Configuration Information

ASR 1000 Series Routers VxLAN Support

Cisco IOS XE Release 3.13.1S

This feature was introduced on the Cisco ASR 1000 Series Routers.

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Click Here