Some of their assumptions are incorrect.
I primarily use the 6000, and 6500 switches, so most of my comments are based on exzperience with those switches, but will also apply to most of the other Cisco switches.
The Span session can be setup to monitor ports or vlans. It can also be setup to monitor rx (receive), tx (transmit), or both types of packets. So their statement that the span port only sees half the connection is incorrect. If you setup a span session to monitor both tx and rx traffic that port then the span destination (the sensor) will see both sides of connections going through that port.
As for over running the port. Yes it is possible, but it is because you can monitor multiple links, unlike TAPs which limit you to a single link. (A link being a physical connection between another device and the switch) To monitor both sides of that link it requires the sensor to have 2 sensing interfaces. The first interface monitors traffic going to the switch, while the second interface monitors traffic going to the other device. If you want to monitor multiple links then you have to have 2 more sniffing interfaces for each link you want to monitor.
The switch's span port, however, lets you monitor multiple links by designating multiple ports (or vlan(s)) to monitor. The traffic from all of these ports is then aggregated to the single span destination port connected to the single sniffing interface of the sensor.
So to monitor multiple links using TAPs you need 2 sniffing interfaces for each link. Then you still have to aggregate all the traffic speeds to determine how much the sensor can monitor.
Monitoring 2 half utilized 100Mbps Full Duplex links would require the sensor be able to monitor a minumum of 200 Mbps with 2 sniffing interfaces.
(Why 200 Mbps? A Full Duplex link allows 100 Mbps each way for a total of 200 Mbps per link. So 2 half utilized Full Duplex links results in 200 Mbps)
Monitoring the same 2 links hooked up to a swoitch would require a sensor that can monitor 200Mbps and have a single Gig link to the switch (i.e. the IDS-4235 or IDS-4250). If you tried to monitor this with the IDS-4230 with a single 100 Mbps interface, you would drop at least half the packets because the interface has a top limit of 100Mbps. But with the IDS-4235 with a Gig interface, the upper limit is more a function of how fast can the sensor process the packets rather than the speed of the interface.
Another scenarios with lets say 10 100Mbps Full Duplex connections that are only partially utilized connected to a switch. And let's say the aggregate bandwidth of all 10 connections is only 90 Mbps.
WIth TAPs you now need 20 sniffing interfaces on your sensor, and a sensing performance of at least 90 Mbps. This would result in no packet loss.
With a Span port (montoring both tx and rx for the ports) you need only 1 sniffing interface on your sensor, and a sensing performance of at least 90 Mbps (either IDS-4230, or IDS-4235).
NOTE: If you use either the IDS-4230 or IDS-4235 connected to a 100Mbps port on the switch you could still run into packet loss even through the aggregate bandwidth is only 90Mbps. It is possible to receive 20 packets all at the exact same time (2 from each port -tx + rx). In this situation, there is a buffer on the port connected to the sensor that will hold some of these packets waiting for sending to the sensor. But in many cases receiving that many at the same time will fill the buffer and cause some packets to be dropped.
So in this scenario, having 20 sensing interfaces woudl prevent the packet drops, but is it worth the extra cost. With the IDS-4235 connected using a Gig port instead of a 100Mpbs port the buffer is larger and the packets transmitted faster so the loss will be even less likely.
In the end if you are concerned about packet loss, I would recommend using the IDS-4235 or IDS-4250 with a Gig connection (not a 100 Mbps connection).
And remember to span both tx and rx when spanning single ports.
ANOTHER THING TO KEEP IN MIND.
When spanning a whole vlan it may not be necessary to span both tx and rx. If both port 1 and 2 are on the same vlan. Then to monitor connections between 1 and 2 will only require that you monitor either tx or rx (not both) and you will still see the whoile connection. This is because the tx packets for port 1 are the rx packets for port 2, and the rx packets for port 1 are the tx packets for port 2. If you monitor tx for the vlan then you see all of the packets transmitted to both ports 1 and 2. If you monitor rx for the vlan then you see all of the packets received from both ports 1 and 2. If you monitor both tx and rx for the vlan, then you wind up receiving duplicate packets.
This is one scenario where span could have an advantage over using TAPs.
