Troubleshoot a Network with ChatGPT

Use ChatGPT and Packet Tracer to diagnose a fictional two-site network.

Introduction

30 Second Summary

A network diagram can look perfectly connected while one hidden setting blocks every packet. Changing the network from appearances alone can turn a small fault into a bigger one.

In this project, you will build a fictional two-site network in Cisco Packet Tracer. You will use ChatGPT to plan the tests that expose a hidden connectivity fault.

What You'll Build

You will watch BR-ENG-PC reach HQ-SERVER across two routers after an ordered evidence ladder isolates the hidden fault.

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

  • A working HQ baseline that proves the local network can carry traffic between NOC-PC and HQ-SERVER.
  • An end-to-end routed path that lets BR-ENG-PC reach the HQ server through the fictional transit segment.
  • A screenshot-based incident record that separates diagram evidence from configuration evidence.
  • Secret Mission: Diagnose a deliberately shut branch router interface with the same evidence ladder. Restore end-to-end service after proving the cause.

Are there any prerequisites?

You need a Windows computer with Cisco Packet Tracer, Windows Snipping Tool, and a signed-in ChatGPT account.

No previous networking configuration experience is required. Basic computer use is enough to begin.

Before We Start

Before any hands-on work, commit to this project's safety boundary. Your statement explains why network evidence must guide changes to the fictional lab.

A network diagram shows the intended devices and links. Hidden endpoint values can still be wrong, so you need command output before deciding what to change.

Verify Your Lab Tools

Your safety statement establishes the rule for this lab. Network evidence comes before any change.

Before the first device is added, the lab environment needs a clean bill of health. In this step, you verify Cisco Packet Tracer, ChatGPT, and Windows Snipping Tool so a missing feature never masquerades as a network fault.

In this step, get ready to:
  • Confirm the required routers, switches, PCs, and server are available in Packet Tracer.
  • Verify that ChatGPT offers image input and Snipping Tool opens its capture overlay.
  • Save a blank Packet Tracer logical workspace as fictional-tower-network.pkt.
Check the Packet Tracer device palette

Packet Tracer can support the later network build only when the required device families are available. This check catches an environment issue before it can look like a topology fault.

  • Press the Windows key to open Windows Search.
  • Type Cisco Packet Tracer and press Enter.
  • Inspect the device palette in the open logical workspace.
  • Confirm that 4321 appears among the routers.
  • Confirm that 2960 appears among the switches.
  • Confirm that PC-PT appears among the end devices.
  • Confirm that a server appears among the end devices.

Missing the 4321 Router?

The later router commands use the 4321 interface layout. Continue only when that model appears in the palette.

  • Update Packet Tracer through the Cisco Networking Academy Resource Hub.
  • Return to the device palette after the update.
  • Confirm that 4321 now appears among the routers.

Need help restoring the 4321 device? You can also use the Cisco Learning Network Packet Tracer page.

Good. Packet Tracer can now supply every device required for the fictional two-site network.

How Each Device Fits the Lab

  • The 4321 routers move traffic between the HQ and branch networks.
  • The 2960 switches connect devices inside each local network.
  • The PC-PT devices represent the two workstations.
  • The server represents the application destination at HQ.
Confirm ChatGPT and Snipping Tool

ChatGPT needs its image-input control for the later topology analysis. Snipping Tool provides the fictional screenshot that becomes that input.

Keep the Test Fictional

Infrastructure screenshots can expose names, addresses, or business relationships. This project keeps that risk outside the workflow by using only the fictional Packet Tracer topology.

  • Keep every real infrastructure image outside this ChatGPT conversation.
  • Select your web browser from the Windows taskbar.
  • Navigate to ChatGPT.
  • Sign in with your existing ChatGPT account.
  • Start a chat.
  • Confirm that the prompt area shows the + control.
  • Select the + control.
  • Confirm that the menu includes Add photos & files.

What This Check Proves

The upload menu confirms that image input is available for this account. You can now use a fictional topology screenshot later without testing the feature during an incident.

  • Dismiss the upload menu without selecting a file.
  • Press Windows logo key + Shift + S.
  • Confirm that the Snipping Tool overlay opens.
  • Cancel the overlay without capturing anything.

That completes the image workflow check. ChatGPT is ready to receive fictional evidence when the troubleshooting begins.

Save the blank Packet Tracer project

