On this page
01 What a mirror port does, and the three directions
A switch delivers a unicast frame only to the port where the destination MAC lives. Port mirroring adds a second delivery: the hardware copies frames matching a source port (or VLAN, on some platforms) to a designated destination port, which stops acting as a normal switch port and only transmits copies. A capture host or IDS sensor plugs into it.
Mirroring is directional. Ingress (input) copies frames arriving at the source port from the attached device; egress (output) copies frames the switch sends out of it; both copies everything. Some platforms cannot mirror egress on every port type or strip VLAN tags from egress copies; check the capture for tags before diagnosing VLAN problems.
02 Oversubscription: mirroring 10G to 1G
The destination port has one transmit direction; the source has two. A 1 gigabit source running flat out both ways produces 2 gigabits per second of copies for a destination that carries 1. A 10 gigabit source mirrored to 1 gigabit can be oversubscribed twenty to one. The switch silently discards the excess; the capture shows gaps and one-sided conversations. Avoid it by mirroring one direction, using a faster destination, filtering to a VLAN or host where supported, or using a TAP.
03 Remote mirroring
When the capture host is on another switch, remote mirroring carries copies across the network, either in a dedicated mirroring VLAN trunked to the switch with the capture port (carrying nothing else, MAC learning disabled) or in a GRE-style tunnel to a remote address, which crosses routed boundaries at the cost of extra headers and possible MTU overrun. Both consume bandwidth on every link in between, so the oversubscription arithmetic applies to trunks and aggregated links too.
04 TAP versus mirror port
| Property | Mirror / SPAN port | Network TAP |
|---|---|---|
| Fidelity | Best-effort; drops under load, may strip tags or errored frames | Every bit including corrupt frames, both directions |
| Impact on production | Config change only | Brief link outage to insert |
| Cost | Free if a spare port exists | Hardware per link, dual-input capture card |
| Best for | Troubleshooting, ad hoc capture | Permanent monitoring, forensics, high-speed links |
05 Procedure: configure, capture, verify, remove
Choose the destination port and prepare the capture host
Pick a port at least as fast as the expected copy volume, with nothing in production attached; it will stop switching normal traffic. On the capture host strip the interface of protocols (no IP address, no discovery, no reassembly offloads) and capture to disk with a ring buffer.
Designate the mirror port
In global configuration on an IronWare-style switch the shape is
mirror-port ethernet 1/24, naming the destination. Other platforms use a monitor session with a destination statement.Enable monitoring on the source
On the source interface set the direction:
monitor both, ormonitor inputormonitor outputfor one direction. Newer releases name the destination, for examplemonitor ethernet 1/24 both.Start the capture and verify
Run
show monitorto confirm source, destination and direction, then start the capture filtered on a host known to be active behind the source port. Frames should appear within seconds.Check for drops, then remove the mirror
Compare destination counters with the sum of source counters over the same minute; a shortfall means oversubscription. When finished, remove the monitor statement and the mirror-port designation. A forgotten mirror copies production traffic to whatever is plugged in later.
mirror-port ethernet 1/24 interface ethernet 1/5 monitor both
show monitor show mirror
06 Port mirroring worked example: one session, one capture
A web server behind port 1/5 is suspected of receiving a scripted crawl. The goal is thirty minutes of both directions, written to disk, with proof that nothing was dropped. The session below runs on an IronWare-style switch and a Linux capture host on port 1/24. Addresses are documentation ranges; the commands are the generic shape, not a drop-in configuration.
sw1# configure terminal sw1(config)# mirror-port ethernet 1/24 sw1(config)# interface ethernet 1/5 sw1(config-if-e1000-1/5)# monitor both sw1(config-if-e1000-1/5)# end sw1# show monitor Monitored Port 1/5 Direction: both Mirror Port: 1/24 $ ip link set eth1 up promisc on $ ethtool -K eth1 gro off lro off tso off rx-vlan-offload off $ tcpdump -i eth1 -nn -s 0 -B 65536 -G 1800 -W 1 -w /cap/e1-5-%Y%m%d-%H%M.pcap tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 1,914,203 packets captured 1,914,203 packets received by filter 0 packets dropped by kernel sw1# show statistics ethernet 1/5 | include packets InPackets 1,102,884 OutPackets 811,319 sw1(config)# interface ethernet 1/5 sw1(config-if-e1000-1/5)# no monitor sw1(config)# no mirror-port ethernet 1/24
The arithmetic at the end is the verification. The source port counted 1,102,884 in and 811,319 out over the window, 1,914,203 in total, and the capture holds 1,914,203 frames with zero kernel drops. When those three numbers disagree, the shortfall sits either at the switch (destination port discards, from oversubscription) or at the host (kernel drops, from a small buffer or a slow disk), and the two are told apart by which counter is short. The ethtool line matters more than it looks: with receive offloads on, the kernel merges consecutive segments before the capture library sees them, and the file shows frames far larger than the MTU that never existed on the wire.
| Failure mode | Symptom in the capture | Fix |
|---|---|---|
| Oversubscribed destination | One-sided TCP conversations, gaps in sequence numbers, switch discards on the mirror port | Mirror one direction, use a faster destination, filter to a VLAN or host, or use a TAP |
| Receive offload on the host | Frames of 20 to 64 KB, checksum errors on outgoing traffic | Disable GRO, LRO and TSO on the capture interface |
| Small capture buffer | Kernel drop count rises under bursts | Raise the buffer, write to a fast disk, filter earlier |
| VLAN tags stripped | Trunk traffic appears untagged, VLAN problems invisible | Check platform behaviour; mirror an access port or use a TAP |
| Mirror left running | Production traffic copied to whatever is plugged in later | Remove the monitor and mirror-port statements when done; audit with show monitor |
| Spanning tree on the destination | Capture starts 30 seconds late, or the port cycles | Confirm the platform disables STP on the mirror port; otherwise set it as an edge port |
07 Verifying with a packet capture
Check three things. Bidirectionality: one TCP conversation should show both request and response segments; one side only means the direction is wrong or egress copies are unsupported. VLAN tags: a trunk source with no tags means the platform strips them. Drops: the capture tool reports kernel drops and the destination counters reveal discards. If any fail under load, narrow the mirror or move to a TAP. sFlow is the complement: sample every port cheaply to decide which deserves a full capture. A short capture from the mirror port is also the quickest way to collect the source addresses, SNI names and connection pacing of a suspected crawler before checking it as described in identifying AI crawlers at the edge. For the long view, interface counters polled through the SNMP interface MIBs show whether the pattern persists, and the network monitoring index links the remaining tools.
08 Privacy and legal note
A mirror port captures the content of communications, not just headers. Most jurisdictions require that the network operator has a legitimate operational purpose, that users have been notified through an acceptable use policy, or both. Capture only what the investigation needs, store captures encrypted with a retention limit, and remove the mirror when done.
09 Expert tips
- Name the file for the switch, port and time, and record the mirror session in the change log. A capture file with no provenance is hard to use in any dispute.
- Time the host with NTP before the capture, then compare the first frame's timestamp with the switch clock. A capture that is 40 seconds off is difficult to align with proxy logs.
- Read the SYNs and the ClientHellos before the payload. TTL, window and cipher order per client, scored the way the per-client signals from TCP and TLS are, often answer the crawler question without decrypting anything.
- Treat the destination port as untrusted. It transmits copies of production traffic; anything plugged into it should be the capture host and nothing else, and the switch should not learn MAC addresses from it. The spanning tree guide explains what a port that neither learns nor forwards does to the topology.
10 Questions
What is the difference between port mirroring and SPAN?
None. SPAN (Switched Port Analyzer) is one vendor name; mirror port, monitor port and analyser port are others. All describe the switch copying frames from a source port or VLAN to a destination port for a capture device.
Why is my mirrored capture missing packets?
Usually oversubscription. A full-duplex source produces copies in both directions, so a 1 gigabit source can exceed a 1 gigabit destination, and 10 gigabit mirrored to 1 gigabit loses data under load. Mirror one direction, use a faster destination, or a TAP.
Does port mirroring affect the traffic being mirrored?
On a modern switch, no. The copy is made in hardware alongside normal forwarding and the source port keeps switching at full rate. Remote mirroring is the exception: copies consume bandwidth on the trunks they cross.
Can a mirror port see traffic between two hosts on other ports?
Only if one of those ports is the source, or the platform supports VLAN mirroring and both hosts are in the mirrored VLAN. A switch delivers unicast frames only to the destination port, so a mirror elsewhere sees only broadcasts and floods.
When should a TAP be used instead of a mirror port?
When every frame matters: forensics, compliance recording, high-speed links, or any capture that must include errored frames and exact timing. A TAP is passive and lossless. A mirror port is best-effort and can drop copies under load or strip VLAN tags.
Why does my mirrored capture show frames larger than the MTU?
Receive offloading on the capture host. The network card or kernel merges consecutive TCP segments into one large buffer before the capture library reads them, so the file shows frames of tens of kilobytes that never existed on the wire. Disable generic and large receive offload on the capture interface and the frames return to wire size.