Jacob 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:[EMAIL PROTECTED] 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 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 exponentially. Hope this helps, Jacob _______________________________________________ ISSForum mailing list [EMAIL PROTECTED] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo
