A SPAN session mirrors both directions of two ports on one switch, and every packet between their hosts appears twice; why, and what does broker deduplication cost?
answer
- count the mirrored points
- in on one, out on the other
- receive-only copies each once
- routed copies are not identical
- a window and a field list
basics
~20 sEach packet enters on one mirrored port and leaves by the other, and both passes are copied. Receive-only mirroring on both ports copies each once; broker deduplication needs a window and a field list, and can discard genuine packets.
solid answer
~50 sA mirror copies a frame every time it crosses a mirrored point in a mirrored direction. A packet from host A on port 1 to host B on port 2 is copied as port 1's **receive** traffic and again as port 2's **transmit** traffic, so with both ports mirrored both ways every packet arrives twice and tools report doubled bytes and phantom retransmissions. The clean fix is at the source: mirror **receive only** on every source port, or both directions of just one port. A **packet broker** (a product category, not a standard) can remove unavoidable duplicates by digesting each packet and discarding repeats within a short window, but routed or multi-point copies differ in MAC addresses, VLAN tag, TTL and checksum, so it must ignore those fields - ignore too much and distinct packets collide, keep the window too short and late duplicates pass.
go deeper
Recall that a packet entering one mirrored port and leaving another is copied at each, so the capture shows it twice.
Explain which direction settings copy each packet once, such as receive-only on every source port, and why routed copies differ in MAC addresses and TTL.
Show the cost of broker deduplication: which fields to ignore, how long a window to keep, and how an over-broad match can delete genuine repeated packets.
Design the visibility layer so duplicates are rare by construction, keeping broker deduplication for unavoidable multi-point copies and documenting what it may discard.
## Where the second copy comes from A mirror session copies a frame each time it passes a mirrored point in a mirrored direction. Take host A on port 1 and host B on port 2 of the same switch, with both ports mirrored in **both directions**: 1. A sends a packet to B. It enters the switch on port 1 and is copied as port 1's receive traffic. 2. The switch forwards it out of port 2, and it is copied again as port 2's transmit traffic. 3. B's reply enters on port 2 and leaves on port 1, and is copied twice in the same way. Every packet between the two hosts therefore reaches the capture host twice, a few microseconds apart. Analysis tools then report doubled byte counts, apparent retransmissions and implausible round-trip times - none of which exist on the wire. | Mirror configuration | Copies of each packet between A and B | |---|---| | Port 1, both directions | 1 | | Ports 1 and 2, receive only | 1 | | Ports 1 and 2, transmit only | 1 | | Ports 1 and 2, both directions | 2 | ## Fixing it at the source The cheapest fix is to copy each packet once: - mirror **receive only** on every source port, so each packet is copied where it enters the switch; or - mirror **both directions of one port** when the subject is one host's traffic. Receive-only on all sources has one gap to remember: traffic that enters on a port which is not a source - from an uplink, say - and leaves by a mirrored port is not copied. Choose the source set so every path of interest enters through it. ## Duplicates that are not identical When the switch **routes** between A's VLAN and B's VLAN, the two copies differ. The transmit copy carries new source and destination MAC addresses, an IPv4 TTL one lower and therefore a different header checksum, and possibly a different VLAN tag. The same is true when two switches along a path both mirror the same packet. A byte-for-byte comparison will not recognise these as one packet. ## What a packet broker does A **packet broker** is a product category, not a standard: a device that sits between many TAP and SPAN feeds and the analysis tools. Its typical functions: - **aggregation** of many feeds onto fewer tool ports; - **filtering**, so each tool receives only the traffic it needs; - **deduplication** of copies seen more than once; - **load balancing** one feed across several tools, hashing so both directions of a session reach the same tool; - **slicing**, truncating copies when only the headers matter. ## How deduplication works, and what it costs A broker typically computes a digest over chosen parts of each packet and discards a packet whose digest it has already seen within a short **window**. Each choice has a price: 1. **Field selection.** To match routed or multi-point duplicates the digest must ignore what changes hop by hop - MAC addresses, VLAN tag, TTL, header checksum. Ignore too much and two distinct packets collide: a genuine repeat that differs from the original only in an ignored field is discarded as a duplicate, removing exactly the evidence of loss you may be hunting. 2. **Window length.** Copies from a distant mirror point arrive later than local ones; if the gap exceeds the window, both copies reach the tool. A longer window costs memory at line rate and widens the chance of discarding a genuine repeat. 3. **Throughput.** Deduplication runs on every packet at line rate and consumes the broker's processing capacity, which is shared with its other functions. ## The design lesson Deduplication repairs a mirror configuration that copies too much. Fix the configuration first - receive-only sources, or one port in both directions - and keep broker deduplication for the duplicates you cannot avoid, such as copies of the same packet from several points along a path. Then write down what the deduplication rule ignores and how long its window is, because both decide which packets a tool will never see. An analyst who later finds fewer retransmissions than the endpoints reported should be able to read that record and know whether the broker removed them.
- Why can broker deduplication hide the very problem you are debugging?It discards any packet whose digest matches one seen within its window. If the digest ignores fields that distinguish two real packets, a genuine repeat - the same segment sent again - can be discarded as a mirror duplicate, so the capture shows less loss and fewer retransmissions than happened. Record the field list and window, and turn deduplication off when the investigation is about repeats.
- When a broker spreads one mirror feed across several tools, why must its hash be symmetric?Each tool needs both directions of a session to rebuild it. A hash over source and destination that gives a different result when they swap sends requests to one tool and replies to another, so neither sees a whole conversation. A symmetric hash, which gives the same result either way round, keeps each session on one tool.
saying these in an interview costs you the question
- Every duplicate in a SPAN capture is a real retransmission on the wire.
- Mirroring both directions on every port is the safe way to miss nothing.
- Routed copies of one packet are byte-identical, so exact matching removes them.
- Deduplication only removes extra copies and can never discard real evidence.
- A packet broker's deduplication behaviour is defined by an IETF standard.