In addition the span itself may not be configured to send the SynAck packets to your sensor.
A simplistic example would be if you were Only spanning the RX traffic on the port connected to your firewall to your sensor.
The sensor would Only see the incoming Syn packets to your web servers (RX on the firewall port), but would not see the corresponding SynAck packets from your web servers (because TX on the firewall port is not being spanned, nor is RX on the web server port being spanned).
In these situations the 3050 could easily misfire often.
In the above it will be fairly obvious that both directions of the traffic are not being copied to the sensor, but in the following example it may not be so obvious.
Let's say your firewall is connected to your Cat 6500 switch on vlan 100. You web servers are on vlan 200. The MSFC routes traffic between vlan 100 and vlan 200.
You attach your sensor and decide to monitor RX traffic on vlan 100. You figure the SYN packets coming in the firewall to the switch will be seen as vlan 100 RX packets. You also figure that the SYNACK response packets from the web servers routed through the MSFC will also be seen as vlan 100 RX packets since they come into vlan 100 from the MSFC.
Unfortunately this would be an incorrect assumption. The MSFC does what is commonly referred to as fast switching which is also known as MLS or Multi-Layer Switching. Those packets from the webservers do not all go through the MSFC for routing. Instead after the first packet gets routed, the switch is smart enough to see that the other packets in the stream will also be routed between the vlans. So instead of sending the other packets through the MSFC it simply fast switches them and sends them straight from the web server on vlan 200 to the firewall on vlan 100. This means that the packets are never seen as vlan 100 RX packets. They are seen as vlan 200 RX packets and vlan 100 TX packets.
SIDE NOTE: By the same token, the additional packets from the Firewall will be seen as vlan 100 RX and vlan 200 TX packets.
In this situation the SynAck usually does get routed through the MSFC and seen as a vlan 100 RX packet form the MSFC port, but the other packets from the web server do not. This can lead to some misfires.
To correct this, a user typically changes it from a RX span to a BOTH span. The problem now, however, is that the sensor will see Duplicates of the first packets in each connection before the fast switching kicks in. This too can lead to some misfires.
To do this correctly, the user should do a BOTH span on the Firewall PORT, rather than a BOTH or RX span on the Firewall VLAN. Doing the BOTH span on the actual port will give you the information you want without the missing of packets, or duplicates that would cause misfires.
In addition your comment about load on the span port is also something to consider. It can be easy to overload a 100MB span port even though you may not be sending a full 100MB. This is because you could have 4 boxes each send a packet at the same time, but the switch can only send one of these packets to the sensor. The additional 3 would be buffered and forwarded to the sensor, but occasionally they will fill the buffer and be dropped. We have seen this at rates lower than 80MB when multiple ports are being monitored. The more ports being monitored the more drops you could see at even lower bandwidths.
I generally recommend monitoring with a Gig port even if you are only monitoring around 80MB.
This is why our IDS-4235 has a Gig monitoring port even though it's performance is rated for 250MB.
You may also see situations where the span port doesn't drop the traffic, but the sensor can't keep up and drops the traffic.
In both those situations it is possible for almost any of the signatures to misfire.
