1

I have server with Broadcom Corporation NetXtreme II BCM5706 Gigabit Ethernet chips, and 2.6.18-164.2.1.el5 kernel from Red Hat Enterprise Linux Server release 5.4 (Tikanga).

During normal work day this machine gets ~ 40000 packets per second (it's database server), and ifconfig shows that it drops about 1 packet per second. Which while not perfect, is acceptable.

but sometimes, something strange happens, and we are getting (?) less packets. For example:

  • 13:38:50 43260
  • 13:38:51 42930
  • 13:38:52 38696
  • 13:38:53 33006
  • 13:38:54 23013
  • 13:38:55 49485
  • 13:38:56 37514
  • 13:38:57 4858
  • 13:38:58 1089
  • 13:38:59 31054
  • 13:39:00 36540
  • 13:39:01 47228
  • 13:39:02 35634
  • 13:39:03 35348
  • 13:39:04 32908
  • 13:39:05 33226
  • 13:39:06 32639
  • 13:39:07 21842
  • 13:39:08 38560

This is number of packets per second. As you can see at 13:38:57 and 13:38:58 we had way less packets (this data is from tcpdump).

dropped: stats in ifconfig eth1 output don't change, switch (some cisco stuff) doesn't show any dropped packets.

Anyone knows what it could be?

2
  • Well, less traffic during that time comes to mind.
    – EEAA
    Sep 28, 2011 at 21:30
  • Nope. While there are fluctuations in traffic, they are not even close to the changes in packet count.
    – user13185
    Sep 28, 2011 at 21:32

1 Answer 1

2

Bigger packets during that time, resulting in less overall packets. E.g. some sort of bulk data transfer.

2
  • While theoretically possible, its just strange. What would cause suddenly, for very short time, such dramatic change? it's db plugged to website, and the traffic on it is pretty much stable.
    – user13185
    Sep 29, 2011 at 13:39
  • There are too many possibilities to give you a good answer. Could be the system checking for updates automatically, could be an automated backup, could be someone else automatically scanning the system, and probably a bunch of other things too. You'll need to isolate what the traffic is during that time to really know. Nov 12, 2015 at 19:52

You must log in to answer this question.