I wanted to reinforce that learning with a practical exercise in Cisco Packet Tracer. Rather than simply repeating commands, I wanted to start understanding what network activity looks like and how devices communicate.

Here’s what I built, what I investigated, and what I learned.

The Lab Setup

I started with a basic LAN consisting of two PCs connected to a Cisco 2960 switch.

Topology:

PC0: 192.168.1.10 PC1: 192.168.1.20 Subnet mask: 255.255.255.0 One Cisco 2960 switch The goal was to establish connectivity, generate network traffic, and investigate what happened behind the scenes.

One early mistake was connecting the PCs directly to each other instead of connecting both to the switch. Once I corrected the topology, I could continue testing connectivity.

It’s a simple mistake, but it reinforced an important lesson: before troubleshooting higher-level networking issues, verify the physical connections first.

1. Testing Connectivity with Ping

I started by running the following command from PC1:

ping 192.168.1.20

This tested whether PC1 could communicate with PC2.

Instead of stopping after seeing successful replies, I opened Simulation Mode in Packet Tracer and filtered the events to observe ARP and ICMP traffic.

This allowed me to inspect the packets rather than treating ping as a command that simply returns a success or failure message.

2. Identifying ICMP Echo Requests and Replies

When I opened the packet details, I found an ICMP Type field.

The first packet I inspected showed:

ICMP Type 8: Echo Request ICMP Type 0: Echo Reply An Echo Request is the message sent by PC0 when it pings PC1. The Echo Reply is the response returned by PC1.

This was a useful exercise because I could verify the purpose of each packet directly in the simulation.

I wasn’t just seeing that the ping worked. I was observing the request and response that made the connectivity test possible.

3. Investigating MAC Addresses on the Switch

Next, I opened the switch CLI and ran:

enable

show mac address-table dynamic

The switch displayed learned MAC addresses associated with its interfaces.

This helped me understand that a switch maintains a MAC address table to determine which port to use when forwarding Ethernet frames.

The table connects two important pieces of information:

The MAC address of a device. The switch port through which that address was learned. This is different from an IP routing table. A Layer 2 switch uses its MAC address table to forward Ethernet frames within a LAN.

4. Inspecting the ARP Table

I then opened PC0’s command prompt and ran:

arp -a

I found PC1’s IP address associated with a physical address, which is its MAC address.

ARP, or Address Resolution Protocol, helps a device discover the MAC address associated with an IPv4 address on the local network.

This gave me an opportunity to compare two tables that contain MAC address information but serve different purposes.

The ARP table on PC0 maps IP addresses to MAC addresses known by the host.

The switch’s MAC address table associates learned MAC addresses with switch ports.

Both are useful when investigating local network communication, but they answer different questions.

An ARP entry also doesn’t guarantee that a device is reachable at that exact moment. A successful ping provides additional evidence that communication is working.

5. Connecting the Exercise to Linux

netstat

My LabEx exercise focused on using netstat to inspect network activity on Linux.

Some of the commands I practiced included:

netstat -a

netstat -t

netstat -u

netstat -l

netstat -n

These options help inspect socket information, including active and listening sockets, TCP and UDP sockets, and numerical addresses and port numbers.

Packet Tracer doesn’t reproduce the Linux netstat command or its socket output. Instead, it provides a complementary way to observe network communication at the packet level.

The distinction is important:

Linux netstat: Helps investigate sockets and network connections on a system. Packet Tracer Simulation Mode: Helps visualize individual packets and inspect their protocol information. arp -a: Displays the host’s ARP cache. show mac address-table dynamic: Displays MAC addresses dynamically learned by the switch. These tools provide different views of networking. Learning what each one reveals is part of developing a troubleshooting process.

What I Learned

This exercise reinforced several networking fundamentals:

