RouterOS provides one of the best ping tools ever included in a product! Here are some the ways that this tool can be used:
- Testing connectivity and latency
- Testing for packet loss
- Testing routing
- Identifing IP conflicts
- Testing MTU
- Generating “Interesting Traffic” for IPSEC
- Testing routing tables
- Testing for packet fragmentation
- Testing DNS resolution
A little bit of background on the Ping tool. Ping uses the ICMP protocol and was created by Mike Muuss in December of 1983 as a tool to troubleshoot problems in IP networks. The ICMP protocol suite came first. The message types that the Ping tool use are part of the ICMP protocol suite. Mike Muuss was inspired to create the ping tool after he heard a remark made by David Mills on using ICMP echo packets for diagnosing IP networks. Mike Muuss named ping after the sound that SONAR makes, since its methodology is analogous to sonar’s echo location. A few other explanations about ping are also common. Some say that PING is an acronym for Packet INternet Groper, but that is a term that become popular somewhere along the way and just stuck. Some have suggested that the name PING comes from the game Ping Pong, but its name actually comes from the way that active SONAR works. Both of the other two explanations have been in use so long that they are widely accepted…. In fact, I have even seen them in college text books.
With active SONAR, a loud sound is generated (the ping) and measurements are made off of the echo. The Ping tool works in a similar fashion. An ICMP Echo Request message (ICMP Control Message Type 8), the ping, is generated and sent out. According to RFC 1122 any network host on an IP based network should be able to respond to ICMP Echo Request (that doesn’t mean that they will… its just means that they are supposed to have the ability.) Once that host receives the ICMP Echo Request they will respond with an ICMP Echo Reply message (ICMP Control Message Type 0). From the message contents and the amount of time it took to receive the response, a variety of information can be deduced.
Let’s look at the Ping tool:
Now lets look at some common usage examples. We’ll start with just a basic ping.
It important, when you are using this tool, to stop and think about a couple of items. First, we know what the destination address of the packet is going to be because we specified it in the “Ping To:” field, but what will the source address be? If we are pinging out across the Internet, the router will select the lowest IP address on the WAN interface and inject that into the source address field of the packet. If we are pinging a host on our LAN, the router will select the best address for the appropriate interface and use that for the source address. This means that we have to have a route-able address on the router to ping from and an appropriate active route before we even get started. Sometimes, the router needs help choosing the source address. The two most common times this happens is if we have multiple IPs on an interface or when we are trying to generate “interesting traffic” for IPSEC. The example below has two ping windows open to show the settings used on both the General and Advanced tabs of a single ping.
We can see in this example that we successfully pinged 188.8.131.52 from a source IP address of 184.108.40.206 (which is simulating one of multile public IP addresses on our router.) The average ping took 5ms to make the round trip and the returned TTL is 57. We don’t actually know what the TTL was set to on the other side, but if we assume a default value of 64, then there were 7 route-able hops between the end device and our router. This could be verified by using Traceroute.
Pinging a Hostname
Pinging a hostname is usefull when either we need to test DNS resolution or when a hostname is more appropriate that an IP address. We may not always know what the IP address is that we want to ping. When you are using Winbox, and you try to ping, Winbox actually resolves the hostname using the DNS settings on the computer and not on the router. This can be very misleading. In order to make this work properly, we need to do one of two things, either set the PC’s DNS server to point to the router or ping from the router’s command line.
Pinging Broadcast and Multicast addresses
MikroTik’s ping tool will allow you to ping both Layer 2 and Layer 3 broadcast and multicast addresses. This is useful for discovering all the devices that are present. However, the IP Scan tool would be a better choice for the Layer 3 discovery.
ARP ping is the best tool to use when you have an IP conflict on your network (IP Scan work really well too), but don’t know what the other host is that has the same IP address. ARP ping requires that an interface is set as in the example below. Notice that both hosts with the same address are queried and the response shows the MAC address as well as the IP address. Also notice, that the normal response information like reply size and TTL are not present.
The Status Field and ICMP Messages
When we are having problems, the most useful information to us is in the Status field. Frequently, we get so fixated on whether or not we got a successful Echo Reply that we disregard the other information. Lets take a look at the most common messages and what they tell us.
Timeout – This means that we sent the Echo Request but did not receive a response within the specified Timeout period. Usually, this is because the host is not able to communicate back. That could be because the host is offline or does not have an appropriate route. A timeout implies that we are sending the packet somewhere and that our router has a route that it believes is usable. As long as we have not made a mistake in our routing table or IP addresses and we’ve checked the firewall to ensure we are not blocking the traffic, then the problem is probably down the line from this point. Occasionally, such as with older satellite systems, you may need to increase the timeout value to get a successful ping.
ICMP_Timeout – Packet Capture File in .zip
No Route to Host – There is no ICMP Control Message associate with this response. This message appears when the router we are pinging from does not have an appropriate route. The problem is in this router. The fix, of course, is to add a route.
TTL Exceeded (ICMP Control Message Type 11 code 0) – There are two times that you may see this message. The most common reason will be a routing routing loop, which means the packet was sent upstream, and then the packet was sent pack downstream so that the routes between those routers create a perpetual loop. A routing loop does not indicate a bridging loop. A routing loop will only occur for specific subnet unless you have two routers that have their default routes pointed at each other. TTL Exceeded will indicate a routing loop 95% of the time. Once the routing loop is found, the next step is to use traceroute and determine which two routers are creating the loop so that you can correct the routes.
Occasionally, you will encounter a situation where the routing is correct, but the number of hops exceeds the TTL set in the packet. When using the default TTL of 64, this almost never happens, but it does happen when the TTL is being adjusted for some reason. TTL adjustment comes and goes in popularity, but it something that all network administrator need to be able to recognize.
Notice in the example below, that the host which is dropping the packet is the one listed in the host field because that host is sending an ICMP Control Message Type 11 Code 0 in response the original Echo Request Message.
ICMP_TTL_Exceeded – Packet Capture File in .zip
Destination Host Unreachable (ICMP Control Message Type 3 Code 1) – DHU means that the host which is generating the ping has a route to another host which also has a route, but the 2nd host is not able to communicate with the intended recipient. This may be because there is a bad route or simply because the intended recipient in not online. Traceroute will verify whether the ping is taking the correct route. After that, troubleshooting begins at the node that sent the DHU message. MikroTik products can also be set to drop a packet an send a DHU response. If you suspect that might be the case, check the routing table for an “ASU” route.
ICMP_Host_Unreachable – Packet Capture File in .zip
Admin Prohibited (ICMP Control Message Type 3 Code 13) – This message means that the router which is sending the response is dropping the packets to that subnet. Troubleshooting should begin at that device. In most products, the cause of the dropped packets will either be found in the routing table or in the firewall.
ICMP_Admin_Prohibited – Packet Capture File in .zip
Net Unreachable (ICMP Control Message Type 3 Code 0) – Network Unreachable is usually caused by a firewall administratively dropping the packets. Check the firewall on the node which sent the response.
ICMP_Net_Unreachable – Packet Capture File in .zip
Hope you enjoyed this tutorial! If you have any questions or insights, please add a comment below.