Network Hop

What Is a Network Hop?

A hop is one leg of a packet's trip across a network. One device (usually a router) hands the packet off to the next. That handoff is the hop.

Data rarely takes a straight path. A request from a laptop to a nearby office server might only cross 3 hops.

Send that same request to a server on another continent, and it could cross 20, each router along the way picking it up, reading where it needs to go, and passing it on.

Switches and gateways can count as hops too, not just routers, though a router is usually the device actually making the routing decision at each stop. A firewall sitting inline on the path counts as one as well.

Hop count is simply the total number of those handoffs. Four hops is short and direct. Eighteen means the packet covered a lot more ground, and every device it passed through added its own sliver of processing delay before sending it forward.

Why Do Network Hops Matter?

Hop count shows up in three places that actually affect how a network behaves.

Path selection comes first. RIP, one of the older routing protocols, treats hop count as the whole distance calculation.

Nothing fancier than counting stops. A 3-hop route beats an 8-hop one every time, even if that 8-hop route actually covers less physical ground.

RIP also has a hard ceiling: past 15 hops, a destination just gets marked unreachable. Newer protocols like OSPF and BGP have mostly moved on from pure hop counting, weighing bandwidth and link cost instead, but the basic logic RIP popularized still shapes how a lot of people think about network distance.

Loop prevention comes second, and this one's about survival, not speed. Every packet carries a Time to Live value: a hop limit, counting down by one at each device it crosses.

Most operating systems start that count at 64 or 128. Get a routing error that sends a packet in circles, and the TTL eventually hits zero. The packet gets dropped right there instead of looping forever and quietly clogging the network.

The third is performance. A router has to receive the packet, figure out where it's headed, then forward it, and all of that takes a few milliseconds per hop, sometimes less.

String together enough of those hops, though, and the milliseconds stack into something a user actually notices, especially if one overloaded or misconfigured router is sitting in the middle of an otherwise clean path.

Hop Count vs. Latency

These two get mixed up constantly, and they're not the same thing.

Hop count is how many devices a packet passes through. Latency is how long the entire trip takes, measured in milliseconds from send to receive. One counts stops. The other counts time.

More hops usually means more latency. Each device adds its own small delay. That's not a fixed rule, though: picture two paths to the same destination.

One crosses 15 hops and still comes in at 20 milliseconds, because every device on it is fast and uncongested.

The other crosses just 5 hops but takes 200 milliseconds, because one single router in that short path is overloaded and stalling every packet that hits it. The 15-hop path is objectively the faster one.

That's exactly why a network team troubleshooting slow performance checks both numbers, not just one.

A high hop count paired with low latency usually means the path itself is fine as it stands. A low hop count paired with high latency points straight at one struggling device, not the whole route.

How Do You Check Hop Count?

Want to see the path for yourself? Traceroute does exactly that. It maps the route and counts the hops along the way.

Windows users: Open the Command Prompt, type tracert, then a domain or IP. Something like tracert google.com. Mac and Linux users get the same tool under a different name, traceroute, same syntax, same target.

Here's the clever part. The tool sends a packet with its TTL set to 1. That packet dies at the very first router, which fires back a message identifying itself.

The next packet goes out with TTL set to 2, and dies at router two. Then TTL 3, then 4, climbing one hop at a time until a packet finally survives long enough to reach the destination.

Every one of those deliberate deaths becomes a line in the hop-by-hop list on screen.

Read the output and you'll see every router in order, response time attached to each one. Watch for a sudden spike in that time, or a row of asterisks where a device just didn't answer.

That's usually where network troubleshooting should start. A timeout doesn't automatically mean trouble, though. Some routers are configured to ignore traceroute probes entirely and just stay silent on purpose.

Run it a few times before drawing conclusions. Routing paths shift, and one slow hop on a single run might just be a momentary blip, not a real, ongoing problem.