Ethernet as a Metro Area Network (MAN) or a Wide Area Network (WAN) technology benefits greatly from the implementation of Operations, Administration and Maintenance (OAM) features. Ethernet Link OAM (ELO) features allow you to monitor the quality of the connections on a MAN or a WAN. ELO operates on a single physical link, and it can be configured to monitor either side or both sides of that link.

ELO can be configured in the following ways:

• Using an ELO profile: An ELO profile can be configured to set the parameters for multiple interfaces. This simplifies the process of configuring Ethernet Link OAM features on multiple interfaces. An ELO profile and its features can be referenced by other interfaces, allowing them to inherit those features. This is the preferred method of configuring custom ELO settings.

• Configuring directly on an interface: Individual ELO features can be configured directly on an interface without being part of a profile. When an interface uses an ELO profile, specific parameters can still be overridden by configuring different values directly on the interface. In such cases, the individually configured features take precedence over the profile settings.

When an ELO packet is received on any one of the Attachment Circuit (AC) interfaces where ELO is not configured, the AC interface multicasts the received packets to other AC interfaces that are part of the Ethernet Virtual Private Network Broadcast Domain (EVPN-BD) to reach the peer. An ELO can be configured on any physical Ethernet interface, including bundle members.

These standard Ethernet Link OAM features are supported on the router:

Neighbor discovery enables each end of a link to learn the OAM capabilities of the other end and establish an OAM peer relationship. Each end also can require that the peer have certain capabilities before it will establish a session. You can configure certain actions to be taken if there is a capabilities conflict or if a discovery process times out, using the action capabilities-conflict or action discovery-timeout commands.

Ethernet Fault Detection (EFD) is a mechanism that allows Ethernet OAM protocols, such as CFM, to control the line protocol state of an interface.

Unlike many other interface types, Ethernet interfaces do not have a line protocol, whose state is independent from that of the interface. For Ethernet interfaces, this role is handled by the physical-layer Ethernet protocol itself, and therefore if the interface is physically up, then it is available and traffic can flow.

EFD changes this to allow CFM to act as the line protocol for Ethernet interfaces. This allows CFM to control the interface state so that if a CFM defect (such as AIS or loss of continuity) is detected with an expected peer MEP, the interface can be shut down. This not only stops traffic flow, but also triggers actions in any higher-level protocols to route around the problem. For example, in the case of Layer 2 interfaces, the MAC table would be cleared and MSTP would reconverge. For Layer 3 interfaces, the ARP cache would be cleared and potentially the IGP would reconverge.

Note	EFD can only be used for down MEPs. When EFD is used to shut down the interface, the CFM frames continue to flow. This allows CFM to detect when the problem has been resolved, and thus bring the interface backup automatically.

This figure shows CFM detection of an error on one of its sessions EFD signaling an error to the corresponding MAC layer for the interface. This triggers the MAC to go to a down state, which further triggers all higher level protocols (Layer 2 pseudowires, IP protocols, and so on) to go down and also trigger a reconvergence where possible. As soon as CFM detects there is no longer any error, it can signal to EFD and all protocols will once again go active.

MIB retrieval enables an OAM peer on one side of an interface to get the MIB variables from the remote side of the link. The MIB variables that are retrieved from the remote OAM peer are READ ONLY.

Miswiring Detection is a Cisco-proprietary feature that uses the 32-bit vendor field in every Information OAMPDU to identify potential miswiring cases.

SNMP traps can be enabled or disabled on an Ethernet OAM interface.

This section provides these configuration procedures:

UDLD can detect these types of faults:

• Transmit faults — These are cases where there is a failure in transmitting packets from the local port to the peer device, but packets are being received from the peer. These faults are caused by failure of the physical link (where notification at layer 1 of unidirectional link faults is not supported by the media) as well as packet path faults on the local or peer device.

• Miswiring faults — These are cases where the receiving and transmitting sides of a port on the local device are connected to different peer ports (on the same device or on different devices). This can occur when using unbundled fibers to connect fiber optic ports.

• Loopback faults — These are cases where the receiving and transmitting sides of a port are connected to each other, creating a loopback condition. This can be an intentional mode of operation, for certain types of testing, but UDLD must not be used in these cases.

• Receive faults — The protocol includes a heartbeat signal that is transmitted at a negotiated periodic interval to the peer device. Missed heartbeats can therefore be used to detect failures on the receiving side of the link (where they do not result in interface state changes). These could be caused by a unidirectional link with a failure only affecting the receiving side, or by a link which has developed a bidirectional fault. This detection depends on reliable, regular packet transmission by the peer device. For this reason, the UDLD protocol has two (configurable) modes of operation which determine the behavior on a heartbeat timeout. These modes are described in the section UDLD Modes of Operation.

UDLD can operate in these modes:

• Normal mode: In this mode, if a Receive Fault is detected, the user is informed and no further action is taken.

• Aggressive mode: In this mode, if a Receive Fault is detected, the user is informed and the affected port is disabled.

  Note	The difference of behavior between normal and aggressive modes is only seen in case of neighbor timeout. In all other cases, irrespective of the normal or aggressive mode, the system error disables a link once a unidirectional link is detected.

UDLD is configured for each interface. The interface must be a physical ethernet interface.

Perform the following steps to configure UDLD protocol on an interface:

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# interface
TenGigE 0/1/0/0

Note	The example indicates a 10-Gigabit Ethernet interface in line card slot 1.

RP/0/RP0/CPU0:IOS(config)#interface tenGigE 0/0/0/0

 RP/0/RP0/CPU0:IOS(config-if)#ethernet udld
 
RP/0/RP0/CPU0:IOS(config-if-udld)#mode ?

   aggressive  Run UDLD in aggressive mode

   normal      Run UDLD in normal mode

 RP/0/RP0/CPU0:IOS(config-if-udld)#mode aggressive
 
 RP/0/RP0/CPU0:IOS(config-if-udld)#message-time ?

   <7-90>  'Mslow' message time (in seconds) to use for the UDLD protocol

 RP/0/RP0/CPU0:IOS(config-if-udld)#message-time 50
 
RP/0/RP0/CPU0:IOS(config-if-udld)#destination mac-address ?
   H.H.H   
             A valid multicast MAC address

   cisco-l2cp           Use the Cisco L2CP MAC address (used by CDP)

   ieee-slow-protocols  Use the IEEE slow protocol destination MAC address
RP/0/RP0/CPU0:IOS(config-if-udld)#destination mac-address 0100.5e01.0101

 RP/0/RP0/CPU0:IOS(config-if-udld)#logging disable
 
 RP/0/RP0/CPU0:IOS(config-if-udld)#commit

 RP/0/RP0/CPU0:IOS(config-if-udld)#end

 RP/0/RP0/CPU0:IOS#sh run interface tenGigE 0/0/0/0
 interface TenGigE0/0/0/0

  ethernet udld
 
  mode aggressive

   message-time 50
 
  destination mac-address 0100.5e01.0101

   logging disable

  !
 
!


RP/0/RP0/CPU0:IOS# sh ethernet udld interfaces

 Device ID:               00:8a:96:e1:20:d8

 Device name:             IOS

 Interface TenGigE0/0/0/0
   
Port state:            Up
   
Main FSM state:        Advertising
   
Detection FSM state:   Unknown
   
Message interval:      7 seconds
   
Timeout interval:      5 seconds
   
Destination MAC:       01:00:5e:01:01:01

 
RP/0/RP0/CPU0:IOS# sh ethernet udld statistics tenGigE 0/0/0/0

 
Interface TenGigE0/0/0/0
   
Counters last cleared:               00:01:18 ago
   
Main FSM transitions (to each state)
     
Link up:     1
     
Detection:   0
     
Advertise:   1
     
Port shutdown: 0
     
UDLD inactive: 0

Detection FSM transitions (to each state)
     
Unknown: 0
     
Bidirectional: 0
     
