Build an Inter-VLAN Network

Build and troubleshoot VLAN trunks and router-on-a-stick in Packet Tracer.

Introduction

30 Second Summary

Connected cables and green link lights can still hide the reason two computers cannot communicate. A clear trail of evidence turns that mystery into a problem you can isolate.

In this project, you will build a small enterprise network in Cisco Packet Tracer. You will use a planned failure to identify the missing Layer 3 path before restoring communication with router-on-a-stick.

What You'll Build

Your finished topology lets PC-A reach PC-B across separate VLANs through one shared router link.

By the end of this project, you'll have:

  • A working inter-VLAN network where PC-A reaches PC-B across an 802.1Q trunk through one physical router link.
  • A repeatable troubleshooting workflow that uses ping, tracert, VLAN tables, trunk state, and interface status to pinpoint a broken path.
  • A labeled .pkt network artifact that reopens with the working baseline ready to demonstrate.
  • Secret Mission: A controlled native VLAN mismatch that you diagnose from trunk evidence before restoring the working baseline.

Are there any prerequisites?

You need basic IPv4 addressing knowledge plus familiarity with the Cisco IOS CLI before you start.

This project is the first hands-on milestone in a skills-first path toward CCIE Enterprise Infrastructure.

Before We Start

Before the hands-on work begins, lock in what this network will demonstrate. Connecting the lab to evidence-based troubleshooting gives your first milestone on the path toward CCIE a clear purpose.

Set Up the Packet Tracer Lab

Troubleshooting only works when every device starts from a known baseline. A fixed topology makes each later result useful evidence.

In this step, you will build that baseline in Cisco Packet Tracer. You will save the topology after assigning the planned IPv4 settings to both PCs.

In this step, get ready to:
  • Save a blank logical topology as ccie-roadmap-project-1.pkt.
  • Assemble the documented five-device topology.
  • Confirm both PCs use the planned static IPv4 settings.
Save the blank logical topology

A .pkt file preserves your Packet Tracer network as it develops. Saving the blank topology now gives the lab a stable home from the start.

  • In the Packet Tracer window from earlier, start a blank logical topology.
  • Use the save control to store the topology as ccie-roadmap-project-1.pkt.

You should see ccie-roadmap-project-1.pkt associated with the open topology.

Can't Confirm the Saved File?

  • Use the save control again if the filename is missing from the open topology.
  • Choose a location you can find again if Packet Tracer asks where to store the file.

Help me save my Packet Tracer topology.

Assemble the documented topology

Device models define the physical capabilities available in the lab. Exact interface choices keep your later troubleshooting evidence comparable with the documented baseline.

  • Place one Cisco 4221 router in the logical workspace.
  • Rename the router R1.
  • Place the first Cisco Catalyst 2960 switch in the logical workspace.
  • Rename the first switch S1.
  • Place the second Cisco Catalyst 2960 switch in the logical workspace.
  • Rename the second switch S2.
  • Place the first PC in the logical workspace.
  • Rename the first PC PC-A.

Why These Exact Devices?

These models expose the interfaces used by the reference lab. Matching them keeps the port names consistent throughout the project.

A different model can present different interface identifiers. Consistent hardware removes that source of confusion.

  • Place the second PC in the logical workspace.
  • Rename the second PC PC-B.
  • Connect R1 interface G0/0/1 to S1 interface F0/5 using Packet Tracer's connection controls.
  • Connect S1 interface F0/1 to S2 interface F0/1 using Packet Tracer's connection controls.
  • Connect PC-A to S1 interface F0/6 using Packet Tracer's connection controls.
  • Connect PC-B to S2 interface F0/18 using Packet Tracer's connection controls.

You should now see five labeled devices joined by four links. The selected interface labels should match the documented connections.

Confirm the PC addressing baseline

Each PC needs a static IPv4 address in its assigned subnet. A default gateway gives the PC a destination for traffic outside that subnet.

  • Select PC-A in the logical topology.
  • Open its IPv4 configuration view from the desktop tools.
  • Set its IPv4 address to 192.168.3.3.
  • Set its subnet mask to 255.255.255.0.
  • Set its default gateway to 192.168.3.1.

How Do These Values Fit Together?

The address 192.168.3.3 identifies PC-A within its local subnet. The mask 255.255.255.0 defines which addresses belong to that subnet.

The address 192.168.3.1 is PC-A's default gateway. The router takes that gateway address in a later step.

  • Switch to PC-B in the logical topology.
  • Open its IPv4 configuration view from the desktop tools.
  • Set its IPv4 address to 192.168.4.3.
  • Set its subnet mask to 255.255.255.0.
  • Set its default gateway to 192.168.4.1.
  • Open a command prompt from PC-A's desktop tools.
  • Open a command prompt from PC-B's desktop tools.

Before you run the check, which address details do you expect each PC to report?

  • Display the saved network settings on each PC by running this command in both command prompts:
ipconfig /all

What Does This Command Show?

The ipconfig /all command reports the PC's complete network settings. It lets you compare the active values with the addressing plan.

On PC-A, you'll see IPv4 address 192.168.3.3. You'll also see subnet mask 255.255.255.0 plus default gateway 192.168.3.1.

