Cisco Networking Labs
My Cisco labs are the closest repeated simulation of real network operations in my current experience. Each exercise turns requirements into an address plan and topology, coordinates configuration across multiple devices, verifies the resulting state, introduces or reveals faults, and requires evidence that the final network works for the intended reason.
Why these labs lead the portfolio
The Cisco labs are the closest repeated simulation of day-to-day infrastructure work in my current experience. Requirements become a topology and address plan, several device configurations have to agree, and evidence must prove that traffic follows the intended path.
They also produce useful failures. A host can have the right address but the wrong gateway; a trunk can be active but omit one VLAN; a routing adjacency can form while a network statement is incomplete; or NAT can hide an addressing problem until traffic crosses a particular boundary.
Planning and topology
Before configuration, I identify networks, broadcast domains, device roles, gateways, routing boundaries, services, and expected traffic flows. IPv4 subnets and IPv6 prefixes are assigned deliberately so verification output can be compared with the intended plan.
The topology record includes interface names, link types, VLAN IDs, trunk expectations, routed networks, DHCP scopes, DNS assumptions, and the commands that should prove each layer.
Layer 2 configuration
Switching work includes VLAN creation, access-port assignment, 802.1Q trunks, native-VLAN and allowed-VLAN checks, spanning-tree observation, and router-on-a-stick where inter-VLAN routing is required.
Verification uses interface status, VLAN tables, trunk state, MAC learning, spanning-tree output, and end-host tests. A configured command is not accepted as evidence until operational state and traffic agree.
Routing and services
Routed labs include static and default routes together with introductory OSPF and EIGRP behavior. I inspect routing tables, next hops, administrative distance, metrics, neighbor state, advertised networks, passive interfaces, and the effect of a failure or changed path.
Supporting services include DHCP, DNS, NAT, IPv4 and IPv6 gateways, and selected access controls. These services are tested from the client perspective as well as from the device providing them.
Troubleshooting sequence
I start with the intended path and narrow the fault domain instead of changing several devices at once.
- Confirm the endpoint address, prefix, gateway, and DNS information.
- Check physical and data-link interface state.
- Verify VLAN membership and trunk carriage.
- Inspect neighbor tables and local routes.
- Follow the routing table hop by hop.
- Check service-specific state such as DHCP bindings, NAT translations, or routing neighbors.
- Use ping, traceroute, IOS show commands, Wireshark, and packet-level evidence where needed.
- Make one justified correction and retest the original path.
Evidence and documentation
Each lab should preserve the requirement, topology, address plan, relevant configuration, initial symptom, observed state, likely fault domain, corrective action, and final verification. Screenshots are useful only when the command and its meaning remain clear.
This approach makes the work reproducible and easier to explain in an interview. It also exposes cases where a local ping succeeds while the complete end-to-end requirement still fails.
Realism and limits
Packet Tracer and CML are controlled learning environments. They are useful for protocol reasoning and repeatable faults, but they do not reproduce every hardware behavior, provider dependency, wireless condition, licensing issue, scale limit, or operational process in a production network.
The next stage is connecting these skills to the Proxmox home lab: segmented virtual networks, routing and firewall boundaries, Windows and Linux services, traffic capture, centralized logs, backups, and recovery tests.