The Switched Port Analyzer (SPAN) feature (sometimes called port mirroring or port monitoring) selects network traffic for analysis by a network analyzer. The network analyzer can be a Cisco SwitchProbe or other Remote Monitoring (RMON) probes.

The SPAN with ACL filtering feature allows you to filter SPAN traffic so that you can reduce bandwidth congestion. To configure SPAN with ACL filtering, you use ACL’s for the session to filter out traffic that you do not want to span. An ACL is a list of permissions associated to any entity in the system; in the context of a monitoring session, an ACL is a list of rules which results in spanning only the traffic that matches the ACL criteria, saving bandwidth for more meaningful data. The filter can apply to all sources in the session.

The SPAN-on-drop feature enables the spanning of packets which would normally be dropped due to unavailable buffer or queue space on ingress. Instead of dropping a packet when congestion occurs, the system stores the packet in a separate SPAN-on-drop buffer and then sends the packet to the specified SPAN-on-drop destination port.

The SPAN-on-Latency feature allows the system to SPAN packets that exceed a pre-configured latency threshold.

For high-latency flows the system can be configured to send a copy to any pre-configured SPAN destination. This creates a data set for analytics that can be used to check which applications are impacted by increased latency in the network. This feature can also be used to identify traffic flows that experience congestion.

Packets exceeding the latency measurements, egressing out of the source port only will be spanned.

Note	SPAN copies can be transported to a local analyzer port, or remote analyzer using IPFIX/ERSPAN encapsulation. The SPAN copies can be truncated to save bandwidth.

• SPAN is not supported on a management interface.

• If an interface is configured as a source port for a SPAN session, either directly as a source interface or indirectly as part of a port-channel, traffic from this interface will not be visible in VLAN SPAN sessions that include this interface as part of a configured VLAN. This limitation occurs as the Ternary Content-Addressable Memory (TCAM) entries for interface SPAN sources are always programmed before the TCAM entries for VLAN SPAN sources.

• Starting from Cisco NX-OS Release 7.3(0)N1(1), a host interface (HIF) port can be a destination port for local SPAN sessions. However, a HIF port cannot be a destination port for SPAN-on-Latency, SPAN-on-Drop and ERSPAN sessions.

• An interface cannot be added as a source interface in the same direction in more than one SPAN session.

• Some protocols such as LLDP, DCBX, LACP, CDP are offloaded to FEX CPU. Hence the parent switch never sees native frames for these protocols and uses MTS messaging to inform the parent CPU.

  Moreover, since SPAN is done on the parent fabric interface, native packets for the protocols that are handled by FEX CPU are not seen in the SPAN.

Cisco Nexus 6000 devices support 16 active local SPAN or ERSPAN-source sessions, 16 active ERSPAN-destination sessions and one active SPAN-on-Drop or SPAN-on-Drop-ERSPAN session.

The following guidelines and limitations apply to SPAN session where multiple destinations are configured:

• Multiple destinations are supported for Local SPAN or SPAN-on-Drop sessions only. Multiple destinations are not supported on ERSPAN or SPAN-on-Latency sessions.

• The maximum number of unique destinations configured on all active sessions is 16. A single SPAN session can have a maximum of 16 destinations, and a SPAN-on-Drop session can have a maximum of 17 destinations, in which case no further SPAN sessions can be configured.

• You cannot SPAN a single source VLAN to multiple destination ports.

• You cannot use the same source interface in multiple SPAN or ERSPAN sessions.

• Connecting SPAN destination ports to a switch device is not supported.

The following guidelines and limitations apply to SPAN-on-Drop sessions:

• Only Ethernet source interfaces are supported (port channels not supported). Sources can be a part of a SPAN-on-Drop session and a local SPAN session simultaneously.

• At most one SPAN-on-Drop or SPAN-on-Drop ERSPAN session may be active at the same time.

• Directions on source interfaces are not supported.

• FEX interfaces are not supported as sources for SPAN-on-Drop sessions. However, fabric interfaces are supported. Setting all fabric interfaces associated with a FEX as sources allows SPAN-on-Drop sessions to be enabled on all FEX ports associated with that fabric interface.

• Multicast egress drops are not spanned. SPAN-on-Drop applies only to packets dropped in ingress due to a lack of buffer resources or when the Virtual Output Queueing (VOQ) size exceeds the preprogrammed threshold.

• ACL-based SPAN is not supported

• Configuring the maximum transmission unit (MTU) truncation size for packets is not supported for SPAN-on-Drop sessions.

The following guidelines and limitations apply to SPAN-on-Latency sessions:

• Although SPAN-on-Latency detection is performed on a per-port basis, the span pointer configuration is a global value.

• The maximum latency threshold value configuration is per 40 Gigabit port. Therefore, if there the system has 10 Gigabit ports, the latency threshold is shared by four 10 Gigabit ports.

• At most only one SPAN-on-Latency or SPAN-on-Latency ERSPAN session may be active at the same time.

• You must issue the clear hardware profile latency monitor all command when the switch is reloaded or when a module is powered on. Until you issue this command no packets are spanned.