Saving the workspace now gives every later network change one consistent home. The filename also makes the fictional scope visible whenever you return to the lab.

  • Switch back to Packet Tracer from earlier.
  • Confirm that the logical workspace is blank.
  • Select File in the top menu.
  • Select Save As.
  • Choose a local Windows folder for the project.
  • Enter fictional-tower-network.pkt as the filename.
  • Choose Packet Tracer Activity File (*.pkt) as the file type.
  • Select Save.

Before you run the final check, which three signs do you expect to confirm? Hold that prediction in mind.

  • Check the Packet Tracer window title for the saved filename.

You should see fictional-tower-network.pkt open on a blank logical workspace.

  • Switch back to the ChatGPT chat from earlier.
  • Select the + control in the prompt area.
  • Confirm that Add photos & files remains available.
  • Dismiss the upload menu without selecting a file.
  • Return to Packet Tracer from earlier.
  • Press Windows logo key + Shift + S.
  • Confirm that the Snipping Tool overlay opens over the saved workspace.
  • Cancel the overlay without capturing anything.

That removes the setup uncertainty. Packet Tracer is ready for the lab.

ChatGPT is ready for a later fictional screenshot. Snipping Tool is ready to capture it.

Checkpoint: Saved blank Cisco Packet Tracer Activity File (*.pkt) in a local Windows location.

Your lab tools are ready. Next, you can build the HQ LAN inside the saved Packet Tracer project.

Build the HQ LAN

Your blank fictional-tower-network.pkt workspace is ready in Cisco Packet Tracer. The next task is to give that workspace a working local network.

A known-good HQ LAN gives you a baseline for the remote troubleshooting later. If a future test fails, you can compare it against connectivity that already works.

In this step, get ready to:
  • Build the four-device HQ topology.
  • Configure addressing across the HQ LAN.
  • Establish a saved local-connectivity baseline.
Build the HQ topology

A physical topology shows which devices exist. It also shows how their ports connect through an Ethernet network.

  • Place one 4321 router from the device palette into the logical workspace.
  • Set the router's Display Name to HQ from its Config tab.
  • Place one 2960 switch from the device palette into the logical workspace.
  • Set the switch's Display Name to HQ-SW from its Config tab.
  • Place one PC-PT device from the device palette into the logical workspace.
  • Set the PC's Display Name to NOC-PC from its Config tab.
  • Place one server end device from the device palette into the logical workspace.
  • Set the server's Display Name to HQ-SERVER from its Config tab.

You should see HQ beside HQ-SW. You should also see NOC-PC beside HQ-SERVER.

The switch gives every HQ device a path onto the same local network. Each cable must terminate on the specified interface so your later tests match the intended topology.

  • Use a Copper Straight-Through cable to connect NOC-PC FastEthernet0 to HQ-SW FastEthernet0/1.
  • Use a Copper Straight-Through cable to connect HQ-SERVER FastEthernet0 to HQ-SW FastEthernet0/2.
  • Use a Copper Straight-Through cable to connect HQ GigabitEthernet0/0/0 to HQ-SW GigabitEthernet0/1.

Each device should now have a visible connection to HQ-SW. The LAN now has a complete physical path.

Does the topology look different?

  • Confirm that every link uses Copper Straight-Through.
  • Check the two endpoint links against FastEthernet0/1 and FastEthernet0/2 on HQ-SW.
  • Check the router link against GigabitEthernet0/1 on HQ-SW.

Need help checking the links? Help me compare my Packet Tracer HQ topology with the required device and port connections.

Configure HQ addressing

An IPv4 subnet groups devices that can communicate locally. A default gateway gives an endpoint the router address it uses for destinations outside that subnet.

  • Select NOC-PC in the logical workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Enter 10.10.10.10 as the IP address.
  • Enter 255.255.255.0 as the subnet mask.
  • Enter 10.10.10.1 as the default gateway.

The NOC-PC configuration should now display 10.10.10.10 with the gateway 10.10.10.1.

The server needs a different address in the same subnet. It uses the same router interface as its default gateway.

  • Select HQ-SERVER in the logical workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Enter 10.10.10.20 as the IP address.
  • Enter 255.255.255.0 as the subnet mask.
  • Enter 10.10.10.1 as the default gateway.

The HQ-SERVER configuration should now display 10.10.10.20 with the gateway 10.10.10.1.

The router interface provides the gateway address for both endpoints. Enabling that interface makes the router available on the LAN.

  • Select HQ in the logical workspace.
  • Select the CLI tab.
  • Apply the HQ router configuration by entering these commands in order:
