![]() |
Table Of Contents
Configuring Ethernet OAM, CFM, and E-LMI
Maintenance Associations and Maintenance Points
Crosscheck Function and Static Remote MEPs
CFM on EVC Bridge Domains and EVC Cross-Connect Interfaces
Default Ethernet CFM Configuration
Ethernet CFM Configuration Guidelines
Configuring Ethernet CFM Crosscheck
Configuring IP SLAs CFM Operation
Manually Configuring an IP SLAs CFM Probe or Jitter Operation
Configuring an IP SLAs Operation with Endpoint Discovery
Configuring CFM on EVC Bridge Domains and EVC Cross-Connect Interfaces
Configuring CFM on EVC Commands
Configuring CFM on an EVC Bridge Domain
Configuring CFM on an EVC with Cross-Connect
Managing and Displaying Ethernet CFM Information
Understanding the Ethernet OAM Protocol
Setting Up and Configuring Ethernet OAM
Default Ethernet OAM Configuration
Ethernet OAM Configuration Guidelines
Enabling Ethernet OAM on an Interface
Enabling Ethernet OAM Remote Loopback
Configuring Ethernet OAM Link Monitoring
Configuring Ethernet OAM Remote Failure Indications
Configuring Ethernet OAM Templates
Displaying Ethernet OAM Protocol Information
E-LMI Configuration Guidelines
Customer-Edge Device Configuration
Ethernet CFM and Ethernet OAM Interaction
Ethernet OAM and CFM Configuration Example
Configuring Ethernet OAM, CFM, and E-LMI
Ethernet Operations, Administration, and Maintenance (OAM) is a protocol for installing, monitoring, and troubleshooting Ethernet networks to increase management capability within the context of the overall Ethernet infrastructure. The Cisco ME 3800X and ME 3600X switch supports IEEE 802.1ag Connectivity Fault Management (CFM), Ethernet Local Management Interface (E-LMI), and IEEE 802.3ah Ethernet OAM discovery, link monitoring, remote fault detection, and remote loopback. It also supports IP Service Level Agreements (SLAs) for CFM.
This chapter provides information about configuring CFM, E-LMI, and the Ethernet OAM protocol.
For complete command and configuration information for Ethernet OAM,CFM, and E-LMI, see the Cisco IOS Carrier Ethernet Configuration Guide.
For complete syntax of the commands used in this chapter, see the command reference for this release and the Cisco IOS Carrier Ethernet Command Reference at this URL:
http://www.cisco.com/en/US/docs/ios/cether/command/reference/ce_book.htmlThis chapter contains these sections:
•
Managing and Displaying Ethernet CFM Information
•
Understanding the Ethernet OAM Protocol
•
Setting Up and Configuring Ethernet OAM
•
Displaying Ethernet OAM Protocol Information
•
Ethernet CFM and Ethernet OAM Interaction
Understanding Ethernet CFM
Ethernet CFM is an end-to-end per VLAN 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) device or customer-edge-to-customer-edge (CE-to-CE) device. Ethernet CFM, as specified by IEEE 802.1ag, is the standard for Layer 2 ping, Layer 2 traceroute, and end-to-end connectivity check of the Ethernet network.
The switch does not support:
•
CFM on VFI interfaces
•
Provider-edge E-LMI
•
CFM on SVI based xconnect
•
CFM on port based xconnect
Note
CFM is supported on EVC BD, EVC xconnect, EFP xconnect and CFM transparencies.
These sections contain conceptual information about Ethernet CFM:
•
Maintenance Associations and Maintenance Points
•
Crosscheck Function and Static Remote MEPs
•
CFM on EVC Bridge Domains and EVC Cross-Connect Interfaces
CFM Domain
A CFM maintenance domain is a management space on a network that is owned and operated by a single entity and defined by a set of ports internal to it, but at its boundary. You assign a unique maintenance level (from 0 to 7) to define the hierarchical relationship between domains. The larger the domain, the higher the level. For example, as shown in Figure 43-1, a service-provider domain would be larger than an operator domain and might have a maintenance level of 6, while the operator domain maintenance level is 3 or 4.
As shown in Figure 43-2, domains cannot intersect or overlap because that would require management by more than one entity, which is not allowed. Domains can touch or nest (if the outer domain has a higher maintenance level than the nested domain). Nesting domains is useful when a service provider contracts with one or more operators to provide Ethernet service. Each operator has its own maintenance domain and the service provider domain is a superset of the operator domains. Maintenance levels of nesting domains should be communicated among the administrating organizations. CFM exchanges messages and performs operations on a per-domain basis.
Figure 43-1 CFM Maintenance Domains
Figure 43-2 Allowed Domain Relationships
Maintenance Associations and Maintenance Points
A maintenance association (MA) identifies a service that can be uniquely identified within the maintenance domain. The CFM protocol runs within a maintenance association. A maintenance point is a demarcation point on an interface that participates in CFM within a maintenance domain. Maintenance points drop all lower-level frames and forward all higher-level frames. There are two types of maintenance points:
•
Maintenance end points (MEPs) are points at the edge of the domain that define the boundaries and confine CFM messages within these boundaries. Outward facing or Down MEPs communicate through the wire side (connected to the port). Inward facing or Up MEPs communicate through the relay function side, not the wire side.
CFM 802.1ag supports up and down per-VLAN MEPs, as well as port MEPs, which are untagged down MEPs that are not associated with a VLAN. Port MEPs are configured to protect a single hop and used to monitor link state through CFM. If a port MEP is not receiving continuity check messages from its peer (static remote MEP), for a specified interval, the port is put into an operational down state in which only CFM and OAM packets pass through, and all other data and control packets are dropped.
–
An up MEP sends and receives CFM frames through the relay function. It drops all CFM frames at its level or lower that come from the wire side, except traffic going to the down MEP. For CFM frames from the relay side, it processes the frames at its level and drops frames at a lower level. The MEP transparently forwards all CFM frames at a higher level, regardless of whether they are received from the relay or wire side. If the port on which MEP is configured is blocked by STP, the MEP can still send or receive CFM messages through the relay function. CFM runs at the provider maintenance level (UPE-to-UPE), specifically with up MEPs at the user network interface (UNI).
Note
The switch rate-limits all incoming CFM messages at a fixed rate of 500 frames per second.
–
A down MEP sends and receives CFM frames through the wire connected to the port on which the MEP is configured. It drops all CFM frames at its level or lower that come from the relay side. For CFM frames from the wire side, it processes all CFM frames at its level and drops CFM frames at lower levels except traffic going to the other lower-level down MEP. The MEP transparently forwards all CFM frames at a higher level, regardless of whether they are received from the relay or through the wire.
•
Maintenance intermediate points (MIPs) are internal to a domain, not at the boundary, and respond to CFM only when triggered by traceroute and loopback messages. They forward CFM frames received from MEPs and other MIPs, drop all CFM frames at a lower level (unless MIP filtering is enabled), and forward all CFM frames at a higher level and at a lower level and regardless of whether they are received from the relay or wire side. When MIP filtering is enabled, the MIP drops CFM frames at a lower level. MIPs also catalog and forward continuity check messages (CCMs), but do not respond to them.
MIP filtering is disabled by default, and you can configure it to be enabled or disabled. When MIP filtering is disabled, all CFM frames are forwarded.
You can manually configure a MIP or configure the switch to automatically create a MIP. You can configure a MEP without a MIP. In case of a configuration conflict, manually created MIPs take precedence over automatically created MIPs.
If port on which the MEP is configured is blocked by Spanning-Tree Protocol (STP), the MIP can receive and might respond to CFM messages from both the wire and relay side, but cannot forward any CFM messages.
CFM Messages
CFM uses standard Ethernet frames distinguished by EtherType or (for multicast messages) by MAC address. All CFM messages are confined to a maintenance domain and to a service-provider VLAN (S-VLAN). These CFM messages are supported:
•
Continuity Check (CC) messages—multicast heartbeat messages exchanged periodically between MEPs that allow MEPs to discover other MEPs within a domain and allow MIPs to discover MEPs. CC messages are configured to a domain or VLAN. Enter the continuity-check Ethernet service configuration command to enable CCM.
The default continuity check message (CCM) interval on the switch is 10 seconds. You can set it to be 100 ms, 1 second, 1 minute, or 10 minutes by entering the continuity-check interval Ethernet service mode command. Because faster CCM rates are more CPU intensive, we do not recommend configuring a large number of MEPs running at 100 ms intervals.
•
Loopback messages—unicast or multicast frames transmitted by a MEP at administrator request to verify connectivity to a particular maintenance point, indicating if a destination is reachable. A loopback message is similar to an Internet Control Message Protocol (ICMP) ping message. Refer to the ping ethernet privileged EXEC command.
•
Traceroute messages—multicast frames transmitted by a MEP at administrator request to track the path (hop-by-hop) to a destination MEP. Traceroute messages are similar in concept to UDP traceroute messages. Refer to the traceroute ethernet privileged EXEC command.
Crosscheck Function and Static Remote MEPs
The crosscheck function is a timer-driven post-provisioning service verification between dynamically configured MEPs (using crosscheck messages) and expected MEPs (by configuration) for a service. It verifies that all endpoints of a multipoint service are operational. The crosscheck function is performed only one time and is initiated from the command-line interface (CLI).
CFM 802.1ag also supports static remote MEPs or static RMEP check. Unlike the crosscheck function, which is performed only once, configured static RMEP checks run continuously. To configure static RMEP check, enter the continuity-check static rmep Ethernet CFM service mode command.
SNMP Traps and Fault Alarms
The MEPs generate two types of SNMP traps: CC traps and crosscheck traps. Supported CC traps are MEP up, MEP down, cross-connect (a service ID does not match the VLAN), loop, and configuration error. The crosscheck traps are service up, MEP missing (an expected MEP is down), and unknown MEP.
Fault alarms are unsolicited notifications sent to alert the system administrator when CFM detects a fault. You can configure the priority level of alarms that trigger an SNMP trap or syslog message. You can also configure a delay period before a fault alarm is sent and the time before the alarm is reset.
Configuration Error List
CFM configuration errors in CFM 802.1ag can be misconfigurations or extra configuration commands detected during MEP configuration. They can be caused by overlapping maintenance associations. For example, if you create a maintenance association with a VLAN list and a MEP on an interface, a potential leak error could occur if other maintenance associations associated with the same VLAN exist at a higher level without any MEPs configured. You can display the configuration error list, which is informational only, by entering the show ethernet cfm errors configuration privileged EXEC command.
IP SLAs Support for CFM
The switch supports CFM with IP Service Level Agreements (SLAs), which provides the ability to gather Ethernet layer network performance metrics. Available statistical measurements for the IP SLAs CFM operation include round-trip time, jitter (interpacket delay variance), and packet loss. You can schedule multiple IP SLAs operations and use Simple Network Management Protocol (SNMP) trap notifications and syslog messages for proactive threshold violation monitoring.
For more information about IP SLAs, see Chapter 42 "Configuring Cisco IOS IP SLAs Operations."
IP SLAs integration with CFM gathers Ethernet layer statistical measurements by sending and receiving Ethernet data frames between CFM MEPs. Performance is measured between the source MEP and the destination MEP. Unlike other IP SLAs operations that provide performance metrics for only the IP layer, IP SLAs with CFM provides performance metrics for Layer 2.
You can manually configure individual Ethernet ping or jitter operations. You can also configure an IP SLAs automatic Ethernet operation that queries the CFM database for all MEPs in a given maintenance domain and VLAN. The operation then automatically creates individual Ethernet ping or jitter operations based on the discovered MEPs.
For more information about IP SLAs operation with CFM, see the IP SLAs for Metro-Ethernet feature module.
CFM on EVC Bridge Domains and EVC Cross-Connect Interfaces
CFM is supported on EVC bridge domains and EVC cross-connect interfaces. EVC interfaces can be used to connect UNI interfaces so that VLAN IDs can be mapped to bridge domains.
CFM is supported on the following types of EVCs:
•
Default
•
Tagged
•
Untagged
•
Single-dot1q tagged
•
QinQ
CFM over pseudowires allows service providers to manage access-side, end-to-end connectivity over an MPLS core.
CFM packets can be forwarded over:
•
SVI Pseudo-wire
•
VPLS Pseudo-wire
•
EVC Xconnect Pseudo-wire
•
Bridge-domain
•
VLAN
The following CFM features are supported on the Cisco ME3600/ME3800 switches:
•
CFM transparency on SVI PW / VPLS PW / EVC xconnect PW
•
CFM Up MEP on EVC Xconnect and Port-Channel EVC Xconnect
•
CFM Down MEP on EVC BD and Port-Channel EVC Xconnect
•
CFM Up MEP on EVC BD and Port-Channel EVC Xconnect
•
MIP support
•
CFM IEEE MIB (EVC BD, EVC Xconnect)
•
ELMI PE and CE support
•
CFM ELMI Interworking
•
CFM and 802.3ah interworking
•
SYSLOG
•
802.3AH SNMP MIB
The following asymmetric configurations are not supported on the Cisco ME3600/ME3800 switches:
•
efps with 1 tag & no rewrite
•
efps with 2 tags & pop 1
•
efps with 2 tags and no rewrite
The following asymmetric configurations are supported on the Cisco ME3600/ME3800 switches:
•
efps with no tag & no rewrite
•
efps with 1 tag & pop 1
•
efps with 2 tag & pop 2
Configuring Ethernet CFM
Configuring Ethernet CFM requires configuring the CFM domain. You can optionally configure and enable other CFM features such as crosschecking, remote MEP, port MEPs, SNMP traps, and fault alarms.
•
Default Ethernet CFM Configuration
•
Ethernet CFM Configuration Guidelines
•
Configuring Ethernet CFM Crosscheck
•
Configuring Static Remote MEP
•
Configuring IP SLAs CFM Operation
•
Configuring CFM on EVC Bridge Domains and EVC Cross-Connect Interfaces
Default Ethernet CFM Configuration
CFM is globally disabled.
CFM is enabled on all interfaces when CFM is globally enabled.
A port can be configured as a flow point (MIP/MEP), a transparent port, or disabled (CFM disabled). By default, ports are transparent ports until configured as MEP, MIP, or disabled.
There are no MEPs or MIPs configured.
When configuring a MEP service, if you do not configure direction, the default is up (inward facing).
Ethernet CFM Configuration Guidelines
•
CFM is not supported on and cannot be configured on routed ports or on Layer 3 EtherChannels.
•
CFM is supported on EtherChannel port channels. You can configure an EtherChannel port channel as MEP or MIP. However, CFM is not supported on individual ports that belong to an EtherChannel and you cannot add a CFM port to an EtherChannel group.
•
Port MEP is not supported on Layer 2 EtherChannels, or on ports that belong to an EtherChannel.
•
CFM is supported on VLAN interfaces and on service instances (bridge domains).
•
CFM is supported on trunk ports and access ports with these exceptions:
–
Trunk ports configured as MEPs must belong to allowed VLANs
–
Access ports configured as MEPs must belong to the native VLAN.
•
A REP port or FlexLink port can also be a service (VLAN) MEP or MIP, but it cannot be a port MEP.
•
CFM is supported on ports running STP.
•
You must configure a port MEP at a lower level than any service (VLAN) MEPs on an interface.
•
You cannot configure tunnel mode by using the native VLAN as the S-VLAN or the C-VLAN.
•
Do not configure double-tagged 802.1ag CFM packets entering a trunk port.
Configuring the CFM Domain
Beginning in privileged EXEC mode, follow these steps to configure the Ethernet CFM domain, configure a service to connect the domain to a VLAN, or configure a port to act as a MEP. You can also enter the optional commands to configure other parameters, such as continuity checks.
Use the no versions of the commands to remove the configuration or return to the default configurations.
This is an example of the basic CFM configuration:
Switch(config)# ethernet cfm ieeeSwitch(config)# ethernet cfm globalSwitch(config)# ethernet cfm domain abc level 3Switch(config-ecfm)# service test vlan 5Switch(config-ecfm-srv)# continuity-checkSwitch(config-ecfm-srv)# exitSwitch(config-ecfm)# exitSwitch(config)# interface gigabitethernet0/2Switch(config-if)# ethernet cfm mep domain abc mpid 222 vlan 5Switch(config-if-ecfm-mep)# exitConfiguring Ethernet CFM Crosscheck
Beginning in privileged EXEC mode, follow these steps to configure Ethernet CFM crosscheck:
Use the no form of each command to remove a configuration or to return to the default settings.
Configuring Static Remote MEP
Beginning in privileged EXEC mode, follow these steps to configure Ethernet CFM static remote MEP:
Use the no form of each command to remove a configuration or to return to the default settings.
Configuring a Port MEP
A port MEP is a down MEP that is not associated with a VLAN and that uses untagged frames to carry CFM messages. You configure port MEPs on two connected interfaces. Port MEPs are always configured at a lower domain level than native VLAN MEPs.
Beginning in privileged EXEC mode, follow these steps to configure Ethernet CFM port MEPs:
Use the no form of each command to remove a configuration or to return to the default settings.
This is a sample configuration for a port MEP:
Switch(config)# ethernet cfm domain abc level 3Switch(config-ecfm)# service PORTMEP portSwitch(config-ecfm-srv)# mep mpid 222Switch(config-ecfm-srv)# continuity-checkSwitch(config-ecfm-srv)# continuity-check static rmepSwitch(config-ecfm-srv)# exitSwitch(config-ecfm)# exitSwitch(config)# interface gigabitethernet0/1Switch(config-if)# ethernet cfm mep domain abc mpid 111 portSwitch(config-if)# endConfiguring SNMP Traps
Beginning in privileged EXEC mode, follow these steps to configure traps for Ethernet CFM:
Use the no form of each command to remove a configuration or to return to the default settings.
Configuring Fault Alarms
Beginning in privileged EXEC mode, follow these steps to configure Ethernet CFM fault alarms. Note that you can configure fault alarms in either global configuration mode or Ethernet CFM interface MEP mode. In case of conflict, the interface MEP mode configuration takes precedence.
Use the no form of each command to remove a configuration or to return to the default settings.
Configuring IP SLAs CFM Operation
You can manually configure an individual IP SLAs Ethernet ping or jitter echo operation or you can configure IP SLAs Ethernet operation with endpoint discovery. You can also configure multiple operation scheduling. For accurate one-way delay statistics, the clocks on the endpoint switches must be synchronized. You can configure the endpoint switches with Network Time Protocol (NTP) so that the switches are synchronized to the same clock source.
For more information about configuring IP SLAs Ethernet operation, see the IP SLAs for Metro-Ethernet.
For detailed information about configuring IP SLAs operations, see the Cisco IOS IP SLAs Configuration Guide.
For detailed information about IP SLAs commands, see the command reference at this URL: http://www.cisco.com/en/US/docs/ios/ipsla/command/reference/sla_book.html
This section includes these procedures:
•
Manually Configuring an IP SLAs CFM Probe or Jitter Operation
•
Configuring an IP SLAs Operation with Endpoint Discovery
Manually Configuring an IP SLAs CFM Probe or Jitter Operation
Beginning in privileged EXEC mode, follow these steps to manually configure an IP SLAs Ethernet echo (ping) or jitter operation:
To remove an IP SLAs operation, enter the no ip sla operation-number global configuration command.
Configuring an IP SLAs Operation with Endpoint Discovery
Beginning in privileged EXEC mode, follow these steps to use IP SLAs to automatically discover the CFM endpoints for a domain and VLAN ID. You can configure ping or jitter operations to the discovered endpoints.
To remove an IP SLAs operation, enter the no ip sla operation-number global configuration command.
Configuring CFM on EVC Bridge Domains and EVC Cross-Connect Interfaces
The following examples show how to configure CFM on EVC.
Configuring CFM on EVC Commands
The following example shows the CLIs that are available for configuring CFM on EVC.
ethernet cfm ieeeethernet cfm globalethernet cfm domain L6 level 6service vlan100 evc evc100 direction downcontinuity-checkservice vlan200 evc evc200continuity-checkservice vlan200 evc evc300continuity-checkservice xconn evc xconn direction downcontinuity-checkConfiguring CFM on an EVC Bridge Domain
The following example shows how to configure CFM on an EVC Bridge Domain.
interface GigabitEthernet2/0/0no ip addressno mls qos trustservice instance 1 ethernet evc100encapsulation dot1q 1000bridge-domain 1000cfm mep domain L6 mpid 99exitservice instance 2 ethernet evc200encapsulation dot1q 2000bridge-domain 2000cfm mep domain L6 mpid 77exitservice instance 3 ethernet evc300encapsulation dot1q 300xconnect 1.1.1.1 1 encap mplscfm mep domain L6 mpid 88exitendDisplaying CFM on EVC
The following example shows how to display CFM information.
Switch# show ethernet cfm ma localLocal MEPs:--------------------------------------------------------------------------------MPID Domain Name Lvl MacAddress Type CCDomain Id Dir Port IdMA Name SrvcInstEVC name--------------------------------------------------------------------------------77 L6 6 000b.45e5.cb90 BD-V YL6 Up Gi 0/2 2000vlan2000 2evc200099 L6 6 00e0.aabb.cc00 BD-V YL6 Down Gi 0/2 1000vlan1000 1evc1000100 R3 3 00e0.aabb.cc0a BD-V YR3 Down Gi 0/10 10sr1 1er12 eccm2 0 00e0.aabb.cc09 BD-V Ieccm2 Down Gi /0/9 100ser2 N/Aevc2Total Local MEPs: 4Local MIPs: NoneConfiguring CFM on an EVC with Cross-Connect
The following example shows how to configure CFM on EVC with cross-connect.
pseudowire-class vlan-xconnectencapsulation mplsinterface gigabit 1/1service instance 10 ethernetencapsulation dot1q 20xconnect 2.2.2.2 123 pw-class vlan-xconnectcfm mep domain Core mpid 100Remote MEPs:--------------------------------------------------------------------------------MPID Domain Name Lvl MacAddress Type CCDomain Id Dir Port IdMA Name SrvcInstEVC name--------------------------------------------------------------------------------7003 ofm_xcon 5 <port-mac> XCONN Yofm_xcon Down Gi4/5 N/Aofm_serv xcon_evc_namexcon_evc_name8103 ifm_xcon 5 <BRAIN-MAC> XCONN Yifm_xcon Up (10.10.10.3,81) PWifm_serv xcon_evc_namexcon_evc_nameManaging and Displaying Ethernet CFM Information
You can use the privileged EXEC commands in these tables to clear Ethernet CFM information.
You can use the privileged EXEC commands in Table 43-2 to display Ethernet CFM information.
This is an example of output from the show ethernet cfm domain brief command:
Switch# show ethernet cfm domain briefDomain Name Index Level Services Archive(min)level5 1 5 1 100level3 2 3 1 100test 3 3 3 100name 4 3 1 100test1 5 2 1 100lck 6 1 1 100Total Services : 1This is an example of output from the show ethernet cfm errors command:
Switch# show ethernet cfm errors--------------------------------------------------------------------------------MPID Domain Id Mac Address Type Id LvlMAName Reason Age--------------------------------------------------------------------------------6307 level3 0021.d7ee.fe80 Vlan 7 3vlan7 Receive RDI 5sThis is an example of output from the show ethernet cfm maintenance-points local detail command:
Switch# show ethernet cfm maintenance-points local detailLocal MEPs:----------MPID: 7307DomainName: level3Level: 3Direction: UpVlan: 7Interface: Gi0/3CC-Status: EnabledCC Loss Threshold: 3MAC: 0021.d7ef.0700LCK-Status: EnabledLCK Period: 60000(ms)LCK Expiry Threshold: 3.5Level to transmit LCK: DefaultDefect Condition: No DefectpresentRDI: FALSEAIS-Status: EnabledAIS Period: 60000(ms)AIS Expiry Threshold: 3.5Level to transmit AIS: DefaultSuppress Alarm configuration: EnabledSuppressing Alarms: NoMIP Settings:-------------Local MIPs:* = MIP Manually Configured------------------------------------------------------------------------------Level Port MacAddress SrvcInst Type Id------------------------------------------------------------------------------*5 Gi0/3 0021.d7ef.0700 N/A Vlan 2,7This is an example of output from the show ethernet cfm traceroute command:
Switch# show ethernet cfm tracerouteCurrent Cache-size: 0 HopsMax Cache-size: 100 HopsHold-time: 100 MinutesYou can use the privileged EXEC commands in Table 43-3 to display IP SLAs Ethernet CFM information.
Understanding the Ethernet OAM Protocol
The Ethernet OAM protocol for installing, monitoring, and troubleshooting Metro Ethernet networks and Ethernet WANs relies on an optional sublayer in the data link layer of the OSI model. Normal link operation does not require Ethernet OAM. You can implement Ethernet OAM on any full-duplex point-to-point or emulated point-to-point Ethernet link for a network or part of a network (specified interfaces).
OAM frames, called OAM protocol data units (OAM 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 a maximum transmission rate of 10 frames per second, resulting in minor impact to normal operations. However, when you enable link monitoring, because the CPU must poll error counters frequently, the number of required CPU cycles is proportional to the number of interfaces that must be polled.
Ethernet OAM has two major components:
•
The OAM client establishes and manages Ethernet OAM on a link and 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. After the discovery phase, it manages the rules of response to OAM PDUs and the OAM remote loopback mode.
•
The OAM sublayer presents two standard IEEE 802.3 MAC service interfaces facing the superior and inferior MAC sublayers. It provides a dedicated interface for the OAM client to pass OAM control information and PDUs to and from the client. It includes these components:
–
The control block provides the interface between the OAM client and other OAM sublayer internal blocks.
–
The multiplexer manages frames from the MAC client, the control block, and the parser and passes OAM PDUs from the control block and loopback frames from the parser to the subordinate layer.
–
The parser classifies frames as OAM PDUs, MAC client frames, or loopback frames and sends them to the appropriate entity: OAM PDUs to the control block, MAC client frames to the superior sublayer, and loopback frames to the multiplexer.
OAM Features
These OAM features are defined by IEEE 802.3ah:
•
Discovery identifies devices in the network and their OAM capabilities. It uses periodic OAM PDUs to advertise OAM mode, configuration, and capabilities; PDU configuration; and platform identity. An optional phase allows the local station to accept or reject the configuration of the peer OAM entity.
•
Link monitoring detects and indicates link faults under a variety of conditions and uses the event notification OAM PDU to notify the remote OAM device when it detects problems on the link. Error events include when the number of symbol errors, the number of frame errors, the number of frame errors within a specified number of frames, or the number of error seconds within a specified period exceed a configured threshold.
•
Remote failure indication conveys a slowly deteriorating quality of an OAM entity to its peers by communicating these conditions: Link Fault means a loss of signal, Dying Gasp means an unrecoverable condition, and Critical Event means an unspecified vendor-specific critical event. The switch can receive and process but not generate Link Fault or Critical Event OAM PDUs. It can generate Dying Gasp OAM PDUs to show when Ethernet OAM is disabled, the interface is shut down, the interface enters the error-disabled state, or the switch is reloading. It also supports Dying Gasp PDUs based on loss of power.
•
Remote loopback mode to ensure link quality with a remote peer during installation or troubleshooting. In this mode, when the switch receives a frame that is not an OAM PDU or a pause frame, it sends it back on the same port. The link appears to the user to be in the up state. You can use the returned loopback acknowledgement to test delay, jitter, and throughput.
OAM Messages
Ethernet OAM messages or PDUs are standard length, untagged Ethernet frames between 64 and 1518 bytes. They do not go beyond a single hop and have a maximum transmission rate of 10 OAM PDUs per second. Message types are information, event notification, loopback control, or vendor-specific OAM PDUs.
Setting Up and Configuring Ethernet OAM
•
Default Ethernet OAM Configuration
•
Ethernet OAM Configuration Guidelines
•
Enabling Ethernet OAM on an Interface
•
Enabling Ethernet OAM Remote Loopback
•
Configuring Ethernet OAM Link Monitoring
•
Configuring Ethernet OAM Remote Failure Indications
•
Configuring Ethernet OAM Templates
Default Ethernet OAM Configuration
Ethernet OAM is disabled on all interfaces.
When Ethernet OAM is enabled on an interface, link monitoring is automatically turned on.
Remote loopback is disabled.
No Ethernet OAM templates are configured.
Ethernet OAM Configuration Guidelines
•
The switch does not support monitoring of egress frames sent with cyclic redundancy code (CDC) errors. The ethernet oam link-monitor transmit crc interface-configuration or template-configuration commands are visible but are not supported on the switch. The commands are accepted, but are not applied to an interface.
•
For a remote failure indication, the switch does not generate Link Fault or Critical Event OAM PDUs. However, if these PDUs are received from a link partner, they are processed. The switch supports generating and receiving Dying Gasp OAM PDUs when Ethernet OAM is disabled, the interface is shut down, the interface enters the error-disabled state, or the switch is reloading. The switch can also generate and receive Dying Gasp PDUs based on loss of power. The PDU includes a reason code to indicate why it was sent.
•
The switch does not support Ethernet OAM on ports that belong to an EtherChannel.
Enabling Ethernet OAM on an Interface
Beginning in privileged EXEC mode, follow these steps to enable Ethernet OAM on an interface:
Enter the no ethernet oam interface configuration command to disable Ethernet OAM on the interface.
Enabling Ethernet OAM Remote Loopback
You must enable Ethernet OAM remote loopback on an interface for the local OAM client to initiate OAM remote loopback operations. Changing this setting causes the local OAM client to exchange configuration information with its remote peer. Remote loopback is disabled by default.
Remote loopback has these limitations:
•
Internet Group Management Protocol (IGMP) packets are not looped back.
•
You cannot configure Ethernet OAM remote loopback on ports that belong to an EtherChannel.
Beginning in privileged EXEC mode, follow these steps to enable Ethernet OAM remote loopback on an interface:
Use the no ethernet oam remote-loopback {supported | timeout} interface configuration command to disable remote loopback support or to remove the timeout setting.
Configuring Ethernet OAM Link Monitoring
You can configure high and low thresholds for link-monitoring features. If no high threshold is configured, the default is none —no high threshold is set. If you do not set a low threshold, it defaults to a value lower than the high threshold.
Beginning in privileged EXEC mode, follow these steps to configure Ethernet OAM link monitoring on an interface:
The ethernet oam link-monitor transmit-crc {threshold {high {high-frames | none} | low {low-frames}} | window milliseconds} command is visible on the switch and you are allowed to enter it, but it is not supported.Enter the no form of the commands to disable the configuration. Use the no form of each command to disable the threshold setting.
Configuring Ethernet OAM Remote Failure Indications
You can configure an error-disable action to occur on an interface if one of the high thresholds is exceeded, if the remote link goes down, if the remote device is rebooted, or if the remote device disables Ethernet OAM on the interface.
Beginning in privileged EXEC mode, follow these steps to enable Ethernet OAM remote-failure indication actions on an interface:
The switch does not generate Link Fault or Critical Event OAM PDUs. However, if these PDUs are received from a link partner, they are processed. The switch supports sending and receiving Dying Gasp OAM PDUs with reason codes when Ethernet OAM is disabled, the interface is shut down, the interface enters the error-disabled state, or the switch is reloading. It can also respond to and generate, Dying Gasp PDUs based on loss of power. Enter the no ethernet remote-failure {critical-event | dying-gasp | link-fault} action command to disable the remote failure indication action.
Configuring Ethernet OAM Templates
You can create a template for configuring a common set of options on multiple Ethernet OAM interfaces. The template can be configured to monitor frame errors, frame-period errors, frame-second errors, received CRS errors, and symbol-period errors and thresholds. You can also set the template to put the interface in error-disabled state if any high thresholds are exceeded. These steps are optional and can be performed in any sequence or repeated to configure different options.
Beginning in privileged EXEC mode, follow these steps to configure an Ethernet OAM template and to associate it with an interface:
The switch does not support monitoring egress frames with CRC errors. The ethernet oam link-monitor transmit-crc {threshold {high {high-frames | none} | low {low-frames}} | window milliseconds} command is visible on the switch and you can enter it, but it is not supported. Use the no form of each command to remove the option from the template. Use the no source-template template-name to remove the source template association.
Displaying Ethernet OAM Protocol Information
You can use the privileged EXEC commands in Table 43-4 to display Ethernet OAM protocol information.
Understanding E-LMI
Ethernet Local Management Interface (E-LMI) is a protocol between the customer-edge (CE) device and the provider-edge (PE) device. It runs only on the PE-to-CE UNI link and notifies the CE device of connectivity status and configuration parameters of Ethernet services available on the CE port. E-LMI interoperates with an OAM protocol, such as CFM, that runs within the provider network to collect OAM status. CFM runs at the provider maintenance level (UPE to UPE with up MEPs at the UNI).
OAM manager, which streamlines interaction between any two OAM protocols, handles the interaction between CFM and E-LMI. This interaction is unidirectional, running only from OAM manager to E-LMI on the UPE side of the switch. Information is exchanged either as a result of a request from E-LMI or triggered by OAM when it received notification of a change from the OAM protocol. This type of information is relayed:
•
Remote UNI name and status
•
Remote UNI counts
The ME 3800X and ME 3600X switch can be only a customer-edge device.
Configuring E-LMI
Most E-LMI configuration occurs on the PE switch on the interfaces connected to the CE device. On the CE switch, you only need to enable E-LMI on the connecting interface.
The switch supports only E-LMI-CE configuration.
•
E-LMI Configuration Guidelines
•
Ethernet OAM and CFM Configuration Example
Default E-LMI Configuration
Ethernet LMI is globally disabled by default.
When you globally enable E-LMI by entering the ethernet lmi global global configuration command, it is automatically enabled on all interfaces. You can also enable or disable E-LMI per interface to override the global configuration. The E-LMI command that is given last is the command that has precedence.
There are no UNIs defined. UNI bundling service is bundling with multiplexing.
E-LMI Configuration Guidelines
The switch supports E-LMI only for the customer edge. The provider side of the connection must be running CFM and E-LMI.
•
E-LMI is not supported on routed ports, EtherChannel port channels or ports that belong to an EtherChannel.
•
You cannot configure E-LMI on VLAN interfaces.
•
You must enter the ethernet lmi ce global configuration command to enable the switch or interface in customer-edge mode.
Enabling E-LMI
You can enable E-LMI globally or on an interface and configure the switch as a CE device. Beginning in privileged EXEC mode, follow these steps to enable for E-LMI on the switch or on an interface. Note that the order of the global and interface commands determines the configuration. The command that is entered last has precedence.
Use the no ethernet lmi global configuration command to globally disable E-LMI. Use the no form of the ethernet lmi interface configuration command with keywords to disable E-LMI on the interface or to return the timers to the default settings.
Use the show ethernet lmi commands to display information that was sent to the CE from the status request poll. Use the show ethernet service commands to show current status on the device.
Customer-Edge Device Configuration
This example shows the commands necessary to configure E-LMI on the CE device. The switch can only be configured as the CE device. The example enables E-LMI globally, but you can also enable it only on a specific interface.
Switch# config tSwitch(config)# ethernet lmi globalSwitch(config)# ethernet lmi ceSwitch(config)# exit
Note
For E-LMI to work, any VLANs used on the PE device must also be created on the CE device. Create a VLAN by entering the vlan vlan-id global configuration command on the CE device, where the vlan-ids match those on the PE device and configure these VLANs as allowed VLANs by entering the switchport trunk allowed vlan vlan-ids interface configuration command. Allowed VLANs can receive and send traffic on the interface in tagged format when in trunking mode.
Displaying E-LMI
You can use the privileged EXEC commands in Table 43-5 to display E-LMI information.
Ethernet CFM and Ethernet OAM Interaction
When the Ethernet OAM Protocol is running on an interface that has CFM MEPs configured, Ethernet OAM informs CFM of the state of the interface. Interaction is unidirectional from the Ethernet OAM to the CFM Protocol, and the only information exchanged is the user network interface port status.
The Ethernet OAM Protocol notifies CFM when these conditions occur:
•
Error thresholds are crossed at the local interface.
CFM responds to the notification by sending a port status of Local_Excessive_Errors in the Port StatusType Length Value (TLV).
•
Ethernet OAM receives an OAMPDU from the remote side showing that an error threshold is exceeded on the remote endpoint.
CFM responds to the notification by sending a port status of Remote_Excessive_Errors in the Port Status TLV.
•
The local port is set into loopback mode.
CFM responds by sending a port status of Test in the Port Status TLV.
•
The remote port is set into loopback mode.
CFM responds by sending a port status of Test in the Port Status TLV.
This section includes this information:
•
Ethernet OAM and CFM Configuration Example
For more information about CFM and interaction with Ethernet OAM, see the Ethernet Connectivity Fault Management feature module.
Enabling Ethernet OAM
Beginning in privileged EXEC mode, follow these steps to enable Ethernet OAM on an interface.
Ethernet OAM and CFM Configuration Example
These are example configurations of the interworking between Ethernet OAM and CFM in a sample service provider network with a provider-edge switch connected to a customer edge switch at each endpoint. You must configure CFM and Ethernet OAM between the customer edge and the provider edge switch.
Customer-edge switch 1 (CE1) configuration:
Switch# config tSwitch(config)# interface gigabitethernet0/1Switch(config-if)# switchport trunk allowed vlan 10Switch(config-if)# switchport mode trunkSwitch(config-if)# ethernet oam remote-loopback supportedSwitch(config-if)# ethernet oamSwitch(config-if)# exitProvider-edge switch 1 (PE1) configuration:
Switch# config tSwitch(config)# interface gigabitethernet0/5Switch(config-if)# switchport trunk encapsulation dot1qSwitch(config-if)# switchport mode trunkSwitch(config-if)# ethernet cfm mip level 7Switch(config-if)# ethernet cfm mep level 4 mpid 100 vlan 10Switch(config-if)# ethernet uni id 2004-20Switch(config-if)# ethernet oam remote-loopback supportedSwitch(config-if)# ethernet oamSwitch(config-if-srv)# exitProvider-edge switch 2 (PE2) configuration:
Switch# config tSwitch(config)# interface gigabitethernet1/20Switch(config-if)# switchport mode trunkSwitch(config-if)# ethernet cfm mip level 7Switch(config-if)# ethernet cfm mep level 4 mpid 101 vlan 10Switch(config-if)# ethernet uni id 2004-20Switch(config-if)# ethernet oam remote-loopback supportedSwitch(config-if)# ethernet oamSwitch(config-if-srv)# exitCustomer-edge switch 2 (CE2) configuration:
Switch# config tSwitch(config)# interface gigabitethernet0/1Switch(config-if)# switchport trunk allowed vlan 10Switch(config-if)# switchport mode trunkSwitch(config-if)# ethernet oam remote-loopback supportedSwitch(config-if)# ethernet oamSwitch(config-if)# exitThese are examples of the output showing provider-edge switch port status of the configuration. Port status shows as UP at both switches.
Switch PE1:
Switch# show ethernet cfm maintenance points remoteMPID Level Mac Address Vlan PortState InGressPort Age(sec) Service ID101 * 4 0015.633f.6900 10 UP Gi0/1 27 blueSwitch PE2:
Switch# show ethernet cfm maintenance points remoteMPID Level Mac Address Vlan PortState InGressPort Age(sec) Service ID100 * 4 0012.00a3.3780 10 UP Gi0/1 8 blueTotal Remote MEPs: 1This example shows the outputs when you start remote loopback on CE1 (or PE1). The port state on the remote PE switch shows as Test and the remote CE switch goes into error-disable mode.
Switch# ethernet oam remote-loopback start interface gigabitEthernet 0/1This is a intrusive loopback.Therefore, while you test Ethernet OAM MAC connectivity,you will be unable to pass traffic across that link.Proceed with Remote Loopback? [confirm]Switch PE1:
Switch# show ethernet cfm maintenance points remoteMPID Level Mac Address Vlan PortState InGressPort Age(sec) Service ID101 * 4 0015.633f.6900 10 UP Gi0/1 27 blueSwitch PE2:
Switch# show ethernet cfm maintenance points remoteMPID Level Mac Address Vlan PortState InGressPort Age(sec) Service ID100 * 4 0012.00a3.3780 10 TEST Gi1/1/1 8 blueTotal Remote MEPs: 1In addition, if you shut down the CE1 interface that connects to PE1, the remote PE2 port will show a PortState of Down.