[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
Office  512-248-3152
Cell     512-917-9844

-----Original Message-----
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:
> Jacob
> 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.

packet loss
    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
    being processed.

    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