enable
configure terminal
hostname HQ
interface GigabitEthernet0/0/0
ip address 10.10.10.1 255.255.255.0
no shutdown
end
copy running-config startup-config

What does this configuration do?

  • The hostname HQ command gives the router its internal name.
  • The interface GigabitEthernet0/0/0 command selects the LAN-facing interface.
  • The ip address 10.10.10.1 255.255.255.0 command assigns the gateway address.
  • The no shutdown command enables the selected interface.
  • The copy running-config startup-config command saves the router configuration.

The switch link can take a short time to settle after the router interface is enabled. A brief delay here does not mean your configuration failed.

  • Wait for the router prompt to return after the configuration is saved.
  • Check the link between HQ and HQ-SW in the logical workspace.

The link indicators should settle into an active state. This confirms that the enabled router interface has a physical connection to the switch.

Is the router link still inactive?

  • Confirm that the router cable uses GigabitEthernet0/0/0.
  • Confirm that the switch end uses GigabitEthernet0/1.
  • Compare the interface configuration with the command sequence above.

Still stuck? Help me diagnose why my Packet Tracer HQ router interface remains inactive.

✔️ Awesome, I've got everything!

Your HQ router configuration now matches the local-network baseline.

ⓧ I'd like to double check the full code

enable
configure terminal
hostname HQ
interface GigabitEthernet0/0/0
ip address 10.10.10.1 255.255.255.0
no shutdown
end
copy running-config startup-config
Prove the local baseline

The physical links now have matching IP settings. The remaining job is to prove that NOC-PC can reach its gateway and the HQ server.

  • Select NOC-PC in the logical workspace.
  • Select the Desktop tab.
  • Select Command Prompt.
  • Display the workstation's complete IP configuration by running:
ipconfig /all

What does this command show?

This command reports the workstation's configured address information. It lets you verify the endpoint values before testing the network.

You should see the IP address 10.10.10.10. You should also see the default gateway 10.10.10.1.

Do the workstation values differ?

  • Return to the Desktop tab on NOC-PC.
  • Select IP Configuration.
  • Compare each displayed value with the required NOC workstation settings.

Need another pair of eyes? Help me compare my NOC-PC IP configuration with the required HQ LAN values.

  • Test the local gateway by running:
ping 10.10.10.1

What does this test prove?

This test sends echo requests from NOC-PC to the router's LAN address. Successful replies prove that the workstation can reach its first network hop.

You should see replies from 10.10.10.1. The workstation can now reach its configured gateway.

Is the gateway test failing?

  • Check the IP address on NOC-PC.
  • Check the subnet mask on NOC-PC.
  • Compare the router interface address with 10.10.10.1.

Need help isolating the failed hop? Help me troubleshoot why NOC-PC cannot reach the HQ gateway in Packet Tracer.

  • Predict whether the HQ server should reply through the local switch.
  • Test the HQ server by running:
ping 10.10.10.20

What does the final test prove?

  • The command tests reachability from NOC-PC to HQ-SERVER.
  • The first attempt may pause while ARP resolves the server's hardware address.
  • Successful replies prove that both endpoints communicate across HQ-SW.
  • Repeat the server test once if the first attempt waits for address resolution.

You should see replies from 10.10.10.20. The working HQ LAN is now your verified local baseline.

Is the server still unreachable?

  • Compare the server IP address with 10.10.10.20.
  • Compare the server subnet mask with 255.255.255.0.
  • Check the server cable against HQ-SW FastEthernet0/2.

Need help tracing the local failure? Help me diagnose why NOC-PC cannot reach HQ-SERVER in this Packet Tracer LAN.

That is the baseline established. Your workstation can now reach both its gateway and the HQ server.

  • Select File in Packet Tracer.
  • Select Save to update fictional-tower-network.pkt.

Your HQ LAN now gives you a trusted result to compare against. Next, you will extend the lab beyond this local network and test the longer path.

Extend to the Branch

Your working HQ LAN gives you a trusted baseline inside Cisco Packet Tracer. The next goal is a second site connected through an Ethernet transit segment.

A complete-looking physical topology can still hide an endpoint setting that blocks remote traffic. This step lets the new branch expose that failure through evidence.

In this step, get ready to:
  • Build the branch-side topology.
  • Configure a routed transit path between HQ and BRANCH.
  • Compare BR-ENG-PC's local reachability with its remote reachability.
Build the branch and transit layout