On PC-B, you'll see IPv4 address 192.168.4.3. You'll also see subnet mask 255.255.255.0 plus default gateway 192.168.4.1.

Address Details Don't Match?

  • Return to the PC whose output differs.
  • Correct the differing field in its IPv4 configuration view.
  • Rerun the verification command shown above.

Help me correct my PC addressing.

  • Save ccie-roadmap-project-1.pkt again with the verified PC settings.

You have the baseline locked in. Every later test now starts from known devices, links, and addresses.

✔️ Awesome, I've got everything!

Great. Your saved topology now has the required devices, links, names, and PC addressing.

ⓧ I'd like to double check the full topology

Compare your saved topology with this baseline:

  • The open file is named ccie-roadmap-project-1.pkt.
  • The topology contains R1 as a Cisco 4221 router.
  • The topology contains S1 plus S2 as Cisco Catalyst 2960 switches.
  • The topology contains PCs named PC-A plus PC-B.
  • The first link joins R1 G0/0/1 to S1 F0/5.
  • The second link joins S1 F0/1 to S2 F0/1.
  • The third link joins PC-A to S1 F0/6.
  • The fourth link joins PC-B to S2 F0/18.
  • PC-A uses 192.168.3.3 with mask 255.255.255.0 plus gateway 192.168.3.1.
  • PC-B uses 192.168.4.3 with mask 255.255.255.0 plus gateway 192.168.4.1.
  • No VLAN, trunk, SVI, or router subinterface configuration is present.

The physical baseline is ready. Next up, you'll create department boundaries with VLANs.

Create VLAN Segmentation and Trunks

Your Cisco Packet Tracer topology now has two PCs with verified static IPv4 settings. Now you will create explicit department boundaries on the switches.

A VLAN limits a Layer 2 broadcast domain. An 802.1Q trunk carries several VLANs across one physical link.

The default VLAN currently groups the switch ports into one broadcast domain. This step creates controlled paths for Management traffic and Operations traffic.

In this step, get ready to:
  • Create the named department VLANs on both switches.
  • Place the PC-facing ports into their planned VLANs.
  • Build controlled trunk links between the switches and toward R1.
Inspect and create the VLANs

The current VLAN table gives you a baseline before configuration begins. This turns every later difference into evidence from your own network.

  • Select S1 in the existing topology.
  • Choose its command-line interface tab.
  • Inspect the current VLAN table by running these commands:
enable
show vlan brief

What do these commands show?

  • The enable command enters privileged mode so you can inspect the switch.
  • The show vlan brief command lists each VLAN with its name and assigned ports.

You should see the active access ports grouped into the default VLAN. This is the single broadcast domain that you are about to divide.

  • Apply the planned VLAN names on S1 by running these commands:
enable
configure terminal
vlan 3
name Management
exit
vlan 4
name Operations
exit
vlan 8
name Native
exit
end
show vlan brief

What does this configuration do?

  • VLAN 3 creates the Management broadcast domain.
  • VLAN 4 creates the Operations broadcast domain.
  • VLAN 8 becomes the planned native VLAN for the trunk links.
  • The final show vlan brief command verifies the three names on S1.

You should see VLAN 3 named Management. You should also see VLAN 4 named Operations plus VLAN 8 named Native.

Missing a VLAN on S1?

Check that each name command was entered inside the matching VLAN configuration mode.

Run show vlan brief again after returning to privileged mode.

Help me fix the VLAN table on S1.

  • Switch back to the logical topology.
  • Select S2.
  • Choose its command-line interface tab.
  • Apply the same VLAN plan on S2 by running these commands:
enable
configure terminal
vlan 3
name Management
exit
vlan 4
name Operations
exit
vlan 8
name Native
exit
end
show vlan brief

Why repeat the VLAN plan?

Each switch maintains its own VLAN database. Creating the same VLAN IDs on S2 lets the upcoming trunk carry those broadcast domains between both switches.

You should now see VLANs 3, 4, and 8 with the same names on both switches.

Different VLAN names on S2?

Confirm that VLAN 3 is named Management. Confirm that VLAN 4 is named Operations.

Confirm that VLAN 8 is named Native.

Help me correct the VLAN names on S2.

Assign access ports and management addresses

A static access port places one endpoint into one VLAN. A switch virtual interface gives each switch an IPv4 presence inside VLAN 3.

The switch management address identifies the switch itself. The default gateway provides the route used when management traffic eventually leaves the local subnet.

  • Return to the command-line interface on S1.
  • Configure the PC-A access port plus the S1 management interface by running these commands:
enable
configure terminal
interface f0/6
switchport mode access
switchport access vlan 3
exit
interface vlan 3
ip address 192.168.3.11 255.255.255.0
no shutdown
exit
ip default-gateway 192.168.3.1
end
show vlan brief
show ip interface brief

What does the S1 configuration do?

  • The access-port commands place PC-A in VLAN 3 through F0/6.
  • The VLAN 3 interface gives S1 the management address 192.168.3.11 with a 255.255.255.0 mask.
  • The default gateway points management traffic toward 192.168.3.1.
  • The final two commands verify port membership plus the management address.

