The Troubleshooting section in the CCNA R&S certification exam weighs about 20% of the whole exam. This means that a candidate should definitely pay attention to such a section. In this lab and later labs, we will be looking as different troubleshooting scenarios and how to resolve them, not just from an I-want-to-pass-the-exam point of view but from a real-world angle.
We will be using the following setup for this troubleshooting scenario, which covers sections 7.1 and 7.2 of the exam syllabus:
A couple of problems have been reported on the network above:
Host1 and Host2 cannot communicate with each other.
Even though Host2 can access the web server (using www.example.com), Host1 is unable to access that URL.
Resolve these issues making sure there is connectivity between the hosts and that the hosts can access the web server.
Two files are attached to this article:
trblsht_netwk_conn_init.pkt: This Packet Tracer file contains the lab setup with the problems described above.
trblsht_netwk_conn_final.pkt: This Packet Tracer file contains the lab with the issues resolved.
A Note on Troubleshooting
Troubleshooting is an art that requires great analytical skills and an understanding of how things work. We sometimes make the mistake of jumping into troubleshooting without first trying to understand the problem. As a result, we fumble about with different tools and methods in a brute-force manner instead of taking a step back to understand what is going on.
That being said, there is no one-size-fits-all method for troubleshooting and the method you use will differ from scenario to scenario. For example, if you are dealing with Layer 3 (IP) forwarding, you probably want to start with understanding the traffic flow: How is traffic supposed to flow from device A to device B? When you’ve got this, then you want to start analyzing why traffic is not flowing that way for those devices and continue drilling down until you find the issue.
On the other hand, if you are troubleshooting why two routers are not forming EIGRP neighbor adjacency, then you will use another method – one that is specific to EIGRP like checking K-values, and so on.
Troubleshooting Scenario Resolution
The most basic troubleshooting scenario you will get as a network engineer is that a computer cannot connect to the network; e.g., the user is unable to access some company resource or the Internet. In a real-world scenario, you will want to ask questions such as:
Is this the only user affected or are all users on the network (or a subset of users) affected?
When did this problem start? What changed on the network that could have caused the problem?
It is always best not to assume that the user is really experiencing the issue and to see if you can replicate it yourself. In this type of scenario, you usually have access to the computer that is experiencing issues and one of the easiest things to kick your troubleshooting off with is Ping.
Note: It is assumed that you have studied the lab setup and that you are familiar with the different IP addresses.
So let’s confirm that Host1 (192.168.10.101) cannot ping Host2 (192.168.10.102):
As you can see, the problem really does exist. Now we need to isolate whether the problem is with both devices or just one of them. One way we can do this is to test whether each device can reach any other device on the LAN (apart from each other). In our own case, another device on the LAN is the EDGE-RTR with IP address of 192.168.10.1 so let’s test from each device:
Here we see that Host2 can access the EDGE-RTR but Host1 can’t. This tells us that we can focus our efforts on Host1’s connectivity issue. Since this is a network problem, what we can do is to check that the IP settings on the host are correct:
Hint: On a Linux computer, you will use the ifconfig command instead of ipconfig.
So Host1 has the correct IP address even though the default gateway is wrong. This is where understanding comes in: Since both hosts (and also the EDGE-RTR) are on the same subnet of 192.168.10.0/24, then the wrong default gateway is not the reason why Host1 cannot communicate with any other device on the LAN.
At this point, you want to make sure that the device is properly connected to the network, i.e., check if the network cables are wired or check wireless network connection. Since we are using Packet Tracer, this step will not apply.
The next device to check is the switch to which the device is connected to. In this step, we will check things like the state of the port (up or down), its VLAN membership, its switchport mode, etc. We will use commands such as show interface, show vlan brief and show run.
The first output snippet shows that the interface is up/up, meaning it’s probably not a Layer 1 issue. The next output, however, reveals something: All ports are in the default VLAN 1 except port Fa0/2. Let’s check the running configuration to view the configuration on that interface:
Ah, so some naughty person (*read me) has moved that port from VLAN 1 to VLAN 10. Let’s change that using the following configuration:
interface FastEthernet0/2 no switchport access vlan 10
Does this resolve the problem or is there still more? Let’s find out:
Great! We have solved the first problem. The second problem is that Host1 cannot access the web server even though Host2 can. Like I said, in the real world, you will want to verify that the problem exists, so let’s try to open the URL from both hosts:
Again our focus will be on Host1, since the issue is specific to that host. Thinking about the problem for a minute, two things come to mind:
Since we are trying to access a device that is outside the device’s subnet, then the default gateway comes into play here; the device will forward the traffic to its default gateway.
Since we are trying to access a URL, it means DNS comes into play. How is the URL being resolved to an IP address?
While troubleshooting the first problem, we already saw that the default gateway was wrong. So we can change that from the IP Configuration tool.
If you are observant, you should also notice that the DNS server is wrong–192.168.20.20 instead of 192.168.20.200–so you should also change that.
With both changes made, if you try to open that URL again, it should work:
This brings us to the end of the lab where we began our troubleshooting series. The scenario presented in this lab is very simple and we will encounter more difficult labs as we go along.
I hope you have found this article helpful.