7.3.3 Lab: Fix A Network Connection

7.3.3 Lab: Fix a Network Connection

The 7.3.3 lab: fix a network connection is a hands‑on exercise that appears in many introductory networking curricula (e.g., Cisco CCNA, CompTIA Network+, or university networking courses). Its purpose is to reinforce the systematic troubleshooting methodology that technicians use when a host cannot reach network resources. By walking through the lab, learners practice verifying physical links, checking IP configurations, testing end‑to‑end connectivity, and isolating problems at the data link, network, or application layers. The following article provides a complete walk‑through of the lab, explains the reasoning behind each step, highlights common pitfalls, and offers best‑practice tips that you can apply to real‑world network issues.

Understanding the Lab Scenario

In the 7.3.3 lab you are typically given a small topology consisting of:

• Two end devices (often PCs or laptops) labeled PC‑A and PC‑B.
• A switch connecting the PCs to the network.
• A router (sometimes a multilayer switch) that provides IP addressing via DHCP and routes traffic between subnets.
• Pre‑configured IP addresses that may be correct, incorrect, or missing.
• A simulated fault such as a disconnected cable, wrong IP address, misconfigured gateway, or ACL blocking traffic.

Your task is to identify why PC‑A cannot ping PC‑B (or cannot reach an external resource like a web server) and then apply the corrective actions to restore connectivity. The lab mirrors the real‑world troubleshooting flow: define the problem → gather information → analyze → implement a solution → verify results → document.

Preparing the Environment

Before diving into the troubleshooting steps, make sure the lab environment is ready:

1. Power on all devices and confirm they have completed their boot sequences.
2. Access the CLI of each PC (or use the GUI if the lab provides it) and the switch/router consoles.
3. Record the baseline topology on a piece of paper or in a text file: note device names, interface labels, expected IP addresses, subnet masks, and default gateways.
4. Disable any unnecessary services (e.g., third‑party firewalls on the PCs) that could interfere with the lab’s built‑in ACLs or QoS policies. Having a clear reference point prevents you from chasing symptoms that are actually caused by mis‑recorded expectations.

Step‑by‑Step Troubleshooting Procedure

Below is the recommended sequence for the 7.3.3 lab. Each step includes the what, why, and how so you can understand the underlying logic rather than just memorizing commands.

1. Verify Physical Connectivity

• Check link LEDs on the NICs and switch ports. A solid green (or amber) light usually indicates Layer 1 is up.
• If a LED is off, reseat the cable, try a different port, or replace the cable.
• Use the show interfaces status command on the switch (if available) to see which ports are in an err‑disable or notconnect state.

Why? Most connectivity problems start at the physical layer. A loose or faulty cable will prevent any higher‑layer communication, making later steps pointless.

2. Confirm Interface Status (Data Link Layer)

• On each PC, run ipconfig /all (Windows) or ifconfig -a / ip addr show (Linux/macOS).
• Verify that the NIC reports “State: Up” and that the MAC address is present.
• On the switch, issue show interfaces <port> switchport to ensure the port is in the correct VLAN and not shut down.

Why? Even if the LED is on, the interface could be administratively shut down or experiencing duplex mismatches. A mismatched duplex (e.g., full‑duplex on one end, half‑duplex on the other) often yields intermittent ping failures.

3. Validate IP Configuration (Network Layer) * Compare the PC’s IP address, subnet mask, and default gateway against the expected values from your topology diagram.

• If the network uses DHCP, run ipconfig /renew (Windows) or dhclient -v <interface> (Linux) to obtain a fresh lease.
• For static configurations, correct any typos in the address or mask.

Why? An incorrect IP address or subnet mask places the host in the wrong logical network, preventing it from reaching the gateway or other subnets. A missing gateway means the host cannot send traffic beyond its local LAN.

4. Test Local Connectivity (Ping the Gateway)

• From PC‑A, ping the default gateway: ping <gateway_IP>.
• If successful, the problem lies beyond the gateway (router or remote host).
• If the ping fails, repeat steps 1‑3 focusing on the link between PC‑A and the switch/router.

Why? Pinging the gateway isolates whether the issue is local (PC‑to‑switch) or involves routing.

5. Verify Routing on the Router (if applicable)

• Access the router CLI and run show ip route.
• Ensure there is a route to the destination network (e.g., PC‑B’s subnet) either via a directly connected interface or a static/dynamic route. * Check for ACLs that might block ICMP: show access-lists or show ip access-list.

Why? Even with correct host configuration, a missing route or an overly restrictive ACL will drop packets before they reach the destination.

6. Test End‑to‑End Connectivity (Ping the Remote Host)

• From PC‑A, ping PC‑B’s IP address: ping <PC‑B_IP>.
• If you receive replies, connectivity is restored.
• If you see “Request timed out.”, move to the next step.
• If you see “Destination host unreachable.”, the problem is likely at the router (no route or ACL).

7. Use Traceroute to Pinpoint the Failure Point

• Run tracert <PC‑B_IP> (Windows) or traceroute <PC‑B_IP> (Linux/macOS).
• Observe where the packets stop. The last successful hop indicates the device just before the failure.
• Examine that device’s configuration (interface status, ACLs, NAT,

8. Address Issues at the Failure Point

If traceroute identifies a specific device (e.g., a switch, router, or intermediate hop) where packets fail, investigate that device:

• Switch: Check the MAC address table (show mac address-table) to ensure the destination host’s MAC is learned on the correct port. Verify the port is access or trunk as required and that the VLAN is correctly assigned.
• Router: Confirm the interface connected to the destination subnet is up and has the correct IP address. Use show ip interface brief to validate status and IP assignment.
• ACLs/Firewalls: If the failure occurs at a router or firewall, review access control lists (show access-lists) or firewall rules to ensure ICMP traffic (or the specific port/protocol) is permitted.

Why? A misconfigured ACL, firewall rule, or MAC table entry can silently drop packets, even if the physical and logical layers appear functional.

9. Check for Duplex/Speed Mismatches

If intermittent connectivity persists, verify duplex and speed settings on both ends of the link:

• Run show interfaces <port> switchport on the switch to confirm auto-negotiation is enabled.
• On the connected device (PC, server, or router), check the interface speed/duplex (e.g., ethtool eth0 on Linux).
• Force matching settings if necessary (e.g., speed 100 duplex full).

Why? Duplex mismatches cause late collisions, packet loss, and degraded performance, often masquerading as routing or VLAN issues.

10. Test with Different Tools and Protocols

If ICMP (ping) fails but other traffic works, test with alternative protocols (e.g., HTTP, FTP) or tools:

• Use telnet <PC-B_IP> 80 to test HTTP connectivity.
• Run traceroute with TCP (traceroute -T <PC-B_IP>) to bypass ICMP filtering.
• Check for stateful firewall rules blocking ICMP but allowing other traffic.

Why? Some networks block ICMP for security reasons but allow other protocols, revealing partial connectivity.

Conclusion

Network troubleshooting is a systematic process of elimination. By methodically checking physical connections, layer 2 configurations (VLANs, MAC tables), layer 3 settings (IP addresses, routing), and intermediate devices (switches, routers, firewalls), you can isolate the root cause. Tools like ping, traceroute, and device-specific CLI commands provide critical insights, but context from topology diagrams and configuration backups is equally vital. Remember: even a single misconfigured ACL, duplex mismatch, or misplaced cable can disrupt connectivity. Patience, precision, and a layered approach ensure efficient resolution.

When in doubt, document every step and test change impact incrementally—network stability depends on it.