You should see F0/6 assigned to VLAN 3. You should also see 192.168.3.11 on the VLAN 3 interface.

S1 port or address missing?

Check that F0/6 appears under VLAN 3 in the VLAN table.

Check that the IP address belongs to the VLAN 3 interface instead of the physical PC port.

Help me troubleshoot the S1 access port or management interface.

  • Return to the command-line interface on S2.
  • Configure the PC-B access port plus the S2 management interface by running these commands:
enable
configure terminal
interface f0/18
switchport mode access
switchport access vlan 4
exit
interface vlan 3
ip address 192.168.3.12 255.255.255.0
no shutdown
exit
ip default-gateway 192.168.3.1
end
show vlan brief
show ip interface brief

What does the S2 configuration do?

  • The access-port commands place PC-B in VLAN 4 through F0/18.
  • The VLAN 3 interface gives S2 the management address 192.168.3.12 with a 255.255.255.0 mask.
  • The default gateway points management traffic toward 192.168.3.1.
  • The verification commands display the new access-port membership plus the SVI address.

You should see F0/18 assigned to VLAN 4. You should also see 192.168.3.12 on the VLAN 3 interface.

S2 port or address missing?

Check that F0/18 appears under VLAN 4 in the VLAN table.

Check that S2 uses 192.168.3.12 for its VLAN 3 interface.

Help me troubleshoot the S2 access port or management interface.

Build the 802.1Q trunk path

The inter-switch trunk carries Management traffic and Operations traffic over the same cable. VLAN 8 handles untagged traffic consistently because both ends use the same native VLAN.

The allowed VLAN list limits the link to the three VLANs used by this topology. This keeps the trunk aligned with the documented design.

  • Return to the command-line interface on S1.
  • Configure the S1 end of the inter-switch trunk by running these commands:
enable
configure terminal
interface f0/1
switchport mode trunk
switchport trunk native vlan 8
switchport trunk allowed vlan 3,4,8
end
show interfaces FastEthernet0/1 switchport

What does the S1 trunk configuration do?

  • The trunk mode lets F0/1 carry several VLANs.
  • The native VLAN setting assigns untagged traffic to VLAN 8.
  • The allowed list restricts the trunk to VLANs 3, 4, and 8.
  • The final command displays the administrative switchport settings for F0/1.

You should see F0/1 configured for trunking. The port details should show native VLAN 8 plus the allowed list 3,4,8.

S1 trunk values look wrong?

Check that all three trunk commands were entered under F0/1.

Enter the allowed list as 3,4,8 without spaces.

Help me correct the S1 F0/1 trunk configuration.

  • Return to the command-line interface on S2.
  • Configure the S2 end of the inter-switch trunk by running these commands:
enable
configure terminal
interface f0/1
switchport mode trunk
switchport trunk native vlan 8
switchport trunk allowed vlan 3,4,8
end
show interfaces FastEthernet0/1 switchport

Why must the S2 values match?

Both ends need the same native VLAN plus the same allowed VLAN list. Matching values create a predictable path for VLAN 3 and VLAN 4 traffic.

You should see F0/1 configured for trunking with native VLAN 8. The allowed list should be 3,4,8.

S2 trunk values look wrong?

Check that you configured F0/1 on S2.

Compare the native VLAN plus the allowed list with the S1 values.

Help me match the S2 F0/1 trunk to S1.

  • Return to the command-line interface on S1.
  • Configure the router-facing trunk on S1 by running these commands:
enable
configure terminal
interface f0/5
switchport mode trunk
switchport trunk native vlan 8
switchport trunk allowed vlan 3,4,8
end
show interfaces FastEthernet0/5 switchport

What does the router-facing configuration prepare?

The F0/5 configuration prepares one shared link for VLANs 3, 4, and 8. The router configuration arrives in a later step.

The final command confirms the intended trunk settings directly on the port.

You should see F0/5 configured for trunking with native VLAN 8. The allowed list should be 3,4,8.

F0/5 settings missing?

Confirm that you configured F0/5 on S1.

Compare its administrative trunk values with the settings on S1 F0/1.

Help me correct the S1 F0/5 trunk configuration.

  • Run the final switch checks on S1 by entering these commands:
show vlan brief
show interfaces trunk

What should S1 prove?

The VLAN table should show the three named VLANs plus F0/6 in VLAN 3. The trunk output should show the active inter-switch trunk on F0/1 with native VLAN 8.

The trunk should allow only VLANs 3, 4, and 8.

  • Run the same final switch checks on S2 by entering these commands:
show vlan brief
show interfaces trunk

What should S2 prove?

The VLAN table should show the three named VLANs plus F0/18 in VLAN 4. The trunk output should show F0/1 carrying VLANs 3, 4, and 8 with native VLAN 8.

  • Switch back to the logical topology.
  • Select PC-A.
  • Choose its command prompt.

Before you run these checks, which switch management addresses do you expect PC-A to reach through VLAN 3?

  • Test both management addresses from PC-A by running these commands:
ping 192.168.3.11
ping 192.168.3.12

What do the replies prove?

