Restore a Two-Subnet Office Network

Troubleshoot DHCP, routing, and link performance in a two-subnet office lab.

Introduction

30 Second Summary

A connection can look healthy because a quick message gets through while a hidden fault still disrupts normal work. Support gets easier when each clue narrows the problem before anything changes.

In this project, you will use Cisco Packet Tracer to restore communication between two office subnets. You will follow evidence from client addressing through link performance before recurring traffic proves the repairs hold.

What You'll Build

Your finished lab lets you demonstrate a complete support ticket from visible network failure to recurring successful traffic.

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

A working two-subnet lab where each PC receives a DHCP lease. Cross-subnet pings pass through BR-R1.
An evidence-based repair that traces the Guest failure to an administratively down interface plus a missing DHCP pool. The repaired Guest PC receives an address on 192.168.20.0/24.
A performance diagnosis that exposes the forced 10 Mb/s, half-duplex uplink even while ping succeeds. Recurring ICMP events prove the link remains healthy after autonegotiation returns.
Secret Mission: Diagnose a Finance PC that reaches its local gateway while remote Guest traffic fails. Correct the wrong default gateway using subnet evidence.

Are there any prerequisites?

You need Cisco Packet Tracer installed on Windows with access to your Cisco account.

The project provides all configuration details, so basic IPv4 familiarity is enough.

Before We Start

This is your moment to commit to restoring Staff-to-Guest connectivity before any hands-on work begins. Your evidence will cover addressing, interface state, performance, DHCP, and ICMP repairs.

Set Up the Incident Workspace

Your incident evidence plan now has a clear goal. The next move is to create a controlled place where every later symptom belongs to this lab.

A clean Cisco Packet Tracer file prevents old device state from contaminating the incident. Saving it before you add devices gives every later observation a reliable starting point.

In this step, get ready to:

Start Cisco Packet Tracer with access to its workspace.
Create a blank Logical workspace in Realtime mode.
Save the clean workspace as office-network-repair.pkt.

Launch Cisco Packet Tracer

Cisco Packet Tracer may ask you to authenticate before it opens the workspace. Completing this check gives you access to the blank canvas for your incident lab.

Press the Windows key to open the search bar.
Type Cisco Packet Tracer into the search bar.
Press Enter to launch the application.
Click LOGIN if the Cisco Packet Tracer Login window appears.
Complete the Cisco account sign-in if Packet Tracer requests authentication.

You are signed in. Cisco Packet Tracer is ready for the incident workspace.

Can't Reach the Logical Workspace?

Confirm that your Windows device has internet access before retrying the Cisco sign-in.
Use the Cisco account that already gives you access to Packet Tracer.
Share the sign-in symptoms in the NextWork community if the login loop continues.

Help me troubleshoot a Cisco Packet Tracer sign-in problem.

Save a blank Logical workspace

Packet Tracer stores the lab in a .pkt file. Creating the file before any topology work preserves a clean incident baseline.

Create a blank workspace using the new-file control in the top menu.
Select Logical in the workspace controls.
Save the workspace under a new name using the save controls in the top menu.
Enter office-network-repair.pkt as the file name.
Select the save control in the file dialog.

Packet Tracer should now identify the current file as office-network-repair.pkt.

File Name Not Visible?

Repeat the save action if the current file still appears unnamed.
Check that the file name ends with .pkt.

Help me confirm that my Packet Tracer workspace saved correctly.

Verify the saved workspace

Realtime mode is the baseline for the network you build next. This final check confirms that the file contains no leftover topology state.

Before the final check, which visible clues would prove that this file is a clean starting point?

Select Realtime in the mode controls.
Confirm that Logical remains the active workspace.
Confirm that no devices or links appear on the canvas.
Confirm that Packet Tracer identifies the current file as office-network-repair.pkt.

You will see an empty Logical canvas with Realtime selected. Packet Tracer identifies the current file as office-network-repair.pkt.

That is your clean baseline secured. Next, you will build the office topology that produces the first incident evidence.

