Define the topology and the expected user journey

Build two access switches connected to a distribution Layer 3 switch or suitable router, plus a second router toward a simulated remote service. Assign VLAN 10 to ordinary clients and VLAN 20 to a printer or service segment. In a documentation-only example, VLAN 10 uses 192.0.2.0/24, VLAN 20 uses 198.51.100.0/24, and the remote transit or service network uses part of 203.0.113.0/24. These RFC 5737 ranges should remain within the lab; they are not production Internet addresses.

Add IPv6 global-unicast examples using the reserved 2001:db8::/32 documentation prefix, with separate /64 LANs. Label each connection, port and VLAN, and document the intended access/trunk mode. The source client should reach its own gateway, a remote lab server by address and, when DNS is configured, by a name in an authorized local testing zone. The baseline must work before fault injection; otherwise it is impossible to know whether the later symptom was created by the intended error or inherited from an unfinished topology.

Write down each device’s role and expected path. The client sends an Ethernet frame to its gateway for off-subnet traffic. The distribution switch or router forwards according to the installed destination route. The remote router delivers the packet to the service segment, and the return path reaches the original client. A service can fail if any stage is absent, so the exercise should identify where each stage can be observed.

Establish a baseline with addresses, routes and interface state

Verify Layer 1 and Layer 2 first. On the switches, record interface status, VLAN assignments and which VLANs are actively carried on trunks. Confirm the relevant MAC learning and spanning-tree state. On the client, record IPv4 address, subnet mask, default gateway and DNS settings. A green interface LED is not the baseline; the baseline is a documented path from an endpoint’s access port to its routed gateway.

At Layer 3, inspect connected and static or dynamic routes for both directions. Use the specific remote service address when applying longest prefix match. If OSPF is part of the topology, capture neighbor relationships and learned routes before changing anything. On IPv6, record global and link-local addresses, default routes and neighbor discovery state separately from IPv4; a dual-stack client may behave differently in the two families.

Generate a small volume of permitted traffic to the test service and capture successful results. Avoid an uncontrolled traffic flood that would turn a networking lab into a capacity test. Save the running configuration of each device, or the relevant simulator snapshot, and mark it as the known-good state. A reversible baseline makes deliberate faults educational rather than destructive.

Inject one VLAN or trunk fault and isolate its symptoms

First remove VLAN 20 from the allowed list of a single appropriate interswitch trunk in the lab. Predict which clients and services will still work. If VLAN 10 remains allowed, the source client’s local gateway may still respond. Traffic destined for the VLAN 20 service fails because that broadcast domain cannot traverse the missing segment, even if the routing table contains a correct connected route. The observation should distinguish the route’s existence from the inability to deliver frames to the intended endpoint.

Use the switch’s trunk display, VLAN status and MAC address table to find where VLAN 20 disappears. Restoring the allowed list should be sufficient if the rest of the baseline is sound. Do not ‘repair’ the problem with a default route that sends traffic elsewhere. Repeat with the VLAN 20 SVI disabled and compare the symptoms: the logical gateway can now be down even when the trunk carries the VLAN correctly.

A good lab report lists the fault, affected flows, unaffected flows, key interface and VLAN outputs, and the corrective command or change. The contrast between an allowed-VLAN fault and an SVI-state fault matters more than memorizing both command syntaxes.

Inject a routing failure and test the reverse path

Restore the switching baseline and change one static route or OSPF advertisement so that the remote service network no longer has a valid path. Predict whether the source client can reach its own gateway and the remote router’s transit interface. Those tests are expected to remain possible if the route error affects only the service subnet. Inspect the route table for the exact destination and check the next hop’s reachability rather than automatically assuming that any default route should solve the failure.

Next introduce a return-path fault at the remote router while leaving the forward path correct. The client may send a packet that reaches the destination, yet the reply never returns. A capture near the server and a route lookup for the source subnet reveal that asymmetry. This scenario is especially helpful because a naive test from the destination to an unrelated source may suggest the network is healthy. Record packet source, destination and chosen interfaces in each direction.