Clear device names make later evidence easier to trace. Exact port choices preserve the intended packet path.

  • Drag one 4321 router into the open area of the logical workspace.
  • Set the router's displayed name to BRANCH.
  • Drag one 2960 switch into the branch LAN area.
  • Set the branch switch's displayed name to BR-SW.
  • Drag one PC-PT into the branch LAN area.
  • Set the PC's displayed name to BR-ENG-PC.
  • Drag one more 2960 switch between the HQ router and the branch router.
  • Set the transit switch's displayed name to ISP-TRANSIT.

What Does the Transit Switch Represent?

ISP-TRANSIT represents a provider-style Layer 2 Ethernet handoff. It carries frames between the two routers across the transit segment.

  • Connect BR-ENG-PC FastEthernet0 to BR-SW FastEthernet0/1 with a Copper Straight-Through link.
  • Connect BRANCH GigabitEthernet0/0/0 to BR-SW GigabitEthernet0/1 with a Copper Straight-Through link.
  • Connect HQ GigabitEthernet0/0/1 to ISP-TRANSIT FastEthernet0/1 with a Copper Straight-Through link.
  • Connect BRANCH GigabitEthernet0/0/1 to ISP-TRANSIT FastEthernet0/2 with a Copper Straight-Through link.

You should now see the branch LAN connected to ISP-TRANSIT. HQ should also have one link to the transit switch.

Cannot Select a Listed Port?

  • Confirm that both routers use the 4321 model.
  • Confirm that both switches use the 2960 model.
  • Delete any link using the required port before reconnecting the intended cable.

Still stuck? Help me check the Packet Tracer devices and ports in my fictional two-site topology.

Configure the routed path

Routers know their connected networks. Static routes add a path to remote subnets.

The transit addresses let HQ pass branch traffic to BRANCH. The return route lets BRANCH send HQ traffic back through the same segment.

  • Select the HQ router in the logical workspace.
  • Switch to the router's command-line tab.
  • Configure HQ for the routed branch path by entering these commands:
  • Press Enter if the router asks you to confirm the destination filename.
enable
configure terminal
interface GigabitEthernet0/0/1
ip address 10.255.255.1 255.255.255.252
no shutdown
exit
ip route 10.20.20.0 255.255.255.0 GigabitEthernet0/0/1 10.255.255.2
end
copy running-config startup-config

What Does the HQ Configuration Do?

  • The address 10.255.255.1 places HQ on the transit subnet.
  • The mask 255.255.255.252 defines the small point-to-point transit range.
  • The static route sends traffic for 10.20.20.0 through the BRANCH next hop at 10.255.255.2.
  • The final command saves the active configuration for the next startup.
  • Inspect HQ's routed state by entering these commands:
show ip interface brief
show ip route

What Should HQ Show?

You should see both configured HQ interfaces in an up state. The routing table should include a static route to 10.20.20.0 marked with S.

HQ Interface or Route Missing?

  • Check that the transit cable uses HQ GigabitEthernet0/0/1.
  • Compare the transit address with 10.255.255.1.
  • Compare the route's next hop with 10.255.255.2.

Need another pair of eyes? Help me diagnose the missing HQ interface state or static route.

  • Select the BRANCH router in the logical workspace.
  • Switch to the router's command-line tab.
  • Configure BRANCH for the routed HQ path by entering these commands:
  • Press Enter if the router asks you to confirm the destination filename.
enable
configure terminal
hostname BRANCH
interface GigabitEthernet0/0/0
ip address 10.20.20.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/0/1
ip address 10.255.255.2 255.255.255.252
no shutdown
exit
ip route 10.10.10.0 255.255.255.0 GigabitEthernet0/0/1 10.255.255.1
end
copy running-config startup-config

What Does the BRANCH Configuration Do?

  • The address 10.20.20.1 gives the branch LAN its router address.
  • The address 10.255.255.2 places BRANCH on the transit subnet.
  • The static route sends traffic for 10.10.10.0 through the HQ next hop at 10.255.255.1.
  • The final command saves the BRANCH configuration for the next startup.
  • Inspect BRANCH's routed state by entering these commands:
show ip interface brief
show ip route

What Should BRANCH Show?

You should see both configured BRANCH interfaces in an up state. The routing table should include a static route to 10.10.10.0 marked with S.

