In the previous lesson, we reviewed the ICMP (Internet Control Message Protocol). It’s the basis for the applications ping and traceroute. If you recall from that lesson, when you ping an address with a command like ping 8.8.8.8, you will likely get several responses in this form: Reply from 8.8.8.8: bytes 32 time 27 ms TTL=55.
Ping can be used to troubleshoot problems on your network. Typically, you can ping an IP address or a computer’s name. Suppose a camera can’t deliver its captured video to a server named MCC_storage at the address 192.168.3.100. Let’s also suppose the camera is using the address 192.168.3.13. Using a laptop inserted into the network with a proper address such as 192.168.3.222, you can issue a ping to the server’s address. If you get a successful reply, but the video still can’t be delivered, try issuing the command ping MCC_storage. If this fails, it tells you that there is a name resolution problem. Either the name server doesn’t know of MCC_storage or it is not listed in the local hosts file. Check whether the camera stores a local hosts file. If not, you’ll find the DNS server and investigate why it is not able to respond to the camera’s DNS query.
Related: Byte-Sized Lesson: ICMP Revisited
In some instances, ping can also be used to diagnose network slowness issues. Pick an address you are sure is valid. We’ll assume such an address is 8.8.8.8. Now issue the command ping 8.8.8.8 /t. This causes continuous pings to be issued. By studying the response times, you can often discover periodic bursts of competing traffic causing the reply time to increase substantially. Use Wireshark to capture traffic and you may be able to see where the competing traffic originates.
Now, let’s turn our attention to the application traceroute. In Windows 10, the command is tracert and its use is similar to the use of ping. Let’s say you issue the command tracert 8.8.8.8. You get a response that looks something like this:
1. <1 ms <1 ms <1 ms my_router [192.168.3.1]
2. 1 ms 1 ms <1 ms my_modem [192.168.3.2]
3. 4 ms 4 ms 4ms my_ISP_router [172.116.31.31]
4. 14 ms 14 ms 14ms Next_ISP_router [220.220.220.220]
5. Etc.
6. ...
7. ...
8. ...
9. 26 ms 26ms 26 ms dns.google [8.8.8.8]
The traceroute application is showing the list of routers in the path and the successive times used to transmit each link between them. Traceroute uses a clever implementation of the IP address field called the TTL (time-to-live), more commonly called the hop count. In the first step, the tracert issues a ping with the hop count set to zero. All routers are required to discard all packets with such a hop count but are also required to send the source a report that it did this. So, my_router reported back to the source. Then the source tracert issues a ping with the hop count set to 1. This packet passes through my_router but decreases the hop count by 1 as required of all routers. When the packet arrives at my_modem, the hop count is discarded, and a report is sent to the source. This iteration continues until 8.8.8.8 is reached.
Occasionally, you’ll see an entry with just asterisks listed instead of actual addresses. That simply means the intermediate router does not participate in responding to pings.
