What Is ERSPAN and How Does It Compare to a Network TAP?

When a performance problem or security alert points to a branch office or remote data center, you need to see the packets. Putting an engineer and a monitoring tool next to every link isn’t realistic. Encapsulated Remote Switched Port Analyzer (ERSPAN) solves part of that problem. It copies traffic from a switch port or virtual LAN (VLAN), wraps each copy in a Generic Routing Encapsulation (GRE) tunnel, and sends it across a routed Internet Protocol (IP) network to a tool somewhere else.

A network test access point (TAP) works differently. It’s a dedicated hardware device that sits in the physical link and copies traffic at the wire, so no switch has to do the work. ERSPAN gives you flexible reach across routed networks, while a TAP gives you complete, independent capture of a link.

This guide explains how ERSPAN works, what its header types carry, where it falls short, and how it compares to a TAP. You’ll also see how a network packet broker can combine both methods in one visibility architecture.

What ERSPAN Is and Where It Fits

ERSPAN is a traffic mirroring feature that extends Switched Port Analyzer (SPAN) across Layer 3. A source device copies the traffic you select and places each copy inside a GRE packet addressed to a destination IP address. Because the copy travels as ordinary IP traffic, it can cross routers and reach any tool your network can reach.

ERSPAN Builds on SPAN and RSPAN

Each generation of mirroring extends the reach of the one before:

• SPAN: Copies traffic from one or more ports to another port on the same switch.
• Remote SPAN (RSPAN): Delivers mirrored traffic to another switch, but only one that’s Layer 2 adjacent to the source, as Cisco’s specification describes.
• ERSPAN: Carries mirrored traffic over any IP transport, so the destination can sit several router hops away.

ERSPAN Isn’t an Internet Standard

Cisco documented ERSPAN in an Internet-Draft submitted to the Internet Engineering Task Force (IETF), and it expired without becoming a Request for Comments (RFC). Support has since spread beyond Cisco hardware. Open vSwitch has supported ERSPAN since version 2.10, and VMware’s distributed switch API lists ERSPAN Type II and Type III as encapsulation options.

Without a ratified standard, some fields, such as the port index, are platform dependent. Confirm what your switches, hypervisors, and tools support before you design around ERSPAN.

How ERSPAN Works

Every ERSPAN deployment has the same three parts and follows the same packet flow.

The Three Building Blocks

• Source session: Defines which ports or VLANs to mirror, in which direction, and often which traffic to filter.
• Routable tunnel: Carries the GRE-encapsulated copies across your IP network to the destination address.
• Destination: Either a device that supports ERSPAN decapsulation or a tool or probe with an IP address that can accept the tunnel, as the specification explains.

Step-by-Step Packet Flow

1. A packet crosses a monitored port or VLAN on the source switch.
2. The switch copies it according to the session’s rules.
3. The switch wraps the copy in ERSPAN, GRE, and IP headers addressed to the destination.
4. Routers forward the tunnel packet like any other IP traffic.
5. The destination strips the outer headers and passes the original frame to the analysis tool, or the tool reads the tunnel packet directly.

What an ERSPAN Packet Contains

A Type II packet is built in layers. From the outside in, it carries:

• Outer Ethernet and IP headers: Route the packet to the destination (14 and 20 bytes).
• GRE header: Marks the payload as ERSPAN and carries a sequence number (8 bytes).
• ERSPAN header: Adds metadata such as VLAN, class of service, and session ID (8 bytes).
• Original frame: The mirrored copy, followed by a new trailing cyclic redundancy check (CRC).

ERSPAN Types I, II, and III

The GRE protocol type tells a receiver which variant it’s handling. Types I and II share the value 0x88BE, and Type III uses 0x22EB. Type I is a bare-bones format with only outer headers and GRE, so Types II and III are the ones that carry useful metadata.

ERSPAN Type II

Type II is usually the default on Cisco switches. Its 8-byte header carries the original VLAN, class of service, trunk encapsulation type, a truncation flag, a 10-bit session ID, and a port index. It has no timestamp, so a tool can only record when the packet arrived, not when the switch saw it.

ERSPAN Type III

Type III uses a larger 12-byte header, plus an optional 8-byte platform-specific sub-header, to support latency analysis, intrusion detection, and performance monitoring. Its additional fields include:

• Timestamp: Taken from a hardware clock, with granularity from 100 microseconds down to 100 nanoseconds, or in IEEE 1588 format.
• Direction: Shows whether the frame was mirrored on ingress or egress.
• Frame integrity: Flags bad, short, or oversized frames.
• Hardware ID and security group tag: Identify the ERSPAN engine and the frame’s security group.

Where ERSPAN Is Used

ERSPAN fits best where physical access is limited or where traffic never touches a physical wire.

Remote and Multi-Site Monitoring

Branch offices and remote data centers rarely have monitoring tools on site. ERSPAN lets you pull mirrored traffic back to a central location over routes you already have. Several platforms accept it, including:

