SAPs and MPLS SDP bindings within Ethernet services, Epipe, and VPLS can be placed into a loopback mode, which allows all packets that arrive on the looped entity to be reflected back into the service. The feature is specific to the entity on which the loopback is configured and is non-disruptive to other SAPs and SDP bindings on the same port or LAG.
Epipe, PBB Epipe, VPLS, and I-VPLS service constructs support both ingress and egress loopbacks on Ethernet SAPs or MPLS SDP bindings.
An ingress loopback configured on the entity has the following effects on traffic forwarding on the entity:
-
Traffic arriving on the entity is looped back to the same entity, via the fabric.
-
Traffic attempting to egress that entity from another SAP or SDP binding within the service is blocked.
Essentially an ingress loopback function isolates the SAP or MPLS SDP binding from the rest of the service. Figure: Ingress loopback packet processing uses a simple Epipe service example to show the various touch points for a packet that is processed by an ingress loopback as it moves through the network element.
.png)
An egress loopback configured on the entity has the following effects on the traffic forwarding on the entity:
-
Traffic arriving on any service SAP or SDP binding that is forwarded to an egress loopback is looped back into the service.
-
Traffic attempting to gain access to the service from that entity (ingress the network element from the entity) is dropped.
In the case of the egress loopback, the SAP or MPLS SDP binding is not isolated from the rest of the service it remains part of the service and reflects traffic back into the service.
Figure: Egress loopback packet processing uses a simple Epipe service to illustrate the various touch points for a packet that is processed by an egress loopback as it moves through the network element. Egress processing does not perform queuing functions on the egress; only functions of the forwarding plane like remarking are performed.
The operational state of the SAP or MPLS SDP binding does not change as a result of the loopback function. This means a SAP or MPLS SDP binding that is operationally up does not change state strictly because the loopback started or stopped. Of course control protocols that are attempting to gain access via the entity that is not allowing packets to enter the service eventually time out.
Exercise caution when considering the use of control protocols in a service with enabled loopbacks. The operator must understand that control protocol interruptions can significantly impact the state of the SAP. When SAPs are dynamically created using a protocol or a protocol is required to maintain the operational state of the SAP, interrupting the control protocol causes the SAP to fail. Other SAPs linking their state to a failed SAP react to that failure as well. This loopback function is per Ethernet SAP or MPLS SDP binding. That is, all traffic that is extracted and sent to the CPM before the loopback process is looped back in the direction it was received, or in the case of VPLS, back into the service. All service based control protocols that are included with this service should be removed to ensure the loopback process is handling the packets and not some other function on the node that can extract the control protocol but never respond because the service is blocked. However, there may be instances where it is essential to continue running control protocols for the service during a loopback. For example, Down MEPs on an Ethernet SAP could continue to process ETH-CFM packets if the loopback is on the mate Ethernet SAP and was configured as an egress loopback.
By default, no MAC swap functions are performed. Options are available to support various MAC swap functions. Table: MAC-Swap configuration and options lists the actions and functions based on the configured mac-swap and associated options.
| Configuration | Reflection with inbound DA | ||||
|---|---|---|---|---|---|
| Action | Options | Unicast (learned) | Unicast (unknown) | Broadcast | Multicast |
|
mac-swap |
no options |
Swap SA to DA Swap DA to SA |
Swap SA to DA Swap DA to SA |
Drop |
Drop |
|
mac-swap |
mac |
Swap SA to DA Swap DA to SA |
Swap SA to DA Swap DA to SA |
Swap SA to DA Static MAC= SA |
Swap SA to DA Static MAC= SA |
|
mac-swap |
mac + all |
Swap SA to DA Static MAC= SA |
Swap SA to DA Static MAC= SA |
Swap SA to DA Static MAC= SA |
Swap SA to DA Static MAC= SA |
|
none |
none |
No swapping |
No swapping |
No swapping |
No swapping |
Only the outer Layer 2 header can be manipulated.
In order for the loopback function to operate, the service must be operationally up, and the SAP, port, or LAG must be administratively up. In the case of a LAG, the LAG must have member ports that are administratively up. If any of these conditions are not met, the loopback function fails.
A SAP that is configured for egress loopback is not required to be operationally up, and the cabling does not need to be connected to the port. However, all necessary hardware must be installed in the network element for the ingress packets to be routed to the egress. Ghost ports do not support loopback operations.
An Epipe service enters an operationally down state when one of the SAPs is non-operational. The service state remains or is returned to an operational state if the ignore-oper-down command is configured under the non-operational SAP. A VPLS service remains operational as long as one SAP in the service is operational. However, if the SAP is a VPLS is configured over a LAG, the SAP is removed from the forwarding table if it has a non-operational state, and, consequently, packets never reach the egress. The process-cpm-traffic-on-sap-down command can be configured under the VPLS SAP over a LAG to allow the LAG SAP to be reached even with a non-operational SAP.
If the service state is not operational or the egress SAP is not reachable via the forwarding plane, the traffic never arrives on the SAP to be looped.
MPLS SDP bindings must be operationally up or the loopback function fails.
Use the tools hierarchy to configure this functionality. In this specific case, the loopback tools supporting this functionality may be configured through CLI or through SNMP. However, these commands are never resident in the configuration. This means the loopback survives high availability events that cause one CPM to change from standby to active, as well as ISSU function or IOM resets (hard or soft). However the loopback function does not survive a complete node reboot.
In the case on SNMP, it is possible to configure a static MAC address for the MAC swap function without actually invoking the MAC swap. This is not possible through the CLI.
This function requires a minimum of IOM/IMM.
This feature and functions that use mirroring are mutually exclusive.
Figure: Active loopback mode shows of sap 1/1/10:2.2 in service id 2 (an Epipe) in an active loopback mode with a MAC swap for all broadcast and multicast destined packets.
The following is an example output of the active loopback mode based on Figure: Active loopback mode.
show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 2 Vpn Id : 0
Service Type : Epipe
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 1 Creation Origin : manual
Last Status Change: 07/08/2013 09:57:02
Last Mgmt Change : 07/08/2013 09:56:49
Admin State : Up Oper State : Up
MTU : 1514
Vc Switching : False
SAP Count : 2 SDP Bind Count : 0
Per Svc Hashing : Disabled
Force QTag Fwd : Disabled
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/2:2.2 qinq 1522 1522 Up Up
sap:1/1/10:2.2 qinq 1522 1522 Up Up
===============================================================================
tools perform service id 2 loopback eth sap 1/1/10:2.2 start ingress mac-swap mac
00:00:00:00:00:88 00:00:00:00:00:88
tools dump service loopback
===============================================================================
Service Ethernet Loopback Points
===============================================================================
Identifier Svc ID Type Swap Swap Oper
Unicast Mlt/Br
-------------------------------------------------------------------------------
SAP 1/1/10:2.2 qinq 2 ingr SA<->DA static up
-------------------------------------------------------------------------------
No. of Service ethernet loopback points: 1
===============================================================================
tools dump service id 2 loopback sap 1/1/10:2.2
===============================================================================
Service ID 2 SAP 1/1/10:2.2 Loopback
===============================================================================
Identifier (SAP) : 1/1/10:2.2 qinq
Service ID : 2
Type : Ingress
MAC Swap
Unicast : SA<->DA
Multicast/Broadcast : Static
Static MAC : 00:00:00:00:00:88
SAP Oper State : Up
-------------------------------------------------------------------------------
Sap Statistics
-------------------------------------------------------------------------------
Last Cleared Time : N/A
Packets Octets
CPM Ingress : 491790 46721290
Forwarding Engine Stats
Dropped : 0 0
Off. HiPrio : 0 0
Off. LowPrio : 0 0
Off. Uncolor : 0 0
Off. Managed : 0 0
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio : 0 0
Dro. LowPrio : 0 0
For. InProf : 0 0
For. OutProf : 0 0
Queueing Stats(Egress QoS Policy 1)
Dro. InProf : 0 0
Dro. OutProf : 0 0
For. InProf : 0 0
For. OutProf : 0 0
-------------------------------------------------------------------------------
===============================================================================
To stop the loopback, a simple stop command is required.
tools perform service id 2 loopback eth sap 1/1/10:2.2 stop