![]() |
Carrier Ethernet Configuration Guide, Cisco IOS Release 15M&T
|
||||||||||||||||||||||||||||
Using Ethernet Operations Admistration and Maintenance
![]() |
|||||||||||||||||||||||||||||
|
Contents
Using Ethernet Operations Administration and MaintenanceLast Updated: November 30, 2012
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 InformationYour 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 at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Information About Using Ethernet Operations Administration and Maintenance
Ethernet OAMEthernet 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 ClientThe 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 SublayerThe 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 BlockThe 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. MultiplexerThe 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. Cisco Implementation of Ethernet OAMThe 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 FeaturesThe 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. DiscoveryDiscovery 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:
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 MonitoringLink 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:
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 IndicationFaults 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:
Remote LoopbackAn 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. OAM MessagesEthernet 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:
IEEE 802.3ah Link Fault RFI SupportThe 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." 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 new keyword, error-block-interface, for the CLI command ethernet oam remote-failure action is introduced with the IEEE 802.3ah Link Fault RFI Support feature. For detailed information about this command, see the Cisco IOS Carrier Ethernet Command Reference. Ethernet Connectivity Fault ManagementEthernet 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.3ahIn 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 OAMThe 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 OAMCisco 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
SUMMARY STEPS
DETAILED STEPS Disabling and Enabling a Link Monitoring SessionLink 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
SUMMARY STEPS
DETAILED STEPS Enabling a Link Monitoring Session
SUMMARY STEPS
DETAILED STEPS Stopping and Starting Link Monitoring OperationsLink 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
SUMMARY STEPS
DETAILED STEPS Starting Link Monitoring Operations
SUMMARY STEPS
DETAILED STEPS Configuring Link Monitoring OptionsPerform this optional task to specify link monitoring options. Steps 4 through 10 can be performed in any sequence. DETAILED STEPS ExampleDevice# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Device(config)# interface gigabitEthernet 3/8 Device(config-if)# Device(config-if)# ethernet oam Device(config-if)# ethernet oam link-monitor high-threshold action error-disable-interface Device(config-if)# ethernet oam link-monitor frame window 399 Device(config-if)# ethernet oam link-monitor frame-period threshold high 599 Device(config-if)# ethernet oam link-monitor frame-seconds window 699 Device(config-if)# ethernet oam link-monitor receive-crc window 99 Device(config-if)# ethernet oam link-monitor transmit-crc threshold low 199 Device(config-if)# ethernet oam link-monitor symbol-period threshold high 299 Device(config-if)# exit Device# show running-config Building configuration... Current configuration : 5613 bytes ! ! version 12.2 ! ! . . . ! ! interface GigabitEthernet3/8 no ip address ethernet oam link-monitor high-threshold action error-disable-interface ethernet oam link-monitor frame window 399 ethernet oam link-monitor frame-period threshold high 599 ethernet oam link-monitor frame-seconds window 699 ethernet oam link-monitor receive-crc window 99 ethernet oam link-monitor transmit-crc threshold low 199 ethernet oam link-monitor symbol-period threshold high 299 ethernet oam Configuring Global Ethernet OAM Options Using a TemplatePerform 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. DETAILED STEPS Configuring a Port for Link Fault RFI SupportPerform 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. DETAILED STEPS Configuration Examples for Ethernet Operations Administration and MaintenanceThe 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)# ethernet oam remote-failure dying-gasp action error-disable-interface Device(config-template)# exit ! ! Enable Ethernet OAM on the CE interface ! Device(config)# interface gigabitethernet 4/1/1 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)# interface gigabitethernet 8/1/1 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 SessionThe following example shows that the local OAM client, Gigabit Ethernet interface Gi6/1/1, 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 StatusThe following example shows how to verify OAM discovery status of a local client and a remote peer:
Device# show ethernet oam discovery interface gigabitethernet6/1/1
GigabitEthernet6/1/1
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 StatisticsThe following example shows how to verify statistics for information OAM PDUs and local and remote faults:
Device# show ethernet oam statistics interface gigabitethernet6/1/1
GigabitEthernet6/1/1
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 StatusThe 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# show ethernet oam status interface gigabitethernet6/1/1
GigabitEthernet6/1/1
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 ClientThe 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 ReferencesRelated Documents
Technical Assistance
Feature Information for Using Ethernet Operations Administration and MaintenanceThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
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: www.cisco.com/go/trademarks. 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) 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. © 2012 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||
|
|