Cisco Nexus 9000 ERSPAN Configuration and Limitations

ERSPAN on Nexus 9000 wraps mirrored frames in a GRE header so they can be delivered to a collector anywhere in the routed network, instead of requiring a physical analyzer port next to the switch. That flexibility comes with platform-specific rules: which switches can terminate an ERSPAN session, how jumbo frames are handled, and where a switch silently drops the traffic. This article documents a working ERSPAN deployment and the limitations you should check before designing a capture plan around it.

SPAN versus ERSPAN in one line

Local SPAN copies frames to a port on the same switch. ERSPAN copies them into a GRE tunnel so the destination can be a remote host running Wireshark, a security appliance, or a monitoring VM. Both are implemented in hardware; the supervisor CPU is not involved in replication, so mirroring does not slow the control plane.

Destination side: a collector session

switch(config)# monitor session 1 type erspan-destination
switch(config-erspan-dst)# destination interface Ethernet1/1
switch(config-erspan-dst)# source ip 10.10.10.50
switch(config-erspan-dst)# no shutdown
switch(config-erspan-dst)# exit

The destination interface must be a physical or port-channel interface in switchport mode on the platforms that support ERSPAN termination. It does not participate in spanning tree or any Layer 3 protocol — in other words, it is not a usable data port while the session exists.

Source side: mirroring traffic into the tunnel

switch(config)# monitor session 1 type erspan-source
switch(config-erspan-src)# source interface Ethernet1/10 both
switch(config-erspan-src)# source interface Ethernet1/11 rx
switch(config-erspan-src)# filter access-group ERSPAN-FILTER
switch(config-erspan-src)# destination
switch(config-erspan-src-dst)# erspan-id 1
switch(config-erspan-src-dst)# ip address 10.10.10.50
switch(config-erspan-src-dst)# origin ip address 10.10.10.60
switch(config-erspan-src-dst)# no shutdown

erspan-id identifies the session at the collector; multiple switches can send to one collector on different IDs. origin ip address sets the tunnel source, which must be reachable from the collector for return-path sanity and for GRE parsing.

Filtering instead of mirroring everything

Mirroring a busy 100G port to a 10G collector is a self-inflicted outage: the session will not rate-limit gracefully, and you lose the frames you actually wanted. Filter with an ACL and, where supported, with truncation.

switch(config)# ip access-list ERSPAN-FILTER
switch(config-acl)# 10 permit tcp 10.20.0.0/16 10.30.0.0/16 eq 443
switch(config-acl)# 20 permit icmp any any
switch(config)# monitor session 1 type erspan-source
switch(config-erspan-src)# filter access-group ERSPAN-FILTER
switch(config-erspan-src)# source interface port-channel 10 both

Two hard rules from Cisco's documentation: an ACL filter in a SPAN session must be configured as a vlan-accessmap for local SPAN, and you cannot configure two ERSPAN or SPAN sessions on the same source interface with only one filter — either all sessions on that source have filters or none do. There is also a documented restriction that an ACL filter cannot be used to ERSPAN subinterface traffic on the parent interface on several 9200/9300-EX/FX/GX platforms.

Platform limitations to check before designing

Release notes matter here: several restrictions were introduced or lifted between 10.1 and 10.4 (for example, RX-only support and the removal of Type 3 headers and destination termination on certain releases). Check the guide for the exact NX-OS version running on your switches before writing a design document.

Verification

switch# show monitor session 1
switch# show monitor session all
switch# show monitor session 1 brief
switch# show run monitor

Confirm the source interfaces, the filter, the tunnel destination and origin, and the session state. Then validate on the collector: the GRE protocol number (47) must not be blocked by any intermediate firewall, and the collector's NIC must accept the encapsulated frames. A session that shows up but delivers nothing is almost always a routing or firewall issue between the origin address and the collector, not a mirroring fault.

Practical deployment notes

• Give the tunnel its own origin IP on a loopback so a single uplink failure does not blind the capture.
• Aggregate mirrored traffic into a dedicated collector VLAN; never let ERSPAN share an oversubscribed data path in production.
• Set a capture window and a session-removal checklist: forgotten SPAN sessions are a recurring cause of unexplained bandwidth usage.
• Where the security team needs continuous visibility, prefer dedicated TAP/aggregator infrastructure over long-lived ERSPAN sessions on production switches.

Where to terminate the tunnel: collector design

Choosing the collector determines whether ERSPAN is a diagnostic tool or a bandwidth liability. Three designs are common:

• Single capture host — simplest; one server with a large, fast local disk runs Wireshark or tcpdump in a capture ring. Suitable for troubleshooting one link at a time.
• Centralised monitoring appliance — many switches send ERSPAN sessions to a dedicated appliance that indexes and retains flows. This is the design used when security needs continuous visibility.
• Aggregator switch plus analyser — switches send ERSPAN to an aggregator that converts it back to local SPAN toward an IDS. Lets you keep a single analyser while watching many switches.

# Aggregator side: receive ERSPAN and strip it to a local monitoring port
switch(config)# monitor session 10 type erspan-source
switch(config-erspan-src)# source interface Ethernet1/1 rx
switch(config-erspan-src)# destination
switch(config-erspan-src-dst)# ip address 10.99.0.20
switch(config-erspan-src-dst)# erspan-id 100

Whatever the design, size the monitoring path for the traffic you intend to mirror, not for the port speed. A 100G uplink mirrored into a 10G monitoring path will drop frames under load, and the loss happens inside the tunnel where you cannot see it.

Performance and capacity considerations

A deployment checklist

1. Confirm the platform supports ERSPAN termination if the switch will also receive tunnels.
2. Choose a loopback as the tunnel origin and confirm it is reachable from the collector.
3. Build the ACL filter first, before configuring the session.
4. Set the session up during a maintenance window and confirm the collector sees packets.
5. Record the session ID, source interfaces, filter and destination in the network documentation.
6. Set a reminder to remove the session; forgotten capture sessions are a recurring operational issue.

Related articles

Port-level VLAN prerequisites are in Cisco Nexus NX-OS VLAN and trunk configuration, and the equivalent on another NOS is covered in Dell OS10 port monitoring and SPAN configuration. If you need a lab to test capture designs, Containerlab multi-vendor network labs is a good starting point.

原文链接：https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/103x/configuration/system-management/cisco-nexus-9000-series-nx-os-system-management-configuration-guide-103x/m-configuring-erspan.html