Port mirroring (SPAN, or Switched Port Analyzer) is the basic way to troubleshoot a network: it copies the packets on a chosen port to a monitor port so a capture PC can read them, while the original forwarding is completely untouched. When a camera suddenly floods broadcast, a device phones home to malware, or VLANs start talking across each other, watching the port LED blink tells you nothing—you need the actual packets. Rayin's managed industrial switches support local SPAN and RSPAN sessions configured through CLI or Web, so you can capture any port's traffic without touching live forwarding.
Standard SPAN only copies packets to the monitor port; it never intercepts them, so mirrored traffic keeps forwarding at full speed.
The monitor port rate must be ≥ the mirrored direction's peak rate—mirroring a 2 × 1 Gbps uplink (peaking 1.5–2 Gbps) needs a 10GE monitor port or you capture only fragments.
RSPAN carries the copy across devices inside a dedicated Remote-VLAN; ERSPAN (Layer-3 GRE) can even send the mirror across a routed network to a central capture server.
Mirror full streams only when needed; pair SPAN with an ACL so the monitor port sees only the anomalous flow, and mark the mirror with low IEEE 802.1p priority.
Short answer: no. Standard port mirroring only replicates—the source port forwards normally and the monitor port receives a copy. So enabling mirroring does not slow the business traffic; the only cost is that the monitor port's bandwidth is consumed by the mirrored stream.
The real mistake is practical: people swap the monitor port and the business port, or pick a monitor port slower than the mirrored traffic peak, so the capture PC receives only fragments and never a full session. The mirror port rate must be ≥ the total rate of the mirrored direction.
Local mirroring is the simplest: within one switch, source port → destination port, and the capture PC plugs into the destination. Cross-device capture needs RSPAN: the mirror traffic is tagged with a dedicated Remote-VLAN and carried transparently through the Layer-2/3 network, then untagged at the destination switch's monitor port. That Remote-VLAN must be separate and must not carry normal business traffic, or the mirror flood hits the production network.
Some high-end models also support ERSPAN (Layer-3 GRE encapsulation), which can ship the mirror across a routed network to a central capture server.
| Method | Scope | Key constraint | Typical use |
|---|---|---|---|
| Local SPAN | Within one switch | Monitor port rate ≥ source rate | Single-device packet capture |
| RSPAN | Same Layer-2 domain, cross-device | Dedicated, isolated Remote-VLAN | Aggregate switch mirroring to a remote site |
| ERSPAN | Across Layer-3 routing | GRE encapsulation, route reachable | Central capture server collecting many sites |
Decide what you are capturing: an uplink (to see inside/outside traffic) or a downlink (to watch a single device)? Pick a free monitor port with enough rate. Never use a business port as the monitor port—its terminal would receive the mirrored copy and be disturbed.
Most vendors expose a "mirror" item in Web or CLI. Create a session and set the mode to local or remote. A switch can run multiple sessions, but the same destination port usually belongs to only one session, to avoid copies overwriting each other.
The source port can be set to a direction: ingress (rx, only what it receives), egress (tx, only what it sends), or both. To find "who is sending out," pick tx or both; to find "what attack it received," pick rx. Multiple source ports can mirror to one destination (1:N), bounded by the destination's bandwidth—do not mirror a 10GE uplink both-ways to a 1GE port.
Bind the monitor port to the session's destination side and enable the session. Open Wireshark on the capture PC and you will see the source port's packet copies. IEEE 802.1Q tags are preserved, so filter by VLAN ID.
Tip: Match the mirror direction to the question. "Who is spamming broadcast?" → tx or both on the suspect port. "What attack arrived?" → rx. Picking both on a busy uplink just fills the monitor port fast.
After capturing, confirm the direction is right and there is no packet loss (watch the monitor port's receive counter grow with traffic). When done, close the mirror session—leaving it open keeps the monitor port saturated, wastes switch-chip replication resources, and may leak packet copies beyond the capture PC.
Mirroring the full stream wastes monitor bandwidth. A sharper method: configure an ACL that matches only the anomaly (a VLAN, a broadcast type, a MAC), then set the mirror source to "the flow matching the ACL" so the monitor port sees only what matters.
On fiber ports, glance at the SFP DDM readout while mirroring: if Rx optical power drops below −27 dBm (Class C+ receive sensitivity is about −27 dBm; Class B+ about −25 dBm), the link is already at the critical edge and the anomaly may just be CRC errors from attenuation. With IEEE 802.1p priority, you can also mark the mirror flow low-priority so it never steals business bandwidth. A managed PoE switch usually exposes both the ACL and the mirror session in the same Web UI, so you can scope the capture without leaving the page.
Warning: Five classic mirror failures—monitor port too slow (fragments only); uplink both-ways mirrored to a 1GE port (instant saturation); Remote-VLAN not isolated (mirror leaks into the business network); session left running (long-term resource waste); and assuming mirroring can alter packets (it only copies, never intervenes).
What is port mirroring (SPAN) on a switch? Port mirroring, also called SPAN (Switched Port Analyzer), copies the packets on one or more source ports to a dedicated monitor port so a capture tool like Wireshark can read them. It replicates traffic only—the source port's forwarding is never changed or slowed.
Does port mirroring slow down the network? No. Standard SPAN only copies packets to the monitor port; the mirrored traffic keeps forwarding at full line rate. The only limit is that the monitor port's bandwidth must be at least the mirrored direction's peak rate, or the capture will be incomplete.
What is the difference between local SPAN and RSPAN? Local SPAN copies traffic within a single switch from a source port to a destination port. RSPAN (Remote SPAN) extends this across devices by carrying the mirrored traffic inside a dedicated Remote-VLAN through the Layer-2/3 network to a monitor port on another switch.
Can port mirroring send traffic across a routed network? Yes, on models that support ERSPAN. ERSPAN wraps the mirrored packets in Layer-3 GRE encapsulation, so the copy can cross routed links and reach a central capture server—useful for collecting traffic from many sites.
Why should I pair port mirroring with an ACL? Mirroring a full stream can saturate the monitor port. By first matching the anomaly with an ACL (a VLAN, a broadcast type, or a MAC) and mirroring only that matched flow, the monitor port carries just the traffic you care about, cutting bandwidth pressure sharply.
Port mirroring is the first tool for any packet-level troubleshooting on industrial switches. Use local SPAN for a single device, RSPAN for cross-device capture, keep the monitor port fast enough, and close the session when you are done.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. She specializes in product selection and writes guides that help procurement engineers and system integrators work more efficiently. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