Build the Staff Network and Expose the Guest Failure

Your saved blank workspace gives this incident a clean baseline in Cisco Packet Tracer. Now you can build the two network paths that the investigation depends on.

A successful Staff gateway test proves that the router can provide working local addressing. The failed Guest lease then gives you a controlled symptom to isolate.

In this step, get ready to:

Place the router, switches, and client PCs in the saved Logical workspace.
Configure BR-R1 with a working Staff interface and Staff DHCP pool.
Prove the Staff baseline before capturing the Guest addressing failure.

Place and cable the office devices

The topology uses one physical router interface for each subnet. This keeps the incident focused on interface state and addressing evidence.

Return to the blank Logical workspace in office-network-repair.pkt.
Drag one Cisco 4221 router from the device palette onto the workspace.
Drag the first Cisco Catalyst 2960 switch onto the left side of the router.
Drag the second Cisco Catalyst 2960 switch onto the right side of the router.
Drag the first PC beneath the left switch.
Drag the second PC beneath the right switch.

Why Two Router Interfaces?

Each router interface acts as the gateway for one subnet. BR-R1 can route between the Staff and Guest networks because both networks connect directly to it.

Rename the Cisco 4221 router to BR-R1 using its device name field.
Rename the left Cisco Catalyst 2960 switch to STAFF-SW using its device name field.
Rename the right Cisco Catalyst 2960 switch to GUEST-SW using its device name field.
Rename the left PC to STAFF-PC using its device name field.
Rename the right PC to GUEST-PC using its device name field.

Keep the Layout Clear

Keep each PC beneath its matching switch. The left-to-right Staff and Guest layout makes the traffic path easy to follow during troubleshooting.

Select Copper Straight-Through from the connections palette.
Create a link from BR-R1 G0/0/0 to STAFF-SW F0/1.
Create a link from BR-R1 G0/0/1 to GUEST-SW F0/1.
Create a link from STAFF-PC FastEthernet0 to STAFF-SW F0/6.
Create a link from GUEST-PC FastEthernet0 to GUEST-SW F0/6.
Click Fast Forward Time if the PC-to-switch links remain amber while the topology converges.
Save office-network-repair.pkt.

You should now see all five named devices with four links between them. The router-facing indicators can remain red until BR-R1 receives its interface configuration.

Configure BR-R1 for the initial incident

BR-R1 needs one gateway address for each subnet. The Staff interface is enabled so you can establish a working baseline.

Select BR-R1 in the Logical workspace.
Switch to the router's command-line terminal.
Configure the Staff gateway interface by entering these commands:

enable
configure terminal
interface g0/0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
end

What Does This Configuration Do?

The address 192.168.10.1 becomes the default gateway for the Staff subnet.
The mask 255.255.255.0 places the interface in 192.168.10.0/24.
The no shutdown command enables the router interface.

Save office-network-repair.pkt.
Click Fast Forward Time if the Staff router link needs time to converge.

You should see the BR-R1 G0/0/0 to STAFF-SW F0/1 link become active.

Staff Router Link Still Down?

Confirm that the cable joins BR-R1 G0/0/0 to STAFF-SW F0/1. Check that the interface configuration includes no shutdown.

Help me check the Staff router link configuration.

The Guest subnet also needs a gateway address. Its interface stays disabled in this initial incident state.

Assign the Guest gateway address by entering these commands:

configure terminal
interface g0/0/1
ip address 192.168.20.1 255.255.255.0
end

What Does This Configuration Do?

The address 192.168.20.1 identifies the intended Guest gateway.
The interface remains administratively down because this configuration does not enable it.

Save office-network-repair.pkt.

The BR-R1 G0/0/1 to GUEST-SW F0/1 link should remain down. That visible state is part of the incident you are reproducing.

Guest Link Became Active?

Compare your Guest interface commands with the reference below. This initial configuration assigns the address without enabling G0/0/1.

Help me reproduce the intended Guest interface state.

The Staff clients need automatic addressing before you can test the working path. BR-R1 supplies those leases from a dedicated DHCP pool.