Replies from 192.168.3.11 prove that PC-A reaches the S1 management interface inside VLAN 3.

Replies from 192.168.3.12 prove that VLAN 3 crosses the inter-switch trunk to S2.

That is your first segmented network milestone. PC-A now reaches both switch management addresses through VLAN 3.

One of the pings fails?

If the first ping fails, confirm that S1 F0/6 belongs to VLAN 3. Confirm that the S1 VLAN 3 interface uses 192.168.3.11.

If only the second ping fails, compare the F0/1 trunk settings on both switches. Confirm that VLAN 3 appears in both allowed lists.

Help me diagnose a failed switch management ping.

✔️ Awesome, I've got everything!

Great. Confirm that both switches show the planned VLANs before you continue.

Confirm that PC-A receives replies from both management addresses.

ⓧ I'd like to double check the full code

Use this reference to compare the cumulative S1 and S2 configuration commands. Apply each labeled section only to its matching switch.

! Configure S1
enable
configure terminal
vlan 3
name Management
exit
vlan 4
name Operations
exit
vlan 8
name Native
exit
interface f0/6
switchport mode access
switchport access vlan 3
exit
interface vlan 3
ip address 192.168.3.11 255.255.255.0
no shutdown
exit
ip default-gateway 192.168.3.1
interface f0/1
switchport mode trunk
switchport trunk native vlan 8
switchport trunk allowed vlan 3,4,8
exit
interface f0/5
switchport mode trunk
switchport trunk native vlan 8
switchport trunk allowed vlan 3,4,8
exit
end

! Configure S2
enable
configure terminal
vlan 3
name Management
exit
vlan 4
name Operations
exit
vlan 8
name Native
exit
interface f0/18
switchport mode access
switchport access vlan 4
exit
interface vlan 3
ip address 192.168.3.12 255.255.255.0
no shutdown
exit
ip default-gateway 192.168.3.1
interface f0/1
switchport mode trunk
switchport trunk native vlan 8
switchport trunk allowed vlan 3,4,8
exit
end

Your VLAN boundaries and trunk path are working. Next, you will test what happens when traffic needs to cross from VLAN 3 to VLAN 4.

Diagnose the Cross-VLAN Failure

Your VLANs now separate Management traffic from Operations traffic. The inter-switch trunk carries both departments without merging their broadcast domains.

The next question is whether that working Layer 2 path can cross subnets. In this step, you will observe the expected failure before using device evidence to isolate the missing Layer 3 path.

In this step, get ready to:
  • Observe the planned PC-A-to-PC-B failure.
  • Prove the Layer 2 baseline.
  • Identify the missing Layer 3 path on R1.
Test the known-good and failed paths

A known-good test gives the failure a boundary. PC-A's management pings prove that VLAN 3 still crosses the inter-switch trunk.

  • Return to PC-A's command prompt from earlier.
  • Confirm the known-good management path by running these commands:
ping 192.168.3.11
ping 192.168.3.12

What Do These Tests Prove?

  • The first test checks PC-A's path to the S1 management interface.
  • The second test checks VLAN 3 across the trunk to the S2 management interface.

Strong start. Both destinations reply, which confirms that the known-good VLAN 3 path still works.

Management Pings Failing?

  • Confirm that PC-A still uses 192.168.3.3 with subnet mask 255.255.255.0.
  • Confirm that the PC-A link still connects to S1 F0/6.
  • Ask for help with the unexpected baseline failure.

Before you run the next test, consider whether VLAN 3 can reach VLAN 4 without an active Layer 3 gateway.

  • Test the path from PC-A to PC-B by running this command:
ping 192.168.4.3

What Does This Test Isolate?

This test sends traffic from PC-A's subnet toward PC-B's subnet. Crossing that boundary requires an active device capable of routing between the two VLANs.

You will see no replies from PC-B. This planned failure proves that the working Layer 2 path does not provide inter-VLAN routing.

This Failure Is the Lesson

The VLAN boundaries are working as designed. Traffic now needs a gateway that can move packets between the two subnets.

Rule out Layer 2 faults

A failed ping can start at Layer 2 or Layer 3. Evidence lets you clear one layer before moving to the next.

  • Return to S1's CLI from earlier.
  • Inspect S1's Layer 2 state by running these commands:
show vlan brief
show interfaces trunk

What Does the S1 Evidence Show?

  • The VLAN table verifies each VLAN's name, status, and assigned access ports.
  • The trunk table verifies the active trunk ports, native VLAN, and allowed VLANs.

On S1, you will see VLANs 3, 4, and 8. You will also see F0/6 assigned to VLAN 3 plus F0/1 trunking with native VLAN 8.

  • Switch back to S2's CLI from earlier.
  • Inspect S2's Layer 2 state by running the same commands:
show vlan brief
show interfaces trunk

What Does the S2 Evidence Add?

S2 provides the far-end view of the same inter-switch trunk. Matching native VLAN and allowed VLAN values clear the trunk as the source of the cross-VLAN failure.

On S2, you will see F0/18 assigned to VLAN 4. You will also see F0/1 trunking with native VLAN 8 plus allowed VLANs 3, 4, and 8.

