Navigating a Network
Networking is one of the more difficult areas of IT to learn while starting out. The level of abstraction skyrockets and has caught me off guard many times. In an attempt to learning about networking, I booted up a command prompt and began pinging websites. I live on the east coast of Florida, so these are my results based on that.
Almost poetically, I had an interesting start to this project. Any attempt to ping a website would time out.
Although obvious to some of you already, I expected the regular IPV4 IP address and could not understand why this was pinging something different. I eventually figured it out during the research phase, but was stumped at the beginning. Given this issue, I loaded up a separate computer and swore to return to the issue.
Ping Results
Pings Sent: 4
Pings Received: 4
Response Time Range: 33ms to 44ms
Average Response Time: 39ms
Pings Sent: 4
Pings Received: 4
Response Time Range: 31ms to 39ms
Average Response Time: 33ms
Pings Sent: 4
Pings Received: 4
Response Time Range: 271ms to 273ms
Average Response Time: 271ms
Traceroute Experiment
In the process of learning about pings, a natural progression towards traceroute occurred. With the command prompt still opened, I began sending traceroutes to the same website
The trace returned 25 hops to Google. Naturally, times got longer the farther out the signal went from my device. Response times ranged from 12ms up to 51ms. Average was roughly 35ms.
Hops: 25
Response Time Range: 12ms to 51ms
Rough Average Response Time: 35ms
Hops: 29
Response Time Range: 12ms to 62ms
Rough Average Response Time: 40ms
Hops: 17
Response Time Range: 13ms to 270ms
Rough Average Response Time: 200ms
Reflection
Ping and Tracert are important commands for troubleshooting network connections. The simplest form is Ping. It outright tests the connection. In my workplace, we have many machines that need an IP to function. If one of these machines goes down, usually one of the first steps is loading Command Prompt and pinging its known IP address. If the IP reliably sends a response, the issue is likely hardware related (excluding the network interface card of course). If no response is found, the next step is running tracert, and waiting to see where a time out occurs.
The results for the pings and traceroutes in this discussion were surprising. Despite datacenters existing close to Florida, Google was second place to a website from Canada. The results from tracert imply that Google passed through more routers than Canada.
The most interesting results were the pings to Japan. Obviously, the website is located across an a landmass and ocean, so response times should be slower. However, tracert gave a cool view into the process. Eventually you can clearly see when the last North America router responds and sends data to the first Japanese router.
These commands can fail for a multitude of reasons. With respect to this discussion, I ran into a roadblock during part 1. All pings and tracert commands would fail. After 2 hours of research, I was able to discover two things:
1.) My computer doesn’t have a connection to a DNS, not even to my ISP’s public one. (Or at the very least nslookup would return with an "Unknown" server.)
2.) My computer’s IPV6 address would always be depreciated. Even an ipconfig release/renew would only maintain the address for a few minutes.
After learning this, I went back into my first computer and forced the Google ping to use IPV4 and it worked without issues! Outside of local tech issues, ping and tracert can fail if any router along the way is not working. In addition, the website you are attempting to connect to could be experiencing downtime itself, which would result in similar errors.
Comments
Post a Comment