Resetting ifconfig counters
Every Linux user is probably familiar with the ifconfig command. This allows us to see the current network settings on a system and to make various changes to the network interfaces (change IP, bring up, down, etc.). A typical run of ifconfig (or ifconfig -a) without any parameters will show the status of all the network interfaces, while using a network interface name (like ifconfig eth0) will output the status of only that interface.
Let’s see how a sample output looks like:
ifconfig eth0
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4233700943 errors:2 dropped:0 overruns:3 frame:5
TX packets:1917219659 errors:1 dropped:0 overruns:0 carrier:348
collisions:5753 txqueuelen:3000
RX bytes:1467520026 (1.3 GiB) TX bytes:2299240337 (2.1 GiB)
As we can see here ifconfig is keeping a couple of counters (RX/TX packets, RX/TX bytes, errors, dropped, overruns, frame, carrier collisions). We can quickly spot if there is a problem by just looking at the ifconfig counters. It is not the scope of this post how to solve these issues, but let’s consider that the problem is solved and then we normally don’t want to see the errors there anymore. Of course if there are new errors that show the same problem or a new one that would be ok to see them. So the normal thought is how to clear those counters and start fresh. How to reset them? If someone has tried to do this before, they might tell us that restarting the network interface will not help. This would have been the most logical choice, but how can we do this without rebooting the system?
The idea is that those counters are kept by the kernel (more exactly by the network card driver). By the way we can look at the same counters directly on the proc system using:
cat /proc/net/dev
Considering this, we have 2 possible choices: the network card driver is build either as a kernel module or build-in statically inside the kernel. These relate to our issue like this:
- kernel module: in this case we can solve this issue and reset the counters by unloading the module from the kernel and then loading it back again. This will clear the counters.
Assuming that I have a NIC using the e100 module this can be done by:modprobe -r e100; modprobe e100; ifup eth0or something similar to bring the interface back up (depending on your particular Linux distribution the script to bring up the network interface might be different).
Note: this will bring down the network interface, and if you are doing this over a ssh connection, use extra care (like maybe create a small script, add some extra measures to ensure you will not lock yourself out of the system).
- module built-in the kernel: in this case there is no way to reset the counters (of course without rebooting the system) if the particular network module driver has not a way to reset them using some code written inside the driver. From what I have seen in the source code of the modules I had used, none of them had such a software hook. But there might be other modules that offer this functionality… just that I have not personally seen it on the common NIC drivers I have used.
By the way a quick way to find out what particular driver is using a network interface is to use ethtool (a very powerfool tool that has many great usages):
ethtool -i eth0
driver: e100
version: 3.4.14-k4-NAPI
firmware-version: N/A
bus-info: 0000:01:07.0
I hope that you found this post useful and please feel free to use the comment box bellow to let me know if you have any additions/corrections to this.
Share This








6th October 2006, 15:20
Nice work, thank you for the information !
On a BCM5704 I’ve seen that these counter were resetting themselves (after a while they begin from 0). From the facts you say here, this seems to be related to the kernel-module. A good hint for debugging my problem … thanks !
6th October 2006, 17:44
Armin,
The counters will also resent when the upper limit is hit (depends on what system this is 32/or/64 bit etc.) and on high traffic sites you will see this quite often. Anyway I am happy that you found this information useful.
Cheers,
- Marius -
12th April 2007, 21:01
Thank you!
This helped me solve an issue on my Gentoo box, which was auto-loading both 8139too and 8139cp modules and caused havoc on TX errors and collisions. The ethtool will go into my book of superb linux tools!
Cheers,
Martin
10th September 2007, 15:49
So how do you know if your network card driver is a kernel module or a module built-in the kernel?
I’m familiar with ethtool to see your driver and lsmod to show loaded modules. But I don’t know if lsmod would should modules “built-in the kernel”? If it does not, then how do you see modules built-in the kernel? If lsmod does show both types, then again, how can you tell if a driver is a kernel module or a module built-in the kernel?
Thanks!
Rick
10th September 2007, 20:07
Rick: lsmod will not show the built-in kernel modules, only the currently loaded “modules”. I don’t think you can see the built-in modules somewhere specifically, but you can see the loaded modules with lsmod, or directly looking into /proc/modules.
23rd April 2008, 09:25
SUSE Linux (SLES9) network error…
Today, one of my SUSE Linux Enterprise Server (SLES9) encounter network error. The problem is the server and client can’t ping each other.
After checked the Cat5 cable using network tester, it shows the cable is working fine. Since the server alr…