You have now cleared the Layer 2 baseline. The access ports and inter-switch trunk match the documented design.

Layer 2 Evidence Does Not Match?

  • Compare S1 F0/6 with the expected VLAN 3 assignment.
  • Compare S2 F0/18 with the expected VLAN 4 assignment.
  • Ask for help interpreting the VLAN or trunk output.
Inspect the missing Layer 3 path

R1 is the only device that can route between these subnets. Its interface summary reveals whether the router-facing link can provide that path.

  • Return to R1's CLI from earlier.

Before you run the final check, predict what evidence R1 will show for the router-facing link.

  • Inspect R1's interface state by running this command:
show ip interface brief

What Does the Router Evidence Prove?

  • The physical G0/0/1 interface must be operational before it can carry VLAN traffic.
  • The G0/0/1.3 and G0/0/1.4 subinterfaces would provide the Layer 3 gateways for the two departments.
  • The G0/0/1.8 subinterface would handle the native VLAN on the shared router link.

You will see that G0/0/1 is not operational. You will not see the required G0/0/1.3, G0/0/1.4, or G0/0/1.8 subinterfaces.

That is a strong diagnosis. No active Layer 3 gateway exists to route traffic between VLAN 3 and VLAN 4.

You have traced the failure to the missing router path without changing the working switch baseline. Next up, you will use router-on-a-stick to supply one gateway per VLAN over the shared link.

Configure Router-on-a-Stick

The earlier evidence cleared the switch path. Traffic still stops because R1 has no active gateway for either subnet.

A router-on-a-stick design uses one physical router link with a subinterface for each VLAN. This step turns R1 into the Layer 3 path that the failed ping exposed as missing.

In this step, get ready to:
  • Enable R1's physical trunk link.
  • Configure a gateway for each routed VLAN.
  • Verify routed connectivity from PC-A.
Build the first routed path

The physical interface carries traffic for several VLANs. Its first subinterface becomes the gateway for devices in VLAN 3.

Why use router-on-a-stick?

Router-on-a-stick lets one physical interface serve multiple VLANs through separate subinterfaces. This avoids dedicating a router port to every department.

  • Return to R1's command-line view from the previous step.
  • Activate the physical link and create the VLAN 3 gateway by running these commands:
configure terminal
interface g0/0/1
 no shutdown
interface g0/0/1.3
 encapsulation dot1q 3
 ip address 192.168.3.1 255.255.255.0
end

What does this configuration do?

  • The no shutdown command enables the physical router interface.
  • The G0/0/1.3 subinterface handles frames tagged for VLAN 3.
  • The encapsulation dot1q 3 command associates that subinterface with 802.1Q VLAN 3 traffic.
  • The address 192.168.3.1 becomes the gateway used by PC-A and both switch management interfaces.

Before you test it, do you expect PC-A's gateway to answer now?

  • Return to PC-A's command window from the previous step.
  • Test the VLAN 3 gateway by running this command:
ping 192.168.3.1

What should you see?

You should see replies from 192.168.3.1. The response proves that VLAN 3 now reaches its router gateway.

Gateway not responding?

Confirm that G0/0/1 received the no shutdown command. Check that the link still connects R1 G0/0/1 to S1 F0/5.

Confirm that G0/0/1.3 uses VLAN 3 with address 192.168.3.1.

If the first test misses a reply, run it once more before changing the configuration. Packet Tracer may need a moment to process the first exchange.

Help me diagnose why PC-A cannot ping its VLAN 3 gateway.

You've closed the first routing gap. VLAN 3 now has an active gateway on R1.

Complete the remaining subinterfaces

VLAN 4 needs its own gateway for PC-B. The native subinterface aligns R1's untagged traffic handling with VLAN 8 on S1.

  • Return to R1's command-line view.
  • Create the VLAN 4 gateway and native VLAN subinterface by running these commands:
configure terminal
interface g0/0/1.4
 encapsulation dot1q 4
 ip address 192.168.4.1 255.255.255.0
interface g0/0/1.8
 encapsulation dot1q 8 native
end

What does this configuration do?

  • The G0/0/1.4 subinterface handles VLAN 4 traffic.
  • The address 192.168.4.1 becomes PC-B's active gateway.
  • The G0/0/1.8 subinterface handles untagged frames for native VLAN 8.
  • The native subinterface has no IP address because this lab does not route user traffic through VLAN 8.

Before you inspect R1, which three subinterfaces do you expect to find?

  • Check the physical interface and its subinterfaces by running this command:
show ip interface brief

What should you see?

You should see G0/0/1 operating with G0/0/1.3 and G0/0/1.4. You should also see G0/0/1.8 operating without an assigned IP address.

Subinterface not operational?

Check that the physical G0/0/1 interface is enabled. A disabled parent interface prevents every subinterface from carrying traffic.

Compare each subinterface number with its VLAN tag. Confirm that VLAN 8 includes the native keyword.

Help me diagnose an inactive router subinterface.

✔️ Awesome, I've got everything!

Great. R1 now has the physical interface and all three required subinterfaces configured.

ⓧ I'd like to double check the full code

Compare your R1 command sequence with the complete configuration used in this step.