Unidirectional: 0
     
Neighbor mismatch: 0
     
Loopback: 0
   
Rx packet counts
     
Probe: 0
     
Echo:                                         0
     
Flush:                                        0
     
Invalid packets (dropped):                    0
   
Tx packet counts
     
Probe:                                       19
     
Echo:                                         0
     
Flush:                                        0
     
Unable to send (dropped):                     0
 
RP/0/RP0/CPU0:IOS#

 RP/0/RP0/CPU0:IOS# sh ethernet udld daemon database 
 
Interface TenGigE0/0/0/0


   Item                          Value
   
----------------------------  -----------------------------------------------
 
  Interface handle              Te0/0/0/0 (0x00000200)       
  Name                          Te0/0/0/0         
  Name (long internal format)   TenGigE0_0_0_0
  Configured ?                  TRUE
  Caps add in progress ?        FALSE 
  Caps remove in progress ?     FALSE       
  Caps added ?                  TRUE  
  Protocol start pending ?      FALSE  
  Protocol running ?            TRUE     
  Registered for packet I/O ?   TRUE     
  Aggressive mode ?             TRUE   
  Logging enabled ?             FALSE 
  Error disabled on start ?     FALSE
  Error disabled during ISSU ?  FALSE  
  Attributes read ?             TRUE 
  Pending state down nfn ?      FALSE 
  Message time                  50

A maintenance domain describes 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 interfaces internal to it and at its boundary, as shown in this figure.

A maintenance domain is defined by the bridge ports that are provisioned within it. Domains are assigned maintenance levels, in the range of 0 to 7, by the administrator. The level of the domain is useful in defining the hierarchical relationships of multiple domains.

CFM maintenance domains allow different organizations to use CFM in the same network, but independently. For example, consider a service provider who offers a service to a customer, and to provide that service, they use two other operators in segments of the network. In this environment, CFM can be used in the following ways:

• The customer can use CFM between their CE devices, to verify and manage connectivity across the whole network.

• The service provider can use CFM between their PE devices, to verify and manage the services they are providing.

• Each operator can use CFM within their operator network, to verify and manage connectivity within their network.

Each organization uses a different CFM maintenance domain.

This figure shows an example of the different levels of maintenance domains in a network.

Note	In CFM diagrams, the conventions are that triangles represent MEPs, pointing in the direction that the MEP sends CFM frames, and circles represent MIPs.

To ensure that the CFM frames for each domain do not interfere with each other, each domain is assigned a maintenance level, between 0 and 7. Where domains are nested, as in this example, the encompassing domain must have a higher level than the domain it encloses. In this case, the domain levels must be negotiated between the organizations involved. The maintenance level is carried in all CFM frames that relate to that domain.

CFM maintenance domains may touch or nest, but cannot intersect. This figure illustrates the supported structure for touching and nested domains, and the unsupported intersection of domains.

A CFM service allows an organization to partition its CFM maintenance domain, according to the connectivity within the network. For example, if the network is divided into a number of virtual LANs (VLANs), a CFM service is created for each of these. CFM can then operate independently in each service. It is important that the CFM services match the network topology, so that CFM frames relating to one service cannot be received in a different service. For example, a service provider may use a separate CFM service for each of their customers, to verify and manage connectivity between that customer's end points.

A CFM service is always associated with the maintenance domain that it operates within, and therefore with that domain's maintenance level. All CFM frames relating to the service carry the maintenance level of the corresponding domain.

Note	CFM Services are referred to as Maintenance Associations in IEEE 802.1ag and as Maintenance Entity Groups in ITU-T Y.1731.

A CFM Maintenance Point (MP) is an instance of a particular CFM service on a specific interface. CFM only operates on an interface if there is a CFM maintenance point on the interface; otherwise, CFM frames are forwarded transparently through the interface.

A maintenance point is always associated with a particular CFM service, and therefore with a particular maintenance domain at a particular level. Maintenance points generally only process CFM frames at the same level as their associated maintenance domain. Frames at a higher maintenance level are always forwarded transparently, while frames at a lower maintenance level are normally dropped. This helps enforce the maintenance domain hierarchy, and ensures that CFM frames for a particular domain cannot leak out beyond the boundary of the domain.

There are two types of MP:

• Maintenance End Points (MEPs)—Created at the edge of the domain. Maintenance end points (MEPs) are members of a particular service within a domain and are responsible for sourcing and sinking CFM frames. They periodically transmit continuity check messages and receive similar messages from other MEPs within their domain. They also transmit traceroute and loopback messages at the request of the administrator. MEPs are responsible for confining CFM messages within the domain.

• Maintenance Intermediate Points (MIPs)—Created in the middle of the domain. Unlike MEPS, MIPs do allow CFM frames at their own level to be forwarded.

Unlike MEPs, MIPs are not explicitly configured on each interface. MIPs are created automatically according to the algorithm specified in the CFM 802.1ag standard. The algorithm, in brief, operates as follows for each interface:

• The bridge-domain or cross-connect for the interface is found, and all services associated with that bridge-domain or cross-connect are considered for MIP auto-creation.

• The level of the highest-level MEP on the interface is found. From among the services considered above, the service in the domain with the lowest level that is higher than the highest MEP level is selected. If there are no MEPs on the interface, the service in the domain with the lowest level is selected.

• The MIP auto-creation configuration (mip auto-create command) for the selected service is examined to determine whether a MIP should be created.

  Note	Configuring a MIP auto-creation policy for a service does not guarantee that a MIP will automatically be created for that service. The policy is only considered if that service is selected by the algorithm first.

The boundary of a domain is an interface, rather than a bridge or host. Therefore, MEPs can be sub-divided into two categories:

• Down MEPs—Send CFM frames from the interface where they are configured, and process CFM frames received on that interface. Down MEPs transmit AIS messages upward (toward the cross-connect).

• Up MEPs—Send frames into the bridge relay function, as if they had been received on the interface where the MEP is configured. They process CFM frames that have been received on other interfaces, and have been switched through the bridge relay function as if they are going to be sent out of the interface where the MEP is configured. Up MEPs transmit AIS messages downward (toward the wire). However, AIS packets are only sent when there is a MIP configured on the same interface as the MEP and at the level of the MIP.

Note	The terms Down MEP and Up MEP are defined in the IEEE 802.1ag and ITU-T Y.1731 standards, and refer to the direction that CFM frames are sent from the MEP. The terms should not be confused with the operational status of the MEP.

This figure illustrates the monitored areas for Down and Up MEPs.

This figure shows maintenance points at different levels. Because domains are allowed to nest but not intersect (see Supported CFM Maintenance Domain Structure), a MEP at a low level always corresponds with a MEP or MIP at a higher level. In addition, only a single MIP is allowed on any interface—this is generally created in the lowest domain that exists at the interface and that does not have a MEP.

MIPs and Up MEPs can only exist on switched (Layer 2) interfaces, because they send and receive frames from the bridge relay function. Down MEPs can be created on switched (Layer 2) interfaces.

MEPs continue to operate normally if the interface they are created on is blocked by the Spanning Tree Protocol (STP); that is, CFM frames at the level of the MEP continue to be sent and received, according to the direction of the MEP. MEPs never allow CFM frames at the level of the MEP to be forwarded, so the STP block is maintained.

MIPs also continue to receive CFM frames at their level if the interface is STP blocked, and can respond to any received frames. However, MIPs do not allow CFM frames at the level of the MIP to be forwarded if the interface is blocked.

Note

A separate set of CFM maintenance levels is created every time a VLAN tag is pushed onto the frame. Therefore, if CFM frames are received on an interface which pushes an additional tag, so as to “tunnel” the frames over part of the network, the CFM frames will not be processed by any MPs within the tunnel, even if they are at the same level. For example, if a CFM MP is created on an interface with an encapsulation that matches a single VLAN tag, any CFM frames that are received at the interface that have two VLAN tags will be forwarded transparently, regardless of the CFM level.

