NIC: Explanation & Insights

The card where your server stops being silicon and starts being part of the internet.

What It Is

A NIC — Network Interface Card, or Network Interface Controller if you want the term that survived the move onto the motherboard — is the piece of hardware that turns your server's bytes into electrical or optical signals on a wire and back again. Everything your machine ever says to another machine, every web request it answers, every row it replicates to another database, every packet of a backup leaving for offsite storage, passes through this one chip. The CPU computes, the disk remembers, the RAM holds the working set — and the NIC is the mouth and ears. It's the only part of the box that touches the outside world at line rate.

For a long time a NIC really was a card: a separate board you slotted into the machine, with a socket on the back for the cable. That's where the "C" comes from. Today, on practically every server you'll touch, the controller is soldered onto the motherboard or baked into the chipset, but the name stuck — the way "dialling" a phone outlived the rotary dial. Physically it may be a port on the board, a 10-gigabit module in a cage, or a purely virtual device the kernel invents for a virtual machine. Logically, to Linux, they all look the same: an interface with a name, a MAC address, a link state, and a long ledger of counters that quietly records every packet — and every packet that went wrong.

This page is about reading that ledger. CleverUptime watches NIC packet errors, so most of what follows builds toward one skill: looking at the error and drop counters and telling, in ten seconds, whether you've got a cable problem, an overload problem, or nothing at all. That distinction is muddier than almost any other on a server, half the internet's advice gets it backwards, and getting it right is the difference between replacing a transceiver and chasing a ghost in your application code for two days.

Why It Matters

The NIC sits at a uniquely awkward spot: it's a hardware device, but the thing it carries — the network — is the one part of your stack you mostly don't own. A failing disk is your disk; a saturated CPU is your CPU. But a NIC throwing errors might be the card, the cable, the switch port three racks away, the duplex setting someone fat-fingered in 2019, or a perfectly healthy link that's simply carrying more than it can drain. The symptom is identical in every case — counters climbing — and the cause spans your hardware, someone else's hardware, and pure software load. No other component forces you to reason across that whole range from a single number.

It matters because network faults are sneaky. A dying disk gets loud fast; a network problem often presents as "the app feels slow sometimes," or "uploads fail but only big ones," or "throughput is a tenth of what it should be and nobody knows why." Those are some of the most expensive bugs to chase, precisely because the instinct is to blame the software — and the software is innocent. The counters on the NIC are the ground truth that ends the argument. Learn to read them and you stop guessing.

And the failure modes are genuinely different in kind. Some are physical and need a human with a cable. Some are load-driven and need tuning, not parts. Some — like the duplex mismatch we'll get to — are the cruelest sort, because the link works: it pings, it passes traffic, the dashboard is green, and yet throughput is mysteriously, infuriatingly terrible. A link that's down is honest. A link that's half-broken will waste your week.

Interface Naming: eth0 and the Predictable Names

The first thing you meet on any NIC is its name, and the naming story is worth knowing because it confuses everyone exactly once.

For decades, Linux named your interfaces eth0, eth1, eth2, in the order the kernel happened to find them at boot. Simple, memorable — and quietly treacherous on any machine with more than one card. The order wasn't guaranteed. Add a second NIC, swap a card, update a driver, and the network port that was eth0 could come back as eth1 after a reboot. On a server that's a small disaster: your firewall rules, your routing, your "bind the database to the internal NIC" config all suddenly point at the wrong wire. People lost afternoons to this.