Create the Staff DHCP exclusions and pool by entering these commands:

configure terminal
ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool STAFF
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
end

What Does This Configuration Do?

The excluded range protects the gateway and the next nineteen addresses from automatic assignment.
The STAFF pool offers addresses from 192.168.10.0/24.
The pool supplies 192.168.10.1 as the client default gateway.

Save office-network-repair.pkt.
Confirm that the router command-line terminal returns to its privileged prompt after the final end command.

Router Rejecting a DHCP Command?

Confirm that ip dhcp excluded-address starts from global configuration mode. Make sure the pool name is STAFF.

Help me check my Staff DHCP configuration.

✔️ Awesome, I've got everything!

Your router now has the complete initial configuration for this incident. Keep the Guest interface disabled and leave the Guest DHCP pool absent.

ⓧ I'd like to double check the full code

Compare your BR-R1 command sequence with this complete reference:

enable
configure terminal
interface g0/0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
end
configure terminal
interface g0/0/1
ip address 192.168.20.1 255.255.255.0
end
configure terminal
ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool STAFF
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
end

Prove the Staff baseline and expose the Guest failure

Client evidence separates a working network path from a broken one. Start with STAFF-PC so the failure has a known-good comparison.

Select STAFF-PC in the Logical workspace.
Open Desktop in the PC window.
Open IP Configuration.
Select DHCP.
Click Fast Forward Time if the address fields do not populate promptly.
Return to Desktop.
Open the PC's command-line tool.
Inspect the Staff lease by running this command:

ipconfig /all

What Should I See?

You should see a valid IPv4 address in 192.168.10.0/24.
You should see 192.168.10.1 as the default gateway.

Before you test the gateway, do you expect the working Staff path to return successful replies?

Test the Staff gateway by running this command:

ping 192.168.10.1

What Should I See?

You should see successful replies from the Staff gateway. This proves that STAFF-PC has a usable lease and can reach BR-R1.

Staff Gateway Ping Failing?

Confirm that STAFF-PC connects from FastEthernet0 to STAFF-SW F0/6. Check that the client received an address from 192.168.10.0/24.

Help me diagnose the failed Staff gateway ping.

The Staff baseline works. Now use the same client workflow on GUEST-PC to reveal the incident symptom.

Select GUEST-PC in the Logical workspace.
Open Desktop in the PC window.
Open IP Configuration.

Before you request a lease, do you think GUEST-PC can receive an address in 192.168.20.0/24 from the current router configuration?

Select DHCP.
Click Fast Forward Time to allow the DHCP request to finish.
Return to Desktop.
Open the PC's command-line tool.
Inspect the Guest addressing result by running this command:

ipconfig /all

The Intended Guest Failure

GUEST-PC should have no valid IPv4 lease in 192.168.20.0/24. This failed request is the incident symptom you carry into the diagnosis.

Save the reproduced incident state in office-network-repair.pkt.

You have a working Staff gateway test beside a failed Guest lease request. That contrast gives you the evidence needed to diagnose the Guest path without guessing.

Your incident lab is ready. Next, you will inspect BR-R1 for the interface-state and DHCP evidence behind the Guest failure.

Restore Guest Connectivity

Your Cisco Packet Tracer Staff baseline already proves that BR-R1 serves one healthy subnet. GUEST-PC still cannot obtain valid addressing.

The Guest failure spans interface state and DHCP service. Testing both areas before editing prevents an incomplete repair.

In this step, get ready to:

Collect router evidence for the Guest interface state and DHCP service.
Enable the Guest interface and configure its DHCP pool.
Renew both client leases and verify bidirectional connectivity.

Diagnose both router faults

Layered troubleshooting checks each part of the failed path before any configuration changes. The interface summary tests the Layer 3 path. The pool summary tests the addressing service.

Before you run these checks, do you expect one fault or more than one?

Select BR-R1 in the topology.
Access the router's command-line interface.
Collect the router's fault evidence by running these commands:

show ip interface brief
show ip dhcp pool

