[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ISSForum] network sensor 7 performance
Teti Lawrence scribed:
> Thanks for the information about "tcp.misseddata_gaps". As I understand you,
> this statistic tracks the total number of gaps in the tcp connections
> monitored by our sensors, and not the total number of packets dropped.
> We have always thought our network was not stressing our sensor farm, but
> armed with your information I checked and noticed that today we are seeing
> an average of 116 tcp.misseddata_gaps every time a SensorStatistics event
> fires. We have four Nokias and I have them reporting every five minutes.
> Is 116 tcp.misseddata_gaps per sensor per five minutes good news, bad news,
> or indifferent news? Should we expect this statistic to be zero?
It really depends upon the number of tcp.connections reported during
the sampling interval. If 116 is a significant fraction of the
tcp.connections value, then this would warrant further investigation.
Ideally, a value of 0 should be reported for this statistic, as
this indicates that no packet loss is occuring.
There are a number of potential causes for packet loss. We have
attempted to document the most common causes in our extended PAM
documentation knowledge base article ("Additional Protocol Analysis
Module Documentation", ISS KB AnswerId #2190). The relevant excerpt
(This text may be found in KB 2190's html help through the index.html ->
status events -> SensorStatistics -> "missed data gap" definition.)
missed data gap
A contiguous sequence of one or more missing TCP packets on a
connection. If PAM reports a large number of these it indicates
significant packet loss is occurring.
when PAM does not receive a valid packet from the network.
This can occur for a variety of reasons:
1. Sensor resources. The CPU powering the sensor is not fast
enough for the amount of traffic. Eventually, the sensor falls
behind and packets are dropped from the internal queue before
2. Sensor limits. More traffic is being presented to the sensor
than it is certified to handle.
3. Aggregation limits. SPAN ports and TopLayer devices all
have their limits. The practical throughput of many SPAN port
implementations falls far below the theoretical limits published
by the vendor. Traffic beyond the practical limit is typically
silently dropped. Even in the optimal case, you cannot combine
120 megabits per second of traffic into a single 100-Base-T cable
to the sensor.
4. Hub aggregation. Hubs cannot avoid packet loss. If you use a
hub to combine the traffic from multiple network segments, you
will experience some packet loss. As you combine more segments
and more total traffic, the amount of packet loss will increase
Hope this helps,
ISSForum mailing list
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo