ERSPAN consists of an ERSPAN source session, routable ERSPAN generic routing encapsulation (GRE)-encapsulated traffic, and an ERSPAN destination session. You can separately configure ERSPAN source sessions and destination sessions on different switches. You can also configure ERSPAN source sessions to filter ingress traffic by using ACLs.

ERSPAN has the following prerequisite:

You must first configure the Ethernet interfaces for ports on each device to support the desired ERSPAN configuration. For more information, see the Interfaces configuration guide for your platform.

Note	For scale information, see the release-specific Cisco Nexus 3600 NX-OS Verified Scalability Guide.

ERSPAN has the following configuration guidelines and limitations:

• The same source can be part of multiple sessions.

• Multiple ACL filters are supported on the same 
source.

• ERSPAN supports the following:

  • From 4 to 6 tunnels

  • Nontunnel packets

  • IPinIP tunnels

  • IPv4 tunnels (limited)

  • ERSPAN source session type (packets are encapsulated as generic routing encapsulation (GRE)-tunnel packets and sent on the IP network. However, unlike other Cisco devices, the ERSPAN header is not added to the packet.).

• ERSPAN packets are dropped if the encapsulated mirror packet fails Layer 2 MTU checks.

• There is a 112-byte limit for egress encapsulation. Packets that exceed this limit are dropped. This scenario might be encountered when tunnels and mirroring are intermixed.

• ERSPAN sessions are shared with local sessions. A maximum of 18 sessions can be configured; however only a maximum of four sessions can be operational at the same time. If both receive and transmit sources are configured in the same session, only two sessions can be operational.

• ERSPAN and ERSPAN ACLs are not supported for packets that are generated by the supervisor.

• ERSPAN and ERSPAN with ACL filtering are not supported for packets that are generated by the supervisor.

• ACL filtering is supported only for Rx ERSPAN. Tx ERSPAN that mirrors all traffic that is egressed at the source interface.

• ACL filtering is not supported for IPv6 and MAC ACLs because of TCAM width limitations.

• If the same source is configured in more than one ERSPAN session, and each session has an ACL filter that is configured, the source interface is programmed only for the first active ERSPAN session. The ACEs that belong to the other sessions will not have this source interface programmed.

• If you configure an ERSPAN session and a local SPAN session (with filter access-group and allow-sharing option) to use the same source, the local SPAN session goes down when you save the configuration and reload the switch.

• The drop action is not supported with the VLAN access-map configuration with the filter access-group for a monitor session. The monitor session goes into an error state if the VLAN access-map with a drop action is configured with the filter access-group in the monitor session.

• Both permit and deny ACEs are treated alike. Packets that match the ACE are mirrored irrespective of whether they have a permit or deny entry in the ACL.

• ERSPAN is not supported for management ports.

• A destination port can be configured in only one ERSPAN session at a time.

• You cannot configure a port as both a source and destination port.

• A single ERSPAN session can include mixed sources in any combination of the following:

  • Ethernet ports or port channels but not subinterfaces.

  • VLANs or port channels, which can be assigned to port channel subinterfaces.

  • Port channels to the control plane CPU.

    Note	ERSPAN does not monitor any packets that are generated by the supervisor, regardless of their source.

• Destination ports do not participate in any spanning tree instance or Layer 3 protocols.

• When an ERSPAN session contains source ports that are monitored in the transmit or transmit and receive direction, packets that these ports receive may be replicated to the ERSPAN destination port although the packets are not actually transmitted on the source ports. Some examples of this behavior on source ports are as follows:

  • Traffic that results from flooding

  • Broadcast and multicast traffic

• For VLAN ERSPAN sessions with both ingress and egress that is configured, two packets (one from ingress and one from egress) are forwarded from the destination port if the packets get switched on the same VLAN.

• VLAN ERSPAN monitors only the traffic that leaves or enters Layer 2 ports in the VLAN.

• When the Cisco Nexus 3600 platform switch is the ERSPAN destination, GRE headers are not stripped off before sending mirrored packets out of the terminating point. Packets are sent along with the GRE headers as GRE packets and the original packet as the GRE payload.

• The egress interface for the ERSPAN source session is now printed in the output of the show monitor session <session-number> CLI command. The egress interface can be a physical port or a port-channel. For ECMP, one interface among the ECMP members is displayed in the output. This particular interface is used for the traffic egress.

• TCAM carving is not required for SPAN/ERSPAN on Cisco Nexus 3600 platform switches.

• You can view the SPAN/ERSPAN ACL statistics using the show monitor filter-list command. The output of the command displays all the entries along with the statistics from the SPAN TCAM. The ACL name is not printed, but only the entries are printed in the output. You can clear the statistics using the clear monitor filter-list statistics command. The output is similar to show ip access-list command. The Cisco Nexus 3600 platform switch does not provide support per ACL level statistics. This enhancement is supported for both local SPAN and ERSPAN.

• The traffic to and/or from the CPU is spanned. It is similar to any other interface SPAN. This enhancement is supported only in local SPAN. It is not supported with ACL source. The Cisco Nexus 3600 platform switch does not span the packets with (RCPU.dest_port != 0) header that is sent out from the CPU.