The CFM protocol consists of a number of different message types, with different purposes. All CFM messages use the CFM EtherType, and carry the CFM maintenance level for the domain to which they apply.

This section describes the following CFM messages:

Continuity Check Messages (CCMs) are “heartbeat” messages exchanged periodically between all the MEPs in a service. Each MEP sends out multicast CCMs, and receives CCMs from all the other MEPs in the service—these are referred to as peer MEPs. This allows each MEP to discover its peer MEPs, and to verify that there is connectivity between them.

MIPs also receive CCMs. MIPs use the information to build a MAC learning database that is used when responding to Linktrace. For more information about Linktrace, see Linktrace (IEEE 802.1ag and ITU-T Y.1731).

All the MEPs in a service must transmit CCMs at the same interval. The interval at which CCMs are being transmitted is called CCM interval. IEEE 802.1ag defines 7 possible intervals that can be used:

• 3.3ms

• 10ms

• 100ms

• 1s

• 10s

• 1 minute

• 10 minutes

A MEP detects a loss of connectivity with one of its peer MEPs when a certain number of CCMs have been missed. This occurs when sufficient time has passed during which a certain number of CCMs were expected, given the CCM interval. This number is called the loss threshold, and is usually set to 3.

CFM is supported only on interfaces which have Layer 2 transport feature enabled.

Maintenance Association Identifier (MAID)

Table 2. Feature History Table

Feature Name	Release	Description
48 byte string-based MAID support for Offloaded Endpoints	Release 7.5.1	This feature is supported on Cisco Network Convergence System 5700 Series routers and routers with the Cisco NC57 line cards operating in native mode. This feature extends MAID functionality to support the flexible format for hardware offloaded MEPs. This removes the restrictions on the type of MAID supported for sessions with less than 1 minute time intervals. To enable the feature in native mode, run the hw-module profile oam 48byte-cfm-maid-enable command in the System Admin Config mode, and reload the router.

Continuity Check Messages (CCM) are essential for detecting various defects in network services. They carry critical information that helps in the identification and maintenance of the service. This is a breakdown of the information contained in CCM messages:

• Maintenance Domain Identifier (MDID): A configured identifier unique to the domain of the transmitting Maintenance End Point (MEP). It is crucial for the identification of the maintenance domain.

• Short MA Name (SMAN): A configured identifier specific to the service of the transmitting MEP. It is used to identify the service within the maintenance domain.

• Maintenance Association Identifier (MAID): A combination of MDID and SMAN. Together, these identifiers form the MAID, which is a composite identifier that must be uniformly configured across all MEPs within the same service.

Note	MDID only supports null value and SMAN supports ITU Carrier Code (ICC) or a numerical. No other values are supported.

Supported MAID Formats for Offloaded MEPs (applicable for NCS 5700 line cards only)

• No Domain Name Format

  • MD Name Format = 1-NoDomainName

  • Short MA Name Format = 3 - 2 bytes integer value

  • Short MA NAme Length = 2 - fixed length

  • Short MA Name = 2 bytes of integer

• 1731 Maid Format

  • MD Name Format = 1-NoDomainName

  • MA Name Format(MEGID Format) = 32

  • MEGID Length = 13 - fixed length

  • MEGID(ICCCode) = 6 Bytes

  • MEGID(UMC) = 7 Bytes

  • ITU Carrier Code (ICC) - Number of different configurable ICC code - 15 (for each NPU)

  • Unique MEG ID Code (UMC) - 4

These are some examples:

• Configuring domain ID null: ethernet cfm domain SMB level 3 id null

• Configuring SMAN: ethernet cfm domain SMB level 3 id null service 901234AB xconnect group 99999 p2p 99999 id number 1

This table summarizes the supported values and parameters for MDID and SMAN. This table only details the MAID restriction on the hardware offload feature. There is no MAID restriction for software offload or non-offloaded MEPs.

For Cisco NCS 5500 series routers, "id null" has to be explicitly configured for the domain ID, for hardware offloaded sessions.

Format	MDID	SMAN	Support	Comment
	No	2 byte integer	Yes	Up to 2000 entries
	No	13 bytes ICCCode (6 bytes) and UMC (7 bytes)	Yes	Up to 15 unique ICC Up to 4K UMC values
48 bytes string based	1-48 bytes of MDID and SMAN		No	Most commonly used

