Troubleshooting with Internet Control Message Protocol (ICMP)

Network troubleshooting, connectivity diagnosis, and problem reporting are all facilitated by the Internet Control Message Protocol, a network layer protocol. Because this protocol is connectionless, data is sent without first establishing a connection with the destination node. 

Sending messages between two network nodes is how the ICMP, also known as the ping protocol, operates. The logic is simple. After being encapsulated, the messages are transmitted to the destination inside IP packets. 

ICMP does not use TCP or UDP for transportation or any application layer protocols. In essence, ICMP operates as a control protocol on layer 3 to help oversee IP network operations.

Not to add, but ICMP can be divided into two groups: query messages (which include timestamp request, timestamp replay, echo request, and echo replay) and error reporting messages (which contain the elements destination unreachable, time exceeded, parameter problem, and source quench). 

In this article, I have focused on troubleshooting using the ICMP protocol. What I have to demonstrate is the pinging technique on layer 2 and layer 3 network topologies. 

Standard Ping on  local LAN

It makes sense to reduce the complexity of the network topology for this exercise to just two routers, two switches, and two PCs. 

In network troubleshooting, the elimination strategy has priority and reduces the time it takes to find the problem. Let’s go to the example I spotted in Figure 2. PC1 is not capable of reaching PC2. 

Also, making this exercise a little more challenging, the network engineer has no physical or remote access to the PC1. The user from PC1 has been switched off, and the network engineer just lost contact with him.

First, troubleshooting could be done locally on the network, according to the network engineer’s instinct. Therefore, an engineer could  think, What could happen on the local network that PC-1 is not able to ping outside? 

The correct approach is a strategy that is used to eliminate potential failure modes in the step by step process. Thus, we must start from the nearest point and follow the data flow to the further destinations (hops). Also, we can start integrating from layer 1 and go through the next upper layer. Realistically, it depends on the case we investigate.

In this example, I started reviewing layers 1 and 2. I checked if the physical cables of the switch and router correctly sit in the ports and protocol data-link, and are in active mode. So. I prompted the command “show ip brief interface” on the switch Sw-1 and router R-1 to which I am remotely connected. 

 My action log was confirmed by the CLI display showing device ports are in the up / up mode (Figure 3).

Before I go further, I need to explain what echo requests and replay messages are. The echo request is set five echo messages send in the slot of two seconds. This indicates that the echo request message is deemed unsuccessful if the echo replay does not return within the allotted two seconds. 

After successfully pinging to the switch Sw-1 located on the local network, I was  able to approve that a MAC address table is updated. Also, it was confirmed that both ARP tables for the PC1 and router R-1 are appropriately refitted with the IP local network addresses. It is important to remember that the first echo request message can be lost in the context of an ARP table update.

The connected interfaces of the router and switch must then be examined to see if they are intended to function in the trunk for the VLAN. More queries, such as “Where is the gateway?" will arise. How is the router's interface subnetted? Is the switch Sw-2's access port set up to permit VLan operations? Plus extra. In this article, I am not going to show all the possibilitiess of failure. For troubleshooting, the cooking receipt cannot be used. We must use our knowledge and turn on our brains. The methodology, though, is crucial. 

However, a simple mistakes can be made easily. When diagnosing a connection issue between routers R-1 and PC1, considering them to be two connected devices on the same subnet. Even if the default gateway was not previously configured, sending echo request messages from the router port Fa1/0 can function properly with replay messages. 

Ping to longer route from the nearest port

Here is the place where the extended ping command comes in handy. We can use extended ping commands from the local network to verify the default router configuration on the device in the same subnetwork. The biggest benefit is that we can ping from the “longer” interface on the route path. I show this approach in Figure 4. 

This extended ping command on a Cisco device has more available options, which I will expand on in a different post. 

This extended ping was unsuccessful, showing that something went wrong when the ping was sent from a different subnet. In this example, the default gateway was not configured. 

By using the extended ping to test the LAN neighbours (192.168.1.0/24), I can determine whether the router R-1's ACL is filtering incoming traffic.  

Ping to destination using Standard and Extended Ping Commands

It is time to look at the equation's correct site if we still can not get from the PC-1 to the PC-2. It means we need to ping outside the local network from the R-1 router. 

Once more, using the standard ping command is a good place to start. We need to make sure that interfaces are working (in active mode) on routers R-1, R-2 and switch Sw-2. In my lab, I used static routing between routers, but there is a probability that a WAN will be set up with dynamic routing.  

The next potential failure in our topology could be port security on switch Sw-2 when router R-2 or PC-2 are forwarding the frames. 

The ACL filter on the router R-2 can be examined using the standard ping command on the path from R-1 to PC-2. Nevertheless, the router R-1 ACL list is not present (checked) and may contain traffic that is discarded. 

Because of this, I must use extended ping, which also addresses the traffic policy for the router R-1 ACL.  

Lastly, I discussed interface configurations, IP addressing, switch security port issues, and ACL policies for both routers. This list does not exhaust the potential problems. 

 More commands are available to assist engineers in troubleshooting the network. Since this post is getting lengthy, I will end it here. And the next time, I will explain how to check the DNS server by pinging a name rather than an IP address. 

While the ping command is essential, I will talk about the traceroute command in a later post because it is sometimes a better option.

Troubleshooting is challenging and complex, but also exciting. This involves identifying the root cause of the problem,  isolating the affected area, and taking corrective action to restore normal network functionality. Isolating the network area is adequate for eliminating potential failure modes, step by step, by overlapping the technology. 

While knowledge of networking concepts, protocols, and technologies is essential for troubleshooting, strategy and taken approach are equally important.

Although knowledge is vital, knowledge gaps can be filled in with the appropriate strategy and approach. A well-structured approach helps to:

• Identify the problem area quickly and efficiently

• Focus on the most likely causes of the problem

• Eliminate potential causes through systematic testing and analysis

• Develop a plan to resolve the issue and implement a solution

In conclusion, efficient troubleshooting eliminates overanalyzing complex issues and/or focusing on the wrong problem area. A proper troubleshooting approach eliminates wasting time and resources on unnecessary troubleshooting steps