Lab 14: Network Troubleshooting - AidanP017/Aidan-NET-150 GitHub Wiki

In this lab, we utilized the Cisco Packet Tracer application to observe and troubleshoot constructed networks.

Challenge #1

Here, there are two laptops connected to two switches and conjoined by a router. However, the laptops are not able to ping each other. The first thing I did to troubleshoot the problem was observe that the laptops displayed the correct IP configuration. I found that while the Foster laptop was assigned the correct information, the Skiff laptop did not have a default gateway assigned to it. Given that it was noted in the interface above that 192.168.1.1 was the default gateway of the side of the network including the Skiff laptop, I typed in the default gateway and was now able to ping successfully between both laptops. In this challenge, I primarily used the spot-the-differences approach.

Challenge 2

Here, the network has a similar construction to that of Challenge 1 and both laptops are once again unable to ping each other, but this time it is for a different reason. Given these details, I deduced that the problem was unrelated to the IP configurations for the laptops but rather had something to do with the route itself. This is when I found that one of the FastEthernet ports for the router was disabled and did not have an IP address and subnet mask matching the default gateway of the Skiff laptop. Once I enabled this port and assigned the appropriate IP address and subnet mask, I pinged between the two laptops and it worked successfully. In this challenge, I also primarily used the spot-the-differences approach but also considered the follow-the-path approach as I monitored the traffic path.

Challenge 3

Here, the network is constructed with a router at the center with a switch connecting four PCs on the left side and a switch connecting one PC on the other side---which the other four PCs need to be able to ping. At first, I used the follow-the-path approach to observe the network traffic, however I found that was unrelated to the problem. Then I switched to using the divide-and-conquer approach to check---if any---the static and RIP routes, however I eventually realized that those would be irrelevant---particularly static routing since that requires more than one router to configure correctly. The last approach I switched to was the spot-the-differences approach where I quickly identified the problem. Of the two FastEthernet ports attached to the router, the configurations were reversed and needed to be switched. Once I did this, I was able to ping successfully from the PCs in the 10.10.10.0/24 network to the PCs in the 20.20.20.0/24 network.

Challenge 4

The interface in this challenge is constructed with two networks, one of which contained a switch and two PCs and the other network contained a switch and one PC. In the middle of these networks were three routers used for connections. Off the bat, I used the spot-the-differences approach to check the static routes for all routers and each PC's IP configurations. I found that every PC shared the same network when there were meant to be two separate networks. After assigning a different network address to the right-side of the interface, as well as re-configuring the static routes and adjusting other port configurations accordingly, I was still unable to ping between both networks. My next idea was to switch to the divide-and-conquer approach and consider that the problem was either a result of static routing or RIP routing. I double-checked the static routes and they were all correct, so I reasoned that RIP routing likely needed to be configured for the routers. And once I did this, the networks were able to ping each other successfully.

Challenge 5

From the offset, it was evident to me that this challenge involved the configuration of sub-interfaces for VLAN connections. There were two VLAN networks configured---with two devices attached to both---as well as two switches and a multilayer switch. The multilayer switch was an immediate outlier because it would not allow me to configure sub-interfaces. Once I swapped that out with an 1841 router, I added an HWIC-4ESW module for switching ports and connected two of them to the 2nd Floor Switch. After configuring the sub-interfaces in the router's CLI terminal and ensuring that the switching ports were trunk ports and properly assigned, the pings between the Clinic PCs and Guest PCs were unsuccessful. Then, I recalled that each of the switching ports from the router needed to be connected to individual switches rather than the same switch. Once I re-connected the appropriate ports to the switches, this did not make a difference with the pings. Then I noticed that because the sub-interfaces were attached to the FastEthernet 0/0 and 0/1 ports, the existing switching ports needed to be the two aforementioned ports and connected to each switch respectively. I also switched over to using cross-over cables once I did this. Finally, after double-checking everything and ensuring that every port that was meant to be a trunk port was a trunk port, the pings between Clinic PC1 and Guest Laptop 2 went through successfully. I primarily used the spot-the-differences approach for this challenge, however I also used the move-the-problem approach to switch the multilayer switch out with a router at the start.