Why these checks come first

The show ip interface brief command summarizes the state of every router interface.
The show ip dhcp pool command lists the DHCP pools that currently exist.
Together, these checks separate an interface fault from a missing service configuration.

You'll see G0/0/1 listed as administratively down. You'll also see only the STAFF pool.

Router commands not accepted?

Confirm the selected device is BR-R1.
Run enable if the router does not accept the show commands.
Check the device name before changing any configuration.
Help me access the correct command mode on BR-R1.

Repair the Guest service

The Guest subnet needs an enabled gateway interface before traffic can leave the local network. It also needs a matching DHCP pool before GUEST-PC can receive usable addressing.

Return to BR-R1's command-line interface.
Enable the existing Guest gateway interface by running these commands:

enable
configure terminal
interface g0/0/1
no shutdown
end

What does this repair do?

The interface g0/0/1 command selects the interface that already holds 192.168.20.1. The no shutdown command enables that interface.

Verify the changed interface state by running this command:

show ip interface brief

What does this check prove?

The interface summary confirms whether the Guest gateway interface is available. This gives you evidence that the Layer 3 path has been restored.

You'll see G0/0/1 is no longer listed as administratively down.

Guest interface still disabled?

Confirm that you entered interface g0/0/1 before running no shutdown.
Confirm that G0/0/1 connects to GUEST-SW.
Help me diagnose why BR-R1 G0/0/1 remains disabled.

The Layer 3 path is available now. The Guest client still needs a pool that supplies addresses from 192.168.20.0/24.

Return to BR-R1's command-line interface.
Create the Guest addressing service by running these commands:

configure terminal
ip dhcp excluded-address 192.168.20.1 192.168.20.20
ip dhcp pool GUEST
network 192.168.20.0 255.255.255.0
default-router 192.168.20.1
end

What does this configuration do?

The excluded range protects the gateway address and the next nineteen addresses from automatic assignment.
The GUEST pool supplies addresses from the Guest subnet.
The network statement defines the subnet mask that clients receive.
The default router value points Guest traffic to 192.168.20.1.

Confirm the new DHCP pool by running this command:

show ip dhcp pool

What does the pool summary prove?

The pool summary confirms that BR-R1 now offers DHCP service for the Guest subnet. It should list both STAFF and GUEST.

You'll see the GUEST pool associated with 192.168.20.0.

Guest pool missing?

Confirm that the pool name is GUEST.
Check that the network is 192.168.20.0 255.255.255.0.
Help me find why the GUEST DHCP pool is missing.

The save command may ask you to confirm its displayed destination filename. Accept the displayed default if that prompt appears.

Save BR-R1's repaired configuration by running this command:

copy running-config startup-config

Why save the router configuration?

The running configuration holds the live repair. Copying it to the startup configuration preserves the interface and DHCP changes for the saved incident lab.

You'll see confirmation that the startup configuration was updated.

Save not confirmed?

Accept the displayed destination filename if the router is waiting for confirmation.
Run the save command again if you returned to the prompt without a confirmation message.
Help me save BR-R1's running configuration.

Check BR-R1's cumulative configuration with the option that fits you:

✔️ Awesome, I've got everything!

Your router now has two enabled gateway interfaces and matching DHCP pools. Continue to the client lease checks.

ⓧ I'd like to double check the full code

Compare your complete router command sequence with this reference:

enable
configure terminal
interface g0/0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
end
configure terminal
interface g0/0/1
ip address 192.168.20.1 255.255.255.0
end
configure terminal
ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool STAFF
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
end
enable
configure terminal
interface g0/0/1
no shutdown
end
configure terminal
ip dhcp excluded-address 192.168.20.1 192.168.20.20
ip dhcp pool GUEST
network 192.168.20.0 255.255.255.0
default-router 192.168.20.1
end
show ip dhcp pool
show ip dhcp binding
copy running-config startup-config

Prove restored connectivity

The router can now offer a Guest lease. Renewing the client forces it to replace the failed request with valid addressing from the repaired pool.