Physical connectivity needs to be verified before moving on to higher-level troubleshooting. Ping uses ICMP Echo Requests and Echo Replies to test reachability. ARP maps IPv4 addresses to MAC addresses on the local network. Switches learn MAC addresses from incoming Ethernet frames and associate them with ports. A successful command is only part of the learning process. Inspecting the output helps explain what actually happened. I’m still building my understanding of these concepts, but being able to generate traffic, inspect packets, and compare device tables gives me a more practical foundation than memorizing commands alone.

What’s Next?

My next step is to build on this foundation with a small client-server network in Packet Tracer. I want to observe TCP connections and application traffic, then relate what I see to the socket and port information available through Linux networking tools.

I’m working toward becoming a network engineer, and I’m trying to make each lab count by connecting the theory to something I can observe and troubleshoot.

One lab at a time.

Rather than just reading about IP addressing, default gateways, and network connectivity, I wanted to build a network, configure it myself, and test whether everything worked.

This lab focused on building two separate local area networks (LANs) connected through a router.

The goal was simple: get all four PCs communicating with one another, including devices on different networks.

1. Building the Network Topology

I started with the following devices in Cisco Packet Tracer:

1 Cisco router 2 Cisco switches 4 PCs Copper straight-through Ethernet cables The topology consisted of two LANs:

LAN 1

PC0 PC1 Switch 1 LAN 2

PC2 PC3 Switch 2 Each switch connected to a separate Ethernet interface on the router.

The router provided the connection between the two networks.

The physical layout was:

PC0 and PC1 → Switch 1 → Router → Switch 2 ← PC2 and PC3

This helped reinforce the roles of different networking devices. Switches connect devices within a LAN, while a router forwards traffic between different IP networks.

1. Configuring IPv4 Addresses

The next step was assigning IP addresses to the PCs and router interfaces.

I used two separate /24 networks.

Device

IPv4 Address

Subnet Mask

PC0

192.168.1.10

255.255.255.0

PC1

192.168.1.11

255.255.255.0

Router G0/0

192.168.1.1

255.255.255.0

Router G0/1

192.168.2.1

255.255.255.0

PC2

192.168.2.10

255.255.255.0

PC3

192.168.2.11

255.255.255.0

The first network was 192.168.1.0/24, and the second was 192.168.2.0/24.

The /24 prefix means the first 24 bits identify the network, leaving eight bits for host addresses.

This configuration placed PC0 and PC1 on one network and PC2 and PC3 on another.

1. Configuring the Router

The router needed an IP address on each interface connected to a LAN.

I configured the interfaces through the router’s CLI.

enable

configure terminal

interface gigabitEthernet 0/0

ip address 192.168.1.1 255.255.255.0

no shutdown

exit

interface gigabitEthernet 0/1

ip address 192.168.2.1 255.255.255.0

no shutdown

end

The ip address command assigned an address and subnet mask to each interface.

The no shutdown command enabled the interface administratively.

I also learned that enabling an interface does not automatically guarantee connectivity. The cable, switch port, and other end of the connection must also be functioning.

To check the interfaces, I used:

show ip interface brief

The goal was to see both connected router interfaces showing up/up.

1. Understanding Default Gateways

This was one of the most important parts of the lab.

Initially, I was troubleshooting failed pings and discovered that a PC did not have a default gateway configured.

The default gateway is the IP address of the router interface a PC uses to reach destinations outside its local network.

I configured the gateways as follows:

PCs

Default Gateway

PC0 and PC1

192.168.1.1

PC2 and PC3

192.168.2.1

Each PC needed to use the router interface belonging to its own subnet.

For example, PC0 had the address 192.168.1.10, so its gateway was 192.168.1.1.

PC2 had the address 192.168.2.10, so its gateway was 192.168.2.1.

I also learned that the gateway is configured in the PC’s Desktop → IP Configuration window in Packet Tracer, not in the router’s Static Routes section.

Because both networks were directly connected to the router, the router could learn their routes automatically. I did not need to configure static routes for this lab.

1. Testing Connectivity with Ping

Once the devices were configured, I used the ping command to test connectivity.

From PC0, I tested the following destinations:

ping 192.168.1.11

ping 192.168.1.1

ping 192.168.2.1