Loopback Messages (LBM) and Loopback Replies (LBR) are used to verify connectivity between a local MEP and a particular remote MP. At the request of the administrator, a local MEP sends unicast LBMs to the remote MP. On receiving each LBM, the target maintenance point sends an LBR back to the originating MEP. Loopback indicates whether the destination is reachable or not—it does not allow hop-by-hop discovery of the path. It is similar in concept to an ICMP Echo (ping). Since loopback messages are destined for unicast addresses, they are forwarded like normal data traffic, while observing the maintenance levels. At each device that the loopback reaches, if the outgoing interface is known (in the bridge's forwarding database), then the frame is sent out on that interface. If the outgoing interface is not known, then the message is flooded on all interfaces.

This figure shows an example of CFM loopback message flow between a MEP and MIP.

Loopback messages can be padded with user-specified data. This allows data corruption to be detected in the network. They also carry a sequence number which allows for out-of-order frames to be detected.

Linktrace Messages (LTM) and Linktrace Replies (LTR) are used to track the path (hop-by-hop) to a unicast destination MAC address. At the request of the operator, a local MEP sends an LTM. Each hop where there is a maintenance point sends an LTR back to the originating MEP. This allows the administrator to discover connectivity data about the path. It is similar in concept to IP traceroute, although the mechanism is different. In IP traceroute, successive probes are sent, whereas CFM Linktrace uses a single LTM which is forwarded by each MP in the path. LTMs are multicast, and carry the unicast target MAC address as data within the frame. They are intercepted at each hop where there is a maintenance point, and either retransmitted or dropped to discover the unicast path to the target MAC address.

This figure shows an example of CFM linktrace message flow between MEPs and MIPs.

The linktrace mechanism is designed to provide useful information even after a network failure. This allows it to be used to locate failures, for example after a loss of continuity is detected. To achieve this, each MP maintains a CCM Learning Database. This maps the source MAC address for each received CCM to the interface through which the CCM was received. It is similar to a typical bridge MAC learning database, except that it is based only on CCMs and it times out much more slowly—on the order of days rather than minutes.

Note	In IEEE 802.1ag, the CCM Learning Database is referred to as the MIP CCM Database. However, it applies to both MIPs and MEPs.

In IEEE 802.1ag, when an MP receives an LTM message, it determines whether to send a reply using the following steps:

1. The target MAC address in the LTM is looked up in the bridge MAC learning table. If the MAC address is known, and therefore the egress interface is known, then an LTR is sent.

2. If the MAC address is not found in the bridge MAC learning table, then it is looked up in the CCM learning database. If it is found, then an LTR is sent.

3. If the MAC address is not found, then no LTR is sent (and the LTM is not forwarded).

If the target MAC has never been seen previously in the network, the linktrace operation will not produce any results.

Note

IEEE 802.1ag and ITU-T Y.1731 define slightly different linktrace mechanisms. In particular, the use of the CCM learning database and the algorithm described above for responding to LTM messages are specific to IEEE 802.1ag. IEEE 802.1ag also specifies additional information that can be included in LTRs. Regardless of the differences, the two mechanisms are interoperable.

CFM supports logging of various conditions to syslog. Logging can be enabled independently for each service, and when the following conditions occur:

• New peer MEPs are detected, or loss of continuity with a peer MEP occurs.

• Changes to the CCM defect conditions are detected.

• Cross-check “missing” or “unexpected” conditions are detected.

• AIS condition detected (AIS messages received) or cleared (AIS messages no longer received).

• EFD used to shut down an interface, or bring it back up.

The Flexible VLAN Tagging for CFM feature ensures that CFM packets are sent with the right VLAN tags so that they are appropriately handled as a CFM packet by the remote device. When packets are received by an edge router, they are treated as either CFM packets or data packets, depending on the number of tags in the header. The system differentiates between CFM packets and data packets based on the number of tags in the packet, and forwards the packets to the appropriate paths based on the number of tags in the packet.

CFM frames are normally sent with the same VLAN tags as the corresponding customer data traffic on the interface, as defined by the configured encapsulation and tag rewrite operations. Likewise, received frames are treated as CFM frames if they have the correct number of tags as defined by the configured encapsulation and tag rewrite configuration, and are treated as data frames (that is, they are forwarded transparently) if they have more than this number of tags.

In most cases, this behavior is as desired, since the CFM frames are then treated in exactly the same way as the data traffic flowing through the same service. However, in a scenario where multiple customer VLANs are multiplexed over a single multipoint provider service (for example, N:1 bundling), a different behavior might be desirable.

This figure shows an example of a network with multiple VLANS using CFM.

This figure shows a provider's access network, where the S-VLAN tag is used as the service delimiter. PE1 faces the customer, and PE2 is at the edge of the access network facing the core. N:1 bundling is used, so the interface encapsulation matches a range of C-VLAN tags. This could potentially be the full range, resulting in all:1 bundling. There is also a use case where only a single C-VLAN is matched, but the S-VLAN is nevertheless used as the service delimiter—this is more in keeping with the IEEE model, but limits the provider to 4094 services.

CFM is used in this network with a MEP at each end of the access network, and MIPs on the boxes within the network (if it is native Ethernet). In the normal case, CFM frames are sent by the up MEP on PE1 with two VLAN tags, matching the customer data traffic. This means that at the core interfaces and at the MEP on PE2, the CFM frames are forwarded as if they were customer data traffic, since these interfaces match only on the S-VLAN tag. So, the CFM frames sent by the MEP on PE1 are not seen by any of the other MPs.

Flexible VLAN tagging changes the encapsulation for CFM frames that are sent and received at Up MEPs. Flexible VLAN tagging allows the frames to be sent from the MEP on PE1 with just the S-VLAN tag that represents the provider service. If this is done, the core interfaces will treat the frames as CFM frames and they will be seen by the MIPs and by the MEP on PE2. Likewise, the MEP on PE1 should handle received frames with only one tag, as this is what it will receive from the MEP on PE2.

To ensure that CFM packets from Up MEPs are routed to the appropriate paths successfully, tags may be set to a specific number in a domain service, using the tags command. Currently, tags can only be set to one (1).

The two types of messages used to notify the head-end router are:

• G.8013 Bandwidth Notification Messages (G.8013 BNM)

• Cisco proprietary Bandwidth Vendor-Specific Messages (Cisco BW-VSM)

Both the message types contain the following information:

• Source MAC

• Port ID

• Maintenance Domain (MD) Level

• Transmission period

• Nominal Bandwidth

• Current Bandwidth

During signal degradation, periodic BNMs are sent to the head-end router containing the current bandwidth (sampled over a period of time) and nominal bandwidth (full bandwidth when there is no degradation). This allows the router to reduce the bandwidth directed to the link as shown in the figure below:

When degradation in bandwidth is detected, depending on the topology, the degradation may affect one or more paths in the network. Therefore, in more complex topologies, the head-end router may need information about links in each affected path. The BNM transmission period and a Link ID are used to differentiate between messages from the same source MAC address which refer to different links.

The list of restrictions for CFM Bandwidth Notifications is:

• Up to 200 unique BNM enabled links learnt from BNMs are supported per line card. Any BNMs for links over this limit will be discarded.

  To reset CFM BNM enabled links for the specified interfaces, use the clear ethernet cfm interface [ <interface> ] bandwidth-notifications { all | state <state> } [ location { all | <node> } ] command. An archive timer is used to clean up any BNM enabled links whose loss timer expired at least 24 hours ago.

• Over process restart:

  • Loss threshold, wait-to-restore, and hold-off timers are restarted. This may cause links to take longer to transition between states than they would have otherwise.

  • Archive timers are restarted. This may cause historical statistics for links to persist longer than they would have otherwise.

  • Queued events for EEM scripts which have been rate-limited are not preserved. Scripts with at least one link in DEGRADED state, or BNMs have changed over process restart, and are invoked. Rate-limit timers are restarted. This may cause scripts to be invoked when they would otherwise have been filtered by the damping or conformance-testing algorithms. If the last link returns to its nominal bandwidth within the rate-limit period but before the process restart, then the script will not be invoked after the process restart. Thus, actions taken by the script may not reflect the (increased) latest bandwidths of any links which returned to their nominal bandwidths within the rate-limit period.

Received BNMs are used to identify BNM enabled links within a Maintenance Entity Group (MEG), and should be uniquely identifiable within the MEG by Port-ID or MAC address. Each link has an associated nominal bandwidth, and a Reported Bandwidth (RBW), which are notified to the operator. The link is considered to be in OK state when the RBW is equal to the nominal bandwidth and DEGRADED if RBW is less than nominal.

Devices sending BNMs can detect changes in bandwidth many times a second. For example, changes caused by an object passing through a microwave link’s line of sight. The protocol for sending BNMs is designed to mitigate fluctuating current bandwidth by sampling across a ‘monitoring-interval’ and applying basic damping to degradation events. To help mitigate this further, a damping algorithm is used. This algorithm is applied on the receiving device, and is distinct from any damping performed by the sender. For more information on this, see Damping Algorithm.

An operator may be interested in more than one BNM enabled link, and needs the ability to register on a set of BNM enabled links which affect the path to a node in the network. To do this, the state and RBW for each link of interest are put into a conformance testing algorithm, which both filters and rate-limits changes to publish events notifying the operator only of significant changes. For more information on this, see Conformance Testing Algorithm.

The following diagram shows how a received BNM flows through the damping and conformance testing algorithm to invoke operator scripts:

Note

Port ID takes precedence over MAC address. This means that BNMs with same port ID but different MAC addresses are counted as same BNMs. If BNM reported bandwidth is equal to the threshold, then EEM will not be invoked. If a degraded link having bandwidth higher than the threshold receives BNM with bandwidth less than the threshold, it doesn't wait for the hold-off timer and instantly changes the bandwidth by invoking EEM script.

The Embedded Event Manager (EEM) consists of an EEM server that monitors various real-time events in the system using programs called Event Detectors (EDs) and triggers registered policies (for example, TCLscripts) to run. The EEM supports at least 200 script registrations.

Typical actions taken in response to signal degradation events include:

• Signaling to G.8032 to switch some flows to alternative paths

• Modifying QoS configuration to adjust traffic shaping to the new bandwidth

• Adjusting IGP metrics to switch some traffic to an alternative path

The following variables can be queried within the TCL script:

The command for EEM TCL scripts registering for CFM Bandwidth Notification events is interface <interface name> level <level> direction <direction> {mac-addresses { <addr1> [, …, <addr20>] } | port-ids { <id1> [, …, <id20>] } threshold <bandwidth> [ ratelimit <time> ].

To configure EEM, use the following commands:

event manager directory user policy disk0:/
event manager directory user library disk0:/
event manager policy EEMscript7.tcl username root persist-time 3600
aaa authorization eventmanager default local

Individual scripts located in the specified directory can then be configured with:

event manager policy <script_name> username lab persist-time <time>

Use the following steps to configure CFM bandwidth notifications:

• Configure a CFM domain at the level BNMs are expected to be received at, and a CFM service in the direction (either up or down-MEPs) the BNMs are expected to be received.

• Configure a CFM MEP on the interface expected to receive BNMs in the domain and service above.

Configuration consists of two parts:

• Configuring global CFM. This is similar to Continuity Check Message (CCM) and other CFM configurations.

  Global CFM configuration:

  ethernet cfm
  domain DM1 level 2 id null
    service SR1 down-meps
    !
  !
  domain dom1 level 1
    service ser1 down-meps
    !
  !

• Configuration related to CFM-BNMs under interfaces. This is optional and used for changing default values.

Interface configuration:

Interface TenGigE0/0/1/1
ethernet cfm
  mep domain DM1 service SR1 mep-id 3001
  !
  bandwidth-notifications
   hold-off 0
   wait-to-restore 60
   loss-threshold 10
   log changes
  !
!
l2transport
!
!
interface TenGigE0/0/0/3
ethernet cfm
  mep domain dom1 service ser1 mep-id 11
  !
  bandwidth-notifications
  hold-off 10
   wait-to-restore 40
   log changes
  !
!
l2transport
!
!

Running Configuration

RP/0/RP0/CPU0:router#show running-configuration
!! IOS XR Configuration 7.1.1.104I
!! Last configuration change at Mon Jun 24 21:26:46 2019 by root
!
hostname R2_cXR
logging console debugging
logging buffered 125000000
event manager directory user policy harddisk:/tcl/
event manager directory user library harddisk:/tcl/
event manager policy EEMmac_lev1.tcl username root persist-time 3600
event manager policy EEMport_lev1.tcl username root persist-time 3600
aaa authorization exec default local group tacacs+
aaa authorization eventmanager default local
!
ethernet cfm
 domain DM0 level 1 id null
  service SR0 down-meps
   continuity-check interval 1m
   mep crosscheck
    mep-id 1003
   !
   ais transmission interval 1s cos 4
   log ais
   log continuity-check errors
   log crosscheck errors
   log continuity-check mep changes
  !
 !
 domain DM1 level 2 id null
  service SR1 down-meps id number 1
   continuity-check interval 1m
   mep crosscheck
    mep-id 431
   !
   ais transmission interval 1m
   log ais
   log continuity-check errors
   log crosscheck errors
   log continuity-check mep changes
  !
 domain dom1 level 3 id string domain3
  service ser1 xconnect group XG1 p2p XC1 id number 2300
   mip auto-create all
   continuity-check interval 1m
   mep crosscheck
    mep-id 2030
   !
interface Loopback0
 ipv4 address 30.30.30.30 255.255.255.255
!
interface MgmtEth0/RSP0/CPU0/0
 ipv4 address 5.18.9.102 255.255.0.0
!
interface MgmtEth0/RSP0/CPU0/1
 shutdown
!
interface TenGigE0/0/0/0
 shutdown
!
interface TenGigE0/0/0/3.1 l2transport
 encapsulation dot1q 6
 ethernet cfm
  mep domain DM1 service SR1 mep-id 231
  !
  bandwidth-notifications
   hold-off 50
   wait-to-restore 50
   loss-threshold 100
   log changes
  !

Verification

RP/0/RP0/CPU0:router#show ethernet cfm interfaces bandwidth-notifications detail
BNM Enabled Links at Level 3 (Down MEP) for GigabitEthernet/1
    MAC Address 000a.000a.000a
      State (OK):
        Nominal Bandwidth:                                     3000 Mbps
        Reported Bandwidth:                                    1000 Mbps
        Elapsed time in this state:                         00:00:13.000
        Transitions into degraded state:                            5000
        Hold-off:                                         111s remaining
      Last BNM received 00:00:10 ago
        Nominal Bandwidth:                                     1000 Mbps
        Current Bandwidth:                                     2000 Mbps
        Interval:                                                    10s
        Packet-type:                                        Cisco BW-VSM
      Packets received:                                            20000

    Port ID 7 (MAC Address 000c.000c.000c)
      State (DEGRADED):
        Nominal Bandwidth:                                     6000 Mbps
        Reported Bandwidth:                                    2000 Mbps
        Elapsed time in this state:                         00:00:39.000
        Transitions into degraded state:                           10000
        Wait-to-restore:                                  111s remaining
      Last BNM received 00:00:33 ago
        Nominal Bandwidth:                                     2000 Mbps
        Current Bandwidth:                                     4000 Mbps
        Interval:                                                   1min
        Packet-type:                                        Cisco BW-VSM
      Packets received:                                            40000

• Support for CFM over L2oMPLS with two-pass GRE tunnel isn't available.

• Y.1731 performance monitoring isn't available for this feature.

• Only select platform variants support this feature.

This section describes how to configure CFM over MPLS GRE tunnel, while also considering the following aspects:

• GRE tunnel is configured in a single-pass encapsulation mode.

• Policy Based Routing (PBR) decapsulation is used for single-pass GRE decapsulation.

• L2VPN “Control word” is supported along with the single-pass GRE tunnel.

• Single-pass PBR decapsulation configuration is used for GRE decapsulation.

RP/0/RP0/CPU0:ios#configure
RP/0/RP0/CPU0:ios(config)#class-map type traffic match-all test_gre1 
RP/0/RP0/CPU0:ios(config-cmap)#match protocol gre  
RP/0/RP0/CPU0:ios(config-cmap)#match source-address ipv4 198.51.100.101 255.255.255.0
RP/0/RP0/CPU0:ios(config-cmap)# end-class-map 
RP/0/RP0/CPU0:ios(config)#policy-map type pbr P1-test 
RP/0/RP0/CPU0:ios(config-pmap)#class type traffic test_gre1  
RP/0/RP0/CPU0:ios(config-pmap-c)#decapsulate gre 
RP/0/RP0/CPU0:ios(config-pmap-c)#exit 
RP/0/RP0/CPU0:ios(config-pmap)#class type traffic class-default  
RP/0/RP0/CPU0:ios(config-pmap-c)#exit
RP/0/RP0/CPU0:ios(config-pmap)#end-policy-map 
RP/0/RP0/CPU0:ios(config)#vrf-policy 
RP/0/RP0/CPU0:ios(config-vrf-policy)#vrf default address-family ipv4 policy type pbr input P1-test
RP/0/RP0/CPU0:ios(config-vrf-policy)#exit
RP/0/RP0/CPU0:ios(config)#interface Loopback0 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 198.51.100.100 255.255.255.0 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface Loopback11 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 10.11.11.11 255.0.0.0 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface Bundle-ether100 
RP/0/RP0/CPU0:ios(config-if)#interface Bundle-ether100.1 l2transport 
RP/0/RP0/CPU0:ios(config-subif)#encapsulation dot1q 1 
RP/0/RP0/CPU0:ios(config-subif)#ethernet cfm 
RP/0/RP0/CPU0:ios(config-if-cfm)#mep domain UP6 service s61 mep-id 1 
RP/0/RP0/CPU0:ios(config-if-cfm-mep)#exit
RP/0/RP0/CPU0:ios(config-if-cfm)#interface TenGigE0/0/0/16/0 
RP/0/RP0/CPU0:ios(config-if)#bundle id 100 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface TenGigE0/0/0/17/1 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 10.18.18.1 255.0.0.0 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface tunnel-ip100 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 198.51.100.111 255.255.255.0 
RP/0/RP0/CPU0:ios(config-if)#tunnel mode gre ipv4 encap 
RP/0/RP0/CPU0:ios(config-if)#tunnel source 198.51.100.100 
RP/0/RP0/CPU0:ios(config-if)#tunnel destination 198.51.100.101 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#router static 
RP/0/RP0/CPU0:ios(config-static)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-static-afi)#10.22.22.22/32 tunnel-ip100 
RP/0/RP0/CPU0:ios(config-static-afi)#exit
RP/0/RP0/CPU0:ios(config-static)#exit
RP/0/RP0/CPU0:ios(config)#router bgp 100 
RP/0/RP0/CPU0:ios(config-bgp)#nsr 
RP/0/RP0/CPU0:ios(config-bgp)#bgp router-id 198.51.100.100 
RP/0/RP0/CPU0:ios(config-bgp)#bgp graceful-restart 
RP/0/RP0/CPU0:ios(config-bgp)#bgp log neighbor changes detail 
RP/0/RP0/CPU0:ios(config-bgp)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-bgp-af)#maximum-paths ebgp 64 
RP/0/RP0/CPU0:ios(config-bgp-af)#neighbor 198.51.100.101 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#remote-as 300 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#ebgp-multihop 10 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#update-source Loopback0 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#next-hop-self 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#route-policy pass-all in 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#route-policy pass-all out 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#exit
RP/0/RP0/CPU0:ios(config-bgp-nbr)#exit
RP/0/RP0/CPU0:ios(config-bgp)#l2vpn 
RP/0/RP0/CPU0:ios(config-l2vpn)#pw-class controlword 
RP/0/RP0/CPU0:ios(config-l2vpn-pwc)#encapsulation mpls 
RP/0/RP0/CPU0:ios(config-l2vpn-pwc-mpls)#control-word 
RP/0/RP0/CPU0:ios(config-l2vpn-pwc-mpls)#exit
RP/0/RP0/CPU0:ios(config-l2vpn-pwc)#exit
RP/0/RP0/CPU0:ios(config-l2vpn)#xconnect group 1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc)#p2p 1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p)#interface Bundle-ether100.1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p)#neighbor ipv4 10.22.22.22 pw-id 1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p-pw)#mpls static label local 25011 remote 25022
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p-pw)#pw-class controlword 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p-pw)#exit
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p)#exit
RP/0/RP0/CPU0:ios(config-l2vpn-xc)#exit
RP/0/RP0/CPU0:ios(config-l2vpn)#exit
RP/0/RP0/CPU0:ios(config)#mpls static 
RP/0/RP0/CPU0:ios(config-mpls-static)#interface TenGigE0/0/0/17/1 
RP/0/RP0/CPU0:ios(config-mpls-static)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-mpls-static-af)#exit 
RP/0/RP0/CPU0:ios(config-mpls-static)#lsp v4_gre_mpls_1 
RP/0/RP0/CPU0:ios(config-mpls-static-lsp)#in-label 24022 allocate per-prefix 10.22.22.22/32
RP/0/RP0/CPU0:ios(config-mpls-static-lsp)#forward  
RP/0/RP0/CPU0:ios(config-mpls-static-lsp-fwd)#path 1 nexthop tunnel-ip100 out-label pop
RP/0/RP0/CPU0:ios(config-mpls-static-lsp-fwd)#exit
RP/0/RP0/CPU0:ios(config-mpls-static-lsp)#exit
RP/0/RP0/CPU0:ios(config-mpls-static)#exit
RP/0/RP0/CPU0:ios(config)#ethernet cfm 
RP/0/RP0/CPU0:ios(config-cfm)#domain UP6 level 6 id null 
RP/0/RP0/CPU0:ios(config-cfm-dmn)#service s6 xconnect group 1 p2p 1 id number 6
RP/0/RP0/CPU0:ios(config-cfm-dmn-svc)#continuity-check interval 100ms 
RP/0/RP0/CPU0:ios(config-cfm-dmn-svc)#mep crosscheck 
RP/0/RP0/CPU0:ios(config-cfm-xcheck)#mep-id 4001 
RP/0/RP0/CPU0:ios(config-cfm-xcheck)#exit
RP/0/RP0/CPU0:ios(config-cfm-dmn-svc)#end
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:yes

