[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ISSForum] network sensor 7 performance

Teti Lawrence scribed:
> Jacob
> 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?
> Larry

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.

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