A library SPAN session mirrors a busy uplink onto a 1-Gbps analyzer port and staff notice drops and incomplete captures during peaks. What operational constraint best explains that behavior?

The library SPAN session mirrors a busy uplink onto a 1-Gbps analyzer port, and staff see drops and incomplete captures during peaks. The operational constraint is classic SPAN oversubscription: when the aggregate mirrored traffic exceeds the capacity of the destination analyzer port (or the SPAN session’s ability to copy without loss), frames are dropped and captures become incomplete. A busy uplink can easily exceed 1 Gbps of interesting traffic, especially if multiple sources feed one session, so the analyzer port becomes the bottleneck even though the production uplink itself may be healthy.

The claim that SPAN automatically upgrades the destination port to the sum of all source interface speeds fails by concept—SPAN does not renegotiate or invent bandwidth; the destination physical/logical capacity is fixed. Saying RSPAN VLANs compress mirrored frames so oversubscription cannot occur is false: RSPAN carries mirrored traffic and can congest trunks; it does not magically compress away oversubscription. Claiming ERSPAN disables CEF and therefore cannot drop on the destination mixes unrelated ideas; ERSPAN still has capacity and path limits and does not exempt destinations from drops.

Exam caveat: always size SPAN destinations for worst-case mirrored load, filter sources when possible, and remember SPAN destinations are typically not used for normal forwarding. Incomplete captures are often capacity problems, not mysterious analyzer software bugs.

Operational check for the library: compare peak mirrored volume to analyzer port speed, reduce source scope or use filters, consider a faster analyzer attachment or multiple sessions, and validate capture completeness during busy hours rather than only in off-peak tests.