-
The type of SPAN supported varies:
-
For generation 1 switches, tenant and access SPAN use the encapsulated remote extension of SPAN (ERSPAN) type I (Version 1
option in the Cisco Application Policy Infrastructure
Controller (APIC) GUI).
-
For generation 2 switches, tenant and access SPAN use the encapsulated remote extension of SPAN (ERSPAN) type II (Version
2 option in the Cisco APIC GUI).
-
Fabric SPAN uses ERSPAN type II.
-
When configuring ERSPAN session, if the SPAN source contains a destination and interfaces from a spine switch within a GOLF
VRF instance, an L3Out prefix is sent to the GOLF router with the wrong BGP next-hop, breaking connectivity from GOLF to that
L3Out.
-
A uSeg EPG or ESG cannot be used as a SPAN source EPG because the SPAN source filter is based on the VLAN ID. Thus, even if
an endpoint is classified to a uSeg EPG or an ESG, traffic from the endpoint is mirrored if its VLAN is the VLAN of the SPAN
source EPG.
-
You cannot specify an l3extLIfP Layer 3 subinterface as a SPAN source. You must use the entire port for monitoring traffic
from external sources.
-
In local SPAN for FEX interfaces, the FEX interfaces can only
be used as SPAN sources, not SPAN destinations.
-
On generation 1 switches, Tx SPAN does not work for any Layer 3 switched traffic.
-
On generation 2 switches, Tx SPAN does not work whether traffic is Layer 2 or Layer 3 switched.
There are no limitations for Rx SPAN.
-
For SPAN of FEX fabric port-channel (NIF), the member interfaces are supported as SPAN source interfaces on generation 1 leaf
switches.
Note
|
While it is also possible to configure FEX fabric port-channel (NIF) member interfaces as SPAN source interfaces on generation
2 switches, this is not supported for releases prior to Cisco APIC release 4.1.
|
-
For information regarding ERSPAN headers, refer to the IETF Internet Draft at
this URL: https://tools.ietf.org/html/draft-foschiano-erspan-00.
-
ERSPAN destination IP addresses must be learned in the fabric as an endpoint.
-
SPAN supports IPv6 traffic but the destination IP address for the ERSPAN cannot be an IPv6 address.
-
The individual port member of a port channel or a vPC cannot be configured as the source. Use the port channel, vPC, or vPC
component as the source in the SPAN session.
-
A fault is not raised on the ERSPAN source group when the destination EPG is
deleted or unavailable.
-
SPAN filters are supported on generation 2 leaf switches only.
-
An access SPAN source supports only one of the following filters at a given
time:
-
EPG
-
Routed outside (L3Out)
-
When deploying the access SPAN source with an L3Out filter, ensure that the L3Out is also deployed on the matching interface:
-
If an L3Out is deployed on a port, a SPAN source must be deployed on the same port.
-
If an L3Out is deployed on a PC, a SPAN source must be deployed on the same PC.
-
If an L3Out is deployed on a vPC, a SPAN source must be deployed on the same vPC.
-
An L3Out routed interface and routed sub-interface can be deployed on a port or a PC, but an L3Out SVI can be deployed on
a port, PC, or vPC. A SPAN source with an L3Out filter must be deployed accordingly.
-
An L3Out filter is not supported in fabric SPAN or tenant SPAN sessions.
-
The correct L3Out must be selected in the L3 configuration tab of the EPG bridge domain; otherwise, packet flow for basic
L3Out will not work.
-
An encapsulation value is mandatory for a routed sub-interface and SVI, but is not applicable for a routed interface. The
L3Out sub-interface or SVI encapsulation value must be different from the EPG encapsulation value.
-
When an EPG filter is enabled within a SPAN session, ARP packets, which are sent
out of the interface in the transit, or tx, direction, will not be spanned.
-
SPAN filters are not supported in the following:
-
L4 port range filter entries will not be added if you attempt to add more L4 port
ranges than are officially supported.
-
A SPAN session will not come up if you attempt to associate more than the
supported filter entries at the SPAN source group level or at the individual
SPAN source level.
-
Deleted filter entries will remain in TCAM if you add or delete more filters
entries than are officially supported.
-
See the Verified Scalability Guide for Cisco
ACI document for SPAN-related limits, such as the maximum number of active SPAN
sessions and SPAN filter limitations.
-
For the SPAN-on-drop feature, the following guidelines and restrictions
apply:
-
The SPAN-on-drop feature is supported on generation 2 leaf switches.
-
The SPAN-on-drop feature only captures packets with forwarding drops in
the LUX block, which captures forwarding drop packets at the ingress.
The SPAN-on-drop feature cannot capture the BMX (buffer) and RWX
(egress) drops.
-
When using the troubleshooting CLI to create a SPAN session with SPAN-on-drop enabled and Cisco APIC as the destination, the session is disabled when 100 MB of data is captured.
-
On a modular chassis, the SPAN-on-drop feature will only work for the
packets dropped on the line cards. Packets that are dropped on the
fabric card will not be spanned.
-
SPAN-on-drop ACLs with other SPAN ACLs are not merged. If a SPAN-on-drop
session is configured on an interface along with ACL-based SPAN, then
any packets dropped on that interface will only be sent to the
SPAN-on-drop session.
-
You cannot confgure SPAN on drop and SPAN ACL on the same session.
-
When an access or fabric port-drop session and a global-drop session are
configured, the access or fabric port-drop session takes the priority
over the global-drop session.
-
The number of filter entries supported in TCAM = (M * S1 * 1 + N * S2 *
2) + (S3 * 2). This is applicable to rx SPAN or tx SPAN, separately.
Currently, the maximum filter entries supported in tx or rx SPAN is 480
in each direction when following this formula (and assuming there are no
other sources that are configured without filter-group association
[means S3 = 0] and with 16 port-ranges included). When the number of
filter entries exceed the maximum number allowed, a fault will be
raised. Note that you can specify Layer 4 port ranges in the filter
entry. However, sixteen Layer 4 ports are programmed into the hardware
as a single filter entry.
Note
|
-
M=The number of IPv4 filters
-
S1=The number of sources with IPv4 filters
-
N=The number of IPv6 filters
-
S2=The number of sources with IPv6 filters
-
S3=The number of sources with no filter group association
|
-
With MAC pinning configured in the LACP policy for a PC or vPC, the PC member ports will be placed in the LACP individual
port mode and the PC is operationally non-existent. Hence, a SPAN source configuration with such a PC will fail, resulting
in the generation of the "No operational src/dst" fault. With the MAC pinning mode configured, SPAN can be configured only
on individual ports.
-
A packet that is received on a Cisco Application Centric
Infrastructure (ACI) leaf switch will be spanned only once, even if span sessions are configured on both the ingress and egress interfaces.
-
When you use a routed outside SPAN source filter, you see only unicast in the Tx direction. In the Rx direction, you can see
unicast, broadcast, and multicast.
-
An L3Out filter is not supported for transmit multicast SPAN. An L3Out is represented as a combination of sclass/dclass in
the ingress ACL filters and can therefore match unicast traffic only. Transmit multicast traffic can be spanned only on ports
and port-channels.
-
You can use a port channel interface as a SPAN destination only on -EX and later switches.
-
You cannot configure multiple SPAN sessions with the same source interface when a SPAN filter (5-tuple filter) is applied.
-
The local SPAN destination port of a leaf switch does not expect incoming traffic. You can ensure that the switch drops incoming
SPAN destination port traffic by configuring a Layer 2 interface policy and setting the VLAN Scope property to Port Local scope instead of Global scope. Apply this policy to the SPAN destination ports. You can configure an Layer 2 interface policy by going to the following
location in the GUI: .
-
When you configure SPAN for a given packet, SPAN is supported for the packet only once. If traffic is selected by SPAN in
Rx for the first SSN, the traffic will not selected by SPAN again in Tx for a second SSN. Thus, when the SPAN session ingress
and egress port sits on a single switch, the SPAN session capture will be one-way only. The SPAN session cannot display two-way
traffic.
-
A SPAN ACL filter configured in the filter group does not filter the broadcast, unknown-unicast and multicast (BUM) traffic
that egresses the access interface. A SPAN ACL in the egress direction works only for unicast IPv4 or IPv6 traffic.
-
When configuring a SPAN destination as a local port, EPGs cannot be deployed to that interface.
-
In a leaf switch, a SPAN source with a VRF filter will match all regular bridge domains and all Layer 3 SVIs under the VRF
instance.
-
In a spine switch, a SPAN source with a VRF matches only the configured VRF VNID traffic and a bridge domain filter will match
only the bridge domain VNID traffic.