Information About Latching Loopback
Feature Name |
Release Information |
Feature Description |
---|---|---|
Latching Loopback |
Cisco IOS XE Cupertino 17.8.1 |
Latching Loopbacks (LLs) are used for Service Activation Testing (SAT) and troubleshooting the information rate for point-to-point and multipoint services across multiple Carrier Ethernet Networks (CENs). Thus, eliminate the need for a peer to interoperate with the Service Provider for SAT. You can configure latching loopback on an interface. Latching loopback supports the following features on RSP3 module:
|
Latching Loopbacks (LLs) are used for Service Activation Testing (SAT) and troubleshooting up to the information rate for point-to-point and multipoint services across multiple Carrier Ethernet Networks (CENs). The Ethernet Test Head in the Service Provider’s network initiates the Latching Loopback in the Access Provider’s NID and then perform end-to-end testing based on IETF RFC-2544 (9), ITU Y.1564 (10), or SAT (MEF 46). The Latching Loopback eliminates the need for peer to interoperate with the Service Provider for SAT.
The Latching Loopback Function (LLF) is deployed in the UNI and ENNI locations in various Carrier Ethernet equipments such as Network Interface Devices (NIDs), bridges, switches, and Ethernet Test Equipment (ETE). The Ethernet Equipment that implements the Latching Loopback Function is referred as a Latching Loopback Device (LLD).
The Latching Loopback Controller that provides an inline control of the Latching Loopback State Machine (LLSM) initiates latching loopback to a Latching Loopback Responder, and supplies the Ethernet frames to be looped back by the Latching Loopback Responder.
The Latching Loopback Responder executes latching loopback at an External Interface (EI) in a Latching Loopback Function (LLF), at the boundary between a CEN and an External Network.
The Latching Loopback is used within a system that consists of the Ethernet Test Equipment (ETE) that acts as a Latching Loopback Controller; the CEN that forwards the Latching Loopback Messages (LLMs), the Latching Loopback Replies (LLRs), and the Ethernet frames that are looped back; and the Network Element (NE) or ETE acting as a Latching Loopback Responder that incorporates the EI with an LLF.
The controller node sends LLM and the responder node sends LLR.
Latching Loopback Support (per MEF 46) for RSP3
Latching Loopback Directions
The Latching Loopback supports two directions for a port; the internal loopbacks and the external loopbacks for a port.
In both directions, the LLSM uses an LLF within the LLD implementing the port being looped back. The Loopback Activate messages received through an Up MEP correspond to internal loopbacks and the messages received through a Down MEP correspond to external loopbacks. The messages received at a MIP correspond to either an internal or external loopback depending on which direction the activate messages are received.
The Latching loopback direction depends on the MEP direction:
-
UP—MEP refers to the Internal direction
-
Down—MEP refers to the External direction
The LLSM is associated with a single MEP only and can activate the corresponding direction of loopback alone.
The controller should be MEP and the responder may be an MEP or MIP.
Latching Loopback State
The LLSM has three states:
-
Latching Loopback Prohibited—Loopbacks are prohibited by an administrative action. LLMs addressed to a specific LLSM are discarded.
-
Latching Loopback Inactive—Loopbacks are permitted, but there is no loopback request currently active.
-
Latching Loopback Active—The loopback is currently active.
Restrictions for Latching Loopback
-
Latching loopback is supported only on the RSP2 module.
Starting with the Cisco IOS XE Cupertino 17.8.1 release latching loopback is supported on the RSP3 module.
-
Latching loopback is not supported for LAG interface.
-
802.1ad is not supported in latching loopback.
-
Latching loopback is not supported on the Trunk EFP.
-
The latching loopback should be applied for each interface or EFP.
-
While configuring the latching loopback, the interface should be in the administrative UP state for UP-MEP sessions.
-
The second dot1q filter double tag encapsulation option is not supported as ACL TCAM entries does not have option to store the second VLAN. If the second VLAN is configured in latching loopback, then the existing ELB is configured instead of latching loopback.
-
ACL is not supported on an EFP when latching loopback is active.
-
Only Ethernet frames are used as loopable frames for facility loopback as L2 ACLs are used to support latching loopback behavior.
-
The destination MAC address can be unicast, multicast, or broadcast address whereas the source MAC address should be the interface MAC address where the latching loopback is configured. The source MAC address cannot be replaced with any other MAC address.
-
Frames with the looping source MAC address and VLAN coming from the opposite direction to the request are forwarded and not discarded, whereas MEF 46 expects frames with same Source MAC and VLAN coming from opposite direction to be discarded. This behavior is similar to existing Ethernet data plane Loopback.
-
The normal MIP cannot be configured at ingress port of responder interface, however, if the MIP is configured as a responder at the ingress port, then you can configure the normal MIP as the egress port.
-
If both the MIP and MEP are configured as responder in the MA and send LLR back to controller, then the MEP takes precedence and becomes a responder since it is at the endpoint of the MA. To configure MIP to be a responder, you must remove responder configuration from the MEP.
-
The latching loopback can be verified only on SADT packets with ethertype of 0XFFFF. The latching loopback cannot be verified for IXIA traffic packets.
-
In latching loopback, IPSLA for untagged and default EFP delay and jitter is not supported, since the values for delay and jitter are in milliseconds.
Restrictions for Latching Loopback on RSP3 Module
-
A total number of 16 latching loopback sessions are supported per router, in which 8 can be terminal and 8 can be facility sessions.
-
The latching loopback sessions can be on the same or different interfaces.
-
One latching loopback session per EFP is supported. The port-based LLB is not supported.
-
The LLB is applicable to all VLANs configured in EFP. Filtering based on specific VLAN is not supported.
-
Latching loopback on routed port infrastructure is not supported.
-
IP packets are looped back with MAC swap but RSP3 does not support IP swap. If packet comes with source MAC address and destination IP address same as BDI MAC and IP address, then the packet is punted and is not looped back. If any Layer 3 packet to be routed, then this packet is looped back.
-
Ethertype, source MAC address, VLAN, COS, and llc-oui-based loopback traffic filtering are not supported.
-
Latching Loopback sessions cannot be initiated on a port that is configured with SPAN or RSPAN.
-
Data filtering for the traffic coming in the opposite direction of loopback is not enforced.
-
In TEFP, if BDI is configured, traffic with VLAN, which is a part of BDI, is not looped back. Any other traffic for TEFP, which is not part of BDI, is looped back based on filters. This limitation is applicable for both types of LLB.
-
Latching loopback and ELB are supported only on the same EFP.
-
In facility latching loopback, port shaper cannot be bypassed.
-
Facility and terminal LLB are not supported on DOT1ad NNI interface.
-
When the service name is in the number format, then ensure that you configure the ID as null, for example:
ethernet cfm domain ninil level 0 id null service number 1234 evc green1 vlan 102 direction down
-
For an offload session, the domain name should be of only a five-character limit.
-
The latching loopback session ID starts from 33 as the IDs ranging 1–32 are already reserved for ELB.