The Internet Control Message Protocol (ICMP) is one of the hidden parts of the Internet Protocol (IP) which keeps the Internet working smoothly. It helps devices on the Internet tell each other important information about local network conditions, so the Internet can send packets in the most efficient way.
But ICMP isn’t just an automated protocol, it’s also a very useful tool for network technicians. I’ve used it hundreds of times to diagnose and fix problems on all sorts of different networks. ICMP is so important that tools to work with it are built in by default to every modern version of the Windows, Mac, and Linux operating system.
What ICMP Does For You
ICMP’s main job is to help routers on the Internet find the most efficient way to send packets. When you connect to a website such as Google, Internet packets go from your computer to your home router to your modem to your local Internet Service Provide (ISP) office to your ISP’s regional router to several different routers on the super high-speed Internet backbone of your country to the nearest ISP for Google to Google’s actual server. Where I live, that whole process usually takes less than 10 milliseconds (1/100th of a second).
Although ICMP had nothing to do with that process (unless you deliberately sent an ICMP packet), it did help arrange the whole process in advance. When one router sees a way for another router to send information more efficiently across the network, it can send an ICMP redirect packet. This helps routers find the fastest route for your packets.
When a router starts to get overwhelmed by the traffic it’s receiving, it can send an ICMP source quench packet to other routers so they don’t send it so much traffic. This helps those routers find alternative paths for your traffic to ensure the maximum speed.
ICMP can do a whole bunch of other things too—it can even help your computer set its clock! But all of these things typically happen on their own in the background. You only notice them when they break, and they’re simple and robust enough that they hardly ever break.
Using ICMP Manually
Windows, Mac OSX, and Linux all have two basic ICMP tools built in to their command lines. (In Mac and Linux, you can open a terminal to the command line; in Windows, you can open the Run… dialog in the Start bar and type in the following command: cmd)
The two basic tools are ping and traceroute (tracert on Windows). Both of these tools do the same basic thing, but they do it in different ways to get different results.
The simpler of the two tools is ping. Ping sends an ICMP echo request packet from your computer to another computer. Most computers on the Internet are programmed to automatically respond to an ICMP echo request with in ICMP echo reply as soon as possible. In short, ping is the rough equivalent of asking “are you still there?” over a mobile phone connection.
But ping doesn’t just tell us whether or not the computer on the other side is still there, it also tells us how long it was between the time we sent the ICMP echo request and the time we received the ICMP echo reply. Subtracting the first time from the second time gives us the Round Trip Time (RTT). When I ping google.com, it typically takes about 17 milliseconds RTT; that means it probably takes less than 9 milliseconds for my echo request to get to Google’s server and less than 9 milliseconds for their reply to get to my computer. You can try this experiment at home; in your Windows, Mac, or Linux terminal, type the following command:
In Windows, the command will usually send 4 pings and stop. In Linux and Mac, you will need to stop it manually by pressing Ctrl-C after it sends a few pings. The command will print the RTT from your computer to Google. Is it faster or slower than the 17 milliseconds I usually get?
Try sending a ping to a website you suspect is a long distance from you. From my current location in New Jersey, USA, I tried sending a ping to a website in Australia, data.gov.au, which had a RTT of 258 milliseconds—over 15 times longer than it took me to connect to the nearest Google server.
(If you try pinging a site and get no response, that site probably has ping blocked to help prevent crude denial of service (DoS) attacks. For your experiments, try a different site which may be less popular. That’s why I used data.gov.au instead of a more popular Australian website.)
Ping gives us an indication of the minimum latency we can expect from a website. If it takes over a quarter second (250 milliseconds) for an ICMP packet to get from New Jersey to Australia, I can’t expect Australian websites to load any faster than that. A quarter second is fine for browsing the Web, but it can make it difficult to use interactive applications such as a game or a voice connection.
The other application built into most operating systems is traceroute (tracert on Windows). This shows us which routers Internet packets travel through to get from your computer to their destination. You can try this one at home too; type the following command and let it run until it finishes:
(Windows users should type tracert instead of traceroute.) You should see a simple table listing each router between your computer and Google’s server. In my case, there are 17 different routers. I recognize the first (192.168.1.1) as my home router, the second as my cable modem, and the third as the cable company office down the street from me. From there, my Internet request goes to a couple other local cable company offices to a medium-sized city near me; from there it apparently goes to an Internet backbone in Virginia through a couple more routers to the Google server.
If I traceroute the path to data.gov.au, it goes through over 100 different routers, including the same first few routers and a whole bunch of high-traffic hidden routers.
Although playing with traceroute can be quite fun, the main reason it’s built into operating systems is to help technicians diagnose problems with your router. If you can’t connect to the Internet, run a traceroute and see where the connection dies—it’s a simple and effective way to use the Internet Control Message Protocol.