Information About ERSPAN
The Cisco NX-OS system supports the Encapsulated Remote Switching Port Analyzer (ERSPAN) feature on both source and destination ports. ERSPAN transports mirrored traffic over an IP network. The traffic is encapsulated at the source router and is transferred across the network. The packet is decapsulated at the destination router and then sent to the destination interface.
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.
ERSPAN Source Sessions
An ERSPAN source session is defined by the following:
-
A session ID.
-
A list of source ports, source VLANs, or source VSANs to be monitored by the session.
-
An ERSPAN flow ID.
-
Optional attributes related to the GRE envelope such as IP TOS and TTL.
-
Destination IP address.
-
Virtual Routing and Forwarding tables.
ERSPAN source sessions do not copy ERSPAN GRE-encapsulated traffic from source ports. Each ERSPAN source session can have ports, VLANs, or VSANs as sources. However, there are some limitations. For more information, see Guidelines and Limitations for ERSPAN.
The following figure shows an example ERSPAN configuration.
Monitored Traffic
By default, ERSPAN monitors all traffic, including multicast and bridge protocol data unit (BPDU) frames.
The direction of the traffic that ERSPAN monitors depends on the source, as follows:
-
For a source port, the ERSPAN can monitor ingress, egress, or both ingress and egress traffic.
-
For a source VLAN or source VSAN, the ERSPAN can monitor only ingress traffic.
ERSPAN Types
Cisco NX-OS Release 7.1(1)N1(1) supports two types of ERSPAN—ERSPAN Type II (default) and ERSPAN Type III. All previous Cisco NX-OS releases support only ERSPAN Type II.
-
Provides timestamp information in the ERSPAN Type III header that can be used to calculate packet latency among edge, aggregate, and core switches.
-
Identifies possible traffic sources using the ERSPAN Type III header fields.
-
ERSPAN Type III provides configurable switch IDs that can be used to identify traffic flows across multiple switches.
Attribute | Type II | Type III |
---|---|---|
Timestamp | NA | Timestamp provided. |
Platform-specific info | NA | Platform-specific info is required for Nexus 5500, Nexus 5600 and Nexus 6000 platforms. |
Source Port Identification at Termination Switch | Limited identification. | Detailed identification. Provision of switch IDs. |
ERSPAN Sources
-
Ethernet ports and port channels.
-
VLANs—When a VLAN is specified as an ERSPAN source, all supported interfaces in the VLAN are ERSPAN sources.
-
A port configured as a source port cannot also be configured as a destination port.
-
ERSPAN does not monitor any packets that are generated by the supervisor, regardless of their source.
-
Ingress traffic at source ports can be filtered by using ACLs so that they mirror only those packets of information that match the ACL criteria.
ERSPAN Destinations
ERSPAN destination sessions capture packets sent by ERSPAN source sessions on Ethernet ports or port channels and send them to the destination port. Destination ports receive the copied traffic from ERSPAN sources.
ERSPAN destination sessions are identified by the configured source IP address and ERSPAN ID. This allows multiple source sessions to send ERSPAN traffic to the same destination IP and ERSPAN ID and allows you to have multiple sources terminating at a single destination simultaneously.
-
A port configured as a destination port cannot also be configured as a source port.
-
Destination ports do not participate in any spanning tree instance or any Layer 3 protocols.
-
Ingress and ingress learning options are not supported on monitor destination ports.
-
Host Interface (HIF) port channels and fabric port channel ports are not supported as SPAN destination ports.
Truncated ERSPAN
Truncated ERSPAN can be used to reduce the amount of fabric or network bandwidth used in sending ERSPAN packets.
The default is no truncation so switches or routers receiving large ERSPAN packets might drop these oversized packets.
Note |
Do not enable the truncated ERSPAN feature if the destination ERSPAN router is a Cisco Nexus 6001 or Cisco Nexus 6004 switch because the Cisco Nexus 6000 Series switch drops these truncated packets. |
ERSPAN with ACL
With ERSPAN traffic the destination is remote and the overall impact of bandwidth congestion can be significant. The ERSPAN with ACL filtering feature allows you to filter ERSPAN traffic so that you can reduce bandwidth congestion. To configure ERSPAN with ACL filtering, you use ACL’s for the session to filter out traffic that you do not 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 the spanning of traffic that matches the ACL criteria, saving bandwidth for more meaningful data. The filter would apply on all sources in the session (vlan or interface).
ERSPAN SPAN on Drop
The ERSPAN 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 ERSPAN-on-drop destination IP address.
ERSPAN SPAN-on-Latency
The ERSPAN-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.
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. |
High Availability
The ERSPAN feature supports stateless and stateful restarts. After a reboot or supervisor switchover, the running configuration is applied.