Return to GUEST-PC from the topology.
Access its command prompt.
Refresh GUEST-PC's addressing evidence by running these commands:

ipconfig /renew
ipconfig /all

What do these commands prove?

The renewal command asks BR-R1 for a fresh lease.
The full address display shows the assigned address and gateway values.

You'll see an IPv4 address in 192.168.20.0/24. The gateway value is 192.168.20.1.

Record the displayed Guest address for the routing tests: GUEST-PC IPv4 address.

Guest lease still invalid?

Confirm that GUEST-PC is still set to DHCP.
Confirm that G0/0/1 is enabled on BR-R1.
Use Fast Forward Time if DHCP processing is still converging.
Help me diagnose why GUEST-PC still has no valid lease.

Return to STAFF-PC from the topology.
Access its command prompt.
Display its current address by running this command:

ipconfig

Why check the Staff address again?

DHCP addresses can vary between saved lab runs. Reading the current Staff address gives the Guest ping an accurate destination.

Record the displayed Staff address for the routing tests: STAFF-PC IPv4 address.

A router-side binding check confirms that both leases came from BR-R1.

Return to BR-R1's command-line interface.
Display the active DHCP leases by running this command:

show ip dhcp binding

What does the binding table prove?

The binding table is router-side evidence that addresses were assigned to both clients. It complements the address details you collected from each PC.

You'll see active bindings for the Staff subnet and the Guest subnet.

Before you test, do you expect routing to work in both directions now that both clients have valid gateway values?

Return to GUEST-PC's command prompt.
Test the path to STAFF-PC by running this command:

ping [[STAFF_PC_IP="STAFF-PC IPv4 address"]]

What does the Guest test prove?

The ICMP exchange crosses from the Guest subnet to the Staff subnet through BR-R1. Replies prove that the Guest lease and inter-subnet route both work.

You'll see replies from STAFF-PC's current address.

Guest ping still failing?

Confirm that the ping destination matches the address displayed on STAFF-PC.
Confirm that GUEST-PC shows 192.168.20.1 as its gateway.
Help me diagnose the failed Guest-to-Staff ping.

Return to STAFF-PC's command prompt.
Test the reverse path to GUEST-PC by running this command:

ping [[GUEST_PC_IP="GUEST-PC IPv4 address"]]

What does the reverse test prove?

The reverse ping confirms that traffic also travels from Staff to Guest. Bidirectional replies close the original connectivity incident.

You'll see replies from GUEST-PC's current address. Strong work. Both office subnets now exchange traffic through BR-R1.

Save office-network-repair.pkt by pressing Ctrl+S.
Confirm that office-network-repair.pkt remains visible in the application title bar.

Guest connectivity is restored with router evidence and client proof. Next, you'll test whether successful pings tell the whole network health story.

Reproduce the Slow-Link Fault

Your Cisco Packet Tracer network now routes traffic between the Staff and Guest subnets. Both PCs hold valid DHCP leases.

The next ticket reports a slow Staff uplink. Reachability alone cannot prove that the link has a healthy operating profile.

You will reproduce the complaint with a forced speed and duplex profile. You will compare ICMP reachability with switch interface evidence.

In this step, get ready to:

Force the Staff uplink to operate at 10 Mb/s in half duplex.
Test whether Staff-to-Guest reachability survives the constrained profile.
Inspect the affected interface and record the slow-link root cause.

Recreate the user's complaint

Speed controls how quickly an interface can transmit data. Duplex controls whether that interface can transmit and receive at the same time.

Select STAFF-SW in the existing topology.
Access the switch command-line interface.
Apply the slow-link profile by entering these commands:

enable
configure terminal
interface f0/1
speed 10
duplex half
end

What does this configuration change?

The interface f0/1 command selects the uplink connected to BR-R1 G0/0/0.
The speed 10 command constrains the uplink to 10 Mb/s.
The duplex half command allows the uplink to send or receive in one direction at a time.

The switch may briefly cycle the interface while these values change, so a short pause is expected.

Wait for the link indicators around F0/1 to settle.