BRANCH Interface or Route Missing?

  • Check that the LAN cable uses BRANCH GigabitEthernet0/0/0.
  • Check that the transit cable uses BRANCH GigabitEthernet0/0/1.
  • Compare the route's next hop with 10.255.255.1.

Need help tracing the mismatch? Help me check the BRANCH interface and static route configuration.

✔️ Awesome, I've got everything!

Both routers now contain the intended LAN interfaces, transit interfaces, and static routes.

ⓧ I'd like to double check the full code

HQ router configuration

This reference includes the working HQ LAN configuration from earlier. It also includes the new transit path.

enable
configure terminal
hostname HQ
interface GigabitEthernet0/0/0
ip address 10.10.10.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/0/1
ip address 10.255.255.1 255.255.255.252
no shutdown
exit
ip route 10.20.20.0 255.255.255.0 GigabitEthernet0/0/1 10.255.255.2
end
copy running-config startup-config

What to Compare

HQ keeps its existing LAN interface at 10.10.10.1. The new interface and route add the path toward the branch LAN.

BRANCH router configuration
enable
configure terminal
hostname BRANCH
interface GigabitEthernet0/0/0
ip address 10.20.20.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/0/1
ip address 10.255.255.2 255.255.255.252
no shutdown
exit
ip route 10.10.10.0 255.255.255.0 GigabitEthernet0/0/1 10.255.255.1
end
copy running-config startup-config

What to Compare

BRANCH uses one interface for the branch LAN. Its second interface and static route provide the path toward HQ.

Test the branch from the endpoint

A default gateway forwards traffic that leaves the workstation's local subnet.

The supplied handover value now gets tested against a local destination. The remote test checks the full path to HQ.

  • Select BR-ENG-PC in the logical workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Enter 10.20.20.10 in the IP Address field.
  • Enter 255.255.255.0 in the Subnet Mask field.
  • Enter 10.20.20.254 in the Default Gateway field.
  • Close the IP Configuration window.

BR-ENG-PC now holds the supplied handover settings. The router configurations remain unchanged.

  • Select Command Prompt on the Desktop tab.

Before you run the checks, which destination do you think will fail first?

  • Test the branch path by entering these commands in order:
ipconfig /all
ping 10.20.20.1
ping 10.10.10.20

What Do These Results Prove?

  • The first command displays the workstation's configured address information.
  • The first ping checks direct reachability to the actual branch router address at 10.20.20.1.
  • The second ping checks the routed path to HQ-SERVER at 10.10.10.20.

The ping to 10.20.20.1 succeeds. The ping to 10.10.10.20 fails.

That contrast is the intended shortfall. The diagram looks complete, but the endpoint cannot hand remote traffic to a working first hop.

Local Ping Also Failing?

  • Repeat the local ping once if the first request waited for address resolution.
  • Compare the workstation address with 10.20.20.10.
  • Confirm that BRANCH GigabitEthernet0/0/0 remains in an up state.

Still missing the expected contrast? Help me troubleshoot why BR-ENG-PC cannot reach its local router before I test HQ-SERVER.

  • Select File in Packet Tracer.
  • Select Save to update fictional-tower-network.pkt.

You have captured the evidence that matters. Local branch reachability works while the remote HQ path still fails.

Your two-site network now contains a failure that cables alone cannot explain. Next, you will turn the fictional topology into a cautious ChatGPT test plan and compare it with command evidence.

Create an AI Test Plan

Your Cisco Packet Tracer network now has a working local path plus a failed remote path. That failure gives you evidence to investigate.

A topology screenshot can reveal intended devices plus links. Hidden endpoint values require command evidence, so ChatGPT should create a test plan instead of declaring a root cause.

In this step, get ready to:
  • Capture a screenshot containing only the fictional topology.
  • Prompt ChatGPT to separate diagram evidence from unknown facts.
  • Use Packet Tracer commands to verify the first-hop mismatch.
Capture the fictional topology

Uploading a network diagram can feel sensitive. This project uses only the fictional workspace, so no real infrastructure belongs in the capture.

The Windows Snipping Tool lets you select one region of the screen. A tight capture keeps unrelated windows plus personal information outside the image.

  • Switch back to Packet Tracer.
  • Fit the full fictional topology inside the logical workspace.
  • Press Windows logo key + Shift + S to start a capture.

You will see the Snipping Tool overlay across your screen. The overlay lets you choose the exact region included in the screenshot.

  • Drag around only the Packet Tracer workspace.
  • Press Ctrl + S to save the captured snip.
  • Choose a local folder for the image.
  • Confirm the save.
  • Switch back to ChatGPT.
  • Select the + control beside the prompt area.
  • Select Add photos & files.
  • Select the saved fictional topology screenshot.

