skip to content

A switch port's CRC error counter keeps rising, yet a SPAN capture of that port shows no damaged frames; why, and how would you see them?

level: seniorimportance: should knowfreq 12%

answer

  1. where the check happens
  2. discarded before forwarding
  3. copies come from the pipeline
  4. the receiver counts the damage
  5. copy the light instead

basics

~20 s

The receiving port checks each frame's FCS and discards a damaged frame before the forwarding pipeline, where mirror copies are made, so a SPAN copy typically never includes it. A passive TAP plus a capture interface that keeps bad frames shows them.

solid answer

~50 s

Every Ethernet frame ends with a 4-octet frame check sequence. A store-and-forward switch recomputes it on receipt, **discards** a frame that fails and counts it as an input error; mirroring copies frames the forwarding pipeline handles, so the damaged ones typically never reach it. Runts, oversized frames and some layer-2 control frames are typically missing for the same reason, though platforms differ. The ERSPAN draft makes the same assumption explicit: Type I and II drop the original CRC, so the receiver cannot check it, while Type III's BSO field can flag bad, short or oversized frames. To see the damage: read receive error counters on both ends - the receiver counts it, so the fault is in whatever feeds that port - then put a passive optical TAP on the link, which copies the light itself, and capture on an interface set to keep frames with a bad FCS.

go deeper

for a junior

Recall that a switch drops frames whose checksum fails when they arrive, so a mirror of that port typically never copies them.

for a middle

Explain the order: the receiving MAC checks the FCS, discards and counts bad frames, and only frames that survive reach the forwarding pipeline where copies are made.

for a senior

Read receive error counters on both ends to locate the damaged direction, and use a passive TAP plus a capture interface that keeps bad frames when you need the frames themselves.

for a principal

Recognise that a mirror delivers only what the switch accepted, and reserve TAP-based capture for link-integrity evidence rather than assuming any mirror shows the wire.

## Where the CRC check happens Every Ethernet frame ends with a 4-octet **frame check sequence** (FCS), a CRC computed by the sender over the frame. The receiving port recomputes it; a frame whose CRC does not match was damaged on the way - a bad cable or connector, dirty optics, interference, a failing transmitter. A store-and-forward switch checks the FCS once the whole frame has arrived, **discards** a frame that fails, and counts it. IF-MIB's `ifInErrors` counts "inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol", and platforms usually break that total down further into CRC, runt and oversize counters. ## Why the mirror never sees it Port mirroring is a feature of the switch's forwarding pipeline: copies are made of frames that the pipeline handles. A frame discarded by the receiving MAC never reaches that stage. So on typical platforms: - **frames failing the FCS check** are counted but not copied; - **runts and oversized frames** are discarded and counted the same way; - **some layer-2 control frames** are not copied - IEEE 802.3 flow-control PAUSE frames are consumed by the receiving MAC, and on some platforms protocol frames sent to reserved multicast addresses go to the control plane without being mirrored; - the original **VLAN tag** may be removed or rewritten on the copy, depending on the platform and the session settings. A cut-through switch, which starts forwarding before the FCS has arrived, can pass a damaged frame on, so on such platforms a damaged frame can appear in the forwarded traffic and in the mirror. That is why every statement here says "typically": port mirroring has no standard, and what a session copies is platform behaviour. ## What ERSPAN does with the CRC The ERSPAN draft (`draft-foschiano-erspan-03`, Informational, never an RFC) states the same assumption outright. Type II copies - and, the draft notes, Type I copies - **exclude the original CRC**; Type II appends a new 4-octet CRC computed over the whole encapsulated frame, so on the receiving device "it is not possible to verify the CRC correctness of the original frame" - the draft says the assumption is "simply that only uncorrupted frames are mirrored". Type III adds a 2-bit **BSO** (Bad/Short/Oversized) field describing the payload: | BSO | Meaning in the draft | |---|---| | 00 | good frame with no error, or unknown integrity | | 01 | short frame | | 10 | oversized frame | | 11 | bad frame with a CRC or alignment error | The draft also notes that Type III's fields let a platform mirror "even an errored frame or a bridge PDU (BPDU) frame" - exactly the cases an ordinary mirror leaves out. ## How to actually see the damage 1. **Read the counters first.** CRC errors are counted by the receiver, so a rising input CRC count on a port points at whatever feeds it: the cable, the optics, a patch panel or the far end's transmitter. Compare with the far end's receive counters; damage is often one-way, and the clean direction narrows the search. 2. **Tap the link.** A passive optical TAP copies the light itself, so damaged frames reach its monitor output just as they reach the switch. An active copper TAP regenerates the signal, and whether it passes damaged frames on is a product property. 3. **Keep them at the capture host.** Many network interfaces discard frames with a bad FCS before software sees them; keeping them is a capture-interface setting, separate from how the copy is delivered. 4. **Or use a mirror that marks them**, such as ERSPAN Type III's BSO field, on a platform that supports it. ## Why it matters The question behind this scenario is usually "is the link damaging traffic, and in which direction?". A clean mirror capture cannot answer it - it shows only what survived the CRC check. Counters on both ends answer the direction question cheaply, and a TAP is the only way to put the damaged frames themselves in front of an analyser. Pointing a mirror at the far switch's transmit side does not help either: that switch typically copies a frame before it meets whatever damages it - the optic, the cable or the connectors downstream - so the copy is the intact version. The practical order of work is therefore cheap to expensive: counters on both ends first, then a TAP only when the damaged frames themselves are needed as evidence, for example to show a supplier that a particular optic corrupts a particular pattern.

  • Which end's counters tell you where the frames are being damaged?
    The receiving end's. A port counts CRC errors on frames it receives, so rising input errors on port A mean the damage happens between the far transmitter and A: the far end's transmitter or optic, the cable, or A's own receiver. The far end's receive counters show whether the other direction is clean, which often isolates a single fibre or optic.
  • What does ERSPAN Type III add for damaged frames?
    A 2-bit BSO field describing the copied payload: 00 good or unknown, 01 short, 10 oversized, 11 bad with a CRC or alignment error. That lets a platform that mirrors errored frames say so to the receiver, which Type I and Type II cannot, because they drop the original CRC and assume only uncorrupted frames were copied.

saying these in an interview costs you the question

  • A SPAN capture shows every frame the port received, damaged ones included.
  • Rising input CRC errors mean the port's own transmitter is corrupting frames.
  • ERSPAN Type II keeps the original FCS, so the receiver can verify it.
  • Mirroring the far switch's transmit side will capture the damaged frames.
  • A clean mirror capture proves the port's CRC error counter is wrong.