You should see the uplink return to a connected state with the forced profile still active.

Link not connected?

Confirm that F0/1 is still linked to BR-R1 G0/0/0.
Select Fast Forward Time to let the simulated link finish settling.
Check that the configuration was entered on STAFF-SW.

Help me diagnose why STAFF-SW F0/1 did not return to a connected state.

Test the constrained path

The Guest address comes from DHCP, so read its current value before testing the path. This keeps the ping tied to the active lease.

Return to the command line on GUEST-PC that you used earlier.
Display its current addressing by running:

ipconfig

What does this command show?

The ipconfig output shows the IPv4 address held by GUEST-PC. You will use that address as the destination for the Staff-side test.

Record the current IPv4 address as GUEST-PC IPv4 address.
Before you test, predict which result you expect: failed traffic or successful replies.
Return to the command line on STAFF-PC that you used earlier.
Send traffic to the recorded Guest address by running:

ping [[GUEST_PC_IP="GUEST-PC IPv4 address"]]

What does this test prove?

The ping command sends ICMP traffic from the Staff subnet to the Guest subnet. Successful replies prove that routing remains available through the constrained uplink.

You should still see successful replies. This is the intended shortfall because a reachability test does not expose the unhealthy speed and duplex profile.

No successful replies?

Confirm that STAFF-PC still holds a valid Staff DHCP address.
Confirm that GUEST-PC still holds a valid Guest DHCP address.
Select Fast Forward Time to let the link finish settling.
Retry the ping after the link indicators return to their connected state.

Help me find why the Staff-to-Guest ping fails after forcing the STAFF-SW uplink profile.

Inspect the uplink evidence

A reachability test answers whether packets cross the network. Interface evidence shows the operating profile carrying those packets.

Return to the command-line interface on STAFF-SW.
Before you inspect the port, predict whether the evidence will match the successful ping or expose an unhealthy profile.
Inspect the uplink status and running configuration by entering:

show interfaces f0/1 status
show running-config interface f0/1

What do these commands reveal?

The show interfaces f0/1 status command displays the port state with its speed and duplex values.
The show running-config interface f0/1 command displays the manual configuration applied to the uplink.

You should see F0/1 in a connected state with 10 and half exposed as its speed and duplex profile. The running configuration should show the two commands that forced those values.

Forced profile not visible?

Confirm that the selected device is STAFF-SW.
Confirm that both inspection commands target F0/1.
Re-enter the configuration sequence from the first substep if the running configuration omits the forced values.

Help me determine why STAFF-SW F0/1 does not show the forced speed and duplex settings.

Return to the incident evidence record from earlier.
Record F0/1 as the affected port.
Record connected as the interface status.
Record half as the duplex value.
Record 10 Mb/s as the speed.
Record the successful Staff-to-Guest ping as the observed symptom evidence.
Record the forced speed and duplex configuration as the slow-link root cause.
Save the existing office-network-repair.pkt file.

The saved topology now preserves a functioning two-subnet network with an intentionally constrained Staff uplink.

✔️ Awesome, I've got everything!

Your Staff uplink remains connected with the forced 10 Mb/s and half duplex profile recorded as the root cause.

ⓧ I'd like to double check the full code

Compare the commands you entered with this complete STAFF-SW sequence.

enable
configure terminal
interface f0/1
speed 10
duplex half
end
show interfaces f0/1 status
show running-config interface f0/1

How does this match the target state?

The configuration commands select F0/1 and force its speed to 10 Mb/s. They also force the interface to half duplex.

The final commands expose the connected state and the manual configuration. Together, they provide the evidence needed to identify the slow-link root cause.

That is the key diagnostic win. You have proven that reachability can survive an unhealthy 10 Mb/s half-duplex profile.

Next, you will restore the uplink's default behavior and monitor recurring traffic for evidence of a stable repair.

Restore Performance and Monitor Stability

Staff and Guest traffic already crosses BR-R1. However, STAFF-SW still forces F0/1 to 10 Mb/s at half duplex.