RP/0/RP0/CPU0:ios#configure
RP/0/RP0/CPU0:ios(config)#class-map type traffic match-all test_gre1 
RP/0/RP0/CPU0:ios(config-cmap)#match protocol gre  
RP/0/RP0/CPU0:ios(config-cmap)#match source-address ipv4 198.51.100.100 255.255.255.0
RP/0/RP0/CPU0:ios(config-cmap)# end-class-map 
RP/0/RP0/CPU0:ios(config)#policy-map type pbr P1-test 
RP/0/RP0/CPU0:ios(config-pmap)#class type traffic test_gre1  
RP/0/RP0/CPU0:ios(config-pmap-c)#decapsulate gre 
RP/0/RP0/CPU0:ios(config-pmap-c)#exit 
RP/0/RP0/CPU0:ios(config-pmap)#class type traffic class-default  
RP/0/RP0/CPU0:ios(config-pmap-c)#exit
RP/0/RP0/CPU0:ios(config-pmap)#end-policy-map 
RP/0/RP0/CPU0:ios(config)#vrf-policy 
RP/0/RP0/CPU0:ios(config-vrf-policy)#vrf default address-family ipv4 policy type pbr input P1-test
RP/0/RP0/CPU0:ios(config-vrf-policy)#exit
RP/0/RP0/CPU0:ios(config)#interface Loopback0 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 198.51.100.101 255.255.255.0 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface Loopback22 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 10.22.22.22 255.255.255.255 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface tunnel-ip100 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 198.51.100.112 255.255.255.0 
RP/0/RP0/CPU0:ios(config-if)#tunnel mode gre ipv4 encap 
RP/0/RP0/CPU0:ios(config-if)#tunnel source 198.51.100.101 
RP/0/RP0/CPU0:ios(config-if)#tunnel destination 198.51.100.100 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface TenGigE0/0/0/24 
RP/0/RP0/CPU0:ios(config-if)#ipv4 address 10.18.18.2 255.0.0.0 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#interface Bundle-ether100 
RP/0/RP0/CPU0:ios(config-if)#interface Bundle-ether100.1 l2transport 
RP/0/RP0/CPU0:ios(config-subif)#encapsulation dot1q 1 
RP/0/RP0/CPU0:ios(config-subif)#ethernet cfm 
RP/0/RP0/CPU0:ios(config-if-cfm)#mep domain UP6 service s6 mep-id 4001 
RP/0/RP0/CPU0:ios(config-if-cfm-mep)#exit
RP/0/RP0/CPU0:ios(config-if-cfm)#interface TenGigE0/0/0/26 
RP/0/RP0/CPU0:ios(config-if)#bundle id 100 
RP/0/RP0/CPU0:ios(config-if)#exit
RP/0/RP0/CPU0:ios(config)#router static 
RP/0/RP0/CPU0:ios(config-static)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-static-afi)#10.10.10.11/32 tunnel-ip100 
RP/0/RP0/CPU0:ios(config-static-afi)#exit
RP/0/RP0/CPU0:ios(config-static)#exit
RP/0/RP0/CPU0:ios(config)#router bgp 300 
RP/0/RP0/CPU0:ios(config-bgp)#nsr 
RP/0/RP0/CPU0:ios(config-bgp)#bgp router-id 198.51.100.101 
RP/0/RP0/CPU0:ios(config-bgp)#bgp graceful-restart 
RP/0/RP0/CPU0:ios(config-bgp)#bgp log neighbor changes detail 
RP/0/RP0/CPU0:ios(config-bgp)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-bgp-af)#maximum-paths ebgp 64 
RP/0/RP0/CPU0:ios(config-bgp-af)#neighbor 198.51.100.100 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#remote-as 100 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#ebgp-multihop 10 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#update-source Loopback0 
RP/0/RP0/CPU0:ios(config-bgp-nbr)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#next-hop-self 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#route-policy pass-all in 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#route-policy pass-all out 
RP/0/RP0/CPU0:ios(config-bgp-nbr-af)#exit
RP/0/RP0/CPU0:ios(config-bgp-nbr)#exit
RP/0/RP0/CPU0:ios(config-bgp)#l2vpn 
RP/0/RP0/CPU0:ios(config-l2vpn)#pw-class controlword 
RP/0/RP0/CPU0:ios(config-l2vpn-pwc)#encapsulation mpls 
RP/0/RP0/CPU0:ios(config-l2vpn-pwc-mpls)#control-word 
RP/0/RP0/CPU0:ios(config-l2vpn-pwc-mpls)#exit
RP/0/RP0/CPU0:ios(config-l2vpn-pwc)#exit
RP/0/RP0/CPU0:ios(config-l2vpn)#xconnect group 1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc)#p2p 1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p)#interface bundle-ether100.1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p)#neighbor ipv4 10.10.10.11 pw-id 1 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p-pw)#mpls static label local 25022 remote 25011
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p-pw)#pw-class controlword 
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p-pw)#exit
RP/0/RP0/CPU0:ios(config-l2vpn-xc-p2p)#exit
RP/0/RP0/CPU0:ios(config-l2vpn-xc)#exit
RP/0/RP0/CPU0:ios(config-l2vpn)#exit
RP/0/RP0/CPU0:ios(config)#ethernet cfm 
RP/0/RP0/CPU0:ios(config-cfm)#domain UP6 level 6 id null 
RP/0/RP0/CPU0:ios(config-cfm-dmn)#service s6 xconnect group 1 p2p 1 id number 6
RP/0/RP0/CPU0:ios(config-cfm-dmn-svc)#continuity-check interval 100ms 
RP/0/RP0/CPU0:ios(config-cfm-dmn-svc)#mep crosscheck 
RP/0/RP0/CPU0:ios(config-cfm-xcheck)#mep-id 1 
RP/0/RP0/CPU0:ios(config-cfm-xcheck)#exit
RP/0/RP0/CPU0:ios(config-cfm)#exit
RP/0/RP0/CPU0:ios(config)#mpls static 
RP/0/RP0/CPU0:ios(config-mpls-static)#interface TenGigE0/0/0/24 
RP/0/RP0/CPU0:ios(config-mpls-static)#address-family ipv4 unicast 
RP/0/RP0/CPU0:ios(config-mpls-static-af)#exit 
RP/0/RP0/CPU0:ios(config-mpls-static)#lsp v4_gre_mpls_1 
RP/0/RP0/CPU0:ios(config-mpls-static-lsp)#in-label 24011 allocate per-prefix 10.10.10.11/32
RP/0/RP0/CPU0:ios(config-mpls-static-lsp)#forward  
RP/0/RP0/CPU0:ios(config-mpls-static-lsp-fwd)#path 1 nexthop tunnel-ip100 out-label pop
RP/0/RP0/CPU0:ios(config-mpls-static-lsp-fwd)#exit
RP/0/RP0/CPU0:ios(config-mpls-static-lsp)#exit
RP/0/RP0/CPU0:ios(config-mpls-static)#exit
RP/0/RP0/CPU0:ios(config-mpls)#end
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:yes

