Packet loss is almost never one point — you trace it layer by layer from the application down to the optics, because ping alone proves almost nothing: ICMP gets the lowest queue priority, so "ping works" does not mean the business flow is clean. A user reports "the network is sluggish, drops occasionally," and the first reflex is to ping the gateway; if it answers, the verdict is "network is fine." But ping only samples the ICMP slice. The business rides TCP, crosses the switch, and ends at a slightly bent fiber — none of which ping sees. Real loss tracing goes by layer: peel from the application down to the optical layer and shrink the suspect range one segment at a time. This guide shows the segmentation method, the tools per layer, and the sneakiest failure — receive-optical-power at the margin.
ping only proves the ICMP slice; it can pass while TCP business traffic still drops.
Trace by layer — application → transport → network → link → optical — and isolate the failing hop.
The hardest loss is at the optical edge: receive power within 2 dB of sensitivity, invisible to ping and switch counters.
Do not test the whole network at once. Work outward from the near end:
ping your own gateway — reachable with zero loss → the local segment (PC to switch) is fine, look outward.
ping another machine in the same subnet — confirms Layer 2 switching is clean.
ping the cross-subnet destination — checks the routing/firewall segment.
tracert from there — shows from which hop loss begins.
finally suspect the physical/optical layer — fiber, modules, receive power.
One round shrinks the scope from "the entire network" to "one hop" or "one strand," a tenfold efficiency gain.
ping reports three things: reachable or not, loss percentage, round-trip time. But ping uses ICMP, and many devices give ICMP the lowest priority — under congestion they drop ICMP first. So "ping works but the business stalls" is common; ping can disprove (unreachable = definitely broken) but cannot prove the business flow is good.
tracert (Windows) / traceroute (Linux) shows per-hop delay and loss, telling you "loss starts at hop N." pathping is harsher — it statistically averages per-hop loss over time. Once isolated to a hop, inspect that device: ACL, rate-limit, CPU.
iperf covers the transport layer's blind spot: real TCP/UDP streams. TCP shows retransmits, UDP shows loss and jitter — closer to the user experience than ping. Video stutters but ping is clean? It is almost always this layer or below.
Many "random drops" are actually the switch port reporting errors. Log in and read the port statistics:
| Counter | What it means |
|---|---|
| CRC / FCS errors | Line or module issue — dirty/bent fiber, incompatible module |
| Half-duplex / negotiated to 100M | Duplex mismatch; classic symptom is throughput collapse and intermittent loss |
| Broadcast storm | A loop without spanning tree; broadcast eats the bandwidth, looks like random network-wide loss |
| Discard counter | Port congestion or rate-limit dropped the packet |
None of these show up in ping — you must log into the device. One workshop "dropped packets every morning at 10" turned out to be a dumb switch with a loop causing a broadcast storm; enabling spanning tree (STP) killed it. ping alone would never have found it.
Warning: A plain ethernet switch vs hub question is moot on modern networks, but the lesson holds — layer-2 behavior (loops, storms) is invisible to ICMP and only shows in port counters, never in a network hub ping.
In PON and fiber links behind an sfp switch, the worst case is "marginal receive power": not down, but optical power sitting right at the sensitivity edge. A GPON Class B+ ONU has a receive sensitivity around -28 dBm; at -27 or -28 dBm it still registers, but the margin is nearly zero — any temperature shift or slight fiber bend drops it. This is ten times harder to find than a clean fiber break.
Optical power meter: measure the ONU/switch receive power (dBm), compare to sensitivity, compute margin. Margin < 2 dB deserves alarm.
OTDR: fire down the whole strand and read the event points — reflection peaks sit at connectors and splices, non-reflective steps are bends or breaks, and it reads out the distance so you go to that spot.
Red-light pen / VFL: for short links, directly spot a break or bend.
One park's GPON user dropped every evening; ping flickered, switch counters were clean. The power meter read -29 dBm, past sensitivity; the OTDR showed a bend step at 1.2 km — a drop cable crushed by a cable tray. Cut and re-splice, margin back to 8 dB, never dropped again.
Tip: When a network hub or switch reports clean but users still see loss, stop trusting counters alone and quantify the optical margin with a power meter.
ping reaches the gateway, so why does the business still stall? ping uses ICMP, which many devices queue at the lowest priority and drop first under congestion. A good ping only proves the network layer is roughly reachable; it cannot prove TCP business traffic is loss-free. Use iperf to measure TCP retransmits and UDP loss.
If tracert shows loss from hop N, is the problem at that hop? Not necessarily. That device may simply not answer ICMP (rate-limited or ping-blocked), which does not mean it drops business traffic. Confirm with iperf measured on both sides of that hop — is it the device or further downstream?
What do CRC errors in switch port counters mean? A line or optical-module problem: dirty fiber, bend, incompatible module, wrong negotiation. First check port duplex/speed, then clean the fiber connectors and swap the module; if needed, OTDR the fiber.
What receive power is normal? It depends on sensitivity. A GPON Class B+ ONU receives at about -28 dBm sensitivity; keep at least 2 dB of margin, and watch anything below -26 dBm. Marginal receive power is far stealthier than a break — quantify it with a power meter.
In an OTDR trace, which is the breakpoint — the step or the reflection peak? Reflection peaks usually sit at connectors and splices (normal); the non-reflective step is the bend or break, and the OTDR labels the distance so you go to that spot on site.
Loss tracing cannot stop at ping: ICMP is often rate-limited, so a good ping does not mean the business flow is good. Peel layer by layer — application → transport → network → link → optical. ping and tracert own the network layer, iperf owns transport, switch port counters own the link layer, and the power meter plus OTDR own the optical layer. The stealthiest loss lives at the optical edge as marginal receive power, and only a power meter quantifies it. Pair Rayin's industrial sfp switch — with port counters and ring protection — with a power meter and OTDR to complete the trace from ping to photon.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. She specializes in technical product selection and writes guides and tutorials that help procurement engineers and system integrators solve problems more efficiently. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
