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.