Using Ping and Traceroute to Diagnose Office Network Problems
When a workstation cannot reach the internet or a server becomes unresponsive, the instinct is often to restart the router and wait. Sometimes that works. More often, the problem is somewhere specific in the network path, and restarting hardware at random delays the actual fix by hours.
Ping and traceroute are the two most useful diagnostic tools available on every modern operating system. They are already installed — no downloads required — and together they can answer the most important questions: is there a connection at all, where is it failing, and how severe is the problem?
What Ping Actually Does
Ping sends a small packet to a target address and waits for a reply. The target can be an IP address or a domain name. The tool reports how long each round trip took, in milliseconds, and whether any packets were lost.
On Windows, open Command Prompt and type:
ping 8.8.8.8On macOS or Linux, open Terminal and type the same command. By default, Windows sends four packets and stops. On macOS and Linux, ping runs continuously until you press Ctrl+C.
A healthy response looks like this:
Reply from 8.8.8.8: bytes=32 time=12ms TTL=117
Reply from 8.8.8.8: bytes=32 time=11ms TTL=117
Reply from 8.8.8.8: bytes=32 time=13ms TTL=117
Reply from 8.8.8.8: bytes=32 time=12ms TTL=117The time value is the round-trip latency. For a connection to a server in Japan, anything under 20ms is excellent. Between 20ms and 80ms is normal. Above 100ms consistently suggests a problem worth investigating.
Reading Ping Results
Request Timed Out
If you see "Request timed out" for every packet, the target is not responding. This could mean the target is offline, a firewall is blocking ICMP packets, or there is no route to the destination. Start by pinging your default gateway (usually 192.168.1.1 or 192.168.0.1) to check whether the problem is local or further away.
Intermittent Packet Loss
If some packets return and others do not, you have packet loss. Even 5% loss causes noticeable problems with video calls and file transfers. Common causes include a faulty cable, a failing network switch port, or congestion at the ISP level.
High Latency
Consistently high response times — above 150ms to a local server, or above 300ms to an overseas server — suggest congestion somewhere on the path. Traceroute helps identify exactly where.
Using Traceroute
Traceroute maps the path that packets take from your computer to the destination, showing each router (hop) along the way and the time taken to reach it.
On Windows:
tracert 8.8.8.8On macOS and Linux:
traceroute 8.8.8.8Each line in the output represents one hop. The three time values are three separate measurements to that router. A typical output might look like:
1 1 ms 1 ms 1 ms 192.168.1.1
2 8 ms 7 ms 8 ms 10.0.0.1
3 12 ms 11 ms 12 ms 203.0.113.1
4 14 ms 13 ms 15 ms 8.8.8.8What to Look For
Work through the output from top to bottom. The first hop is your router. If that already shows high latency or times out, the problem is within your local network. If the first several hops are fine but latency suddenly increases at a specific hop, that router or the link after it is the likely source of the problem.
Asterisks (* * *) at a hop mean that router is not responding to traceroute probes. This is common — many routers are configured to ignore them for security reasons. It does not necessarily indicate a problem. What matters is whether the hops after the asterisks respond normally.
A Practical Diagnostic Sequence
When a connection problem is reported, work through these steps in order:
- Confirm the problem exists on more than one device.
- Ping your default gateway. If this fails, the problem is between your computer and the router.
- Ping a known IP address outside your network, such as 8.8.8.8. If this fails but the gateway responds, the problem is between your router and the internet.
- Ping a domain name, such as google.com. If IP addresses work but domain names do not, the problem is DNS.
- Run traceroute to identify the specific hop where latency increases or packets are lost.
This sequence narrows the problem to a specific segment of the network, which makes the fix much more straightforward.
DNS Problems That Look Like Internet Outages
A surprisingly common issue in office networks is DNS failure. When DNS stops working, websites become unreachable even though the underlying internet connection is fine. The diagnostic test is simple: if you can ping 8.8.8.8 but cannot open google.com in a browser, DNS is the problem.
A quick fix is to temporarily change your DNS server to a public one. On Windows, go to Network Settings, find your network adapter, and change the DNS server to 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). If connectivity is restored immediately, the issue was with your ISP's DNS server or your router's DNS configuration.
For more information on DNS infrastructure in Japan, the Japan Network Information Center (JPNIC) maintains useful documentation.
When Ping Is Blocked
Some servers and firewalls are configured to drop ICMP packets, which means ping will show timeouts even when the server is running normally. If you suspect this, try connecting to a specific port instead. On Windows:
Test-NetConnection -ComputerName example.com -Port 80This checks whether port 80 (HTTP) is reachable, which is more reliable than ICMP ping for servers with restrictive firewall rules.
Saving Results for Further Analysis
When reporting a network problem to an ISP or IT support team, it helps to provide the actual output rather than a description. On Windows, you can save traceroute output to a file:
tracert 8.8.8.8 > traceroute-results.txtThis creates a text file in your current directory with the full output, which you can attach to a support ticket or email.