Building the Network From Scratch
Today I completed what is probably my most challenging Packet Tracer lab so far. Instead of following a guided exercise, I designed and configured a multi-site network from scratch.
Seeing every PC successfully communicate at the end was satisfying, but what mattered more was how much my understanding changed while building it.
I started the lab thinking I already understood VLANs, subnetting, and routing. Once I had to make the design decisions myself, I realized there were several concepts I only understood at a surface level.
Understanding Why Routed Networks Must Be Unique
One of my first questions was whether two different LANs could use the same IP network.
I remembered learning that private IP addresses can be reused, so initially I thought this should work. But after thinking about how routers make forwarding decisions, it started to make sense.
Separate, isolated networks can reuse the same private address space. Once those networks are connected through routing, however, their subnets need to be unique.
If a router sees the same network prefix in two different places, it would have no clear way to determine where that traffic should go.
That realization helped me understand an important rule:
Every routed subnet in the same connected network needs a unique address range.
VLSM Made More Sense in Practice
Subnetting also became much clearer during this lab.
While planning the addressing with VLSM, I accidentally allocated one of the smaller subnets first. That quickly caused problems when I tried to place the larger networks afterward because the address ranges started overlapping.
I reworked the plan by allocating the largest subnet first, then continued from largest to smallest.
Once I did that, the rest of the addressing fell into place naturally.
This was one of those situations where making the mistake actually helped me remember the concept better than simply memorizing the VLSM procedure.
The Access Port vs. Trunk Breakthrough
The biggest breakthrough happened while configuring VLANs.
I already understood the basic idea that trunk links carry multiple VLANs, but I couldn't understand why one of the router connections in my topology didn't need to be configured as a trunk.
At first, I associated trunking with routing.
After stepping through the traffic flow, I realized that was the wrong way to think about it.
The real question is:
How many VLANs need to travel across this physical connection?
If several VLANs share one cable, the traffic needs VLAN tags so the receiving device knows which VLAN each frame belongs to. That connection needs to be a trunk.
If only one VLAN travels across the connection, there is nothing to distinguish. An access port is enough.
That simple distinction made router-on-a-stick much easier to understand.
Comparing Two Inter-VLAN Routing Methods
I also experimented with two different approaches to inter-VLAN routing in the same topology.
On one side, I used router-on-a-stick, where a router uses multiple subinterfaces over a trunk connection.
On the other side, I used a multilayer switch with Switch Virtual Interfaces, or SVIs.
Seeing both approaches working in the same network helped me understand that networking problems do not always have one correct configuration.
Different designs can accomplish the same goal depending on the equipment, network size, and requirements.
Static Routes vs. Default Routes
Toward the end of the lab, I needed to decide how the different routed networks would reach one another.
One option was to configure an individual static route for every VLAN subnet.
That would work, but it would also mean maintaining several routes on the edge routers.
Instead, I used default routes on the edge routers while keeping the central router aware of the internal networks.
The logic became much simpler:
If the edge router does not know the destination, send the traffic toward the central router.
This helped me understand why default routes are useful and how routing decisions can become easier to manage as networks grow.
Learning to Ask Better Questions
Looking back, the biggest lesson from this lab wasn't another Cisco command.
It was learning to ask better questions.
Earlier in my networking studies, I often thought:
What command should I type next?
During this lab, I found myself asking different questions:
Why does this connection need to be a trunk?
Why does this subnet overlap?
How will this router decide where to send the packet?
Does this router really need every route individually configured?
Once I understood the reasoning behind VLAN tagging, subnetting, and routing, the commands became much easier to remember.
What I Took Away From This Lab
This lab reminded me that networking isn't mainly about memorizing commands.
It's about understanding how devices make decisions.
Building the topology from scratch forced me to make mistakes, troubleshoot them, rethink assumptions, and understand why certain configurations worked.
And when every device finally communicated successfully across its local VLAN, between VLANs, and across both sites, it felt much more meaningful because I understood what was happening behind the configuration.
This was easily one of the most rewarding networking exercises I've completed so far.