class-map type traffic match-all test_gre1
 match protocol gre 
 match source-address ipv4 198.51.100.101 255.255.255.0
 end-class-map
! 
policy-map type pbr P1-test
 class type traffic test_gre1 
  decapsulate gre
 ! 
 class type traffic class-default 
 ! 
 end-policy-map
!
vrf-policy
 vrf default address-family ipv4 policy type pbr input P1-test
!
interface Loopback0
 ipv4 address 198.51.100.100 255.255.255.0
!
interface Loopback11
 ipv4 address 10.11.11.11 255.0.0.0
!
interface Bundle-ether100
interface Bundle-ether100.1 l2transport
 encapsulation dot1q 1
 ethernet cfm
  mep domain UP6 service s61 mep-id 1
!
interface TenGigE0/0/0/16/0
 bundle id 100
!
interface TenGigE0/0/0/17/1
 ipv4 address 10.18.18.1 255.0.0.0
!
interface tunnel-ip100
 ipv4 address 198.51.100.111 255.255.255.0
 tunnel mode gre ipv4 encap
 tunnel source 198.51.100.100
 tunnel destination 198.51.100.101
!
router static
 address-family ipv4 unicast
  10.22.22.22/32 tunnel-ip100
 !
!
router bgp 100
 nsr
 bgp router-id 198.51.100.100
 bgp graceful-restart
 bgp log neighbor changes detail
 address-family ipv4 unicast
   maximum-paths ebgp 64
 neighbor 198.51.100.101
   remote-as 300
   ebgp-multihop 10
   update-source Loopback0
   address-family ipv4 unicast
    next-hop-self
   route-policy pass-all in
   route-policy pass-all out
  !