If the lab supports a backup static route, test a controlled primary-link failure and observe whether a floating route becomes installed. A route present only in configuration is not the same as an installed forwarding choice. Capture the route table before, during and after the failure to establish actual failover behavior.

Introduce a service and policy fault without changing routing

With switching and routing restored, misconfigure the lab DHCP relay or server scope so one client cannot obtain the expected address. Observe whether the client sends Discover and whether an Offer arrives. This is a service delivery problem, not a routing fault in the user’s application path—although the relay’s route to the server can be one contributing factor. Record the lease and gateway options when service is repaired.

Then configure an intentionally wrong DNS A or AAAA answer for the lab server or temporarily remove the relevant record. Test the service by address and by name. If IP connectivity succeeds but the name fails, the evidence isolates resolution from packet forwarding. Do not change a working ACL or static route because the browser says ‘server not found.’ The distinction between a missing DNS answer and an unreachable resolved address should be explicit in the final notes.

Finally apply a deliberate ACL deny to the test application protocol while leaving simple ICMP pings permitted. A successful ping now coexists with application failure. Compare the ACL hit counter with the expected packet flow, and restore the intended policy. The exercise proves why ‘ping works’ is not a sufficient definition of service health.

Extend the incident to IPv6 and wireless where supported

On the IPv6 LAN, deliberately assign the wrong prefix length to one endpoint or remove default-router advertisement. Compare its neighbor table and routes with a correctly configured client. A global IPv6 address does not guarantee a usable remote route. If the endpoint prefers IPv6 based on an AAAA answer, it can encounter a different failure from IPv4; test both explicitly rather than assume the network is one homogeneous path.

If an access point is part of the topology, map a WLAN to VLAN 10 and introduce a wrong VLAN assignment for a guest or test SSID. Record whether the client can authenticate and associate before address assignment fails. Radio association success does not clear the switched uplink and DHCP path. Conversely, a client that cannot associate should not trigger immediate troubleshooting of OSPF on the remote router.

Only extend the lab when the environment supports the necessary behavior. Packet Tracer, Cisco Modeling Labs and other tools differ in feature support, and a virtual lab cannot reproduce every fiber power or radio-frequency measurement. Label simulated or conceptual outputs as such. A reliable smaller lab with observable faults is more valuable than an impressive diagram whose results have been invented.

Collect evidence as if another engineer must verify it

For each fault, use one table with symptom, initial hypothesis, first confirming command, disconfirming evidence, root cause, smallest correction and post-fix verification. Preserve device name, interface and timestamp where relevant. A command transcript without an explanation is less useful than a short narrative that predicts and then verifies how the packet path should change. The purpose is to make the conclusion independently reviewable.

The lab also supports operational habits beyond exam study. Save a prechange snapshot, review the blast radius, alter one variable at a time and have an explicit rollback. If a command behaves differently from the reference because of IOS version or emulator limitations, investigate the difference and document it instead of pretending the reference is universal.

A peer review should ask whether the evidence truly supports the conclusion. If the student says ‘DNS was broken’ but did not query the actual resolver, the claim may be stronger than the data. If they say ‘OSPF was fixed’ but only pinged a connected subnet, the test may not have exercised OSPF at all. Honest uncertainty and the right next command are central parts of network engineering work.

Adapt the same topology to CCNA v1.1 or v2.0 objectives

CCNA v1.1 asks candidates to configure and verify network access, routing, services and security, while the announced v2.0 increases explicit troubleshooting and configuration work in IPv6, DHCPv4, OSPFv3, DNS, NAT/PAT, access security, network operations and management. A candidate sitting v1.1 can focus the lab on the currently listed task verbs, while a post-February-2027 candidate should extend it to the specific v2.0 objectives. Do not treat the newer blueprint as already active simply because it has been published.

The IPv4 subnetting article provides the addressing calculations, and the Cisco lab tools comparison helps choose a practice environment. Match the project to the applicable Cisco v1.1 specification or v2.0 objectives. A strong completed lab is not defined by the number of devices, but by its verified explanation of what fails, where and why.