configure terminal
interface g0/0/1
 no shutdown
interface g0/0/1.3
 encapsulation dot1q 3
 ip address 192.168.3.1 255.255.255.0
end
configure terminal
interface g0/0/1.4
 encapsulation dot1q 4
 ip address 192.168.4.1 255.255.255.0
interface g0/0/1.8
 encapsulation dot1q 8 native
end
Prove end-to-end routing

The router now has one gateway in each user subnet. The final test checks whether packets can cross the VLAN boundary without disturbing VLAN 3 management access.

Before you send the tests, do you expect all three destinations to reply?

  • Return to PC-A's command window.
  • Test the gateway, PC-B, and S2 by running these commands:
ping 192.168.3.1
ping 192.168.4.3
ping 192.168.3.12

What do the results prove?

You should see replies from 192.168.3.1. This confirms PC-A can reach its gateway.

You should see replies from 192.168.4.3. This confirms R1 routes traffic between VLAN 3 and VLAN 4.

You should see replies from 192.168.3.12. This confirms the original VLAN 3 management path still works.

One destination still unreachable?

If only PC-B fails, confirm that G0/0/1.4 uses address 192.168.4.1. Confirm that PC-B still uses that address as its default gateway.

If every destination fails, check the physical router link first. Confirm that S1 F0/5 still carries VLANs 3,4,8.

Help me troubleshoot the failed end-to-end ping.

That's the routing breakthrough. PC-A can now cross from VLAN 3 to PC-B in VLAN 4 while keeping the original management path intact.

Your inter-VLAN network is operational. Next, you'll document the working baseline and prove that it survives a reopen.

Validate and Document the Network

Your router-on-a-stick path now carries traffic between two VLANs. You have already proved that PC-A can reach its gateway, PC-B, and the S2 management interface.

A working network needs a repeatable baseline that another engineer can verify. This step turns your open Cisco Packet Tracer topology into a labeled record that survives a full close and reopen test.

In this step, get ready to:
  • Capture device evidence for the working traffic path.
  • Label the topology with its operational baseline.
  • Save the configurations for a clean reopen test.
Validate the working paths

A reliable baseline combines access-port evidence, trunk evidence, router state, and end-to-end tests. Each check proves a different part of the traffic path.

  • Confirm S1's VLAN membership and trunk state by running these commands at the S1 CLI prompt:
show vlan brief
show interfaces trunk

What do these checks prove?

  • The show vlan brief output proves that VLANs 3, 4, and 8 exist. It also shows which access ports belong to each VLAN.
  • The show interfaces trunk output proves that the switch links carry the required VLANs. It also identifies native VLAN 8.
  • Repeat the same two checks at the S2 CLI prompt.

On S1, you should see F0/6 assigned to VLAN 3. On S2, you should see F0/18 assigned to VLAN 4.

You should also see F0/1 trunking on both switches with native VLAN 8. S1 should show F0/5 as the router-facing trunk.

Missing a VLAN or trunk?

  • Confirm that you are checking S1 or S2 instead of R1.
  • Compare the displayed access-port assignments with the labels beside each PC.
  • Compare the native VLAN and allowed VLAN list at both ends of each trunk.

Ask for help comparing the switch evidence.

  • Confirm R1's physical interface and subinterface state by running this command at the R1 CLI prompt:
show ip interface brief

What does the router check prove?

The output shows whether R1 can provide the Layer 3 gateways for VLANs 3 and 4. The physical interface must support the operational subinterfaces below it.

The addresses on G0/0/1.3 and G0/0/1.4 identify the gateway for each subnet.

You should see G0/0/1.3 with 192.168.3.1. You should see G0/0/1.4 with 192.168.4.1.

Subinterface missing or down?

  • Check that the physical link from R1 G0/0/1 to S1 F0/5 is connected.
  • Check that R1 G0/0/1 remains enabled.
  • Check that S1 F0/5 remains a trunk carrying VLANs 3, 4, and 8.

Ask for help interpreting the R1 interface state.

  • Predict whether all three PC-A destinations still reply before running the checks below.
  • Test PC-A's gateway, PC-B, and S2 by running these commands at the PC-A command prompt:
ping 192.168.3.1
ping 192.168.4.3
ping 192.168.3.12

What do the three pings prove?

  • The first test proves that PC-A can reach its R1 gateway.
  • The second test proves that R1 routes traffic between VLAN 3 and VLAN 4.
  • The third test proves that VLAN 3 reaches the S2 management interface across the inter-switch trunk.

You should receive replies from all three destinations. Together, those replies confirm the working Layer 2 and Layer 3 path.

  • Predict how many routed devices appear before PC-B reaches PC-A.
  • Trace the route from PC-B to PC-A by running this command at the PC-B command prompt:
tracert 192.168.3.3

What does the route trace prove?

The traceroute follows the path toward PC-A. It shows that traffic from PC-B crosses R1 before entering the VLAN 3 subnet.

This path evidence connects the successful result to the router-on-a-stick design.

You should see the route pass through R1 and reach PC-A at 192.168.3.3.

