Network Services and Protocols Part I: How to Use ICMP functions and ARP for Troubleshooting
What are we doing?
Part I of this lab consists of 3 exercises that introduces us to troubleshooting with ICMP functions, such as ping and traceroute/tracert, as well as introduce us to ARP.
Why would we want to do this?
So, there’s this thing out there called structured troubleshooting¹ when dealing with network issues and it primarily consists of our handy OSI/TCP-IP model and different ways of eliminating probable causes. Cisco Systems has gone ahead and provided us with 5 structured approaches to troubleshooting, based on the user’s preference:
- Top-down approach
- Bottom-up approach
- Divide-and-conquer approach
- Follow-the-path approach
- Spot-the-differences approach
- Move-the-problem approach
Give this article a read so we can familiarize ourselves a little more on some of these approaches:
Troubleshooting Methods for Cisco IP Networks
This lab helps us better understand how we can better utilize structured troubleshooting with the tools readily available for us to use.
Who would use this?
Personally, I feel everyone who uses a computer should be using these tools and shouldn’t be seen as an exclusive skill of IT hobbyists and professionals. These tools and processes are basic enough for a computer literate individual to grasp and understand. It’s important that a computer user learns how their computer is communicating and to whom, so they can better help with the troubleshooting process, if issues arise.
Thoughts?
It seems like man-in-the-middle attacks can be quite common among LANs with the use of ARP poisoning so I wonder how reliable ARP would be as a tool when we need to troubleshoot our network.
Vendor
Practice Labs
Lab
1.4 — Network Services and Protocols Part I (Introduction)
Learning Outcomes
- Exercise 1 — Preparing the lab
- Exercise 2 — Using ICMP to troubleshoot network issues
- Exercise 3 — Understanding the working of ARP
After completing this lab, we will be able to:
- Verify Windows firewall configuration
- Use ICMP to troubleshoot network issues
- Explain how ARP works
CompTIA Network+ Exam Objectives
N10–007 1.1 — Explain the purposes and uses of ports and protocols (Protocol types, ICMP)
N10–007 1.3 — Explain the concepts and characteristics of routing and switching (Properties of network traffic, multicast)
N10–007 5.2 — Given a scenario, use the appropriate tool — software tools, Command line:
- ping
- traceroute/tracert
- ipconfig
- arp
Exercise 1
Preparing the lab
Learning objective
Know how to verify Windows firewall configuration
Task 1 — Prerequisite Task
Step 1: Connect to PLABSA01 and right-click on the network icon at the bottom right and click on Open Network & Internet Settings.
Step 2: Select Ethernet on the left pane, then Network & Sharing Center. Next, click on the Windows Defender Firewall on the lower left side of the window
Step 3: Ensure that the firewall for the Private networks as well as for the Public networks is switched on.
Now we know where to go when we need to verify Windows firewall settings.
Exercise 1 Complete!
Exercise 2
Using ICMP to Troubleshoot Network issues
Learning Objective
To be capable of using ICMP to troubleshoot network issues
Task 1 — Use ICMP to analyze a network issue
In this task, we’ll be using the Divide-and-Conquer approach to troubleshooting and start at the network layer (OSI layer 3 / TCP layer 2) and either work our way up or down, depending on the outcome.
Step 1: Connect to PLABWIN10 and open the Command Prompt terminal and input
ping 192.168.0.4
at the prompt to try and connect to PLABSA01(192.168.0.4)
Now that we’ve confirmed a network connection problem between PLABWIN10 and PLABSA01 by sending 4 ICMP messages to PLABSA01 and having all 4 fail to make a connection, we can move on to Step 2
Step 2: Connect to PLABSA01. With the Firewall & network protection window still displayed, select Allow an app through firewall on the left pane and scroll down to File and Printer Sharing and ensure the Private box to the right is checked and click OK
Note that the ICMP functionality is part of the File and Printer Sharing app. Microsoft has chosen to group these together, so by enabling File and Printer Sharing, we should be able to ping packets and bypass the firewall.
Now that we’ve enabled File and Printer Sharing within the Private network, let’s go ahead to Task 2 and see if we’ve solved our connection problem between PLABSA01 and PLABWIN10
Task 1Complete!
Task 2— Verify that the ICMP connection Issue is resolved
In this task, we will again use ICMP to verify that the networking issue is resolved by the reconfiguration of the firewall settings on PLABSA01. In this task, we will ping the PLABSA01 server again, using PLABWIN10, to ensure the network connectivity.
Step 1: Connect to PLABWIN10 and input in the terminal command prompt
ping 192.168.0.4
The ICMP echo request now shows a successful connection, with 0% packet loss.
Now, let’s take notice the information that is sent back with every request.
By default, 4 requests are sent. The reply indicates:
- IP address of the source of the reply
- The size of the ping packet sent
- The time the round-trip took
- A Time to Live or TTL value of 128
- Summarized statistics of the echo request
Task 2 Complete!
Task 3— Use traceroute/tracert to determine a network path
The traceroute(Linux/Unix)/tracert(Windows) command is used to find the path a packet will end up taking to its destination. In this task, we will be using tracert to examine paths to various destinations.
Step 1: Connect to PLABWIN10 and clear the terminal screen (cls) and input
tracert 192.168.1.1
so that we can examine the route our packet will take when traveling to PLABWEB01(192.168.1.1)
The result is a list of two entries indicating the route taken to the destination.
The first entry indicates that the first place the packet went to was 192.168.0.1
Looking at the lab diagram we can see that this is the our router, PLABRTR01. This is to be expected as this is the default gateway for our Windows 10 computer, PLABWIN10, for destinations of 192.168.1.X.
The next entry is the destination device of 192.168.1.1
So, the trace indicates that the packet reached PLABWEB01 via the PLABRTR01 device, as is expected.
Note: You may notice during a tracert/traceroute call that one or more hops returns a Request timed out message during the process. This is because the specific router on that path has been configured not to respond to ICMP requests.
If you want to give this a try and see for yourself go ahead and input in your own Command Prompt terminal tracert -d 8.8.8.8
Now we know how to use ICMP commands such as ping
and traceroute
/ tracert
to analyze and troubleshoot our network. We also got a better understanding that the ICMP feature/package is included in the File and Printer Sharing app and, by default, is only enabled to pass through the Windows firewall on the public network — our ICMP feature is blocked by our firewall within the private network.
Exercise 2 Complete!
Exercise-2-Summary
So, at the beginning of the exercise we mention that we are using the Divide-and-Conquer approach to troubleshooting, which means we most likely started at the network layer(layer 3) before determining which layer to further escalate to. We used ping
to see if we could connect to our server(PLABSA01) using our Windows 10 computer(PLABWIN10), only to find out that our computer can’t connect and keeps losing packets anytime we try to talk to our server(PLABSA01).
We started at layer 3 and confirmed a network issue. Since our issue was confirmed using an ICMP function called ping
, and both ARP tables from PLABSA01 and PLABWIN10 match, we’re going to go ahead and escalate our issue to the transport layer(layer 4) given that layer 4 is responsible for the transport mechanism of each packet, whether it be TCP, UDP, or ICMP. Layer 2(Data link layer) wouldn’t make too much sense since its primary concern is MAC addresses and both our ARP tables match.²
Check this out to get a much more in-depth view of how the Transport, Network, and Data-link Layers function for each packet (not necessary for the lab, but worth the read):
Understanding Layer 2, 3, and 4 Protocols
We then check our firewall configurations for our server(PLABSA01) to see if any of our settings are preventing access to it, and find that our firewall was indeed preventing transport mechanisms, such as ICMP, from being accepted within our private network. We went ahead and enabled ICMP functionality on the server(PLABSA01) and confirmed our resolution to the network issue using ICMP function ping
on our Windows 10 Computer(PLABWIN10). In conclusion, our Divide-and-Conquer approach consisted of these steps:
- Start
- Layer 3 — issue confirmed
- Layer 4 — issue escalated from layer 3 to test solution
- Layer 3 — solution confirmed, issue resolved
- End
In Task 4, we are merely exemplifying the utility of using the ICMP function traceroute
/ tracert
as a troubleshooting tool. Sometimes our problem is happening a few hops down our route and traceroute/tracert helps us map out the destinations our packets take so that we can better isolate where the issue arises.
Exercise 3
Understand the Workings of ARP
Learning Objective
Understand how ARP works
Address Resolution Protocol (ARP) translates the IP address of a device to its physical address (a packet moving from layer 3 to layer 2 of the OSI model) also known as an Ethernet address/MAC address. It is one of the main components of the TCP/IP protocol suite. Misconfigured ARP can lead to random connectivity issues across the network. We can analyze the ARP cache to troubleshoot and resolve issues including address conflict or IP address duplication on a network.³
Task 1 — View ARP Cache
Let’s see which MAC addresses are already stored(cached) on certain systems within our private network.
In this task, we will learn how to view the ARP caches of the various computers on the network and identify the MAC or physical address of each computer. We’ll also learn that using an ICMP function, like ping, will automate ARP.
Step 1: Connect to PLABDC01 and open the Command Prompt terminal and input
arp -a
The IP address 192.168.0.2 belongs to the server we’re currently on, PLABDC01
- 192.168.0.3 to PLABDM01
- 192.168.0.4 to PLABSA01
- 192.168.0.5 to PLABWIN10
Step 2: Connect to PLABSA01 and open the Command Prompt terminal and input
arp -a
Notice that the IP addresses 192.168.0.1 and 192.168.0.3 are missing, when we compare our results. The IP addresses are missing because these servers haven’t had any communication with PLABSA01 yet, therefore their MAC addresses haven’t been stored in PLABSA01’s ARP Table and will not show up in the ARP cache (this must mean we can safely assume our ARP cache is dynamically updated).
Let’s fix that in the coming steps
Note: The output includes ARP cache of two interfaces. The second interface, which is not connected to the network, includes only multicast addresses as well as an IPv4 link local address.
Step 7: from the PLABSA01 terminal, input
ping 192.168.0.1
in order to say “hello” to PLABTR01 and to start a so-called relationship between PLABSA01 and PLABTR01
The ping is successful. This indicates that the server is accessible even though the IP address was missing from the ARP table displayed, but since we’ve initiated a conversation by introducing ourselves to PLABTR01, and they decide to introduce themselves back to us, we can then add their information into our address book, and the ARP cache can be dynamically updated and viewed on the next arp -a
command
Task 1 Complete!
Task 2 — Verify MAC Addresses Individually
In this task, we will learn to identify the physical address (MAC) individually for each computer on the network.
Step 1: Connect to PLABDC01. With the Command Prompt terminal still open, input
ipconfig /all
Scroll up the output and find the following values:
Make note of these values because we will be using them in the next few steps.
Step 2: Connect to PLABWIN10 and input at the Command Prompt:
arp -a
Check the ARP cache for IP address 192.168.0.2, our PLABDC01 device. Compare its physical address with that noted in Step 1. They should be the same.
Task 2 Complete!
Task 3 — Configure a Static ARP Cache Entry
Until now, all ARP entries of other devices on the network were dynamically learned and populated within the cache.
In this task, we will learn how to create a static ARP cache entry. We are going to enter an incorrect static physical address in the PLABDC01 device that maps to the PLABWIN10 device then find out its effect on network connectivity.
Step 1: Connect to PLABDC01 and right-click on the Network Icon on the lower right-hand side of the taskbar and select Open Network & Internet Settings
Step 2: On the Settings — Status window, select the Ethernet option listed on the navigation pane at the left and go to the Network and Sharing Center link
Step 3: Under the View your active networks section, click on the Ethernet link then Properties
Step 4: On the Ethernet Properties dialog box, clear the Internet Protocol Version 6 (TCP/IPv6) check box and click OK
Note: We disabled IPv6 on PLABDC01’s interface to prevent it from using the protocol in making a secondary connection to IPv6-aware devices such as PLABWIN10.
Step 5: Reopen the Command Prompt window as administrator and input the following command:
netsh interface ipv4 add neighbors “Ethernet” 192.168.0.5 00–11–22–33–44–5e
The netsh command we entered will map a fictitious MAC address to a device with an IP address of 192.168.0.5 (our PLABWIN10 device)
Step 8: Now, at the next Command Prompt, input
arp -a
Find the static ARP cache and the incorrect physical address mapped to 192.168.0.5 (PLABWIN10).
Step 9: To test connectivity among PLABDC01 and PLABWIN10 input
ping 192.168.0.5
Notice the ping packets all timed out. This is because of the incorrect MAC address we assigned to PLABWIN10.
Step 10: To clear the ARP cache on PLABDC01, input
arp -d
so our server(PLABDC01) can reset our ARP Table
Step 11: To view the ARP cache, input the following command again
arp -a
Notice that there are fewer entries than before and that the static entry is gone. Also, notice that the correct MAC address is now restored to IP 192.168.0.5 (PLABWIN10) and listed in the ARP cache.
Step 12: To verify the correct MAC assignment, attempt to ping 192.168.0.5 once again:
ping 192.168.0.5
Notice the reply to the ping command. This verifies the connectivity has been restored.
Exercise 3 Complete!
Part I of this lab is complete and provides us enough information to progress forward to Part II of this lab
[1]: Troubleshooting Methods for Cisco IP Networks 2015 https://www.ciscopress.com/articles/article.asp?p=2273070&seqNum=2
[2]: Understanding Layer 2, 3, and 4 Protocols https://ptgmedia.pearsoncmg.com/images/0131014684/samplechapter/0131014684_ch02.pdf
[3]: Practice Labs 1.4 Part I 2021 https://skills.practice-labs.com/