• Network detection sensors: Fortinet’s FortiNDR Cloud documentation says sensors can receive ERSPAN Type II and Type III traffic.
• Operational technology (OT) monitoring: Microsoft’s Defender for IoT guidance lists ERSPAN alongside TAPs as a way to feed an OT sensor.
• Temporary troubleshooting: Engineers can start a session without a site visit.

Virtual and Cloud Environments

Virtual switches have no physical port to tap. ERSPAN lets a hypervisor forward virtual machine traffic to an external analyzer. The OpenStack specification describes ERSPAN and GRE mirroring as a good way to send cloud traffic to an analyzer outside the cloud.

Capturing Packets a Switch Drops

Some ERSPAN uses have no TAP equivalent. Cisco’s SPAN-on-Drop feature for Nexus 9000 GX2 series switches (NX-OS 10.2 and later) mirrors packets the switch discards internally, such as those lost to lookup misses, access control list (ACL) drops, or policer drops, and sends them to an ERSPAN destination. A TAP can show that a packet arrived, but not why the switch discarded it.

What a Network TAP Does Differently

A network TAP connects to the cabling between two devices and copies traffic for monitoring while the original traffic carries on. Send and receive streams are copied on separate channels, so your tools receive both directions in real time.

How a TAP Copies Traffic

A passive fiber TAP uses internal mirrors to split the light on a fiber link. Part of the light budget continues through the live network, and the rest carries an exact copy to your tool. We offer custom split ratios of 50:50, 60:40, and 70:30 to suit different link distances. Passive TAPs need no power and no IP or Media Access Control (MAC) address, so they’re invisible to the network.

Types of TAPs

Most deployments use one of three TAP types:

• Passive fiber TAPs: Split light with no power, so capture continues through a power outage.
• Ethernet TAPs: Active devices for copper links that copy both directions to your tools.
• Bypass TAPs: Protect inline security tools by redirecting traffic automatically when a tool stops responding to heartbeat signals.

ERSPAN vs. Network TAP Compared

Both methods copy your traffic. They differ in where the copy is made and what can go wrong before it reaches the tool.

Visibility and Packet Fidelity

ERSPAN copies travel as regular IP packets, so they face the same congestion as everything else. Three gaps matter most:

• Delayed or dropped copies: Cisco’s specification suggests raising the Quality of Service (QoS) priority of ERSPAN frames when congestion could keep them from reaching the analysis device.
• Truncated frames: Copies that exceed the configured maximum transmission unit (MTU) are cut short and flagged.
• Missing error evidence: Types I and II don’t preserve the original CRC, so the receiver can’t confirm whether the original frame was corrupt. A TAP passes full-duplex traffic, including errors.

Impact on Production Traffic

ERSPAN sessions run on the same devices that forward your production traffic, and the tunnels share your production links. Cisco’s guidance for its Secure Workload platform warns that a session can generate enough packets to saturate the receiving agent and notes that lowering the ERSPAN MTU limits bandwidth use. A TAP sits outside the switch, so mirroring adds no load to it.

Timing Accuracy

Type II carries no timestamp, so the receiving tool stamps packets on arrival, which includes any delay in the tunnel. Type III fixes this at the source, but your tools must read the field. Cisco notes that its Secure Workload agents support all three versions but don’t currently use the extra Type II and III information.

Security and Cost

Cisco’s specification says ERSPAN has no authentication or encryption of its own. Source and destination addresses must be routable, and you can limit packet reach with the time to live (TTL) setting or carry ERSPAN through IPsec tunnels. ERSPAN needs no extra hardware, but you pay in configuration effort and tool capacity. A TAP is a hardware purchase that takes the mirroring workload off your switches and delivers unencapsulated traffic to your tools.

ERSPAN Limitations to Plan For

None of these limitations rules ERSPAN out, but each can decide whether it’s right for a particular link.

Bandwidth and MTU Overhead

A Type II packet adds 50 bytes of headers to every mirrored frame: 14 for Ethernet, 20 for IP, 8 for GRE, and 8 for ERSPAN, plus a new 4-byte trailer. Type III headers are larger, so overhead grows. That has three effects:

• Truncation: A full-size frame plus 50 bytes of headers exceeds a standard 1,500-byte MTU, so the copy is truncated and flagged unless you raise the MTU along the path.
• Extra bandwidth: Every mirrored packet crosses your network a second time, with added headers.
• Planning effort: You must raise the MTU on every hop between source and destination, or accept truncated copies.

Switch Resources and Session Limits

Platforms limit how many ERSPAN sessions you can run, and the numbers vary by switch model and line card. Cisco directs engineers to its scalability guides for session limits, so check them before you plan a large number of sessions.

Tool Compatibility

Not every monitoring tool understands ERSPAN. You have three practical options:

• Native support: Choose tools that accept Type II or Type III directly.
• Tunnel termination: Use a device that removes the outer headers and forwards the original frame.
• Header-aware tools: Choose tools that actually use ERSPAN metadata, such as timestamps.

