Considerations for SLX 9150, SLX 9250, Extreme 8520, and Extreme 8720

Keep the following things in mind when configuring SPAN/RSPAN/ERSPAN on SLX 9150, SLX 9250, Extreme 8520, and Extreme 8720 devices.

  • The devices support four hardware SPAN sessions.
    • One unique SPAN destination in the session configuration consumes one hardware SPAN session.
    • Two hardware SPAN sessions are reserved for ACL logging and SPAN sessions created using the legacy acl-mirror command.
    • Therefore, you can configure two different destinations for port mirroring. If you try to configure mirror sessions with more than two different destination ports, the configuration fails and generates a RASLog message. You have to manually remove the failed configuration.
    • The application telemetry feature consumes one hardware SPAN session. If you configure application telemetry, you can configure only one monitor session with a unique destination or multiple monitor sessions that share the same SPAN destination.
  • CPU-generated frames that do not enter the ingress pipeline of the ASIC cannot be mirrored by an egress SPAN session (an egress SPAN session is enabled on the interface from which the CPU-generated frame egresses). Egress SPAN occurs primarily in the ingress pipeline at the Memory Management Unit (MMU) stage of the ASIC pipeline. For example, a ping that is generated from the device and egresses on a physical Layer 3-routed port does not enter the ingress pipeline. The ping cannot be mirrored by an egress SPAN session.
  • The platforms do not support true egress mirroring. If incoming packets are modified and sent to egress ports, some fields, such as VLAN and TTL, in the mirrored captured frames are not identical to the egress frame.
  • Because egress SPAN occurs primarily at the MMU stage (which is the last stage of the ingress pipeline of the ASIC), mirrored copy is the same as the packet content seen at this stage. Any VLAN modifications that occurred before this stage are reflected in the mirror copy. However, the original packet can have modifications farther in the egress pipeline and those modifications are not reflected in the mirrored copy.
  • Because egress SPAN occurs in the ingress pipeline, the mirroring engine may replicate the egress packets even though the original egress packets could be dropped at later stage. This replication has various causes, such as the source suppression of unknown unicast, broadcast traffic. Source suppression drops unknown traffic before it is transmitted out of the ingress port. However, the replication engine replicates the traffic when the same ingress port is configured as a SPAN source with an egress direction. Therefore, there may not be actual egress frames on the SPAN source interface.
  • Flow based egress mirroring is not supported for SPAN, RSPAN, and ERSPAN.
These are the limitations for ERSPAN Type 3 Mirroring.
  • For ingress mirroring, copying of VLAN and COS field from original frame to ERSPAN type3 header of mirrored copy is not supported for flow based ERSPAN. It is not supported for Port based ERSPAN and is a hardware limitation.
  • For ingress mirroring, if ERSPAN DST IP is reachable through a router port, ERSPAN mirroring will not work.
  • Egress mirroring for ERSPAN is not supported due to hardware limitations.