ping 192.168.2.10

ping 192.168.2.11

These tests served different purposes.

192.168.1.11: Tested connectivity to PC1 on the same LAN. 192.168.1.1: Tested connectivity to the local router interface. 192.168.2.1: Tested connectivity to the router interface on the second LAN. 192.168.2.10 and 192.168.2.11: Tested connectivity to the PCs on the second LAN. The ping command uses ICMP echo requests and replies to help verify IP connectivity.

1. Troubleshooting the Failed Pings

The first attempts did not work as expected. I encountered 100% packet loss and a destination-unreachable message.

Instead of rebuilding the entire network, I worked through the possible causes.

Checking interface status

I ran:

show ip interface brief

The router interfaces were showing as up, so I continued checking the configuration rather than assuming the physical links were the problem.

Checking IP addressing

I verified that the PCs were assigned addresses in the correct subnets and that the subnet masks were consistent.

A device on 192.168.1.0/24 and a device on 192.168.2.0/24 belong to different networks, even though both addresses begin with 192.168.

Finding the missing default gateway

The key issue was a PC without a default gateway.

Without the correct gateway, a PC can communicate with devices on its own subnet, but it cannot properly forward traffic to destinations on other subnets.

I corrected the gateway configuration and ensured that the PCs on each LAN used the IP address of their local router interface.

Testing again

After correcting the configuration, I repeated the ping test from PC0 to PC2.

This time, it worked.

Alhamdulillah, the network was communicating across both LANs.

This troubleshooting process reinforced an important lesson: when connectivity fails, verify the addressing and gateway configuration before making unnecessary changes elsewhere.

1. What I Learned

This lab gave me practical experience with several networking fundamentals:

IPv4 addressing: Assigning unique addresses to hosts and router interfaces.

Subnet masks: Understanding how devices determine whether a destination belongs to their local network.

Default gateways: Configuring the next hop for traffic destined for other networks.

Router interfaces: Assigning IP addresses and enabling interfaces through the Cisco IOS CLI.

Ping and ICMP: Using connectivity tests to identify where communication may be failing.

Troubleshooting: Checking interface status, verifying addressing, identifying a missing gateway, and testing again after correcting the configuration.

I also reinforced the difference between a router interface IP address, a PC’s default gateway, and a static route. They are related, but they serve different purposes.

1. Final Thoughts

One of the biggest takeaways from this exercise was that networking concepts become easier to understand when I actually configure and troubleshoot them.

Reading about default gateways is one thing. Seeing a network fail, investigating the problem, correcting the missing configuration, and watching the ping succeed is another.

This was a useful step in building my networking foundation as I continue working toward network engineering and studying for CompTIA Network+ and eventually CCNA-level material.

The next step is to expand the topology and practice additional routing, subnetting, and network troubleshooting scenarios.

One lab at a time. One concept at a time.

Alhamdulillah.

Objective

Connect two PCs through a switch, assign static IPs, and verify connectivity with ping.

Topology

| Link | Cable |

| PC1 to Switch | Copper straight-through |

| PC2 to Switch | Copper straight-through |

Addressing

| Device | IP Address | Subnet Mask |

| PC1 | 192.168.0.1 | 255.255.255.0 |

| PC2 | 192.168.0.2 | 255.255.255.0 |

| MAC Address |

Configuration

On each PC: Desktop > IP Configuration > Static, then enter the IP and mask. No gateway is needed because both PCs are on the same subnet. The switch runs on its default configuration.

Verification

From PC1:

ping 192.168.0.2

Observations

• PC1 (192.168.0.1) pinged PC2 (192.168.0.2) across the switch: 4 of 4 replies, 0% loss, round-trip times under 1 ms.

• TTL=128 on all replies, the default for Packet Tracer PCs, which fits a single-switch lab with no router.

• ipconfig/all returns "Invalid Command." The correct syntax is ipconfig /all, with a space.

Takeaways

• Devices on the same subnet communicate through a switch without a router.

• Straight-through cable is used for PC to switch.