> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # /proc/net and Networking sysctls: Where the Numbers Come From - URL: https://www.pinglabz.com/proc-net-linux/ - Published: 2026-08-19T16:30:35.000Z - Updated: 2026-08-19T16:30:35.000Z - Description: Every Linux networking tool is a formatter over a handful of kernel files. Here is what is in them, how to read the hex, and what happens when you change the sysctls that matter. - Author: Jaime - Tags: Linux, Troubleshooting, Tools Every tool in this cluster is, underneath, a formatter. `ifconfig` reads a file. `netstat -s` reads a file. `nload`, `ifstat` and `bmon` read the same file as each other. When those tools disagree, or when the one you want is not installed on the box in front of you, knowing where the numbers actually live turns a dead end into a one-line answer. This article is part of the [Linux networking commands guide](https://www.pinglabz.com/linux-networking-commands/). All output is from a Debian 13 host at 10.77.0.100 bridged into a CML lab, captured while it moved real traffic to servers at 10.77.2.10 and 10.77.3.10. ## What is in there ``` j@llmbits:~$ ls /proc/net | wc -l 57 j@llmbits:~$ ls /proc/net | head -12 anycast6 arp connector dev dev_mcast dev_snmp6 fib_trie fib_triestat hci icmp icmp6 if_inet6 ``` Two things to know before you read any of it. First, these are not files. They are kernel data structures rendered as text at the moment you read them. There is no disk involved and no caching, which is why `cat /proc/net/dev` twice in a row gives different numbers. Second, and this catches people constantly: **/proc/net is per network namespace.** Read it inside a container and you get that container's counters, not the host's. This is exactly why `netstat` run inside a pod shows an almost empty socket table while the host is busy. It is not broken; it is looking at a different namespace. ## /proc/net/dev: the file behind half the tooling ``` j@llmbits:~$ 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: 3808252 64631 0 0 0 0 0 0 3808252 64631 0 0 0 0 0 0 ens224: 75028297 803129 0 0 0 0 0 28 2185022768 527116 0 0 0 0 0 0 ``` Sixteen counters per interface. Now the same numbers through the modern command: ``` j@llmbits:~$ ip -s link show ens224 RX: bytes packets errors dropped missed mcast 75028297 803129 0 0 0 28 TX: bytes packets errors dropped carrier collsns 2185022768 527116 0 0 0 0 ``` Identical, to the byte. `ifconfig`, `ip -s link`, `nload`, `ifstat` and `bmon` all read this and divide by elapsed time. That is the whole mechanism behind [the live bandwidth monitors](https://www.pinglabz.com/linux-bandwidth-monitoring/), and it explains why the counter-based ones agree with each other so closely while the packet-capture-based ones drift slightly. The practical use is that you can build a rate meter with no tools at all: ``` j@llmbits:~$ A=$(awk '/ens224:/{print $10}' /proc/net/dev); sleep 5 j@llmbits:~$ B=$(awk '/ens224:/{print $10}' /proc/net/dev); echo $(( (B-A)*8/5/1000000 )) Mbit/s ``` Field 10 is transmitted bytes. That is the entire algorithm every one of those monitors implements. ## /proc/net/snmp: the counters netstat -s formats ``` j@llmbits:~$ grep -A1 '^Tcp:' /proc/net/snmp Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors Tcp: 1 200 120000 -1 11296 10614 490 30 1 976175 1662308 9438 0 57 0 ``` The format is a header line naming the fields and a value line in the same order. It is genuinely awkward to read by eye and trivial to parse in awk, which is the point: this file is an interface, not a report. Here, 1,662,308 segments out against 9,438 retransmitted is a retransmit rate of about 0.57 percent for the life of the host. The counters are live. Snapshot them around 20 pings: ``` before: InMsgs=2338 InEchoReps=522 OutMsgs=1894 after : InMsgs=2358 InEchoReps=542 OutMsgs=1914 ``` Exactly 20 on each counter. That precision is what makes these files worth reaching for: you can prove a packet was received by the stack, not merely that a tool claims it was. ### The Forwarding=2 trap This one has cost people real time. The first field of the Ip line looks like a boolean and is not: ``` j@llmbits:~$ sysctl -n net.ipv4.ip_forward 0 j@llmbits:~$ grep '^Ip: [0-9]' /proc/net/snmp | awk '{print "snmp Ip Forwarding field =", $2}' snmp Ip Forwarding field = 2 ``` The sysctl says forwarding is off. The file says 2\. Both are correct, because `/proc/net/snmp` reports the SNMP MIB value of `ipForwarding`, where **1 means forwarding and 2 means not-forwarding**. Any script that treats that field as true or false gets the answer backwards. Read `/proc/sys/net/ipv4/ip_forward` if you want a boolean. ## /proc/net/netstat: where the interesting TCP counters hide The extended counters, the ones that actually diagnose things, are in a separate file under the `TcpExt` prefix: ``` j@llmbits:~$ awk 'NR==1{for(i=1;i<=NF;i++)h[i]=$i} NR==2{for(i=1;i<=NF;i++) if(h[i]~/Retrans/) print h[i]"="$i}' /proc/net/netstat TCPLostRetransmit=111 TCPFastRetrans=9348 TCPSlowStartRetrans=3 TCPRetransFail=0 TCPSynRetrans=60 ``` Read that as a diagnosis. 9,348 fast retransmits against 3 slow-start retransmits means loss is being detected by duplicate ACKs, not by timeout, which is the good failure mode: the sender noticed quickly and recovered without stalling. A host with those numbers reversed is timing out, and users are feeling multi-second pauses. `TCPSynRetrans=60` counts connection attempts that had to retry the SYN, which is the counter you want when someone reports intermittently slow connection setup. `ListenDrops` and `ListenOverflows` live in the same file, and they are the definitive answer to "is my accept backlog too small." That question connects directly to `net.core.somaxconn` further down this page. ## The hex files, and how to read them `/proc/net/tcp` is a socket table written in hexadecimal, little endian, which looks hostile until you decode it once: ``` j@llmbits:~$ head -3 /proc/net/tcp sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode 0: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 7039 1: 0100007F:0277 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 400884 2: 64004D0A:1F90 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 525870 ``` The address is four bytes in host order, so on x86 they are reversed. Port is plain hex: ``` j@llmbits:~$ python3 -c " import socket,struct h='00000000:0016'; ip,port=h.split(':') print(socket.inet_ntoa(struct.pack('