I'm using the following points when discussing the situation.
- Taps free SPAN ports for tactical, on-demand monitoring, especially intra-switch monitoring. Many switches have only two ports capable of SPAN, and some offer only one. If you commit a SPAN port for permanent monitoring duties, and you need to reassign it for some sort of troubleshooting on a VLAN or other aspect of the traffic, you have to deny traffic to your sensor while the SPAN port is doing other work. Keep your SPAN ports free so you can do intra-switch monitoring when you need it.
- Taps provide strategic, persistent monitoring. Installing a tap means you commit to a permanent method of access to network traffic. Once the tap is installed you don't need to worry about how you are going to access network traffic again. Taps should really be part of any network deployment, especially at key points in the network.
- Selected taps do not permit injected traffic onto the monitored link. Depending on the tap you deploy, you will find that it will not be physically capable of transmitting traffic from the sensor to the monitored link. This is not true of SPAN ports. Yes, you can configure SPAN ports to not transmit traffic, and that is the norm. However, from my consulting days I can remember one location where I was told to deploy a sensor on a box with one NIC. Yes, one NIC. That meant the same NIC used for remote SSH access also connected to a switch SPAN port. Yes, I felt dirty.
- What taps see is not influenced by configuration (as is the case with SPAN ports); i.e., what you see is really what is passing on the link. This is key, yet underestimated. If you own the sensor connected to a SPAN port, but not the switch, you are at the mercy of the switch owner. If the switch owner mistakenly or intentionally configures the SPAN port to not show all the traffic it should, you may or may not discover the misconfiguration. I have seen this happen countless times. With a network tap, there's no hiding the traffic passing on the monitored link. Many shops have been surprised by what is traversing a link when the finally take a direct look at the traffic.
- Taps do not place traffic on a switch data plane, like a SPAN port does. This point is debatable. Depending on switch architecture, SPAN ports may or may not affect the switch's ability to pass traffic. By that I mean a SPAN port may not receive all traffic when the switch is loaded, because forwarding may take precedence over SPANning.
There are other reasons to prefer network taps, but I'll direct you to the links I provided. Those are good resources.
Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.