Your fictional topology is now safely attached to the ChatGPT conversation. The image should contain only the Packet Tracer workspace.

Ask ChatGPT for ordered tests

Image analysis can produce incorrect descriptions during precise spatial tasks. A constrained prompt keeps the response focused on visible evidence plus testable unknowns.

  • Tell ChatGPT how to structure its analysis by pasting this prompt:
You are assisting a beginner with a fictional Cisco Packet Tracer network. Read only what is visible in this topology screenshot. Return exactly four sections: Visible devices and links; Expected packet path from BR-ENG-PC to HQ-SERVER; Facts the image cannot prove; Tests in order. Do not invent IP addresses, VLANs, routes, interface states, or root causes. Start the tests with ipconfig /all, then the local gateway, then the remote destination with ping, then tracert.

How Does This Prompt Limit Guessing?

  • The four requested sections separate visible details from facts that require command evidence.
  • The guardrail prevents ChatGPT from inventing addresses or interface states.
  • The test order starts at the workstation before moving toward the remote destination.

This structure exposes AI uncertainty instead of hiding it. Each unknown becomes a question that Packet Tracer can answer.

  • Submit the prompt.
  • Count the sections in the response.

You should see exactly four sections named Visible devices and links, Expected packet path from BR-ENG-PC to HQ-SERVER, Facts the image cannot prove, plus Tests in order.

Your screenshot has now become a cautious test plan. ChatGPT has identified what the diagram suggests without treating those suggestions as configuration facts.

Did ChatGPT Invent Configuration Details?

  • Check that you pasted the full prompt after attaching the screenshot.
  • Repeat the guardrail if the response claims an address or interface state that the image cannot prove.

Still seeing unsupported claims? Help me make ChatGPT separate visible topology evidence from unknown network configuration.

Prove the gateway mismatch

An evidence ladder checks the endpoint before testing the wider path. This order helps you identify the first point where the observed behavior stops matching the intended route.

  • Switch back to Packet Tracer.
  • Select BR-ENG-PC.
  • Select the Desktop tab.
  • Select Command Prompt.

Before you run the checks, which result do you expect to separate local reachability from remote reachability?

  • Collect endpoint, gateway, destination, plus path evidence by running these commands in order:
ipconfig /all
ping 10.20.20.1
ping 10.10.10.20
tracert 10.10.10.20

What Does This Evidence Ladder Check?

  • The ipconfig /all output reveals the workstation's configured network values.
  • The ping 10.20.20.1 result tests the local router interface.
  • The ping 10.10.10.20 result tests the remote destination.
  • The tracert 10.10.10.20 result checks how far the packet travels.

The first failed layer narrows the investigation. Later tests provide context without replacing that first useful boundary.

Your endpoint details should report gateway 10.20.20.254. The local test to 10.20.20.1 should succeed.

The remote ping should fail. The trace should not reach HQ-SERVER.

Missing One of the Expected Results?

  • Confirm that you entered the commands in the BR-ENG-PC Command Prompt.
  • Repeat the local ping if its first attempt pauses during address resolution.
  • Check that the destination addresses match the commands shown above.

Need help reading the evidence? Help me interpret these Packet Tracer connectivity checks without changing the configuration.

  • Copy the observed command output.
  • Switch back to ChatGPT.
  • Paste the output into the conversation.
  • Ask ChatGPT to evaluate the evidence by adding this request below the output:
compare the evidence with the visible router LAN address without proposing a change first.

Why Withhold the Fix?

The request keeps ChatGPT in analysis mode. It must connect each claim to the command evidence before suggesting any action.

This protects the working links plus routes from unnecessary changes. A single mismatch can then be handled as a controlled fault.

  • Submit the evidence plus comparison request.

ChatGPT should highlight the difference between the workstation gateway plus the branch router's LAN address. Treat that response as a hypothesis until you compare the values yourself.

Did ChatGPT Jump Straight to a Fix?

Ask it to cite the observed value behind each conclusion. Keep configuration changes outside this conversation until your independent check is complete.

Need a stricter review? Help me challenge an AI troubleshooting conclusion using only my Packet Tracer evidence.

