Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Number of TCP Streams Curiosity

We have 4 sensors in production at our organization. With two separate connections to the Internet. 2 sensors are "external", 2 sensors are "internal". The internal sensors lie behind port-filtering load ballancing devices.

Of our two internet connections, one is the primary for all traffic coming into our DMZ. It is the sensor that monitors this specific link that has a much greater number of TCP streams reported. I'm trying to figure out why.

Sensor 01 - External

Sensor 02 - External (primary)

Sensor 03 - Internal

Sensor 04 - Internal (primary)

Sensor 01 - Number Of TCP Streams: 679

Sensor 02 - Number Of TCP Streams: 1651

Sensor 03 - Number Of TCP Streams: 854

Sensor 04 - Number Of TCP Streams: 4194

Sensor 04 really stands out of the crowd regarding TCP streams. If sensor 04 sees traffic, that traffic should have (primarily) gone past 02. The traffic may have gone past 01. At the very least, adding up 01 and 02 should come close to 04. This is not the case.

What do you think is the best way to determine why Sensor 04 reports so many more TCP streams? We have an issue that our Internal (Sensor 04) is recording inbound intrusions that sensors 01 and 02 are not. A TAC case is open regarding this condition.


Cisco Employee

Re: Number of TCP Streams Curiosity

Here are a few thoughts of where you might look.

Let me know is you are able to figure anything out.


Check the configuration on your sensors.

Differences in configuration may account for the number of active TCP Streams.

One configuration area to check is the TCP Three Way handshake configuration and

other TCP Session Reassembly timeouts.

These configuraiton entries are found in either the SigUser.conf or SigSettings.conf

files (I can't remember which).

Having TCP Three Way Handshake turned off on one and not the other, or having different timeouts, can result in the sensors tracking the sessions differently. Sessions on one sensor may time out faster than on another, or one sensor may be monitoring partial sessions while another is only monitoring sessions that have a complete 3 way handshake seen.


Check the routing setup for your network.

If packets for a web connection can come in one one link and be seen by sensor01, but the web responses go out the other link being monitored by sensor02, then neither sensor01 nor sensor02 will be seeing the entire connection, and neither sensor can montior the TCP Session.

If this is the case, and sensor4 is monitoring the web servers, then only sensor 4 would see and be able to monitor both sides of the connection.

I have found this to be the case at a few customer sites where the links to the internet were load balanced rather than strictly failover. In these situations one sensor has to monitor both of the links (usually aggregated together by a small switch).


Another thing you could check is the sensor hardware. Are all the sensors the same type or do you have a mix of 4210s, 4230s, or even older NRS sensors.

Different sensor hardware have different performance capabilities, and can monitor different numbes of streams.


You may also want to enable the 993 alarm.

This way you can be alerted if the sensor is dropping packets. It is a remote possibility that the external sensors are seeing quite a bit of traffic being blocked by the Firewall. This extra bit of traffic could be pushing those sensors ove the edge in their ability to analyze traffic, that the internal sensors don't see.

The resultant dropped packets could be pieces of the 3 way handshake. If those packets are dropped, then the session winds up not being monitored.