So modern distributions (via systemd's udev) switched to predictable interface names — the slightly alien-looking enp3s0, eno1, ens5 you'll see today. They're ugly, but they're stable: the name is derived from where the device physically sits, not from boot-time luck. Decode enp3s0: en = Ethernet, p3 = PCI bus 3, s0 = slot 0. eno1 means onboard NIC number 1; ens5 means PCI slot 5; a w prefix (wlp2s0) is wireless. The name is the physical address, so the same port gets the same name on every boot, forever, no matter what else you add.

Backstory

The old eth0 scheme had a famous workaround that made the problem worse: a udev rule file (70-persistent-net.rules) that pinned each MAC address to a name. It worked until you cloned a VM image — the clone inherited the rule pinning the old MAC, the new VM's NIC didn't match, so the kernel named the real card eth1 while eth0 pointed at a device that didn't exist, and the machine booted with no network. A generation of admins learned to delete that file as the first step after cloning. Predictable names killed the whole class of bug by deriving the name from the slot, not from a remembered MAC — which is why the names look like hardware coordinates, because that's exactly what they are.

You can still find the old-style names if you insist (a kernel boot flag, net.ifnames=0, brings eth0 back), and inside containers and many cloud VMs you'll still see eth0 because there's only one virtual NIC and the ordering can't bite. But on bare metal, learn to love the ugly names. They're ugly because they're honest.

The MAC Address

Every NIC carries a MAC address (Media Access Control) — a 48-bit number, written as six hex pairs like 52:54:00:a1:b2:c3, burned in at the factory to be globally unique. If the IP address is where your server lives (and it can move — change it any time), the MAC is more like a serial number stamped on the hardware. It's how machines on the same local segment find each other: when your server wants to send a packet to a neighbour, it looks up the neighbour's MAC via ARP and addresses the Ethernet frame to it. IP gets the packet across the internet; MAC gets it across the last cable.

The first three bytes are the OUI (Organizationally Unique Identifier), assigned to the manufacturer — so a MAC starting 52:54:00 is famously a KVM/QEMU virtual NIC, and a quick lookup of the first half of any MAC tells you who made the card. The catch worth knowing: a MAC is "burned in" but not immutable. Linux will happily let you override it (ip link set enp3s0 address 02:11:22:33:44:55), which is how VMs get assigned MACs, how some failover setups move an address between cards, and, less cheerfully, how a laptop spoofs its identity on a café network. The hardware default is unique; the running value is whatever the kernel says it is.

The OSI Stack: Where the NIC Sits

To place the NIC in the bigger picture, it lives at the bottom two floors of the OSI model — layer 1 (physical) and layer 2 (data link). Layer 1 is the raw signalling: voltages on copper, light in fibre. Layer 2 is frames — the NIC wraps your data in an Ethernet frame with the source and destination MAC, a type field, and a trailing checksum, then hands it to the wire. Everything above — IP at layer 3, TCP and UDP at layer 4 — rides inside that frame as payload the NIC neither reads nor cares about. The NIC's whole job is: take a frame, put it on the wire correctly; take a frame off the wire, check it's intact, hand it up. This matters enormously for reading errors, because it tells you which layer a counter is complaining about. A frame-level error (a bad checksum) is a layer-1/2 problem — physics, cables, signal. A drop is usually a layer-above problem — the software couldn't keep up. Knowing which floor the alarm is on is half the diagnosis.

Link Speed, Duplex, and MTU

Three settings define how a link behaves, and you should be able to read all three at a glance.

Speed is the obvious one: 100Mb/s, 1000Mb/s (gigabit), 10000Mb/s (10-gig), and up. The number you see is what the link negotiated, not what the card is capable of — and the two can differ. A gigabit card on a bad cable might fall back to 100 Mb/s and never tell you, which looks like "the network is weirdly slow" until you check the speed and find it ten times lower than it should be.

Duplex is where the trouble hides. Full duplex means the NIC can send and receive at the same time, on separate pairs in the cable — the normal, correct state for any modern switched link. Half duplex means it can only do one direction at a time, taking turns, and detecting collisions when two devices talk at once. Half duplex is a relic of the hub era (more on that below), and on a modern link it should essentially never appear. When it does, it's almost always a sign of a duplex mismatch — the single nastiest NIC fault there is, and the centrepiece of this page.

MTU (Maximum Transmission Unit) is the largest frame the interface will send in one piece, classically 1500 bytes for Ethernet. Anything bigger gets fragmented or rejected. You can raise it — jumbo frames of 9000 bytes are common on storage and backend networks, where bigger frames mean less per-packet overhead and more throughput. The trap: MTU must match end to end. Set 9000 on your server but leave the switch at 1500 and you get a maddening bug where small packets (pings, the start of a connection) work fine but large transfers silently stall, because the oversized frames hit a wall partway across and get dropped without a peep. "Ping works but SSH hangs after the banner" is the classic MTU-mismatch fingerprint.

How the NIC Talks to the CPU: IRQs, DMA, and Ring Buffers

This is the part most explanations skip, and it's the part that makes the drop counters make sense. A NIC at gigabit speed can receive well over a million packets a second. If the CPU had to personally babysit each one — copy it byte by byte out of the card, then handle it — the machine would do nothing but service the network. So the hardware is built to not bother the CPU more than it has to, and the mechanism is worth understanding once.

When a packet arrives, the NIC writes it straight into main RAM by itself, using DMA (Direct Memory Access) — a hardware path that lets the device move data into memory without the CPU copying a single byte. The card deposits the packet into a slot in a ring buffer: a fixed-size circular queue of descriptors in RAM, set up by the driver, that the NIC fills as packets come in and the kernel empties as it processes them. Then, instead of interrupting the CPU for every packet, the NIC raises a single IRQ (interrupt request) to say "there's work in the ring." The CPU's interrupt handler does the bare minimum and schedules the real processing as a softirq — the kernel's "I'll finish this in a moment" mechanism (this is the si you see in top, and on a busy server it's often the largest non-idle slice). The softirq drains the ring, hands the frames up to IP and TCP, and frees the slots for the NIC to reuse. Modern drivers (NAPI) even switch off the interrupt under heavy load and just poll the ring in a tight loop, because at a million packets a second the interrupts themselves become the bottleneck.

Hold onto that picture, because it explains the most misread counter on the whole page. The ring buffer is finite. If packets arrive faster than the softirq can drain them — because the CPU is busy, or pinned to the wrong core, or simply overwhelmed — the ring fills up, and the next arriving packet has nowhere to go. The NIC drops it. That dropped packet is counted as rx_dropped, and it is not a hardware fault. The card is fine, the cable is fine, the packet arrived perfectly intact — the machine just couldn't pick it up in time. Drops are an overload story, told in the language of IRQ and CPU scheduling. Keep that straight and the counters below stop being a riddle.

Offload Features: Letting the Card Do the Work

A modern NIC is not a dumb pipe; it's a small specialised processor, and it can take work off the CPU. These are the offload features, and they're on by default for good reason.

Checksum offload — every TCP/IP packet carries a checksum the receiver verifies. Computing it for millions of packets is real CPU work, so the NIC does it in hardware, both directions. (A side effect that bites the curious: a packet captured before the card computes its checksum looks "wrong" in tcpdump — that's not corruption, it's just the checksum hasn't been filled in yet. The tool even labels it "checksum incorrect (maybe caused by hardware offload).")
Segmentation offload — GSO/TSO (Generic / TCP Segmentation Offload) — instead of the kernel chopping a big chunk of data into MTU-sized frames, it hands the NIC one giant buffer and lets the card slice it. Fewer trips through the network stack, more throughput.
GRO (Generic Receive Offload) — the mirror image on the way in: the card and driver merge a burst of small incoming frames into one large buffer before handing it up, so the stack processes one big thing instead of forty small ones.

You inspect and toggle these with ethtool -k enp3s0. They're worth knowing about for one reason: when chasing a truly baffling network bug — corruption that no cable explains, a specific app that misbehaves only over the network — turning offloads off (ethtool -K enp3s0 tso off gso off gro off) is a classic diagnostic. If the problem vanishes, you've found a driver or firmware offload bug. It's a rare cause, but it's the kind that makes you doubt your sanity until you think to check.

How I Inspect It

Four places tell you everything, and you read them roughly in this order — fast overview first, then the detail.

ip link and ip -s link — the modern first glance. ip link show enp3s0 tells you the state (UP/DOWN), the MAC, and the MTU. Add -s and you get the statistics block — the error and drop ledger — which is where the diagnosis lives:

ip -s link show enp3s0

2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    link/ether 52:54:00:a1:b2:c3 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    981234567  812345      0       0       0    1024
    TX:  bytes packets errors dropped carrier collsns
    412345678  601234      0       0       0       0

Read it like a scorecard. state UP and LOWER_UP both present means the interface is administratively up and the physical link is live (carrier detected). errors, dropped, carrier, collsns all at 0 is a healthy link. Any of them climbing is the start of the story below.

ethtool — the physical-layer truth. Where ip shows you the logical interface, ethtool talks to the card itself: negotiated speed, duplex, whether the link is detected, and the driver's full private counter set.

ethtool enp3s0

Settings for enp3s0:
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Link detected: yes

Speed: 1000Mb/s, Duplex: Full, Link detected: yes is what you want. Speed: 100Mb/s on a gigabit link, or Duplex: Half, is a flashing red light. And ethtool -S enp3s0 dumps the driver-specific statistics — dozens of counters with names like rx_crc_errors, rx_no_buffer_count, rx_missed_errors, tx_aborted_errors — the most granular view there is, and where you confirm exactly which kind of error is accumulating.

/sys/class/net/ — the same data as plain files, one number per file, which is exactly what a monitoring agent reads. cat /sys/class/net/enp3s0/operstate returns up or down; cat /sys/class/net/enp3s0/speed returns 1000; and the whole counter set lives under /sys/class/net/enp3s0/statistics/ (rx_errors, rx_dropped, tx_errors, collisions, …). This is the kernel publishing the NIC's live state as files you can read — the same "everything is a file" idea that makes Linux so inspectable. No tool required; cat is enough.

/proc/net/dev — the one-screen summary of every interface's counters at once, the oldest of the four and the source ifconfig reads from. One cat /proc/net/dev and you see RX/TX bytes, packets, errors, and drops for lo, enp3s0, and every other interface in a single table — handy when you want the whole box at a glance rather than one card in depth.

The Counters, Explained — the Part Everyone Reads Wrong

Here's the heart of it. The NIC keeps separate ledgers for receive (RX) and transmit (TX), and the counters mean genuinely different things. Conflating them is the number-one diagnostic mistake. Let's take them one at a time and, crucially, tie each to its cause.

rx_errors / tx_errors — the catch-all error totals. These are sums of more specific counters (CRC errors, frame errors, etc. roll up into rx_errors). A non-zero, rising error count almost always means a physical-layer problem: the bits arriving on the wire are damaged. That points at the cable, the connector, the transceiver (the optical/copper module), or a duplex mismatch — never at your application. This is the single most important sentence on the page: errors are a hardware/physics story, not a software one. If rx_errors is climbing, stop reading your app logs and go look at the wire.

rx_dropped / tx_dropped — packets that arrived (or were queued to send) perfectly intact, but got discarded because there was nowhere to put them. As we saw above, the usual cause on receive is the ring buffer overflowing — packets came in faster than the CPU's softirq could drain them. This is an overload story, not a hardware one. The packet was fine; the machine was busy. Rising rx_dropped under load means tune, don't replace.

rx_crc_errors (a major contributor to rx_errors) — the frame arrived but its checksum didn't match, so the data was corrupted in transit. CRC errors are the cleanest possible signal of a physical fault: a bad or too-long cable, a flaky connector, electrical interference, a dying transceiver, or — the sneaky one — a duplex mismatch causing late collisions. CRC errors essentially never come from software. If they're climbing, the diagnosis is physical, full stop. (This is the direct cousin of disk cable errors, where a flaky SATA cable corrupts data the same way — bad cables don't care what they're carrying.)

rx_frame_errors — a frame that didn't end on a byte boundary (an "alignment" error). Same family as CRC: a physical-layer fault, usually the same cable/connector/interference culprits.

rx_missed_errors / rx_fifo_errors / rx_over_errors — the NIC's own internal buffer (its FIFO, on the card) overflowed before it could DMA the packet into the ring. This is overload at the hardware level — the card itself couldn't keep up, often because the bus or the DMA path was contended. Treat it like rx_dropped's more serious sibling: a load problem, not a wire problem.

tx_carrier_errors — the card tried to transmit but lost the carrier signal mid-frame: the link flapped, the cable was yanked, the switch port reset. A physical/link-state problem on the transmit side.

collisions — two devices transmitted at once on a shared medium, and the NIC detected the clash. On a modern full-duplex switched link this should be a flat, permanent zero, because full duplex has separate send and receive paths — nobody collides. A non-zero, rising collision count on a link you believe is full duplex is a screaming siren for a duplex mismatch. On genuinely half-duplex links a few collisions are normal (it's how the protocol works), but you shouldn't have half-duplex links in the first place.

So the whole muddy field resolves into two clean questions: are the packets damaged (errors, CRC, frame → physics, go check the wire) or merely discarded (drops, missed, FIFO → overload, go tune the box)? Once you sort every counter into those two buckets, the diagnosis writes itself.

The Duplex Mismatch Trap

This deserves its own section because it's the gem of NIC troubleshooting — the bug that "works" while quietly destroying you.

Picture a link where one end is set to full duplex and the other to half duplex. It happens easily: someone hard-codes the speed and duplex on a switch port (a habit from the bad old days), auto-negotiation on the server side can't see a partner negotiating, and the two ends settle on different assumptions. Now: the full-duplex side sends whenever it likes, because it believes it can send and receive simultaneously. The half-duplex side believes only one device may transmit at a time and listens for collisions. So when the full-duplex end transmits while the half-duplex end is also transmitting, the half-duplex end sees a collision — and worse, a late collision (one detected after the first 64 bytes, which on a correct half-duplex segment should be physically impossible).

Here's the cruelty: the link comes up. It pings. Small transfers work. Everything looks fine on a casual check. But every time a collision or late collision happens, frames are dropped and TCP has to retransmit — and under any real load that's constant. Throughput collapses to a tiny fraction of the link's rated speed, latency goes erratic, and there is no obvious error unless you know to look at ethtool (Duplex: Half where you expected Full) and the collision and CRC counters. People burn days blaming the application, the database, the "slow network" — when the truth is two numbers on two devices that disagree about how to take turns.

Warning

Never force a modern link to half duplex, and be deeply suspicious of any hard-coded speed/duplex setting on a switch port. The correct state for essentially every gigabit-and-up Ethernet link is auto-negotiation on, full duplex. If you ever see Duplex: Half in ethtool on a link you didn't deliberately make half-duplex, you've found a mismatch — fix the negotiation, don't tune around it. A half-duplex gigabit link is almost always a misconfiguration wearing a working link as a disguise.

Reading It by Example

Real readings and the verdict each one points to. Assume a single gigabit link unless noted.

errors 0 dropped 0 collsns 0, speed 1000, duplex full — a clean, healthy NIC. Nothing to do. This is what "good" looks like, and most of the time this is exactly what you'll see.

rx_dropped climbing under heavy traffic, rx_errors flat at 0, CPU softirq high — classic overload. Packets are arriving intact but the ring buffer fills before the CPU can drain it. The fix is tuning, not parts: enlarge the ring buffers (ethtool -G enp3s0 rx 4096), or spread receive processing across cores with RPS (Receive Packet Steering), or pin the NIC's IRQ to a dedicated core. Do not swap the card — it's working perfectly; the machine just can't keep up.

rx_crc_errors and rx_errors rising together, traffic light or heavy — a physical fault. Reseat or replace the cable first (it's free and it's the cause two times out of three), check the connector, suspect the transceiver, and verify both ends agree on duplex. Don't touch your application; the bits are being corrupted on the wire before software ever sees them.

collisions and late collisions climbing on a link you think is full duplex, throughput mysteriously terrible — a duplex mismatch, nearly every time. Check ethtool on both ends, fix auto-negotiation, watch the collisions stop and the throughput leap.

Speed reads 100Mb/s on a gigabit card, no errors — a cable or negotiation problem dragging the link to a lower rate. Often a damaged pair in the cable (gigabit needs all four pairs; lose one and it falls back to 100, which needs only two). Replace the cable and re-check.

state DOWN or Link detected: no — nothing's plugged in, the cable's dead, or the switch port is shut. Layer 1 is simply absent; no amount of software will help until there's a carrier.

Cheat Sheet

The moves worth keeping within reach, roughly in order of use:

# --- Inspect (overview → detail) ---
ip link show                         # all interfaces: state, MAC, MTU
ip -s link show enp3s0               # the error/drop counters for one NIC
ethtool enp3s0                       # speed, duplex, link detected
ethtool -S enp3s0                    # the full driver-specific counter dump
ethtool -k enp3s0                    # which offloads (checksum/TSO/GRO) are on
cat /proc/net/dev                    # every interface's counters in one table
cat /sys/class/net/enp3s0/operstate  # up / down, straight from the kernel
cat /sys/class/net/enp3s0/speed      # negotiated speed in Mb/s

# --- Tune (when drops climb under load) ---
ethtool -g enp3s0                    # show current vs max ring buffer sizes
ethtool -G enp3s0 rx 4096            # enlarge the RX ring buffer

# --- Diagnose a baffling corruption bug ---
ethtool -K enp3s0 tso off gso off gro off   # disable offloads; if the bug vanishes, it's a driver/offload fault

# --- Configure (modern, runtime) ---
ip link set enp3s0 up                # bring the interface up
ip addr add 192.0.2.10/24 dev enp3s0 # assign an address
ip link set enp3s0 mtu 9000          # jumbo frames (must match end to end!)

Pro Tip

When you read a counter, always ask "rising or just non-zero?" A counter is cumulative since boot, so a handful of errors a server picked up during a cable swap three months ago means nothing. Note the value, wait a minute, read it again. A number that's climbing right now under traffic is a live fault; a static number is history. Diagnose the derivative, not the total — the same way every CPU tool reads the rate of /proc/stat, not the raw count.

A Note on ifconfig and the Old Tools

You'll still find ifconfig everywhere in old tutorials, and it still works on most boxes — but it's deprecated, often not installed by default on modern minimal images, and it shows a less complete picture of the counters than ip -s link does. The whole net-tools family (ifconfig, route, netstat) was superseded by the iproute2 suite (ip, ss) years ago. The new tools are more capable and actively maintained; reach for ip and ethtool by default and treat ifconfig as a thing you can read but shouldn't write new habits around. (And collisions is the one field where the old tool's prominence misleads: it's been a near-permanent zero since hubs died, yet it still has a dedicated column, a fossil from when collisions were a daily fact of network life.)

History and Philosophy

The NIC's deepest scars come from Ethernet's origins, and they explain the collision counter that confuses everyone today. Ethernet was born in 1973 at Xerox PARC, designed by Robert Metcalfe, and the early networks were a single shared coaxial cable that every machine tapped into — a literal ether they all shouted across. With everyone on one wire, two machines transmitting at once garbled both messages: a collision. The protocol's answer was CSMA/CD — Carrier Sense Multiple Access with Collision Detection — politely paraphrased as "listen before you talk; if you both talk anyway, both shut up, wait a random moment, and try again." Collisions weren't a fault; they were the normal operating mechanism of a shared medium, and half duplex (one talker at a time) was simply how it had to work.

Then the switch changed everything. A switch gives every device its own dedicated link instead of a shared bus, with separate wires for send and receive — full duplex — so nobody ever has to take turns and a collision becomes literally impossible. The entire CSMA/CD apparatus, the collision counter, half duplex itself — all of it became a vestige the moment switched full-duplex Ethernet took over in the late 1990s. That's why a non-zero collision count today is so diagnostic: in a world where collisions can't happen, seeing one means something is configured as if it were still 1985. The counter survived as a fossil, and like the appendix, it's mostly useless until the day it tells you something's badly wrong.

The other thread worth pulling is DMA and interrupts — the IRQ/DMA/ring-buffer dance from earlier — which is one of the prettier pieces of co-design in computing. The whole architecture exists because of a simple, brutal asymmetry: a CPU operates in nanoseconds, a network packet arrives every microsecond at gigabit speed, and naively handling each one with an interrupt would drown the processor in overhead before it did any real work. So the engineers pushed the work down into the hardware (let the card DMA straight to memory), batched the notifications (one interrupt for many packets), and eventually switched off interrupts entirely under load in favour of polling. Each step trades a little latency for a lot of throughput, and the result is a server that can field a million packets a second while leaving the CPU free to actually use them. It's the same instinct as everything good in systems design: don't interrupt the busy person for every little thing — let the work pile up a bit, then handle it in a batch.