• Even though fabric interfaces are supported as sources, FEX interfaces and Port Channel are not supported as sources.

• Span-on-Latency Source cannot be part of any other span session i.e. Local Span or Span-on-drop.

• ACL based SOL is not supported.

The following limitations apply to SPAN (local SPAN) session Access Control Lists (ACL) configurations:

• Due to system limitations, the extent to which an ACL associated to SPAN session can scale depends on the how the SPAN source is configured. The following table shows different scenarios and the corresponding maximum ACL size supported.

  Note	These calculations assume that each ACE in the ACL results in one final TCAM entry.

  Scenario	Maximum ACL Size
  SPAN has single Switch Port as source with both Tx and Rx.	Current Available TCAM Entries/2
  SPAN has multiple Switch Ports as source with both Tx and Rx.	Current Available TCAM Entries/3
  SPAN has Port Channel (with one or more member switch ports) as source with both Tx and Rx.	Current Available TCAM Entries/3
  SPAN has single HIF Ports as source with both Tx and Rx.	Current Available TCAM Entries/3
  SPAN has multiple HIF Ports as source with both Tx and Rx.	Current Available TCAM Entries/4
  SPAN has HIF Port Channel (with one or more member HIF ports) as source with both Tx and Rx.	Current Available TCAM Entries/4

• The following scenarios are unaffected by any system limitations for ACL and SPAN session scaling:

  • SPAN has single Switch Port as source with Tx only.

  • SPAN has multiple Switch Ports as source with Tx only.

  • SPAN has a Port Channel (with one or more member switch ports) as source with Tx only.

  • SPAN has a single Host Interface (HIF) Port as source with Tx only.

  • SPAN has multiple HIF Ports as source with Tx only.

  • SPAN has a single Port HIF Channel (with one or more member HIF ports) as source with Tx only.

  • SPAN has a single Switch Port as source with Rx only.

  • SPAN has multiple Switch Ports as source with Rx only.

  • SPAN has a Port Channel (with one or more member switch ports) as source with Rx only.

  • SPAN has a single HIF Ports as source with Rx only.

  • SPAN has multiple HIF Ports as source with Rx only.

  • SPAN has a HIF Port Channel (with one or more member HIF ports) as source with Rx only

• The following guidelines apply when configuring local SPAN sessions with ACLs:

  • When you associate an ACL with a SPAN session, you must ensure that its size is not greater than the calculations given in the table above. Otherwise the SPAN session fails and generate a "TCAM resource unavailable" error. If the ACL has Layer 4 Operations and TCAM resource expansion is enabled, you need to know the expected expanded size and you need to use the expanded size to calculate the maximum ACL size.

  • If you change the ACL that is attached to a SPAN session, the ACL size can exceed the maximum ACL size allowed. In this scenario, the SPAN session continues to work with the modified ACL. However, you should undo the ACEs added to the ACL to limit the size to maximum allowed ACL size.

  • If you add a SPAN session when one already exists, then to modify the first span session there should be free TCAM entries of size equal to number of ACEs in the associated ACL (Assuming that each ACE requires one TCAM entry. If it gets expanded, the expanded size should be considered). Therefore, TCAM entries consumed by the second SPAN session should be released.

  • To replace a large ACL with another large ACL (which could cause the SPAN session to enter a generic error state), you must first remove the existing filter access group (using the no filter access-group current acl name command), and then configure the new filter access group (using the filter access-group new acl name command).

• Local SPAN/SPAN on Drop/SPAN on Latency is not aware of VPC.

• The following is the limitation for HIF and Virtual Ethernet (Veth) as SPAN destination:

  • Multi-destination SPAN is not supported. If HIF/VETH port is a destination, the monitor session must have single destination.

  • A SPAN destination port, which is part of an active SPAN session, receives flood traffic. You can prevent this behavior by using the unknown unicast flood block feature. To enable this feature, use the switchport block unicast command.

If a SPAN session is down, do the following:

• Check if one of the destination port is operational by performing the following:

  • Use the show running interface interface command and check if the switchport monitor is configured.

  • Use the show interface interface command and check if the destination interface shows the status as "admin up".

• Use the show interface interface command to check if one of the source port is operational and if the source interface shows the status as "admin up".

• If ACL filter is applied, check if the filter definition exists. Use the show access-lists listname command to check the configured access list with entries

This example shows how to configure a SPAN ACL:

switch# configure terminal
switch(config)# ip access-list match_11_pkts
switch(config-acl)# permit ip 11.0.0.0 0.255.255.255 any
switch(config-acl)# exit
switch(config)# monitor session 1
switch(config-erspan-src)# filter access-group match_11_pkts

This example shows how to configure an SPAN-on-Latency session:

switch# configure terminal
switch(config) # interface ethernet 1/1
switch(config-if) # packet latency threshold 530000000
switch(config) # monitor session 11 type span-on-latency
switch(config-span-on-latency) # description span-on-latency-session_11
switch(config-span-on-latency) # source interface ethernet 1/3
switch(config-span-on-latency) # destination interface ethernet 1/1
switch(config-span-on-latency) # mtu 1500
switch(config) # copy running-config startup-config
switch(config) #