Before you compare the two values, do you expect the configured workstation gateway to equal the router's LAN address?

  • Return to Packet Tracer.
  • Locate the gateway value in the BR-ENG-PC ipconfig /all output.
  • Return to the BRANCH CLI output from earlier.
  • Locate the GigabitEthernet0/0/0 row from show ip interface brief.
  • Compare the two addresses.
  • Leave the BR-ENG-PC settings unchanged.

You will find that BR-ENG-PC reports 10.20.20.254, while BRANCH GigabitEthernet0/0/0 uses 10.20.20.1.

You have isolated the first-hop mismatch without changing the topology. Your AI test plan stayed subordinate to Packet Tracer evidence.

Your test plan has narrowed the outage to one unsupported gateway value. Next up, you will make one controlled change before verifying the full routed path.

Fix the Gateway Fault

Your Cisco Packet Tracer evidence has isolated the failure to one endpoint setting. The branch workstation can reach its local router.

It still sends remote traffic toward the wrong default gateway. This step uses one controlled change to restore the routed path.

Every known-good network setting stays untouched. That keeps the cause-and-effect relationship clear.

In this step, get ready to:
  • Correct the default gateway on BR-ENG-PC.
  • Verify local gateway access plus end-to-end connectivity.
  • Create an evidence-based incident record with ChatGPT.
Correct the branch gateway

A workstation uses its gateway to send traffic beyond its local subnet. The gateway must point to a router interface that the workstation can reach directly.

  • Select BR-ENG-PC in the Packet Tracer workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Locate the Default Gateway field showing 10.20.20.254.
  • Replace the gateway value with 10.20.20.1.
  • Keep 10.20.20.10 in the IP Address field.
  • Keep 255.255.255.0 in the Subnet Mask field.

Good catch. BR-ENG-PC now points at the branch router interface on its own subnet.

Why change only one setting?

A controlled change tests one evidence-backed cause. If connectivity returns after this edit, the result supports the gateway diagnosis.

The workstation address remains valid. The subnet mask remains valid.

The cables remain untouched. The router interfaces plus static routes remain untouched.

Verify the restored path

The troubleshooting ladder now retests the endpoint configuration before moving outward. Each result shows whether the correction works at a specific part of the path.

Before you run the checks, which result do you expect to change now that the gateway points to the local router? Take a moment to decide.

  • Return to the Desktop tab.
  • Select Command Prompt.
  • Retest the endpoint plus routed path by running these commands:
ipconfig /all
ping 10.20.20.1
ping 10.10.10.20
tracert 10.10.10.20

What do these checks prove?

  • The configuration output confirms that BR-ENG-PC now reports 10.20.20.1 as its gateway.
  • The first ping confirms that the workstation can reach its local router.
  • The second ping confirms that traffic can cross the routed path to HQ-SERVER.
  • The trace confirms that the path reaches 10.10.10.20.

You should see 10.20.20.1 as the default gateway. The gateway ping should return replies.

The HQ server ping should return replies. The trace should reach 10.10.10.20.

That path is live again. BR-ENG-PC can now reach the HQ server through both routers.

Still seeing a failed remote test?

  • Confirm that the Default Gateway field shows 10.20.20.1.
  • Confirm that the workstation address still shows 10.20.20.10.
  • Confirm that the subnet mask still shows 255.255.255.0.

If the remote test still fails, help me compare my branch gateway settings with my Packet Tracer command output.

The successful output is your proof that the controlled change restored service. Capture that proof while the relevant Packet Tracer window is visible.

  • Keep the successful ping or trace visible in the BR-ENG-PC command window.
  • Press Windows logo key + Shift + S to open Windows Snipping Tool.
  • Drag over only the fictional Packet Tracer workspace or successful command output.
  • Press Ctrl + S to save the second screenshot locally.
  • Save fictional-tower-network.pkt from Packet Tracer's file menu.

Keep the evidence fictional

Capture only the fictional topology or its successful command output. This keeps real infrastructure details outside the evidence record.

Document the verified incident

An incident record turns your troubleshooting evidence into a reusable explanation. Its structure keeps the observed symptom separate from the proven cause.

  • Switch back to the ChatGPT conversation from earlier.
  • Paste only the verified failed-path observations plus the successful results from BR-ENG-PC.
  • Request the incident record by pasting this prompt:
Use only the verified before-and-after observations I provided. Return exactly five lines using these labels: Symptom, Evidence, Cause, Fix, and Verification. Reject any statement that is not supported by my command output.