!
l2vpn
  pw-class controlword
    encapsulation mpls
     control-word
    !
 !
 xconnect group 1
  p2p 1
   interface Bundle-ether100.1
   neighbor ipv4 10.22.22.22 pw-id 1
    mpls static label local 25011 remote 25022
    pw-class controlword
   !
  !
 !
!
mpls static
 interface TenGigE0/0/0/17/1
 address-family ipv4 unicast
 !
  lsp v4_gre_mpls_1
  in-label 24022 allocate per-prefix 10.22.22.22/32
  forward 
   path 1 nexthop tunnel-ip100 out-label pop
  !
 !
!
ethernet cfm
domain UP6 level 6 id null
  service s6 xconnect group 1 p2p 1 id number 6
   continuity-check interval 100ms
   mep crosscheck
    mep-id 4001
!

 class-map type traffic match-all test_gre1
 match protocol gre 
 match source-address ipv4 198.51.100.100 255.255.255.0
 end-class-map
! 
policy-map type pbr P1-test
 class type traffic test_gre1 
  decapsulate gre
 ! 
 class type traffic class-default 
 ! 
 end-policy-map
!
vrf-policy
 vrf default address-family ipv4 policy type pbr input P1-test
!
interface Loopback0
 ipv4 address 198.51.100.101 255.255.255.0
!
interface Loopback22
 ipv4 address 10.22.22.22 255.255.255.255
!
interface tunnel-ip100
 ipv4 address 198.51.100.112 255.255.255.0
 tunnel mode gre ipv4 encap
 tunnel source 198.51.100.101
 tunnel destination 198.51.100.100
!
interface TenGigE0/0/0/24
 ipv4 address 10.18.18.2 255.0.0.0
!
!
interface Bundle-ether100
!
interface Bundle-ether100.1 l2transport
 encapsulation dot1q 1
 ethernet cfm
  mep domain UP6 service s6 mep-id 4001
!
interface TenGigE0/0/0/26
bundle id 100
!
router static
 address-family ipv4 unicast
  10.10.10.11/32 tunnel-ip100
 !
!
router bgp 300
 nsr
 bgp router-id 198.51.100.101
 bgp graceful-restart
 bgp log neighbor changes detail
 address-family ipv4 unicast
  maximum-paths ebgp 64
 neighbor 198.51.100.100
  remote-as 100
  ebgp-multihop 10
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
   route-policy pass-all in
   route-policy pass-all out
  !
!
l2vpn
  pw-class controlword
    encapsulation mpls
     control-word
    !
 !
 xconnect group 1
  p2p 1
   interface bundle-ether100.1
   neighbor ipv4 10.10.10.11 pw-id 1
    mpls static label local 25022 remote 25011
    pw-class controlword
!
ethernet cfm
domain UP6 level 6 id null
  service s6 xconnect group 1 p2p 1 id number 6
   continuity-check interval 100ms
   mep crosscheck
    mep-id 1
!
mpls static
 interface TenGigE0/0/0/24
  address-family ipv4 unicast
 !
 lsp v4_gre_mpls_1
  in-label 24011 allocate per-prefix 10.10.10.11/32
  forward
   path 1 nexthop tunnel-ip100 out-label pop
  !
!

RP/0/RP0/CPU0:ios#show ethernet cfm peer meps | utility more 
Wed Jan 10 13:38:27.713 UTC
Flags:
> - Ok                          I - Wrong interval
R - Remote Defect received      V - Wrong level
L - Loop (our MAC received)     T - Timed out
C - Config (our ID received)    M - Missing (cross-check)
X - Cross-connect (wrong MAID)  U - Unexpected (cross-check)
* - Multiple errors received    S - Standby
 
