Packet loss, latency, and jitter can all make a network feel “slow,” but they are different conditions.

Latency is delay.

Packet loss is traffic that never arrives successfully.

Jitter is variation in delay between packets.

The current CompTIA Network+ exam emphasizes structured troubleshooting, performance metrics, interface errors, and network tools. The most important skill is to determine where the impairment begins instead of assuming every poor application experience is an internet problem. A strong N10-009 troubleshooting practice scenario includes interface counters, a packet-loss pattern and latency observations before asking which layer the administrator should investigate first.

Establish a baseline first

Before changing anything, record the symptom.

Ask:

• Which application is affected?
• Which users are affected?
• Is the problem wired, wireless, or both?
• Does it happen all day or only at peak times?
• Is one site affected?
• Is one destination affected?
• Did anything change recently?

Then establish normal performance.

A 40 ms round trip can be excellent across a long geographic path and terrible inside one local network.

Numbers need context.

Latency is end-to-end delay

Latency is commonly measured with round-trip time.

ping can provide a basic ICMP round-trip measurement.

High latency can come from:

• geographic distance
• congested links
• queueing
• overloaded firewall or router
• wireless retransmissions
• inefficient routing
• VPN path
• satellite or mobile transport
• overloaded destination

One high ping does not prove a network outage.

Collect several samples and compare:

• minimum
• average
• maximum
• consistency

A consistently high value and a wildly varying value suggest different problems.

Packet loss is traffic that never arrives successfully

Packet loss can occur when:

• interface drops packets
• wireless frames are corrupted
• buffers overflow
• cable or optic is faulty
• duplex or physical-layer issue exists
• firewall or policy intentionally drops traffic
• route is unstable
• provider link is congested

Some devices also rate-limit or deprioritize ICMP.

That means a router can appear to “lose pings” while forwarding normal application traffic correctly.

Confirm loss with several forms of evidence before declaring a hop faulty.

Jitter is variation in packet delay

Jitter is especially important for real-time traffic such as:

• voice
• video
• interactive remote desktop
• gaming
• live collaboration

Two packets can both arrive successfully but arrive with very different delays.

Applications may use jitter buffers to smooth that variation.

Excessive jitter can still create:

• choppy voice
• frozen video
• robotic audio
• unstable interactive sessions

A network can have low average latency and still have poor real-time performance because the delay is inconsistent.

Start local and move outward

A useful path test begins near the source.

1. Test the local host.
2. Test the default gateway.
3. Test another local system.
4. Test the WAN edge.
5. Test external destinations.

If latency is already high to the default gateway, the problem is local.

Possible causes include:

• Wi-Fi interference
• overloaded LAN
• bad cable
• duplex/physical errors
• host issue

If the LAN is clean but delay appears after the WAN edge, investigate provider or remote-path behavior.

When tests to the local gateway are clean but the application path is impaired, compare DNS results, route selection, interface counters and captured packets at successive boundaries. The essential network troubleshooting tools help gather that evidence, but a command is useful only when its result can distinguish a failing segment from a healthy one.

Use traceroute to find where the path changes

Traceroute shows Layer 3 hops along the path.

On Linux, traceroute can send probes with successively increasing TTL values to reveal responding Layer 3 hops. Compare repeated runs from the same source with destination symptoms: a slow intermediate control-plane response alone does not demonstrate packet-forwarding loss.

Traceroute can help identify:

• unexpected routing
• a new long path
• where latency appears
• routing loops
• missing reachability

Interpret it carefully.

An intermediate router may respond slowly to traceroute probes while forwarding transit traffic normally.

The key pattern is whether the latency or loss continues through later hops and reaches the destination.

Do not accuse the first hop that shows one delayed ICMP response.

Check interface counters

Interface statistics can reveal physical or congestion problems.

Look for items such as:

• CRC errors
• frame errors
• input errors
• output drops
• queue drops
• discards
• link flaps

Rising CRC errors often point toward a physical-layer problem.

Possible causes include:

• bad copper cable
• damaged connector
• failing transceiver
• dirty fiber
• electromagnetic interference
• bad port

High output drops with clean physical counters can point more toward congestion or queueing.

Use the counter that matches the failure mechanism.

Check utilization and queueing

A link near full utilization can create queueing delay.

As queues fill:

• latency rises
• jitter rises
• buffers can overflow
• packet loss follows

This pattern is especially common on:

• WAN circuits
• internet uplinks
• VPN appliances
• oversubscribed wireless
• backup windows

