Capturing traffic from multiple connections on a switch

Question

Consider the traffic monitoring setup on the bottom of this page: https://www.ntop.org/pf_ring/port-mirror-vs-network-tap/

The two lines of a network tap are connected to a switch which merges the traffic and then sends the traffic to a PC for analysis. I'm not sure, however, how this will work when multiple connections are used since one the of the desribed outcomes is that packages will be broadcasted to all other ports. As an example we want to monitor 3 100mbit connections over copper and use a passive tap. From each of the connections two cables will go to the switch and overall 6 ports will be occupied. The switch will then mirror all these ports into a single (TX ?) connection e.g. to a port with a SFP adapter. Since, according to the website, no traffic from the monitoring PC should be send back to the switch just connecting TX of the SFP to RX of the SFP on the PC should be enough. According to the website an alternative would be using ethernet and cutting the TX side from the PC.

But what would happen with the broadcasted traffic from port 1 to e.g. port 6? Would port 6 broadcast that traffic again to all other different ports resulting in a broadcast storm? If yes, what would be appropriate countermeasures? Is it possible to disable broadcasting and only send traffic to the specific SFP port?

Answer 1

This depends largely on your switch.

E.g. on HP Provision switches, the monitored ports ingress and egress traffic is copied to the mirror port. When you monitor both port A and port B, you get A->B or vice versa flows twice on the mirror port with some devices and just once on others. I'm not sure about broadcasts, but you're likely to get a copy from each monitored port.

Since forwarding is only done with ingress frames, a frame exiting the mirror port will not be multiplied.

Usually you just monitor the traffic on a single port in both directions and that's not a problem.

When using a passive tap, the tap is a one-way connection (or rather two such connections), so nothing will ever flow back. The problem with aggregating multiple taps through a switch is that the switch won't have a destination port for pretty much any frame, so all frames are likely to be flooded to all switch ports (mimicking a repeater hub). learns all tapped MAC addresses as belonging to one of the tapping ports - this may cause frequent situation were a frame received on on tapping port is forwarded out (to nowhere) the other tapping port. You won't get a complete capture.

Also, you must not connect that switch back to the monitored network - this would create a bridge loop, causing a broadcast storm and SAT instability.

Cutting the transmit side (for dual-simplex connections like 10BASE-T, 100BASE-TX, 1000BASE-SX, ...) might not work. Using auto negotation requires both sides to see each other which won't work. You'd need to force speed and duplex on the port so the connection just relies on the carrier. This may not work with modern NICs (as very often you can't really deactivate autoneg, just limit it to a single speed and duplex mode).

Answer 2

As tap ports do not receive but transmit only, the switch has no clue who’s sitting behind the ports. The consequence is that it broadcast the packets to all ports.

Incorrect. Switches learn the location of nodes by watching the traffic entering each port. If a frame with src MAC X arrives on port 1, the switch records X=1. When it sees any subsequent frames with dst MAC X, that frame will be sent only to port 1. The monitor system on port 3 will see nothing.

In short, you cannot use a standard switch to aggregate taps or spans.

(If your switch has a knob to turn off mac learning, then it'll work -- because you've created a hub.)