An IDS team says its SPAN feed of a 10 Gb/s link misses packets, though the link averages only 4 Gb/s in and 3 Gb/s out; why?
answer
- two directions, one exit
- averages hide bursts
- a buffer lasts milliseconds
- copies are dropped first
- count in plus out against sent
basics
~20 sBoth directions of the link converge on one 10 Gb/s destination port, so coinciding bursts offer up to 20 Gb/s. The egress buffer fills within milliseconds and the switch drops the surplus copies first, even though the averages total only 7 Gb/s.
solid answer
~50 sA mirror of **both directions** of a full-duplex 10 Gb/s link sends two streams to one destination port, so copies can arrive at up to 20 Gb/s while the port sends 10. The 4 + 3 = 7 Gb/s figure is a minutes-long average; at millisecond scale bursts in both directions can coincide near line rate. The egress queue then grows at about 10 Gb/s - 1.25 GB per second - so a buffer of a couple of megabytes lasts under two milliseconds, and after that the excess copies are dropped. Switches typically protect production forwarding, so copies go first and nothing on the network looks wrong. Prove it by comparing the source port's in-plus-out packet counts, the destination's transmitted packets and output discards, and the capture's count over one window; fix it with a breakout TAP into two ports, a faster destination, or by mirroring less.
go deeper
Recall that mirroring both directions of a link can send up to twice the link's speed to one destination port, which then drops copies.
Explain why averages under the port speed still lose copies: bursts in both directions coincide, the egress buffer fills in milliseconds, and mirror copies are dropped first.
Show the diagnosis - source in-plus-out counts, destination transmits and output discards, and the capture count over one window - then fix delivery with a breakout TAP or a faster port.
Decide which links need full-fidelity copies and fund ports and TAPs for their peak, accepting documented one-direction or filtered mirrors elsewhere.
## Two directions, one exit A mirror session that copies **both directions** of a full-duplex port sends two streams to one place. A 10 Gb/s full-duplex link can carry 10 Gb/s in each direction at the same time, so the copies can arrive at up to **20 Gb/s** while the destination port can transmit only 10 Gb/s. Every copy has to leave through that single port's egress queue, which is where the trouble starts. ## Why the averages lie The link in the scenario averages 4 Gb/s in and 3 Gb/s out - 7 Gb/s combined, comfortably under 10 on a five-minute graph. But an average over minutes is built from bursts measured in microseconds and milliseconds. A bulk transfer in one direction can coincide with a burst of replies or another transfer in the other, and while both run near line rate the destination receives copies at close to 20 Gb/s. The egress buffer absorbs that difference only briefly: 1. Copies arrive at 20 Gb/s and leave at 10 Gb/s, so the queue grows at 10 Gb/s, which is 1.25 GB per second. 2. With, say, 2 MB of buffer available to that port (buffer sizes, and how they are shared between ports, are platform properties), the queue is full after 2,000,000 / 1,250,000,000 s = **1.6 ms**. 3. From then on, every copy beyond 10 Gb/s is discarded until the burst ends. When the averages themselves exceed the port, no buffer helps. At 6 Gb/s each way, 12 Gb/s is offered to a 10 Gb/s port, and at least 2 / 12 - about **17 %** - of the copies are lost, before any burst is counted. ## Mirror copies come last On typical platforms the switch protects production forwarding. Mirrored copies are served at lower priority, and when buffers or replication resources run short the copies are dropped while the original frames are forwarded normally. That is why the network looks healthy while the capture has holes: there is no production fault to see. Because port mirroring has no standard, the exact policy - and whether several sessions share one replication budget - is platform-specific, and it is worth reading for the switch in question. ## Proving where the loss is Count packets at each stage over the same window: - the **source port's** received and transmitted packet counters - what the mirror should have copied, in plus out; - the **destination port's** transmitted packets and its **output discards**. IF-MIB defines `ifOutDiscards` as outbound packets "chosen to be discarded even though no errors had been detected to prevent their being transmitted", which is where many platforms count mirror drops; some do not count them at all, and then the arithmetic above has to bound the loss; - the **capture host's** received count. If the source's in-plus-out exceeds what the destination transmitted, the mirror dropped copies. If the destination sent everything and the capture still lacks packets, the loss is on the capture host - a separate stage with its own buffers and counters. A capture filter on the host cannot help with mirror loss: the switch has discarded the copies before any filter sees them. ## Fixing it at the delivery layer | Change | Effect on a 20 Gb/s peak | Cost | |---|---|---| | Breakout TAP, one 10 Gb/s capture port per direction | each direction has its own 10 Gb/s | a link break to insert, two capture ports, merging in the tool | | Faster destination port | headroom for both directions | a capture host that can take the rate | | Mirror one direction, or filter the session | less is offered | the capture shows less | | Truncate copies, where the platform supports it | fewer bits per copy | payload beyond the cut is gone; the packet rate is unchanged | | Aggregating TAP onto one 10 Gb/s port | none | the same convergence, so the same drops | A **packet broker** can also spread one feed across several tools, hashing so both directions of a session reach the same tool, but only if its input ports can take the full rate in the first place. ## The interview answer in one line "Both directions share one exit, bursts coincide, the buffer lasts milliseconds, and copies are dropped first - so measure in-plus-out against what left the destination, then give each direction its own port." An answer that stops at "the link is only at 70 %" has missed the convergence, and one that blames the capture host without checking the destination's counters has skipped a stage.
- How do you show the loss happens at the mirror and not on the capture host?Take the same time window at three stages: the source port's received plus transmitted packets, the destination port's transmitted packets and output discards, and the capture host's received count. A gap between source in-plus-out and destination transmits, or rising output discards, puts the loss in the switch. If the destination sent everything, the capture host is dropping.
- Why doesn't an aggregating TAP fix an oversubscribed mirror?It merges both directions onto one output exactly as the mirror merges them onto one destination port. Two 10 Gb/s directions into one 10 Gb/s output still overflow whenever their sum stays above 10 Gb/s longer than the TAP's buffer lasts. A breakout TAP, with each direction on its own output and capture port, removes the convergence.
- Does truncating mirrored copies cure the drops?Only when the bottleneck is bits per second. Truncation shortens each copy, so a burst of large frames takes far less of the destination port's capacity. It does nothing for a limit on packets per second, and the payload beyond the cut is gone, which rules it out when the tool needs full content.
saying these in an interview costs you the question
- If the combined average is under the destination's speed, the mirror cannot drop copies.
- A 10 Gb/s destination port is enough to mirror both directions of a 10 Gb/s link.
- When copies are dropped, the switch also drops the original frames on the source port.
- An aggregating TAP solves the oversubscription that a SPAN destination suffers.
- A capture filter on the host reduces what the switch must send to the mirror port.