[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ISSForum] network sensor 7 performance
Please pardon my igorance, but I need to have this issue cleared up. Mgt
is not at all happy with RS and I want to give them accurate
information. Just to make sure I understand, tcp.misseddata_gaps is not
counting the number of missing sequence numbers but rather counting an
event where there are missing sequence numbers related to a session? If
I see a count of 100 in the tcp.misseddata_gaps parameter the number of
packets dropped is probably much higher than 100?
Thanks again for your help
Scott Johnson, CISSP, GSEC
ERCOT Cyber Security
From: Jacob Langseth [mailto:jwl@xxxxxxxxx]
Sent: Thursday, January 08, 2004 3:07 PM
To: Johnson, Scott
Subject: Re: [ISSForum] network sensor 7 performance
Johnson, Scott scribed:
> For clarity, do the parameter values listed for the paramater
> "tcp.misseddata_gaps" represent a missed packet? IE if I see 10 is
> that 10 decimal (ten packets drops)?
The number does not represent the number of packets dropped, but rather
than the number of tcp connection gaps detected. One or more contiguous
missing tcp segments could make up a gap.
The value is expressed in decimal. A value of 10 indicates that there
were 10 tcp connection gaps experienced during the sampling interval.
The following is the definition of the tcp.misseddata_gaps statistic, as
taken from ISS KB article #2190, "Additional Protocol Analysis Module
Documentation". This document is available on the ISS website.
index.html -> status events -> SensorStatistics -> missed data gaps
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