Domain sp (level 3), Service s1
Up MEP on Bundle-Ether191.1 MEP-ID 1
================================================================================
St    ID MAC Address    Port    Up/Downtime   CcmRcvd SeqErr   RDI Error
-- ----- -------------- ------- ----------- --------- ------ ----- -----
>  5001 008a.968d.54db Up      02:56:38       106011      0     1     0

RP/0/RP0/CPU0:ios#show ethernet cfm local meps interface Bundle-Ether191.1 verbose 
Wed Jan 10 13:39:17.994 UTC
Domain sp (level 3), Service s1
Up MEP on Bundle-Ether191.1 MEP-ID 1
================================================================================
  Interface state: Up      MAC address: fcbc.cec4.e48a
  Peer MEPs: 1 up, 0 with errors, 0 timed out (archived)
  Cross-check errors: 0 missing, 0 unexpected
 
  CCM generation enabled:  Yes, 100ms (Remote Defect detected: No)
                           CCM processing offloaded to software
  AIS generation enabled:  Yes (level: 5, interval: 1s)
  Sending AIS:             No
  Receiving AIS:           No
  Sending CSF:             No
  Receiving CSF:           No
 
  Packet        Sent      Received
  ------  ----------  ---------------------------------------------------------
  CCM         106571        106514  (out of seq: 0)
  AIS              7             0

RP/0/RP0/CPU0:ios#show ethernet cfm summary 
Wed Jan 10 13:40:43.106 UTC
 
CFM System Summary
==================
 
Domains                                   2
Services                               1600
Total CCM rate (pps)                 305000
Local Meps                             1500
  Operational                          1500
    Down MEPs                             0
    Up MEPs                            1500
    Offloaded                          1500
      3.3ms                            1000
      10ms                                0
      100ms or greater                  500
  Disabled (misconfiguration)             0
  Disabled (resource limit)               0
  Disabled (operational error)            0
Peer MEPs                              1500
  Operational                          1500
    Defect detected                       0
    No defect detected                 1500
  Timed out                               0
MIPs                                    100
Interfaces                             1500
Bridge domains/Xconnects               1500
Traceroute cache entries                  0
Traceroute cache replies                  0
CCM Learning database entries          1500
BNM Enabled Links                         0
 
CFM Summary for 0/3/CPU0
========================
 
Domains                                   2
Services                               1600
Total CCM rate (pps)                      0
Local Meps                                0
  Operational                             0
    Down MEPs                             0
    Up MEPs                               0
    Offloaded                             0
      3.3ms                               0
      10ms                                0
      100ms or greater                    0
  Disabled (misconfiguration)             0
  Disabled (resource limit)               0
  Disabled (operational error)            0
Peer MEPs                                 0
  Operational                             0
    Defect detected                       0
    No defect detected                    0
  Timed out                               0
MIPs                                      0
Interfaces                                0
Bridge domains/Xconnects               1500
Traceroute cache entries                  0
Traceroute cache replies                  0
CCM Learning database entries             0
BNM Enabled Links                         0
ISSU Role                           Primary
 
CFM Summary for 0/7/CPU0
========================
 
Domains                                   2
Services                               1600
Total CCM rate (pps)                 300000
Local Meps                             1000
  Operational                          1000
    Down MEPs                             0
    Up MEPs                            1000
    Offloaded                          1000
      3.3ms                            1000
      10ms                                0
      100ms or greater                    0
  Disabled (misconfiguration)             0
  Disabled (resource limit)               0
  Disabled (operational error)            0
Peer MEPs                              1000
  Operational                          1000
    Defect detected                       0
    No defect detected                 1000
  Timed out                               0
MIPs                                      0
Interfaces                             1000
Bridge domains/Xconnects               1500
Traceroute cache entries                  0
Traceroute cache replies                  0
CCM Learning database entries          1000
BNM Enabled Links                         0
ISSU Role                           Primary
 
CFM Summary for 0/RP0/CPU0
==========================
 
Domains                                   2
Services                               1600
Total CCM rate (pps)                   5000
Local Meps                              500
  Operational                           500
    Down MEPs                             0
    Up MEPs                             500
    Offloaded                           500
      3.3ms                               0
      10ms                                0
      100ms or greater                  500
  Disabled (misconfiguration)             0
  Disabled (resource limit)               0
  Disabled (operational error)            0
Peer MEPs                               500
  Operational                           500
    Defect detected                       0
    No defect detected                  500
  Timed out                               0
MIPs                                    100
Interfaces                              500
Bridge domains/Xconnects                500
Traceroute cache entries                  0
Traceroute cache replies                  0
CCM Learning database entries           500
BNM Enabled Links                         0
ISSU Role                           Primary

RP/0/RP0/CPU0:ios#ping ethernet cfm domain sp service s1 mep-id 5001 source interface Bundle-Ether191.1
Wed Jan 10 13:41:59.562 UTC
Type escape sequence to abort.
Sending 5 CFM Loopbacks, timeout is 2 seconds -
Domain sp (level 3), Service s1
Source: MEP ID 1, interface Bundle-Ether191.1
Target: 008a.968d.54db (MEP ID 5001):
  Running (5s) ...
Success rate is 100.0 percent (5/5), round-trip min/avg/max = 1/1/3 ms
Out-of-sequence: 0.0 percent (0/5)
Bad data: 0.0 percent (0/5)
Received packet rate: 1.3 pps
 
RP/0/RP0/CPU0:ios#traceroute ethernet cfm domain sp service s1 mep-id 5001 source interface Bundle-Ether191.1
Wed Jan 10 13:42:13.129 UTC
Type escape sequence to return to prompt.
 
Traceroutes in domain sp (level 3), service s1
Source: MEP-ID 1, interface Bundle-Ether191.1
================================================================================
Traceroute at 2024-01-10 13:42:13 to 008a.968d.54db,
TTL 64, Trans ID 677741245:
 
  Running (7s) ...
 
Hop Hostname/Last            Ingress MAC/name       Egress MAC/Name            Relay
--- ------------------------ ---------------------- ---------------------- ----------
  1 R1-5508                  fcbc.cec4.e48a [Ok]     FDB 0000-fcbc.cec4.e48a   BE191.1                                            
  2 R3                       008a.968d.54db [Ok]     Hit R1-5508               BE391.1                MEP  
Replies dropped: 0

Use the Ethernet frame delay measurement to measure frame delay and frame delay variations. The system measures the Ethernet frame delay by using the Delay Measurement Message (DMM) method.

The loss measurement mechanism defined in Y.1731 can only be used in point-to-point networks, and only works when there is sufficient flow of data traffic. The difficulties with the Y.1731 loss measurement mechanism were recognized across the industry and hence an alternative mechanism has been defined and standardized for measuring loss of traffic.

This alternative mechanism does not measure the loss of the actual data traffic, but instead injects synthetic CFM frames and measures the loss of these synthetic frames. You can perform a statistical analysis to give an approximation of the loss of data traffic. This technique is called Synthetic Loss Measurement (SLM). SLM has been included in the latest version of the Y.1731 standard. Use SLA to perform the following measurements:

• One-way loss (Source to Destination)

• One-way loss (Destination to Source)

SLM supports the following:

• All Layer 2 transport interfaces, such as physical, bundle interfaces, Layer2 sub-interfaces, pseudowire Head-end interfaces or attachment circuits.

• Up and Down MEPs.

• Transparent passing of the SLM packets through the MIP without punting it to the software.

• 1000 pps of SLM/SLR traffic.

• LLF isn't permitted on sub-interfaces.

• LLF is only permitted on up MEPs.

• LLF is not supported on LACP bundle.

• The system runs a damping timer to govern transitions from an interface being TX-disabled to an interface being TX-enabled. The following restrictions apply on such a scenario:

  • The period of the damping timer is given by three times the configured CCM interval. However, you can't configure the damping timer.

  • The system doesn't provide damping for transitions from TX-enabled to TX-disabled.