Yeah, you're seeing "packet loss exceeds acceptable threshold" in your monitoring tool or just watching pings drop. It's annoying, especially when everything else looks fine. Let's fix it fast.
Immediate Fix: Force Duplex and Speed
The culprit here is almost always a duplex mismatch. Your switch says full duplex, your NIC auto-negotiated to half. Or the other way around. Either way, you're dropping packets.
On Windows (Server 2016/2019/2022, Windows 10/11):
- Open Device Manager → Network adapters → right-click your NIC → Properties.
- Go to the Advanced tab.
- Find Speed & Duplex. Set it to 1.0 Gbps Full Duplex (or 100 Mbps Full Duplex if that's your link).
- Click OK. You might lose connectivity for a few seconds while the link re-negotiates.
On Linux:
ethtool -s eth0 speed 1000 duplex full autoneg offReplace eth0 with your interface. Run ethtool eth0 after to confirm.
Now test packet loss again. Use ping -n 100 google.com on Windows, or ping -c 100 google.com on Linux. If loss drops to 0%, you're done.
Why Forcing Duplex Works
Auto-negotiation is a 25-year-old standard that still trips up. Here's the deal: when two devices auto-negotiate, they talk over a protocol that uses voltage pulses on the link. If one side has a slightly different firmware version, a cheap cable, or a flaky port, the negotiation fails silently. One side ends up full duplex, the other half.
Half duplex means the NIC can't send and receive at the same time. Full duplex expects simultaneous traffic. So when the switch sends data while the NIC is sending, the NIC sees a collision and drops the packet. You get exactly the symptom: intermittent packet loss, not a full outage.
Forcing duplex on both sides removes the guesswork. It's ugly but it works. Always set both ends—the switch port and the NIC—to the same speed and duplex. If you can't touch the switch, at least hard-set the NIC.
Less Common Variations
Bad Cables
A damaged Cat5e or Cat6 cable can cause packet loss without a duplex mismatch. Check with a cable tester if you have one. Simpler test: swap the cable with a known-good one. If loss disappears, the cable was the problem.
I've also seen loss from loose connectors—push the cable in firmly at both ends. Even a slightly unseated RJ45 can cause random drops.
Jumbo Frames Enabled on One Side Only
If you have jumbo frames (MTU 9000) on the server but the switch or router uses standard 1500 MTU, packets over 1500 bytes get fragmented or dropped. This shows up as loss on large pings but not small ones. Check your MTU settings:
ping -f -l 1472 google.com # Windows test for MTU 1500If it fails, your MTU is wrong. Set both sides to 1500 unless you have a specific reason for jumbo frames.
TCP Offload Engine (TOE) Issues
Some NICs with hardware offloading (like TCP checksum offload, Large Send Offload) can corrupt packets under load. This causes loss that looks like a physical problem but isn't. Disable all offload features in the NIC advanced settings for a test:
- Large Send Offload (LSO) → Disabled
- TCP Checksum Offload → Disabled
- UDP Checksum Offload → Disabled
Does loss stop? Leave them off. Many enterprise admins disable offloading by default on critical servers.
Switch Buffer Exhaustion
If you're seeing loss only during bursts (monitoring shows 1-2% loss for a few seconds, then fine), you might be hitting a switch buffer limit. This happens on cheaper switches. Workaround: turn on QoS on the switch and prioritize your traffic, or replace the switch with one that has larger buffers.
Prevention
Don't rely on auto-negotiation for critical links. Standardize on hard-set duplex and speed. For server-to-switch connections, set both to 1 Gbps Full Duplex. For router links, match the port capabilities.
Label your cables. Use quality Cat6 or Cat6a for gigabit runs. Replace any cable that's been bent sharply, stepped on, or exposed to moisture.
Run a baseline ping test after every change to the network stack. A 5-minute ping test with 0% loss is your new normal. If you see even 0.1% loss later, investigate right away—it never gets better on its own.
Keep NIC drivers updated. I'm not saying drivers cause this often, but I've fixed it twice with driver updates where nothing else worked.