Ping or route trace failing?

  • Confirm that PC-A still uses gateway 192.168.3.1.
  • Confirm that PC-B still uses gateway 192.168.4.1.
  • Compare the failed destination with the switch and router evidence you collected above.

Ask for help isolating the failed network layer.

Document the working baseline

Topology labels turn the workspace into an operational map. Another engineer can use that map to connect each test result to a VLAN, subnet, gateway, trunk, or interface.

  • Use the logical workspace's text annotation control to add VLAN 3 Management | 192.168.3.0/24 | gateway 192.168.3.1 beside PC-A.
  • Add VLAN 4 Operations | 192.168.4.0/24 | gateway 192.168.4.1 beside PC-B.

The two department segments should now be readable directly from the logical workspace.

  • Add S1 F0/1 to S2 F0/1 | trunk | native VLAN 8 | allowed VLANs 3,4,8 above the inter-switch link.
  • Add R1 G0/0/1 to S1 F0/5 | trunk | native VLAN 8 | allowed VLANs 3,4,8 above the router link.

Both trunk paths should now show their interfaces, native VLAN, and allowed VLANs.

  • Add PC-A to S1 F0/6 | access VLAN 3 beside the PC-A link.
  • Add PC-B to S2 F0/18 | access VLAN 4 beside the PC-B link.

Every physical connection should now show its role in the working baseline.

The troubleshooting note preserves the lesson behind the configuration. It records the failed symptom before the fix, the evidence that narrowed the fault, the root cause, and the correction.

  • Add a new topology note by pasting this troubleshooting record into the logical workspace:
Troubleshooting record

Symptom: PC-A could not reach PC-B across VLANs.
Evidence: VLAN membership was correct. The inter-switch trunk carried VLANs 3,4,8 with native VLAN 8. R1 had no operational VLAN subinterfaces.
Root cause: No active Layer 3 path existed between 192.168.3.0/24 and 192.168.4.0/24.
Fix: Enabled R1 G0/0/1. Added 802.1Q subinterfaces for VLANs 3,4,8.

Why structure the note this way?

  • The symptom records what the user experienced.
  • The evidence records what the device outputs proved.
  • The root cause names the missing network function.
  • The fix records the configuration that restored service.
  • Save the updated ccie-roadmap-project-1.pkt file.
  • Inspect the saved workspace for the six link and subnet labels plus the troubleshooting note.

You should see both VLANs, both access links, both trunks, every relevant interface name, and the four-part troubleshooting record.

Labels difficult to read?

  • Move each subnet label closer to its matching PC.
  • Place each trunk label above its matching connection.
  • Resize the troubleshooting note so every line remains visible.

Ask for help arranging the topology record.

Save and reopen the baseline

A startup configuration preserves each device's running state. Saving the Packet Tracer file preserves the topology, labels, and device data as one baseline.

Each device may show a destination filename prompt after the save command. The displayed default keeps the configuration in its standard startup location.

  • Save R1's running configuration at the R1 CLI prompt by running this command:
copy running-config startup-config

What does this command preserve?

The command copies the active device configuration into the startup configuration. This gives the device a saved baseline instead of relying only on the current running state.

Press Enter if the device asks you to accept the displayed destination filename.

  • Repeat the same configuration save at the S1 CLI prompt.
  • Repeat the same configuration save at the S2 CLI prompt.

Each device should confirm that its startup configuration has been written.

Configuration not saved?

  • Confirm that you ran the command separately on R1, S1, and S2.
  • Accept the displayed destination filename when a device asks for confirmation.
  • Wait for the device to finish writing before switching to another device.

Ask for help saving the device configurations.

Closing the topology is a controlled persistence test. Your saved ccie-roadmap-project-1.pkt file and startup configurations protect the working baseline.

  • Save the open ccie-roadmap-project-1.pkt file again.

The saved file now includes the working configurations, topology labels, and troubleshooting note.

  • Close the open topology.
  • Reopen ccie-roadmap-project-1.pkt from Cisco Packet Tracer's recent-files area.

You should see R1, S1, S2, PC-A, and PC-B in the same positions. The labels and troubleshooting note should remain visible without reconfiguration.

  • Predict whether the three PC-A destinations still reply after reopening the file.
  • Repeat the final PC-A connectivity checks by running these commands at the PC-A command prompt:
ping 192.168.3.1
ping 192.168.4.3
ping 192.168.3.12

What does the reopen test prove?

Successful replies prove that the reopened file retains the gateway path, inter-VLAN route, and S2 management path. No configuration changes should be necessary after reopening.

You should receive replies from 192.168.3.1, 192.168.4.3, and 192.168.3.12.

  • Predict whether the reopened topology still sends PC-B traffic through R1.
  • Repeat the route trace by running this command at the PC-B command prompt:
tracert 192.168.3.3

What confirms the saved baseline?

The route should reach PC-A through R1 after the reopen. That result proves that the saved topology reproduces the same routed path without new configuration.

You should see the trace reach 192.168.3.3 through R1.

Connectivity lost after reopening?

  • Confirm that you reopened ccie-roadmap-project-1.pkt instead of an older copy.
  • Check that the physical links return to an operational state before testing.
  • Compare the current VLAN, trunk, and router outputs with the baseline recorded above.