When to Use ERSPAN, a TAP, or Both

Choose ERSPAN When

• You need quick visibility: A temporary capture across a routed network is more important than perfect fidelity.
• The link is virtual or cloud-based: There’s no physical cable to tap.
• You need dropped-packet visibility: Your switch supports features such as SPAN-on-Drop.
• Occasional loss is acceptable: Missing an odd packet or timing precision won’t undermine your analysis.

Choose a TAP When

• You need every packet: Critical links require full-duplex copies, including errors.
• Switch resources are tight: Your switches are already short on processing power or bandwidth.
• Evidence matters: Security, forensic, or compliance work needs dependable, complete capture.
• Stealth matters: Passive TAPs have no IP or MAC address for an attacker to find.

Use Both Together

Most networks end up with both. Place TAPs on critical physical links and use ERSPAN where tapping isn’t practical. A packet broker, which collects, filters, and distributes traffic to the right tools, then ties the streams together:

1. Tap critical links where you need complete capture.
2. Use ERSPAN for virtual, cloud, and hard-to-reach segments.
3. Send both streams to your packet broker, after confirming it can terminate ERSPAN tunnels or terminating them on an upstream device.
4. Filter and distribute so each tool receives only the traffic it needs.

How to Get Remote Visibility Without ERSPAN

If your goal is multi-site visibility rather than ERSPAN itself, you can tap each site and tunnel the results to a central location. A packet broker with GRE support makes this straightforward:

1. Install TAPs on the critical links at each site.
2. Aggregate and filter the copied traffic locally, so you tunnel only what matters.
3. Encapsulate the traffic in a GRE tunnel and send it to your central tool farm.
4. Deliver it to your monitoring and security tools, load balancing where needed.

Our SmartNA-XL supports IP, GRE, Network Virtualization using GRE (NVGRE), and Virtual Extensible LAN (VXLAN) encapsulation for point-to-point tunneling. It’s also a hybrid TAP and packet broker, so you get centralized monitoring of multi-site networks with TAP-grade capture at each location.

ERSPAN Best Practices

If you run ERSPAN, these practices prevent common problems:

1. Filter at the source. Mirror only the ports, VLANs, and traffic you need, using ACLs where your switch supports them.
2. Plan the MTU end to end. Account for the header overhead on every hop.
3. Set QoS deliberately. Raise priority if losing ERSPAN traffic is unacceptable, and lower it if production traffic must always win.
4. Match the type to your tools. Use Type III only when your tools read the timestamp and other metadata.
5. Limit the tunnel’s reach. Set the TTL, use trusted paths, and consider IPsec, because ERSPAN doesn’t encrypt.
6. Keep session IDs unique. The 10-bit session ID must be unique between the source and its receivers.
7. Validate before you rely on it. Compare an ERSPAN capture with a known-good capture of the same link.

Frequently Asked Questions

Is ERSPAN the same as GRE?

No. ERSPAN is a variant of GRE that adds its own header with mirroring metadata, such as session ID and VLAN. The OpenStack specification notes that ERSPAN’s session ID is far smaller than the GRE key, so plan your numbering accordingly.

Does ERSPAN encrypt mirrored traffic?

No. ERSPAN offers no authentication or encryption. If mirrored data crosses untrusted networks, carry it through IPsec tunnels and limit its reach with the TTL setting.

Can ERSPAN replace a network TAP?

For some links, yes, such as virtual switches or temporary troubleshooting. For critical physical links where you need every packet, including errors, a TAP is more dependable because the copy doesn’t depend on switch resources or network conditions.

Which ERSPAN type should I use?

Use Type II if your tools only need the traffic and basic metadata. Choose Type III if you need source timestamps and richer metadata, and confirm that both your switch and your tools support it.

The Bottom Line on ERSPAN and TAPs

ERSPAN is a practical way to send mirrored traffic across routed networks and into virtual environments. It needs no extra hardware, but its copies depend on the switches and networks that carry them.

A TAP captures the link itself, independent of your switches, so it’s the stronger choice when completeness and accuracy matter most. The two methods work best together, each applied where it fits.

How Network Critical Can Help

Network Critical has provided network visibility hardware since 1997, and we design and manufacture all of our TAPs and packet brokers. That lets you pair complete capture on critical links with flexible tunneling to central tool farms.

Our SmartNA-PortPlus packet brokers cover 1G to 100G networks and scale from one to five rack units. For 100G, 200G, and 400G visibility, SmartNA-PortPlus HyperCore delivers 32 QSFP-DD interfaces in a single rack unit. Both are managed through Drag-n-Vu, which lets you build filters and map traffic to ports with drag-and-drop simplicity.

Whether you’re choosing between ERSPAN and TAPs, extending monitoring to remote sites, or consolidating tools, our team can help you design an architecture that delivers complete coverage.