• For SPAN forward drop traffic, SPAN only the packets that get dropped due to various reasons in the forwarding plane. This enhancement is supported only for ERSPAN Source session. It is not supported along with SPAN ACL, Source VLAN, and Source interface. Three ACL entries are installed to SPAN dropped traffic. Priority can be set for the drop entries to have a higher or lower priority than the SPAN ACL entries and the VLAN SPAN entries of the other monitor sessions. By default, the drop entries have a higher priority.

• SPAN UDF (User-Defined Field) based ACL support

  • You can match any packet header or payload (certain length limitations) in the first 128 bytes of the packet.

  • You can define the UDFs with particular offset and length to match.

  • You can match the length as 1 or 2 bytes only.

  • Maximum of 8 UDFs are supported.

  • Additional UDF match criteria is added to ACL.

  • The UDF match criteria can be configured only for SPAN ACL. This enhancement is not supported for other ACL features, for example, RACL, PACL, and VACL.

  • Each ACE can have up to 8 UDF match criteria.

  • The UDF and http-redirect configuration should not coexist in the same ACL.

  • The UDF names need to be qualified for the SPAN TCAM.

  • The UDFs are effective only if they are qualified by the SPAN TCAM.

  • The configuration for the UDF definition and the UDF name qualification in the SPAN TCAM require the use of copy r s command and reload.

  • The UDF match is supported for both Local SPAN and ERSPAN Src sessions.

  • The UDF name can have a maximum length of 16 characters.

  • The UDF offset starts from 0 (zero). If offset is specified as an odd number, 2 UDFs are used in the hardware for one UDF definition in the software. The configuration is rejected if the number of UDFs usage in the hardware goes beyond 8.

  • The UDF match requires the SPAN TCAM region to go double-wide. Therefore, you have to reduce the other TCAM regions' size to make space for SPAN.

  • The SPAN UDFs are not supported in tap-aggregation mode.

• If a sup-eth source interface is configured in the erspan-src session, the acl-span cannot be added as a source into that session and vice versa.

• IPv6 User Defined Field (UDF) on ERSPAN support

• ERSPAN source and ERSPAN destination sessions must use dedicated loopback interfaces. Such loopback interfaces should not be having any control plane protocols.

The following table lists the default settings for ERSPAN parameters.

The following example shows how to configure an ERSPAN source session:

switch# config t
switch(config)# interface e14/30
switch(config-if)# no shut
switch(config-if)# exit
switch(config)# monitor erspan origin ip-address 3.3.3.3 global
switch(config)# monitor session 1 type erspan-source
switch(config-erspan-src)# filter access-group acl1
switch(config-erspan-src)# source interface e14/30
switch(config-erspan-src)# ip ttl 16
switch(config-erspan-src)# ip dscp 5
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 9.1.1.2
switch(config-erspan-src)# no shut
switch(config-erspan-src)# exit
switch(config)# show monitor session 1

This example shows how to configure an ERSPAN 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)# ip access-list match_12_pkts
switch(config-acl)# permit ip 12.0.0.0 0.255.255.255 any
switch(config-acl)# exit
switch(config)# vlan access-map erspan_filter 5
switch(config-access-map)# match ip address match_11_pkts
switch(config-access-map)# action forward
switch(config-access-map)# exit
switch(config)# vlan access-map erspan_filter 10
switch(config-access-map)# match ip address match_12_pkts
switch(config-access-map)# action forward
switch(config-access-map)# exit
switch(config)# monitor session 1 type erspan-source
switch(config-erspan-src)# filter access_group erspan_filter

This example shows how to configure UDF-based ERSPAN to match on the inner TCP flags of an encapsulated IP-in-IP packet using the following match criteria:

• Outer source IP address: 10.0.0.2

• Inner TCP flags: Urgent TCP flag is set

• Bytes: Eth Hdr (14) + Outer IP (20) + Inner IP (20) + Inner TCP (20, but TCP flags at 13th byte)

• Offset from packet-start: 14 + 20 + 20 + 13 = 67

• UDF match value: 0x20

• UDF mask: 0xFF

udf udf_tcpflags packet-start 67 1
hardware access-list tcam region racl qualify udf udf_tcpflags
copy running-config startup-config
reload
ip access-list acl-udf
	 permit ip 10.0.0.2/32 any udf udf_tcpflags 0x20 0xff
monitor session 1 type erspan-source
  source interface Ethernet 1/1
  filter access-group acl-udf

This example shows how to configure UDF-based ERSPAN to match regular IP packets with a packet signature (DEADBEEF) at 6 bytes after a Layer 4 header start using the following match criteria:

• Outer source IP address: 10.0.0.2

• Inner TCP flags: Urgent TCP flag is set

• Bytes: Eth Hdr (14) + IP (20) + TCP (20) + Payload: 112233445566DEADBEEF7788

• Offset from Layer 4 header start: 20 + 6 = 26

• UDF match value: 0xDEADBEEF (split into two-byte chunks and two UDFs)

• UDF mask: 0xFFFFFFFF

udf udf_pktsig_msb header outer l3 26 2
udf udf_pktsig_lsb header outer l3 28 2
hardware access-list tcam region racl qualify udf udf_pktsig_msb udf_pktsig_lsb
copy running-config startup-config
reload
ip access-list acl-udf-pktsig
		permit udf udf_pktsig_msb 0xDEAD 0xFFFF udf udf_pktsig_lsb 0xBEEF 0xFFFF 
monitor session 1 type erspan-source
		source interface Ethernet 1/1
		filter access-group acl-udf-pktsig