Bug 69049 - Network traffic counters wrap around after 4GB
Network traffic counters wrap around after 4GB
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: iptraf (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-17 10:56 EDT by redhat-bugs2eran
Modified: 2007-04-18 12:44 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-29 09:46:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description redhat-bugs2eran 2002-07-17 10:56:34 EDT
The kernel maintains, for each network device, the total number of bytes and
packets that were transmitted and sent. These counters are apparently only 32bit
long, and thus wrap in common circumsntaces such as transmitting more than 4GB
on an Ethernet device.
The counters can be read using "cat /proc/net/dev", "ifconfig" and (presumably)
various system monitoring tools.

Since the kernel currently reports false data without warning, this can have
unfortunate consequences. Consider, for instance, web colocation services that
bill you by the gigabyte transferred -- you really want your statistics to be
reliable.

How reproducible:
Always

Steps to Reproduce:
While I observed this happening on Ethernet interfaces, it's easiest to
reproduce with the "lo" interface. Here's a sample transcript, obtained on my
RedHat 7.3 box. I used NetCat to pump /dev/zero data over the "lo" interface,
stopping it manually after a few seconds. As you can see, the byte counters
rolled over.

$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes   
packets errs drop fifo colls carrier compressed
    lo:4162190490  633694    0    0    0     0          0         0 

$ nc -v -l -p 1234 > /dev/null & sleep 1;  nc -v 127.0.0.1 1234 < /dev/zero
[1] 31365
listening on [any] 1234 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 37222
localhost [127.0.0.1] 1234 (?) open
 punt!
[1]+  Done                    nc -v -l -p 1234 >/dev/null

$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes   
packets errs drop fifo colls carrier compressed
    lo:75993510  665305    0    0    0     0          0         0
Comment 1 Arjan van de Ven 2002-07-17 11:08:32 EDT
Counters *will* wrap no matter how big. That's why the ip traffic accounting
program takes that into account...
Comment 2 redhat-bugs2eran 2002-07-17 14:41:45 EDT
> Counters *will* wrap no matter how big. That's why the ip traffic accounting
> program takes that into account...

Uhm, sorry to nag, but -- which accounting program are you referring to, and how
does it take that into account, if the information is long lost?

Also, indeed all counter eventually wrap, but a 64bit counter will take about
2000 years to wrap on fully utilized OC48 channel (2.48Gbit), while a 32bit
counter may wrap within a couple of hours on a 10Mbit ethernet!
Comment 3 Arjan van de Ven 2002-07-17 14:46:11 EDT
iptraf
Comment 4 redhat-bugs2eran 2002-07-17 17:30:41 EDT
iptraf starts all its statistics gathering from 0. It "solves" the wrap around
problem by sampling the counter very often, so it needs to be running
continuously. It thus cannot answer the simple yet useful question "how many
bytes did this interface transmit since it went up", unless it happened to be
running all along.
Comment 5 Karsten Hopp 2003-10-29 09:46:08 EST
iptraf doesn't wrap the counters -> works for me

Note You need to log in before you can comment on or make changes to this bug.