Monitor traffic over time.

A link that looks fine at 10:00 may be saturated at 14:00.

SNMP and flow telemetry are useful here.

NetFlow monitoring can identify which conversations consumed bandwidth during the incident window; correlate flow records with interface discards and queue counters before blaming a particular conversation for packet loss. Flow volume alone does not show where packets were dropped.

Wireless adds RF-specific causes and retransmissions

If wired users are healthy but wireless users suffer loss and jitter, investigate:

• signal strength
• interference
• channel utilization
• roaming
• retransmissions
• channel width
• AP load
• client driver

Do not troubleshoot the ISP before testing the same application on a wired connection.

A clean wired baseline can quickly isolate the issue to Wi-Fi.

MTU problems can look application-specific

MTU and fragmentation issues can produce unusual symptoms.

Small packets may work.

Large transfers may stall.

VPN or tunneled paths can make the problem more visible because encapsulation adds headers.

Symptoms can include:

• websites partially load
• large file transfers fail
• one application works while another hangs
• ping works with small payloads but fails with larger packets

Test the path with appropriately sized traffic and investigate Path MTU behavior where relevant.

Measurements are most useful when you collect them from the same source, toward the same destination, over a meaningful time window. A single ping spike can be caused by local scheduling, ICMP rate limiting, or a transient queue. A repeated pattern during the user’s problem window is much stronger evidence. For voice or video, collect loss, latency, and jitter together because one good metric does not cancel out another bad one.

Path testing also needs a control destination. If one SaaS service is slow, compare it with another external target and with the default gateway. If every external target becomes slow at the same time but the gateway stays clean, the WAN or upstream path becomes more likely. If only one destination is affected, investigate remote routing, peering, CDN behavior, or the application service rather than changing the local LAN.

Queue drops and physical errors tell different stories. CRC or framing errors suggest signal or media problems. Output drops with clean physical counters can indicate congestion or queue policy. Interface utilization near 100 percent supports that hypothesis, but average utilization can hide short microbursts. On real-time applications, brief queue pressure can create audible jitter or loss even when five-minute averages look comfortable.

Traceroute and hop-by-hop ping results must be interpreted as control-plane evidence, not an automatic blame list. Routers often deprioritize or rate-limit responses addressed to themselves while forwarding transit traffic normally. A slow intermediate hop is significant when the same degradation continues through later hops and the destination. If the next hops recover, the apparent delay may be only the device’s ICMP response behavior.

Tunnels and VPNs add another layer because encapsulation consumes MTU and can shift traffic onto different paths. If ordinary browsing works but large transfers or specific applications stall, test packet size and Path MTU Discovery behavior. A black-holed ICMP message can prevent a host from learning the usable size, producing failures that look application-specific rather than like a general link outage.

QoS can protect real-time traffic

When congestion is unavoidable, Quality of Service can prioritize selected traffic classes.

QoS does not create bandwidth.

It decides which traffic receives preferred treatment during contention.

For voice and video, this can reduce latency, jitter, and loss during busy periods.

QoS is useful only when classification and queueing are configured correctly across the path.

One switch marking traffic does not guarantee the WAN provider or remote network honors the same policy.

When you hand a case to another team or provider, include measurable evidence rather than “the network is slow.” Record timestamps, source and destination, baseline and failing RTT, observed loss percentage, jitter if relevant, traceroute results, interface counters, utilization, and whether the problem reproduces on wired and wireless paths. That package makes escalation faster and reduces the chance that each team restarts the investigation from zero.

After a change, repeat the same tests that proved the problem. A new QoS policy, cable replacement, route change, or capacity upgrade is only a fix if the original metric and application behavior improve during the same conditions that produced the fault.

Find the first point where the metric becomes abnormal

1. Define the affected application, users, and time window.
2. Establish a baseline.
3. Test the default gateway.
4. Compare wired and wireless.
5. Use ping for latency/loss trends.
6. Use traceroute to inspect path changes.
7. Review interface errors and drops.
8. Check link utilization.
9. Use SNMP, flow telemetry, or packet capture for deeper evidence.
10. Check QoS and queue behavior.
11. Test MTU when large traffic fails selectively.
12. Escalate to the provider only after local evidence is clean.

Treat latency, loss, and jitter as separate measurements, then locate the first segment where the bad metric persists. Interface counters, utilization, path tests, flow data, and targeted packet capture should all support the same fault hypothesis before you change the network. Preserve the before-and-after measurements in the incident record so later recurrence can be compared against the same baseline.