Ask for help comparing the reopened network with the saved baseline.

✔️ Awesome, I've got everything!

Your labeled ccie-roadmap-project-1.pkt baseline is saved and reopened. The device configurations and final connectivity tests remain operational.

ⓧ I'd like to double check the full code

Packet Tracer stores this project as a topology file. Compare your reopened baseline with every item below.

  • The topology contains R1 as a Cisco 4221. It contains S1 and S2 as Catalyst 2960 switches plus PC-A and PC-B.
  • R1 G0/0/1 connects to S1 F0/5. S1 F0/1 connects to S2 F0/1.
  • PC-A connects to S1 F0/6. PC-B connects to S2 F0/18.
  • PC-A uses 192.168.3.3/24 with gateway 192.168.3.1. PC-B uses 192.168.4.3/24 with gateway 192.168.4.1.
  • Both switches contain VLAN 3 Management, VLAN 4 Operations, and VLAN 8 Native.
  • S1 F0/6 is a static VLAN 3 access port. S2 F0/18 is a static VLAN 4 access port.
  • S1's VLAN 3 SVI uses 192.168.3.11/24. S2's VLAN 3 SVI uses 192.168.3.12/24.
  • Both switches use default gateway 192.168.3.1.
  • S1 F0/1 and S2 F0/1 are trunks with native VLAN 8. Both trunks allow VLANs 3, 4, and 8.
  • S1 F0/5 is a trunk to R1 with native VLAN 8. The trunk allows VLANs 3, 4, and 8.
  • R1 G0/0/1 is enabled. G0/0/1.3 uses dot1Q 3 with 192.168.3.1/24.
  • R1 G0/0/1.4 uses dot1Q 4 with 192.168.4.1/24. G0/0/1.8 uses dot1Q 8 native without an IP address.
  • The topology labels identify VLAN IDs, subnets, gateways, trunks, and physical interfaces.
  • The troubleshooting note records the failed symptom, device evidence, missing Layer 3 path, and router-on-a-stick fix.
  • R1, S1, and S2 have their running configurations saved to startup configuration.
  • PC-A reaches its gateway, PC-B, and S2. PC-B reaches PC-A through R1 during the route trace.

That is your working baseline locked in. Another engineer can now reopen the file, read the design, follow the troubleshooting evidence, and reproduce the successful path.

Secret mission

Trigger and Repair a Native VLAN Mismatch

Turn your working network into a controlled troubleshooting drill. You will create a native VLAN mismatch on one trunk endpoint, diagnose it from device evidence, repair it, and prove that the original traffic paths still work.

Clean Up Your Resources

Clean Up Your Resources

Your Cisco Packet Tracer lab runs locally. Keeping both saved files creates no ongoing cost.

Choose the cleanup option that fits what you want to do next.

Resources you used:

  • Saved working baseline named ccie-roadmap-project-1.pkt with the operational inter-VLAN network.
  • Saved challenge copy named ccie-roadmap-project-1-native-vlan-mismatch.pkt with the repaired native VLAN mismatch.

Keep everything running

No action is needed. Choose this option if you want to reuse the working network or practise troubleshooting again.

  • Keep ccie-roadmap-project-1.pkt as your known-good network baseline.
  • Keep ccie-roadmap-project-1-native-vlan-mismatch.pkt as evidence of your repaired trunk fault.
  • Leave Cisco Packet Tracer installed for future networking labs.

Pause - I'll come back to this later

Closing Cisco Packet Tracer stops the local simulation while preserving both saved files. You can continue from the same network state later.

  • Close Cisco Packet Tracer.
  • Leave ccie-roadmap-project-1.pkt in its current saved location.
  • Leave ccie-roadmap-project-1-native-vlan-mismatch.pkt in its current saved location.

Delete - I don't want to use this again

Deleting both copies removes your reusable baseline. Keep the files if you want to repeat the troubleshooting exercise.

  • Close Cisco Packet Tracer.
  • Search your computer for ccie-roadmap-project-1.pkt.
  • Delete the matching ccie-roadmap-project-1.pkt file from the search results.
  • Search your computer for ccie-roadmap-project-1-native-vlan-mismatch.pkt.
  • Delete the matching ccie-roadmap-project-1-native-vlan-mismatch.pkt file from the search results.
  • Empty your system's deleted-items folder to remove both files permanently.
  • Search your computer for each filename again.

You should see no matching .pkt files in the results.

Nice Work!

Nice Work!

You did it! Your Cisco Packet Tracer lab now routes traffic between two segmented departments through one router link. This saved network is your first practical milestone on the path toward CCIE Enterprise Infrastructure.

You've learned how to:

  • Built a segmented inter-VLAN network that routes traffic between Management and Operations through one physical router link.
  • Used VLAN, trunk, and interface evidence to isolate a missing Layer 3 path before changing the configuration.
  • Saved ccie-roadmap-project-1.pkt as a repeatable working baseline that another engineer can reopen and verify.
  • Secret Mission: Triggered a native VLAN mismatch. Diagnosed it from switch evidence. Restored native VLAN 8 without losing the working baseline.

Ready to quiz yourself?