Why Perspective Matters for Network Testing

Web tools seem convenient when you want to test your network, but they're often telling you something you already know. To fix a problem, you need to see it from your point of view.

Before we dive into network know-how, I have a quick question: What’s the traffic looking like for your next commute?

I’m serious! It could be your next trip to or from work, the path between you and the mailbox, or the route to anywhere you plan to go in the next hour or so. I’ll give you a sec to work it out.

Got it? Ok. Next, for fun, how long would it take if you were commuting to the same place, but this time, it’s from Base Camp South at Mt. Everest? Is it longer? Weirdly shorter? Should you even care how long it takes to get from Nepal to your office fridge?

You’re absolutely right — you shouldn’t! Knowing that doesn’t help you at all!

Yet that’s the kind of logic people use all the time when they go to test their network connection online. Speed tests and web tools aren’t looking at your data’s actual commute. They’re just checking on the traffic to and from somewhere you probably don’t care about. To get data you can use to solve a problem, you need the right perspective.

Luckily, it doesn’t take much to see things from your unique point of view.

Every which way but yours

Perspective is an important part of any quality network test. However, many web-based tools come up short in providing this crucial component due to how they actually collect data.

Many web tools approximate your network connection by running ping, traceroute, and/or MTR scripts from their end to whatever router IP address the tool identifies when you visit the webpage. This seems fine in theory, but there are two fundamental issues at work.

First, and this is the biggest issue, is the limited scope of the test. The test packets being sent by the remote device are only coming from that device. This may be helpful if you’re having generic network issues, but it’s only showing you one thing: the path from the web tool’s server to your router.

To use the commute analogy, it would be like getting that traffic report from Everest. If you plan to drive literally anywhere but base camp, the data quickly becomes irrelevant.

Second, even when the destination is the same, the specific route the test packets take may not be. Routing protocols are constantly evaluating the best path for your data, and this means the route the test data takes to you isn’t always the same route your data takes to the destination.

To be fair, this information is better than nothing, but it’s incomplete for the purpose of actual network troubleshooting.

Here’s an example: We used a web-based network support tool to test our connection over a network we know to be...not so great. This is what we received:

As you can see from the web test, we see things start to get dicey...and then nothing. The web test packets never made it to us. The web tool showed the issue is likely network-related (which is good to know), but that’s just about all we learned. If we want to fix the problem, we need a complete picture.

Let’s see what we find when we add some perspective. Here’s the same test conducted at the exact same time, but this one starts at our device and goes out to their server (we used PingPlotter for the trace because it’s prettier than a command line — it’s still the same test):

If you look closely, you may notice two things about our results. First, we have a complete route. Instead of wondering where or how the connection falls apart, we see every hop in full detail. If our issue lived in the first few hops, the web tool would have only hinted at it.

Second, and more importantly, look at the addresses in the two routes. They’re different! While some of our route is similar, other parts are wildly divergent.

Specifically, take a look at this hop from the web tool:

Now, compare it to the results from our local test:

Notice that the web tool routes data through Los Angeles, while the test from our perspective routes through Seattle. If the Seattle hops were having issues, our web test would have missed them completely.

Up, down, and all around

While web tests might fall short in identifying the root cause of an issue, many professionals find web-based or hosted tools appealing for large-scale uptime monitoring on remote devices (such as servers or off-site employee machines). The deployment and maintenance of these options are fairly frictionless, as there is no software to install or update. However, the lack of perspective still makes troubleshooting network issues remotely a challenge.

If you’re only concerned about whether a device is up or down, these uptime tools are probably more than enough for your needs. On the other hand, a number of admins find value in keeping a lightweight, versatile network tool installed in cases where network failure impacts a remote device. In most environments, you can keep these tools running as background processes while your device operates normally. Once a problem hits, these tools can spring into full traceroute mode, providing a critical perspective when needed.

See it from the right side

Many web tools can identify the existence of a problem, but that often means validating something you already know. If you actually intend to fix it, you’ll need information only perspective can provide.

Adding a self-hosted network tool to your troubleshooting and monitoring kit ensures the testing you do is relevant and accurate. The data you collect can confidently point to where problems live on a network, serving as stronger evidence for ISPs, customer support, or clients you’re assisting with managed IT.

A wise fictional character once said, "There's a difference between knowing the path and walking the path," and you can't do either without perspective.

Speaking of which, gaining perspective is just the first step in becoming the master of your domain (puns!). We have a number of handy resources to help you get the most out of your networking tools, regardless of what you use. Our wisdom hub has guides on troubleshooting best practices, identifying common network problems, and more.