[Oisf-users] Percentage of dropped packets

[Chris Wakelin]

On 29/05/12 16:44, Peter Bates wrote:
> 
> Hello all
> 
> On 29/05/2012 16:15, Victor Julien wrote:
>>> tcp.invalid_checksum      | AFPacketeth61             | 42560
> 
>> Invalid checksums can be caused by checksum offloading on your 
>> nic.
> 
> # ethtool -k eth6 Offload parameters for eth6: rx-checksumming:
> off tx-checksumming: off
> 
> Is there something else I need to do - or is there some way the 
> ethtool settings work with the settings in the suricata
> configuration?

What's the NIC? Which version of ethtool are you using? For my Intel
10GB cards (ixgbe)  I get:

Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on

and for me tcp.invalid_checksum is always 0.

> 
>>> tcp.stream_depth_reached  | AFPacketeth61             | 1 
>>> tcp.reassembly_memuse     | AFPacketeth61             |
>>> 15422350 tcp.reassembly_gap        | AFPacketeth61
>>> | 4894
> 
>> This is an indicator for packet loss. It indicates missing
>> packets in TCP streams. It is possible that it's caused by the
>> invalid checksums above as well though.
> 
> Running the script Chris provided (a wrapper round ethtool -S):
> 
> 2012-05-29 16:40:26 - Pkts: 262913600, Lost: 0, 0/10 %, Pkts/s: 
> 317592, Mb/s: 1875, Lost/s: 0, FSize 773 2012-05-29 16:40:36 -
> Pkts: 266014130, Lost: 0, 0/10 %, Pkts/s: 310053, Mb/s: -1469,
> Lost/s: 0, FSize -621 2012-05-29 16:40:46 - Pkts: 269054018, Lost:
> 0, 0/10 %, Pkts/s: 303988, Mb/s: 1780, Lost/s: 0, FSize 767
> 
> I don't entirely understand the negative values I'm getting here.

Probably my flaky script :-)

I should have said FSize is average frame size (pkts/bytes). I'm
guessing it's not matching the "bytes" lines properly.

> 
> And using his wrapper around the Suricata stats.log:
> 
> Date: 1/13/2012 -- 15:10:51 (uptime: 0d, 00h 01m 16s) : 7 secs,
> 37533 pkts/s, 163 Mb/s, 2534 gaps, 21 gaps/s    262732 Date:
> 1/13/2012 -- 15:10:57 (uptime: 0d, 00h 01m 22s) : 6 secs, 45241 
> pkts/s, 215 Mb/s, 2735 gaps, 33 gaps/s    271449
> 

I should also have mentioned you can add a divisor for the big
numbers; e.g. "suricata_stats.sh decoder.bytes 8192" would divide them
by 8192 so you'd get Mbytes per second (every 8 seconds) in this case.

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094