skip to content

How do RSPAN and ERSPAN each carry a mirrored copy to a capture host on another switch, and what does each demand of the path?

level: middleimportance: should knowfreq 18%

answer

  1. layer 2 versus layer 3
  2. a VLAN that carries only copies
  3. GRE inside IP, routable
  4. Don't Fragment and the MTU
  5. a sequence number per session

basics

~20 s

RSPAN, a vendor feature, floods copies into a reserved VLAN that trunks carry to another switch, so it needs an unbroken layer-2 path. ERSPAN wraps each copy in GRE over IP, so it routes but needs MTU headroom and a trusted path.

solid answer

~50 s

**RSPAN** (a vendor feature with no RFC) puts copies into a VLAN reserved for the session; trunks carry that VLAN to the destination switch, which copies it to its local destination port. It needs every switch and trunk in between to carry that VLAN, and the copies eat trunk capacity beside production. **ERSPAN**, described only in the expired Informational draft `draft-foschiano-erspan-03`, wraps each copy in Ethernet, IPv4, GRE and an ERSPAN header, so it can be routed anywhere. Type II adds 50 octets in front of the frame and the draft sets the IP Don't Fragment bit, so a full-size frame becomes a 1,550-octet IP packet: either raise the path MTU or accept truncated copies, flagged by the T bit. ERSPAN has no authentication or encryption, and its per-session GRE sequence number lets the receiver see loss in transit.

go deeper

for a junior

Recall that RSPAN carries mirrored copies in a dedicated VLAN between switches, while ERSPAN wraps them in GRE over IP so they can be routed.

for a middle

Explain what each needs from the path: the reserved VLAN end to end for RSPAN; routing plus MTU headroom for ERSPAN's added headers; capacity on links shared with production for both.

for a senior

Show production judgment: copies compete with real traffic, ERSPAN's Don't Fragment bit forces truncation or a larger MTU, its packets are unencrypted, and GRE sequence gaps expose loss in transit.

for a principal

Weigh a remote-mirroring fabric that consumes production capacity and exposes copies in clear against dedicated monitoring links or local TAPs feeding a central toolset.

## The problem: the tools are somewhere else A local mirror session needs the capture host on the same switch as the traffic. In practice the analysis tools sit in one place and the traffic of interest is everywhere, so the copies have to travel. Two vendor extensions of port mirroring do this, and they make very different demands on the network in between. ## RSPAN: copies in a reserved VLAN **RSPAN** (remote SPAN) is a vendor feature with no RFC. It moves copies at layer 2: 1. The source switch places each copied frame into a VLAN reserved for the mirror session. 2. Trunks between switches carry that VLAN like any other. On typical implementations MAC learning is disabled in it, so the copies are flooded along the VLAN instead of being forwarded towards a learned port. 3. The destination switch copies everything arriving in that VLAN to its local destination port. What it demands of the path: - **An unbroken layer-2 path.** Every switch and trunk between source and destination must carry the reserved VLAN; a routed hop ends it. - **Trunk capacity.** The copies share trunks with production frames, so a heavy mirror can congest a trunk that real traffic depends on. - **Discipline with the VLAN.** It must carry nothing but copies; a host placed in it would receive the whole mirror feed. - Typically the copy travels tagged with the reserved VLAN, so the frame's original VLAN is not carried along with it. ## ERSPAN: copies in GRE over IP **ERSPAN** is described in `draft-foschiano-erspan-03`, an Informational Internet-Draft that expired in August 2017 and was never published as an RFC. The source wraps each copy in an outer Ethernet header, an IPv4 header, a **GRE** header in RFC 1701's format (GRE travels as IP protocol 47, per RFC 2784) and, from Type II on, an ERSPAN header. The result is an ordinary IP packet, so it can be **routed** to any reachable address - the draft notes the destination address may even front an analyser that has no address of its own. | Property (per the draft) | Type I | Type II | Type III | |---|---|---|---| | GRE protocol type | 0x88BE | 0x88BE | 0x22EB | | GRE sequence number | absent | present, per packet per session | optional | | ERSPAN header | none | 8 octets | 12 octets, plus an optional 8-octet sub-header | | Headers added | 14 + 20 + 4 = 38 octets | 14 + 20 + 8 + 8 = 50 octets | larger again | What it demands of the path: - **MTU headroom.** The draft says ERSPAN packets have the IP Don't Fragment bit set by design. Type II puts 20 + 8 + 8 = 36 octets around the copied frame inside the IP packet, so a full-size 1,514-octet frame (1,500 octets of payload and its 14-octet header) becomes a **1,550-octet** IP packet. It cannot be fragmented, so either the path MTU is raised, or the source truncates copies to the session's configured MTU and sets the **T bit**; a copy sent larger than the path allows is discarded on the way. - **Capacity and priority.** Copies ride production links. The draft lets the operator set CoS and ToS per session - higher so copies survive congestion, lower so they are dropped before production traffic. - **A trusted path.** ERSPAN has no authentication or encryption. The draft offers only a configurable IP TTL to limit how far the packets reach, and notes they can be carried inside IPsec. A copy of sensitive traffic otherwise crosses the network in clear. - **Session identity.** A 10-bit Session ID must be unique between a source and its receivers; different source and destination pairs may reuse numbers. ## Seeing loss in transit Type II's GRE sequence number increments per packet per session, so a receiver that finds gaps knows copies were lost between the source and itself - on a congested link, or dropped for size. It says nothing about frames the source switch never copied in the first place; an oversubscribed source is invisible to it. ## Choosing between them 1. **RSPAN** when source and tools share one switched domain and the trunks have spare capacity. 2. **ERSPAN** when a routed hop intervenes or the tools sit at another site - after checking the MTU, the capacity and whether copies may cross that path unencrypted. 3. A **local session or a TAP** next to the tools when neither the trunks nor the routed path can carry the copies without hurting production. Both methods turn a monitoring feature into production traffic. The question to ask before enabling either is not "can the copies reach the tools?" but "what else do they share the path with?".

  • How can an ERSPAN receiver tell that copies were lost on the way?
    In Type II the GRE header carries a sequence number that increments per packet per session, so a gap means copies were lost between source and receiver - congestion, or packets dropped for exceeding the MTU with Don't Fragment set. It cannot reveal frames the source never copied, such as copies dropped inside an oversubscribed source switch. Type I has no sequence number at all.
  • Why might you lower the priority of ERSPAN traffic instead of raising it?
    Copies share production links. The ERSPAN draft lets the operator set CoS and ToS per session: raising them helps copies reach the analyser during congestion, which is when you most want to see traffic, but they then compete with the production traffic causing it. Lowering them makes copies the first thing dropped, protecting production at the cost of a gappy capture.

saying these in an interview costs you the question

  • ERSPAN is an IETF standard defined in its own RFC.
  • RSPAN crosses a routed hop as long as both ends use the same VLAN number.
  • ERSPAN copies are encrypted because they travel inside a GRE tunnel.
  • Remote mirror traffic uses spare capacity and cannot hurt production traffic.
  • An ERSPAN copy of a full-size frame fits through any 1,500-byte path.