A successful ping can survive a constrained link. Interface evidence must confirm the performance repair before you close the incident.

This step restores autonegotiation on the uplink. Cisco Packet Tracer then sends recurring ICMP traffic to prove the result stays stable.

In this step, get ready to:

Restore default autonegotiation on STAFF-SW F0/1.
Monitor recurring ICMP traffic in Simulation mode.
Complete the final incident evidence set.

Repair the STAFF-SW uplink

The Cisco Catalyst 2960 returns to its default negotiated behavior when the manual speed and duplex commands are removed. Changing those settings can briefly interrupt the interface while the link renegotiates.

Return to the command-line window on STAFF-SW.
Prepare to press Enter if the save command requests confirmation.
Apply the default uplink settings and save the switch configuration by running:

enable
configure terminal
interface f0/1
no speed
no duplex
end
show interfaces f0/1 status
copy running-config startup-config

What does this configuration do?

The no speed command removes the manually forced speed from F0/1.
The no duplex command removes the manually forced half-duplex setting.
The interface status check exposes the uplink's negotiated operating state.
The final copy preserves the current switch configuration for the next startup.

Review the status output for F0/1.

You should see F0/1 connected without the forced 10 or half settings. The uplink now uses its default autonegotiated behavior.

Record the restored autonegotiation in your incident evidence.

Uplink still shows forced settings?

Use Fast Forward Time if F0/1 needs more time to return to a connected state.
Confirm that interface f0/1 selected the uplink before the reset commands ran.

Help me diagnose why STAFF-SW F0/1 still shows a forced speed or duplex setting.

Create a recurring ICMP monitor

A Periodic Complex PDU generates repeated traffic instead of testing one moment in time. Simulation mode records each exchange in the Event List.

Select Simulation mode in Packet Tracer's mode controls.
Select Add Complex PDU.
Choose STAFF-PC as the source device.
Choose GUEST-PC as the destination device.
Select Periodic.
Set the Interval to 5 seconds.

Before you start the capture, consider whether the Event List will show one isolated event or a repeating pattern.

Start the monitor with Auto Capture / Play.
Let the monitor run until the Event List contains at least two complete ICMP exchanges.

You should see the ICMP exchange complete repeatedly at an interval of 5 seconds. Good work. The repaired path is now proving itself across multiple cycles.

Record the recurring ICMP success in your incident evidence.

Recurring events not completing?

Confirm that Periodic is selected for the Complex PDU.
Confirm that the Interval shows 5 seconds.
Confirm that both PCs still hold their valid DHCP leases.

Help me diagnose why my Periodic Complex PDU is not producing recurring successful ICMP exchanges.

Collect the closeout evidence

Incident closure needs evidence from each layer. Router output proves interface state and DHCP service.

Switch output proves the uplink repair. Client addressing and cross-subnet tests prove the complete traffic path.

Return to the command-line window on BR-R1.
Collect the router interface and DHCP evidence by running:

show ip interface brief
show ip dhcp pool
show ip dhcp binding

What does the router evidence prove?

The interface summary confirms that both router LAN interfaces remain healthy.
The pool output confirms that the Staff and Guest address pools still exist.
The binding output confirms that the router still holds client leases.

Review the three router outputs.

You should see healthy states for G0/0/0 and G0/0/1. You should also see the STAFF and GUEST pools with active bindings.

Return to the command-line window on STAFF-SW.
Collect the final uplink status by running:

show interfaces f0/1 status

What does the switch evidence prove?

The status output confirms that the router uplink remains connected after the repair. Its operating profile no longer exposes the forced speed and duplex settings.

Review the final status output for F0/1.

You should see a connected uplink using its negotiated operating state.

Return to STAFF-PC's Command Prompt.
Collect its complete lease evidence by running:

ipconfig /all

What does the client evidence prove?

The IPv4 address identifies the client's active lease.
The subnet mask confirms the client's local network.
The default gateway confirms the router address used for remote traffic.

Review STAFF-PC's displayed addressing.