How does this prompt control the record?

  • The Symptom line records the original connectivity failure.
  • The Evidence line records the command observations that isolated the mismatch.
  • The Cause line names the incorrect branch gateway.
  • The Fix line records the controlled gateway correction.
  • The Verification line records the successful ping plus trace.
  • Compare every incident-record statement with the Packet Tracer output you observed.
  • Tell ChatGPT to remove any statement that your command output does not support.
  • Confirm that the final response contains exactly five lines.
  • Confirm that each line begins with its required label.

You should see one line for each required part of the incident. The Verification line should cite the restored HQ server ping plus trace.

Your evidence now tells a complete story. The failed path led to one isolated cause before one controlled fix restored connectivity.

Secret mission

Diagnose a Shut Interface

Create a new outage by shutting the branch LAN interface. Diagnose it from the workstation outward. Restore service only after the router evidence confirms the cause.

Clean Up Your Resources

Clean Up Your Resources

Your Cisco Packet Tracer lab runs locally with no paid cloud infrastructure or ongoing project costs. Choose whether to keep the artifacts, close the tools for now, or delete the saved files plus your ChatGPT conversation.

Resources you used:

  • Your restored Cisco Packet Tracer lab in fictional-tower-network.pkt.
  • Your locally saved fictional-topology-screenshot plus working-connectivity-screenshot evidence.
  • Your ChatGPT conversation containing the cautious test plan, verified observations, and five-line incident record.

Keep everything running

No action is needed. Choose this option if you want to revisit the working lab or reuse the evidence ladder.

  • Keep fictional-tower-network.pkt as a working two-site troubleshooting lab.
  • Retain fictional-topology-screenshot plus working-connectivity-screenshot as before-and-after evidence.
  • Leave the ChatGPT conversation in your account for future reference.

Pause - I'll come back to this later

Closing the tools ends the current session while preserving each saved artifact. Your restored network stays ready for another practice session.

  • Switch back to Cisco Packet Tracer from earlier.
  • Confirm fictional-tower-network.pkt is the open restored lab.
  • Close Cisco Packet Tracer.
  • Close ChatGPT.
  • Keep both locally saved screenshots in their current folder.

Delete - I don't want to use this again

This option removes the saved lab artifacts from Windows. It also removes the fictional conversation from your ChatGPT history.

Protect What You Want to Keep

Deleting the finished lab can feel drastic.

The steps below remove the saved Packet Tracer file plus both local screenshots.

They also remove the ChatGPT conversation containing the fictional upload.

  • Press the Windows logo key to open Windows search.
  • Type File Explorer.
  • Press Enter to open File Explorer.

File Explorer is now ready for the folder that holds your saved lab.

  • Return to the folder where you saved fictional-tower-network.pkt.
  • Select fictional-tower-network.pkt.
  • Press the Delete key.
  • Select fictional-topology-screenshot.
  • Press the Delete key.
  • Select working-connectivity-screenshot.
  • Press the Delete key.
  • Confirm all three artifacts are absent from the folder.

That is your local cleanup complete. The restored lab plus both screenshots are now absent from their saved folder.

  • Return to ChatGPT from earlier.
  • Find the conversation containing the fictional topology in your chat history.
  • Open the conversation menu.
  • Select Delete.
  • Confirm Delete in the confirmation dialog.
  • Confirm the conversation no longer appears in your chat history.

You have wrapped this up cleanly. The local lab evidence plus fictional ChatGPT conversation are no longer in their original locations.

Nice Work!

Nice Work!

You did it! Your restored two-site network in Cisco Packet Tracer now carries traffic from BR-ENG-PC to HQ-SERVER. You turned uncertain diagram clues into a verified incident record grounded in command output.

You've learned how to:

  • Built a two-site routed network in Packet Tracer. Configured IPv4 interfaces across both sites. Added static routes so BR-ENG-PC could reach HQ-SERVER.
  • Established a known-good local baseline before testing the remote destination. Applied an evidence ladder from endpoint checks through router state checks. This isolated the wrong default gateway without disturbing working links or routes.
  • Used ChatGPT to turn a fictional topology screenshot into ordered tests. Kept Packet Tracer command output as the source of truth. Captured the verified result in a five-line incident record.
  • Secret Mission: Diagnosed a deliberately shut GigabitEthernet0/0/0 interface on BRANCH from the workstation outward. Restored the interface with no shutdown. Reverified end-to-end connectivity from BR-ENG-PC to HQ-SERVER.

Ready to quiz yourself?