You should see a valid address in 192.168.10.0/24 with gateway 192.168.10.1.

Record STAFF-PC's displayed IPv4 address as current STAFF-PC IPv4 address.
Return to GUEST-PC's Command Prompt.
Run the same address command.

You should see a valid address in 192.168.20.0/24 with gateway 192.168.20.1.

Record GUEST-PC's displayed IPv4 address as current GUEST-PC IPv4 address.
Save office-network-repair.pkt in Cisco Packet Tracer.

Before the last cross-subnet checks, consider whether the restored uplink should pass traffic in both directions.

Return to STAFF-PC's Command Prompt.
Use ping to test current GUEST-PC IPv4 address.
Return to GUEST-PC's Command Prompt.
Use ping to test current STAFF-PC IPv4 address.

You should receive successful replies in both directions. These results confirm that routing and client addressing remain healthy after the performance repair.

Cross-subnet ping stopped working?

Confirm that each ping targets the current IPv4 address shown on the opposite PC.
Confirm that both client gateways still match their local subnets.
Confirm that both router LAN interfaces remain healthy in the interface summary.

Help me diagnose why cross-subnet ping stopped after I restored autonegotiation on STAFF-SW F0/1.

Add both successful cross-subnet ping results to your incident evidence.

You have closed the performance incident with evidence at every layer. The recurring ICMP events show that the repair remains stable.

Secret mission

Secret Mission: Repair a Remote-Only Finance PC Failure

Add a Finance PC that reaches its local gateway but fails across subnets. Diagnose the addressing mismatch from evidence, repair one field, and prove remote connectivity in both directions.

Clean Up Your Resources

Your repaired office network runs locally inside Cisco Packet Tracer on Windows at no ongoing cost. Cleanup covers the active simulation session plus the saved office-network-repair.pkt file.

Resources you used:

Your active Cisco Packet Tracer session running the Periodic Complex PDU.
The saved office-network-repair.pkt lab containing the repaired topology plus its incident evidence.

Keep everything running

No action needed. Choose this if you want to continue testing the repaired office network.

Leave Cisco Packet Tracer open if you want the recurring ICMP events to continue.
Keep office-network-repair.pkt as the saved copy of your repaired topology.
Use the lab again whenever you want to practise diagnosing addressing or interface faults.

Pause - I'll come back to this later

Shut down the active session to free local memory. Keep the saved lab ready for another troubleshooting session.

Switch back to the Cisco Packet Tracer window from earlier.
Stop Auto Capture / Play so the Periodic Complex PDU stops adding events.
Save office-network-repair.pkt to preserve the repaired topology.
Close Cisco Packet Tracer to end the local simulation session.

The recurring events stop. The saved lab remains available for your next session.

Delete - I don't want to use this again

Close the simulator before permanently removing the saved lab. Deleting the file removes the topology plus its incident evidence.

Close the Cisco Packet Tracer window from earlier.
Press the Windows key to open Windows search.
Type File Explorer into the search field.
Press Enter to open File Explorer.
Select This PC in the left sidebar.
Enter office-network-repair.pkt in the search box.
Select the matching file in the results.
Press Shift+Delete to remove the selected file permanently.
Confirm permanent deletion in the prompt.

The matching result disappears from File Explorer after confirmation. Your local Packet Tracer lab is now fully removed.

Nice Work!

Excellent work! Your repaired Cisco Packet Tracer office network now routes traffic between the Staff, Guest, and Finance clients.

What you learned:

Built a demo-ready two-subnet office network that routes traffic through BR-R1.
Used a layered troubleshooting workflow to isolate the disabled Guest interface plus the missing DHCP pool. Proved the repair with router output plus client addressing.
Diagnosed a forced 10 Mb/s half-duplex uplink while reachability remained available. Restored autonegotiation. Proved stability with recurring ICMP traffic in Simulation mode.
Secret Mission: Isolated a wrong default gateway on FINANCE-PC after local tests passed but remote access failed. Corrected only the gateway. Proved Guest connectivity with a final ping.

Ready to quiz yourself?