Nationwide WAN Link Operations

Build and troubleshoot a two-site WAN with static routing and incident evidence.

Introduction

30 Second Summary

Two offices can look healthy on their own while traffic between them quietly fails. Without a repeatable test record, the next engineer has to start the investigation from scratch.

In this project, you will build a two-site network in Cisco Packet Tracer 9.0.1 that carries traffic between an HQ user and a regional branch over a point-to-point WAN. You will turn a routing failure into a tested recovery with a clear operations record.

What You'll Build

At the finish line, you can show an HQ user reaching a branch user through two routers across a labeled carrier circuit.

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

  • A working HQ-to-branch WAN demo where HQ-PC can reach BR-PC through both routers.
  • A repeatable failure-and-recovery test that exposes missing remote routes before reciprocal static routes restore traffic.
  • An operations record that gives an interviewer clear evidence of circuit acceptance and incident recovery.
  • Secret Mission: Diagnose an incorrect default gateway on BR-PC without misclassifying it as a provider outage.

Are there any prerequisites?

No networking experience is required. A Windows PC with at least 8 GB of RAM is the only prerequisite.

Before We Start

Before the hands-on work begins, lock in the goal: connect an HQ user to a branch user through a point-to-point WAN. You will also document the test evidence needed to prove the link works and support troubleshooting.

Set Up Your Free Network Lab

Router tests become difficult to reproduce when the lab cannot be reopened. An evidence file gives another engineer a clear record of what happened.

In this step, you will prepare a local Cisco Packet Tracer lab. You will also create a Windows Notepad record before adding any network devices.

In this step, get ready to:
  • Create a free Cisco Networking Academy account.
  • Install Cisco Packet Tracer 9.0.1 on your Windows PC.
  • Save the empty topology file and operations record.
Create your Cisco Networking Academy account

Cisco Networking Academy provides the free account used to download Packet Tracer. Your password stays inside Cisco's account flow.

You should see Packet Tracer described as a free networking simulation tool. This confirms that you are using Cisco's official access path.

  • Join the free introductory Packet Tracer course if the site requests enrollment.
  • Follow the registration prompts to create your Cisco Networking Academy login.

Your account is ready when you can access the official Packet Tracer learning collection. That login now unlocks the Windows download.

Install and authenticate Packet Tracer

This project uses Cisco Packet Tracer 9.0.1 so the lab starts from a consistent version. The installer creates the local simulation workspace used throughout the project.

Why Packet Tracer for this lab?

Packet Tracer keeps this first project focused on IPv4 addressing and routing. It provides a free local simulation path through Cisco Networking Academy.

The official Windows setup for GNS3 adds a separate GNS3 VM. It also requires learner-supplied Cisco IOS images.

  • Choose the tab that matches the Packet Tracer installation currently on your Windows PC.

✔️ I have the required version

Use this path when Cisco Packet Tracer 9.0.1 is already installed.

  • Press the Windows key to open Windows search.
  • Type Cisco Packet Tracer in the search field.
  • Press Enter.

You should see the Cisco Packet Tracer Login window. This confirms that the application launches successfully.

Authentication continues in your browser. Your account password stays outside the Packet Tracer workspace.

  • Click LOGIN.
  • Authenticate with your Cisco Networking Academy account in the browser.

The browser should display You have successfully logged in to Cisco Packet Tracer. You may close this tab..

  • Return to Packet Tracer.

You should see the empty Packet Tracer workspace. Your authenticated lab is ready for a saved baseline.

ⓧ I have an older version

An older installation needs the current Windows installer. This path upgrades the lab to Cisco Packet Tracer 9.0.1.

  • Visit the official Cisco Resource Hub.
  • Download the Windows installer for Cisco Packet Tracer 9.0.1.

You should see the Packet Tracer installer in your browser's completed downloads. This confirms that the installation package is available locally.

  • Double-click the downloaded Windows installer.
  • Accept the License Agreement.

The installer now asks where to place the application. The suggested options are suitable for this lab.

  • Keep the suggested destination option.
  • Keep the suggested Start Menu option.

You should reach the installer review screen. This gives you one final chance to confirm the selected options.

  • Review the installation settings.
  • Click Install.

The completed installer confirms that Cisco Packet Tracer 9.0.1 is available on your PC.

  • Press the Windows key to open Windows search.
  • Type Cisco Packet Tracer in the search field.
  • Press Enter.

You should see the Cisco Packet Tracer Login window. This confirms that the upgraded application launches.

  • Click LOGIN.
  • Authenticate with your Cisco Networking Academy account in the browser.

The browser should display You have successfully logged in to Cisco Packet Tracer. You may close this tab..

  • Return to Packet Tracer.

You should see the empty Packet Tracer workspace. The upgraded lab is authenticated and ready.

ⓧ Packet Tracer is not installed

This is the expected path for a new lab PC. The official Windows installer sets up Cisco Packet Tracer 9.0.1 locally.

  • Visit the official Cisco Resource Hub.
  • Download the Windows installer for Cisco Packet Tracer 9.0.1.

You should see the Packet Tracer installer in your browser's completed downloads. This confirms that the installation package is available locally.

  • Double-click the downloaded Windows installer.
  • Accept the License Agreement.

The installer now asks where to place the application. The suggested options are suitable for this lab.

  • Keep the suggested destination option.
  • Keep the suggested Start Menu option.

You should reach the installer review screen. This confirms that the installer has the options it needs.

  • Review the installation settings.
  • Click Install.

The completed installer confirms that Cisco Packet Tracer 9.0.1 is available on your PC.

  • Press the Windows key to open Windows search.
  • Type Cisco Packet Tracer in the search field.
  • Press Enter.

You should see the Cisco Packet Tracer Login window. This confirms that the new installation launches.

  • Click LOGIN.
  • Authenticate with your Cisco Networking Academy account in the browser.

The browser should display You have successfully logged in to Cisco Packet Tracer. You may close this tab..

  • Return to Packet Tracer.

You should see the empty Packet Tracer workspace. Your new lab is authenticated and ready.

Packet Tracer does not launch or authenticate?

  • Confirm that you downloaded the Windows installer from the official Cisco Resource Hub.
  • Complete the browser authentication before returning to Packet Tracer.
  • Launch Packet Tracer again if the completed browser login has not updated the application.

Help me troubleshoot my Packet Tracer installation or login. You can also search the Cisco Learning Network for Packet Tracer support.

Save the lab baseline and create the record

A saved empty project gives every later network change a known starting point. The operations record separates circuit inventory from test evidence and incident details.

  • Save the empty Packet Tracer workspace as nadra-wan-operations.pkt in a local folder you can find again.
  • Keep nadra-wan-operations.pkt open in Packet Tracer.

You should see nadra-wan-operations.pkt as the open project. The workspace should contain no network devices or links.

  • Press the Windows key to open Windows search.
  • Type Notepad in the search field.

Windows search should show Windows Notepad in the results. Choose the tab that matches what you see.

✔️ I see Windows Notepad

  • Select Notepad from the search results.

You should see a blank plain-text document. This is where you will keep the WAN operations evidence.

ⓧ Windows Notepad is missing

Windows Notepad is available from Microsoft's official store listing. Installing it gives you the plain-text editor required for the operations record.

The completed installation adds Windows Notepad to your PC.

  • Press the Windows key to open Windows search.
  • Type Notepad in the search field.
  • Select Notepad from the search results.

You should see a blank plain-text document. Windows Notepad is now available for the operations record.

  • Create the operations record headings by copying the text below into the blank Notepad document:
WAN LINK INVENTORY

ACCEPTANCE TEST

INCIDENT RECORD

What does this record capture?

  • WAN LINK INVENTORY holds the circuit identity and addressing details.
  • ACCEPTANCE TEST holds evidence that the working link meets the lab requirements.
  • INCIDENT RECORD holds symptoms and test results from a fault investigation.
  • Save the document as wan-operations-record.txt in the folder containing nadra-wan-operations.pkt.
  • Keep wan-operations-record.txt open in Notepad.

You should see wan-operations-record.txt as the open document. The three headings should have one blank line between them.

Headings or filename look wrong?

  • Match the capital letters in each heading to the reference block.
  • Keep one blank line between each pair of headings.
  • Confirm that the saved filename ends with .txt.

Help me compare my operations record with the required file.

✔️ Awesome, I've got everything!

Great. Double-check that both project files are saved and remain open.

ⓧ I'd like to double check the full code

Your nadra-wan-operations.pkt artifact should be a saved empty Cisco Packet Tracer 9.0.1 project with no network devices or links.

WAN LINK INVENTORY

ACCEPTANCE TEST

INCIDENT RECORD

Before you perform the final check, which two filenames should remain open?

  • Switch back to Packet Tracer.
  • Confirm that nadra-wan-operations.pkt remains open.
  • Confirm that the Packet Tracer workspace contains no network devices or links.
  • Return to Notepad.
  • Confirm that wan-operations-record.txt remains open.
  • Compare the document with the three required headings.

You should see nadra-wan-operations.pkt open in Cisco Packet Tracer 9.0.1 with an empty workspace. You should also see wan-operations-record.txt open in Notepad with the complete record structure.

That clean baseline is now secured. Every network change has a saved lab and a dedicated place for evidence.

Your free network lab is ready. Next, you will build the HQ LAN and prove that its PC can reach the local router.

Bring the HQ LAN Online

Your lab files are ready from the last step. The empty Cisco Packet Tracer topology still has no local site that can carry traffic.

A WAN test only means something after each LAN works on its own. You will build the HQ site first so HQ-PC can prove reachability to its local router.

In this step, get ready to:
  • Build the HQ topology with three labeled devices.
  • Configure HQ-R1 as the local gateway.
  • Prove local connectivity from HQ-PC.
Build and label the HQ LAN

The router acts as the default gateway for traffic leaving HQ. The switch joins the PC to that gateway inside the local network.

  • Select the router category from the device palette in the bottom-left corner.
  • Drag one router onto the workspace.
  • Select the switch category from the device palette.
  • Drag one switch onto the workspace.
  • Select the end-device category from the device palette.
  • Drag one PC onto the workspace.

You should now see three separate devices in the workspace. Their names still need to show each device's operational role.

  • Set the router's Display Name field to HQ-R1 from its Config tab.
  • Set the switch's Display Name field to HQ-SW1 from its Config tab.
  • Set the PC's Display Name field to HQ-PC from its Config tab.

The connection controls are compact, so take this one port at a time.

  • Select an Ethernet cable from the connection tools in the bottom-left corner.
  • Connect the Ethernet port on HQ-PC to an unused Ethernet port on HQ-SW1.
  • Connect another unused port on HQ-SW1 to GigabitEthernet0/0 on HQ-R1.
  • Place the label 192.168.10.0/24 beside the HQ devices.
  • Save nadra-wan-operations.pkt from the File menu.

You should see HQ-PC connected through HQ-SW1 to HQ-R1. GigabitEthernet0/1 on HQ-R1 should have no cable attached.

Configure the HQ router gateway

The router needs an IPv4 address before HQ-PC can use it as a gateway. You will inspect the available interfaces before assigning that address.

  • Click HQ-R1 in the workspace.
  • Select the CLI tab.
  • Press Enter to activate the command prompt.
  • Inspect the router's Ethernet interfaces by running these commands:
enable
show ip interface brief

What Does This Check?

  • The show ip interface brief command lists the router interfaces with their addresses and current states.
  • GigabitEthernet0/0 is the HQ LAN interface for this topology.
  • GigabitEthernet0/1 stays unused for the future site-to-site connection.

You should see GigabitEthernet0/0 and GigabitEthernet0/1 in the interface list. Neither interface should have an IP address yet.

  • Apply the HQ gateway settings by running these commands:
configure terminal
hostname HQ-R1
interface GigabitEthernet0/0
description HQ-LAN
ip address 192.168.10.1 255.255.255.0
no shutdown
end
show ip interface brief

What Does This Configuration Do?

  • The hostname command gives the router its operational name of HQ-R1.
  • The HQ-LAN description records the purpose of the interface.
  • The address 192.168.10.1 becomes the gateway for devices on the HQ subnet.
  • The interface enable command allows the connected Ethernet link to carry traffic.
  • The final verification command displays the resulting interface state.
  • Confirm GigabitEthernet0/0 lists the address 192.168.10.1.
  • Confirm the status and protocol for GigabitEthernet0/0 both show up.
  • Confirm GigabitEthernet0/1 remains unused without an IP address.
  • Save nadra-wan-operations.pkt from the File menu.

Interface Still Down?

  • Check that the Ethernet link terminates on GigabitEthernet0/0 of HQ-R1.
  • Confirm that the other end of the link terminates on an Ethernet port of HQ-SW1.
  • Confirm that your router configuration includes the interface enable command shown above.

Help me diagnose why the HQ router interface is not up.

Configure HQ-PC and verify local access

HQ-PC needs an address from the same subnet as its gateway. Its subnet mask identifies which addresses belong to that local network.

  • Click HQ-PC in the workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Choose Static for the address configuration.
  • Enter 192.168.10.10 in the IP Address field.
  • Enter 255.255.255.0 in the Subnet Mask field.

The PC now belongs to the same 192.168.10.0/24 subnet as the router interface. It still needs the router's address for its gateway.

  • Enter 192.168.10.1 in the Default Gateway field.
  • Close the IP Configuration window.
  • Select Command Prompt from the Desktop tab.
  • Test the gateway with a ping by running this command:

Before you run the test, do you expect HQ-PC to reach its gateway? The command below puts that prediction to the test.

ping 192.168.10.1

What Does This Test Prove?

  • The command sends reachability tests from HQ-PC to its local gateway.
  • Replies prove that the PC addressing works on the HQ subnet.
  • A successful result also proves that both Ethernet links can carry local traffic.
  • Confirm the Command Prompt shows four replies followed by Lost = 0 (0% loss).
  • Save nadra-wan-operations.pkt from the File menu.

Ping Not Getting Replies?

  • Confirm HQ-PC uses 192.168.10.10 with the mask 255.255.255.0.
  • Confirm the default gateway is 192.168.10.1.
  • Return to HQ-R1 to confirm GigabitEthernet0/0 shows up for both status fields.

Help me find why HQ-PC cannot ping its local gateway.

Your first site is live. HQ-PC can now reach its local gateway through HQ-SW1.

Next, you will extend this local success across the site-to-site link.

Turn Up the Branch WAN and Find the Routing Gap

Your HQ LAN can already reach its local gateway inside Cisco Packet Tracer. That proves the first site works locally.

Now the network needs a regional branch plus a point-to-point WAN handoff. The crucial question is whether that working handoff gives every device a complete path.

In this step, get ready to:
  • Build the addressed branch LAN.
  • Configure the simulated carrier handoff.
  • Compare router reachability against site-to-site reachability.
Build the branch LAN

The branch mirrors the HQ design with one router gateway. A switch connects the branch user to that gateway.

  • Drag a router matching HQ-R1 from the lower device palette to the right side of the topology.
  • Rename the new router to BR-R1 through its Config tab.
  • Drag a switch matching HQ-SW1 beneath BR-R1.
  • Rename the new switch to BR-SW1 through its Config tab.
  • Drag one PC beneath BR-SW1.
  • Rename the new PC to BR-PC through its Config tab.
  • Connect BR-PC to BR-SW1 with a copper straight-through Ethernet link.
  • Connect BR-SW1 to BR-R1 interface GigabitEthernet0/0 with another copper straight-through Ethernet link.

You should now see a three-device branch beside the existing HQ site.

  • Add the label 192.168.20.0/24 beside the branch devices.

Router models identify their Ethernet ports with exact interface names. Checking those names first prevents the LAN address from landing on the carrier-facing port.

  • Select BR-R1.
  • Select the CLI tab.
  • Inspect the available interfaces by running this command:
show ip interface brief

What does this command show?

  • The output lists each interface with its current IP address.
  • The status columns show whether the port is administratively enabled.
  • The interface names identify the exact ports used by the following configuration.

You should see GigabitEthernet0/0 for the branch LAN plus unused GigabitEthernet0/1 for the WAN.

  • Configure the branch gateway through the BR-R1 CLI by entering these commands:
enable
configure terminal
hostname BR-R1
interface GigabitEthernet0/0
description BRANCH-LAN
ip address 192.168.20.1 255.255.255.0
no shutdown
end
show ip interface brief

What does this configuration do?

  • The hostname identifies the router as BR-R1 in later tests.
  • The description records that GigabitEthernet0/0 serves the branch LAN.
  • The address 192.168.20.1 becomes the branch PC's local gateway.
  • The interface command enables the port so it can carry traffic.
  • Save nadra-wan-operations.pkt from Packet Tracer's File menu.
  • Check the GigabitEthernet0/0 row in the command output.

You should see 192.168.20.1 assigned to GigabitEthernet0/0. The interface should report an active state after the Ethernet link settles.

Is the branch interface still inactive?

  • Confirm the switch link uses GigabitEthernet0/0 on BR-R1.
  • Check that the interface configuration includes the enable command.
  • Wait briefly for Packet Tracer to bring the Ethernet link online.

Help me diagnose why the branch router interface is not active.

The branch PC needs an IPv4 address from the branch subnet. Its default gateway points to the router interface you just configured.

  • Select BR-PC.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Enter 192.168.20.10 in the IPv4 Address field.
  • Enter 255.255.255.0 in the Subnet Mask field.
  • Enter 192.168.20.1 in the Default Gateway field.
  • Close the BR-PC configuration window.
  • Save nadra-wan-operations.pkt from Packet Tracer's File menu.

The branch now has its own addressed PC plus an active router gateway.

Configure the carrier handoff

A /30 subnet provides two usable host addresses for a point-to-point link. One address belongs to the HQ router. The other belongs to the branch router.

  • Connect HQ-R1 interface GigabitEthernet0/1 to BR-R1 interface GigabitEthernet0/1 with an Ethernet link.
  • Add the label ISP-P2P-FIBER-01 beside the router-to-router link.
  • Select HQ-R1.
  • Select the CLI tab.
  • Configure the HQ side of the handoff by entering these commands:
configure terminal
interface GigabitEthernet0/1
description ISP-P2P-FIBER-01
ip address 10.0.0.1 255.255.255.252
no shutdown
end
show ip interface brief

What does the HQ configuration do?

  • The interface description ties the router port to circuit ISP-P2P-FIBER-01.
  • The address 10.0.0.1 identifies the HQ endpoint on subnet 10.0.0.0/30.
  • The final command displays the updated address plus the current interface state.
  • Check the GigabitEthernet0/1 row in the latest output.
  • Save nadra-wan-operations.pkt from Packet Tracer's File menu.

You should see 10.0.0.1 assigned to the HQ WAN interface. Its line protocol can remain inactive until the branch endpoint is enabled.

Can't configure the HQ WAN port?

  • Confirm you selected the unused GigabitEthernet0/1 interface.
  • Check that GigabitEthernet0/0 still holds the HQ LAN address.
  • Confirm the router-to-router cable reaches the matching branch WAN port.

Help me troubleshoot the HQ side of the point-to-point WAN.

  • Switch back to the CLI tab on BR-R1.
  • Configure the branch side of the handoff by entering these commands:
enable
configure terminal
interface GigabitEthernet0/1
description ISP-P2P-FIBER-01
ip address 10.0.0.2 255.255.255.252
no shutdown
end
show ip interface brief

What does the branch configuration do?

  • The address 10.0.0.2 identifies the branch endpoint on the carrier handoff.
  • The mask 255.255.255.252 places both router endpoints in the same point-to-point subnet.
  • Enabling the second endpoint allows the link protocol to become active at both ends.
  • Check the GigabitEthernet0/1 row in the branch output.
  • Save nadra-wan-operations.pkt from Packet Tracer's File menu.

You should see 10.0.0.2 on the branch WAN interface. The interface status plus line protocol should both be active.

Is the WAN link still inactive?

  • Check that both routers use GigabitEthernet0/1 for the carrier link.
  • Confirm both WAN interfaces are administratively enabled.
  • Compare the two WAN masks for an exact match.

Help me find why the two Packet Tracer WAN interfaces are not active.

Use the following check to compare your cumulative router configuration before testing the circuit.

✔️ Awesome, I've got everything!

Your HQ plus branch interfaces now match the planned addressing.

ⓧ I'd like to double check the full code

  • Compare the cumulative HQ-R1 configuration with this reference:
enable
configure terminal
hostname HQ-R1
interface GigabitEthernet0/0
description HQ-LAN
ip address 192.168.10.1 255.255.255.0
no shutdown
interface GigabitEthernet0/1
description ISP-P2P-FIBER-01
ip address 10.0.0.1 255.255.255.252
no shutdown
end
show ip interface brief

What should match on HQ-R1?

The HQ LAN remains on GigabitEthernet0/0 with address 192.168.10.1. The carrier handoff uses GigabitEthernet0/1 with address 10.0.0.1.

  • Compare the cumulative BR-R1 configuration with this reference:
enable
configure terminal
hostname BR-R1
interface GigabitEthernet0/0
description BRANCH-LAN
ip address 192.168.20.1 255.255.255.0
no shutdown
interface GigabitEthernet0/1
description ISP-P2P-FIBER-01
ip address 10.0.0.2 255.255.255.252
no shutdown
end
show ip interface brief

What should match on BR-R1?

The branch LAN uses GigabitEthernet0/0 with address 192.168.20.1. The carrier handoff uses GigabitEthernet0/1 with address 10.0.0.2.

Test each layer of reachability

A layered test starts with the shortest path. First you will test only the router-to-router handoff.

  • Switch back to the CLI tab on HQ-R1.

Before you test the circuit, do you think the branch WAN endpoint is reachable from HQ?

  • Test the carrier-facing branch address by running this command:
ping 10.0.0.2

What does this result prove?

You should receive successful replies from 10.0.0.2. This proves both WAN interfaces can exchange traffic across ISP-P2P-FIBER-01.

That is a solid checkpoint: the simulated carrier handoff now carries traffic between the routers.

Does the router ping fail?

  • Confirm both WAN interfaces show an active status.
  • Compare the WAN addresses against 10.0.0.1 plus 10.0.0.2.
  • Check that both WAN interfaces use 255.255.255.252.

Help me troubleshoot why HQ-R1 cannot ping the branch WAN address.

The router test proves the handoff itself works. The next test asks whether an HQ user can reach the branch user through both routers.

  • Select HQ-PC.
  • Select the Desktop tab.
  • Select Command Prompt.

Before you run the end-to-end tests, do you think the successful WAN ping guarantees that the branch PC is reachable?

  • Test remote reachability plus the packet path by running these commands:
ping 192.168.20.10
tracert 192.168.20.10

The routing gap is visible

The ping fails to reach 192.168.20.10. The trace also fails to complete at the branch PC.

Each router knows its directly connected LAN plus the shared WAN subnet. Neither router knows how to forward traffic to the remote LAN.

  • Save nadra-wan-operations.pkt from Packet Tracer's File menu.

Your test evidence now separates a working carrier handoff from a failed end-to-end path. That distinction keeps a missing route from being misclassified as a carrier outage.

Seeing a different end-to-end result?

  • Confirm HQ-PC still uses default gateway 192.168.10.1.
  • Confirm BR-PC uses address 192.168.20.10.
  • Inspect both routing tables for any remote routes added before this test.

Help me reproduce the expected routing gap in my two-site Packet Tracer topology.

The WAN is live while the remote LAN remains unknown to each router. Next up, you will add reciprocal static routes so traffic can cross the complete path.

Restore Connectivity with Static Routes

Cisco Packet Tracer 9.0.1 now shows a healthy point-to-point handoff. HQ-R1 reaches BR-R1 across ISP-P2P-FIBER-01 while HQ-PC still cannot reach BR-PC.

Each router's routing table contains only its connected networks. In this step, you will add reciprocal static routes so each router knows the path to the remote LAN.

In this step, get ready to:
  • Route HQ traffic toward the branch LAN.
  • Route branch return traffic toward the HQ LAN.
  • Prove reciprocal routing through end-to-end tests.
Route HQ traffic to the branch LAN

The destination network identifies the remote LAN. The next hop identifies the neighboring router that can forward traffic toward it.

  • Select HQ-R1 in the topology.
  • Return to its command-line window from the earlier WAN test.
  • Add the branch route to HQ-R1 by entering these commands:
enable
configure terminal
ip route 192.168.20.0 255.255.255.0 10.0.0.2
end
show ip route

What does this route do?

  • The destination 192.168.20.0 identifies the branch LAN.
  • The mask 255.255.255.0 defines that destination as a /24 network.
  • The next hop 10.0.0.2 points HQ-R1 toward BR-R1 across the carrier handoff.
  • The final command displays HQ-R1's updated routing table.
  • Review the routing table output for the branch network.

You should see an S entry for 192.168.20.0/24 through 10.0.0.2. The S confirms that HQ-R1 learned the destination through a static route.

Branch route missing?

  • Confirm the destination is 192.168.20.0.
  • Check that the subnet mask is 255.255.255.0.
  • Verify that the next hop is BR-R1 at 10.0.0.2.

Help me diagnose a missing static route on HQ-R1.

Route branch traffic to the HQ LAN

HQ-R1 now knows the forward path to the branch. BR-R1 needs a matching return path to deliver replies to the HQ LAN.

  • Select BR-R1 in the topology.
  • Return to its command-line window from the earlier WAN setup.
  • Add the HQ return route to BR-R1 by entering these commands:
enable
configure terminal
ip route 192.168.10.0 255.255.255.0 10.0.0.1
end
show ip route

What does the return route do?

  • The destination 192.168.10.0 identifies the HQ LAN.
  • The mask 255.255.255.0 defines that destination as a /24 network.
  • The next hop 10.0.0.1 points BR-R1 toward HQ-R1 across the carrier handoff.
  • The final command displays BR-R1's updated routing table.
  • Review the routing table output for the HQ network.

You should see an S entry for 192.168.10.0/24 through 10.0.0.1. Both routers now have an explicit path to the remote LAN.

HQ route missing?

  • Confirm the destination is 192.168.10.0.
  • Check that the subnet mask is 255.255.255.0.
  • Verify that the next hop is HQ-R1 at 10.0.0.1.

Help me diagnose a missing static route on BR-R1.

✔️ Awesome, I've got everything!

Great. HQ-R1 has a route to the branch LAN. BR-R1 has a return route to the HQ LAN.

ⓧ I'd like to double check the full code

Compare the static-route configuration on HQ-R1 with these commands.

enable
configure terminal
ip route 192.168.20.0 255.255.255.0 10.0.0.2
end
show ip route

HQ-R1 route check

This configuration sends traffic for the branch LAN to BR-R1 at 10.0.0.2. The routing table should identify the branch network as static.

Compare the static-route configuration on BR-R1 with these commands.

enable
configure terminal
ip route 192.168.10.0 255.255.255.0 10.0.0.1
end
show ip route

BR-R1 route check

This configuration sends traffic for the HQ LAN to HQ-R1 at 10.0.0.1. The routing table should identify the HQ network as static.

Verify end-to-end recovery

Traffic now has a forward path plus a return path. The final tests prove that packets can cross the WAN in both directions.

Before you run these checks, do you expect the original failure to remain or disappear now that both routing tables contain reciprocal routes?

  • Select HQ-PC in the topology.
  • Return to its command prompt from the earlier failed test.
  • Test branch reachability plus the routed path by running these commands:
ping 192.168.20.10
tracert 192.168.20.10

What do these tests prove?

  • The ping test checks whether HQ-PC can exchange packets with BR-PC.
  • The tracert test reveals the routed path through HQ-R1 toward BR-R1.
  • Together these results prove that the carrier handoff plus both static routes support end-to-end traffic.

You should see replies from 192.168.20.10 with no lost packets. The trace should reach the branch through HQ-R1 plus BR-R1.

Still unable to reach BR-PC?

  • Confirm HQ-R1 shows an S route for 192.168.20.0/24.
  • Confirm BR-R1 shows an S route for 192.168.10.0/24.
  • Check that BR-PC still uses 192.168.20.1 as its default gateway.

Help me troubleshoot why HQ-PC still cannot reach BR-PC after adding both static routes.

Before you run the reverse test, do you think a successful HQ-to-branch result guarantees that BR-PC can start a new connection back to HQ-PC?

  • Select BR-PC in the topology.
  • Return to its command prompt from the branch setup.
  • Test the reverse path to HQ-PC by running this command:
ping 192.168.10.10

Why test the reverse direction?

This test starts traffic from the branch LAN. A successful result confirms that BR-R1 uses its HQ route while HQ-R1 provides the return path.

You should see replies from 192.168.10.10 with no lost packets. Bidirectional end-to-end connectivity now succeeds.

Reverse ping failing?

  • Confirm BR-PC still uses the IP address 192.168.20.10.
  • Verify that BR-PC still uses 192.168.20.1 as its default gateway.
  • Check that HQ-PC still uses 192.168.10.1 as its default gateway.

Help me troubleshoot why BR-PC cannot ping HQ-PC after both static routes were added.

  • Save nadra-wan-operations.pkt in Cisco Packet Tracer.
  • Leave the saved topology open for the next step.

That routing gap is closed. Your two-site WAN now carries traffic between HQ-PC plus BR-PC in either direction.

Your routed WAN is working from end to end. Next, you will capture acceptance evidence before reproducing a controlled carrier-link outage.

Run Link Acceptance and an Outage Drill

Your static routes now carry traffic between HQ and the branch. The working path gives you a baseline for this operations drill.

Network operations require evidence of the normal state. Link acceptance creates that evidence before an outage makes troubleshooting urgent.

You will also reproduce a controlled link failure. Your incident record will show the impact before proving recovery.

In this step, get ready to:
  • Record the circuit inventory for ISP-P2P-FIBER-01.
  • Capture passing acceptance evidence for the working WAN.
  • Run a controlled outage drill with recovery evidence.
Record the WAN inventory

A circuit inventory ties the carrier label to its endpoints. It also captures the IPv4 addressing needed during fault isolation.

  • Return to the open topology in Cisco Packet Tracer 9.0.1.
  • Select HQ-R1 in the topology.
  • Switch to the router command-line panel.
  • Check the HQ interface states by running this command:
show ip interface brief

What does this command show?

  • The output lists each interface with its assigned IP address.
  • The status columns show the administrative state plus the operational state.
  • The row for GigabitEthernet0/1 confirms the HQ side of the carrier handoff.

You should see GigabitEthernet0/0 with 192.168.10.1. You should also see GigabitEthernet0/1 with 10.0.0.1.

  • Switch to BR-R1 in the topology.
  • Switch to the router command-line panel.
  • Check the branch interface states by running this command:
show ip interface brief

What does the branch output prove?

  • The row for GigabitEthernet0/0 identifies the branch LAN gateway.
  • The row for GigabitEthernet0/1 identifies the branch side of the carrier handoff.
  • The two interface states establish the branch baseline before the outage.

You should see GigabitEthernet0/0 with 192.168.20.1. You should also see GigabitEthernet0/1 with 10.0.0.2.

  • Switch back to wan-operations-record.txt in Windows Notepad.
  • Select the existing WAN LINK INVENTORY heading.
  • Replace that heading with this completed inventory section:
WAN LINK INVENTORY
Circuit ID: ISP-P2P-FIBER-01
Transport: P2P fiber service, simulated handoff
Provider: Training ISP
Endpoints: HQ-R1 GigabitEthernet0/1 to BR-R1 GigabitEthernet0/1
WAN subnet: 10.0.0.0/30
HQ LAN subnet: 192.168.10.0/24
Branch LAN subnet: 192.168.20.0/24
Interface administrative and operational status: recorded from both routers
Date and time: recorded during lab

What does this inventory capture?

  • The circuit ID gives the simulated carrier service one consistent reference.
  • The endpoints identify the exact interfaces connected to the service.
  • The subnet entries separate the WAN addressing from each site LAN.
  • The status entry links the inventory to the interface checks you just performed.
  • Save wan-operations-record.txt by pressing Ctrl+S.
  • Confirm the inventory lists HQ-R1 GigabitEthernet0/1 as one endpoint.
  • Confirm the inventory lists BR-R1 GigabitEthernet0/1 as the other endpoint.

Missing an interface or address?

Compare each inventory entry with the interface output from its router. The HQ WAN address must be 10.0.0.1.

The branch WAN address must be 10.0.0.2. Both addresses belong to 10.0.0.0/30.

Ask for help if the inventory does not match the topology. Help me compare my WAN inventory with the HQ-R1 and BR-R1 interface details.

Capture the acceptance baseline

A ping to the peer router tests the point-to-point handoff. The PC tests extend that proof across both LANs.

  • Return to the HQ-R1 command-line panel.
  • Test the branch WAN interface by running this command:
ping 10.0.0.2

What does this ping prove?

A successful response proves that HQ-R1 can reach the branch router across ISP-P2P-FIBER-01. This isolates the carrier-facing handoff from the site LAN tests.

You should see replies from 10.0.0.2.

  • Select HQ-PC in the topology.
  • Switch to its command prompt.
  • Test end-to-end reachability by running this command:
ping 192.168.20.10

What does the PC ping add?

This test crosses the HQ LAN. It also crosses both routers before reaching BR-PC.

A successful result proves the static routes support traffic in both directions.

You should see successful replies from 192.168.20.10 with no lost packets.

  • Trace the accepted path by running this command:
tracert 192.168.20.10

What does the trace prove?

The trace shows the path taken toward the branch PC. It reaches HQ-R1 before crossing to BR-R1.

This path evidence becomes the reference for the outage test.

You should see the trace reach HQ-R1 plus BR-R1 before BR-PC.

  • Return to wan-operations-record.txt.
  • Select the existing ACCEPTANCE TEST heading.
  • Replace that heading with this completed acceptance section:
ACCEPTANCE TEST
HQ-R1 and BR-R1 show ip interface brief status: recorded
Ping 10.0.0.2: successful
HQ-PC ping 192.168.20.10: successful
HQ-PC tracert 192.168.20.10: reaches HQ-R1 and BR-R1 before BR-PC
Overall result: PASS
Note: simulated round-trip times are lab evidence only and are not a production SLA measurement.

Why record the acceptance result?

The acceptance section establishes what healthy service looks like. Each result can be repeated during later troubleshooting.

Packet Tracer timing is simulation output. The route plus reachability results provide the transferable evidence in this lab.

  • Save wan-operations-record.txt by pressing Ctrl+S.
  • Confirm the acceptance section records PASS.
  • Confirm the final note identifies the simulated timing as lab evidence.

Does an acceptance test fail?

  • Check whether both WAN interfaces have an operational state showing the link is up.
  • Confirm the static route on HQ-R1 points to 10.0.0.2.
  • Confirm the return route on BR-R1 points to 10.0.0.1.

Help me isolate which acceptance test is failing.

Create the outage and prove recovery

The outage affects only this simulated lab. You restore the same HQ interface before the drill ends.

A controlled shutdown gives you a known trigger. The resulting failure creates evidence that supports escalation.

  • Return to the HQ-R1 command-line panel.
  • Disable the HQ WAN interface by running this configuration:
configure terminal
interface GigabitEthernet0/1
shutdown
end

What does this configuration do?

  • The interface command selects the HQ side of the carrier handoff.
  • The shutdown command administratively disables that interface.
  • The static route remains configured during the outage.

The WAN link is now intentionally unavailable. This is the failure state you need to document.

Before you test, how do you expect an HQ user to experience the disabled WAN interface?

  • Return to the HQ-PC command prompt.
  • Test branch reachability during the outage by running this command:
ping 192.168.20.10

What does the failed ping prove?

You should see the requests fail while the HQ WAN interface is disabled. The result reproduces the user impact of the circuit outage.

  • Collect path evidence during the outage by running this command:
tracert 192.168.20.10

What does the failed trace add?

You should see that the trace cannot complete the accepted path to the branch. This provides path evidence alongside the failed reachability test.

Does traffic still reach the branch?

Confirm you applied the shutdown to HQ-R1 GigabitEthernet0/1. Shutting down GigabitEthernet0/0 would affect the HQ LAN instead.

Check the HQ WAN interface state before repeating the failed tests.

Help me verify that my controlled outage targets the correct interface.

  • Return to the HQ-R1 command-line panel.
  • Restore the HQ WAN interface by running this configuration:
configure terminal
interface GigabitEthernet0/1
no shutdown
end

What does this configuration restore?

The no shutdown command enables the same HQ WAN interface. The point-to-point handoff can carry traffic again once the simulated link returns to its operational state.

Before you test again, do you expect the saved static route to resume carrying traffic without being recreated?

  • Return to the HQ-PC command prompt.
  • Verify recovered reachability by running this command:
ping 192.168.20.10

What does the recovered ping prove?

You should see successful replies from 192.168.20.10. The restored interface has returned HQ-to-branch traffic to service.

  • Verify the recovered path by running this command:
tracert 192.168.20.10

What does the recovered trace confirm?

You should see the path reach the branch through HQ-R1 plus BR-R1. The result matches the accepted baseline.

  • Return to wan-operations-record.txt.
  • Select the existing INCIDENT RECORD heading.
  • Replace that heading with this completed incident section:
INCIDENT RECORD
Problem and user impact: controlled outage of HQ-R1 GigabitEthernet0/1 interrupted HQ-to-branch traffic.
Expected behavior: HQ-PC reaches BR-PC through ISP-P2P-FIBER-01.
Observed behavior: ping and tracert to 192.168.20.10 failed while HQ-R1 GigabitEthernet0/1 was shut down.
Start time: recorded during lab.
Trigger or recent change: shutdown applied to HQ-R1 GigabitEthernet0/1.
Affected circuit and addressing: ISP-P2P-FIBER-01, 10.0.0.0/30, HQ-R1 10.0.0.1, BR-R1 10.0.0.2.
Test evidence: failed ping and tracert collected during outage.
Action taken: no shutdown applied to HQ-R1 GigabitEthernet0/1.
Recovery verification: ping 192.168.20.10 succeeded after interface restoration.

What makes this an escalation record?

The record separates expected behavior from observed behavior. It also identifies the affected circuit plus the known trigger.

The failed tests establish impact. The corrective action plus recovery test close the incident with evidence.

  • Save wan-operations-record.txt by pressing Ctrl+S.
  • Switch back to nadra-wan-operations.pkt.
  • Save the Packet Tracer project by pressing Ctrl+S.
  • Confirm the incident record identifies GigabitEthernet0/1 as the restored interface.
  • Confirm the recovery entry records a successful ping to 192.168.20.10.

Does the recovered ping still fail?

  • Confirm the no shutdown command was applied to HQ-R1 GigabitEthernet0/1.
  • Check that the HQ WAN interface has returned to an operational state showing the link is up.
  • Repeat the router-to-router ping before testing from HQ-PC.

Help me troubleshoot why the WAN did not recover after no shutdown.

✔️ Awesome, I've got everything!

Your operations record now contains the inventory baseline. It also contains acceptance plus outage recovery evidence.

ⓧ I'd like to double check the full code

WAN LINK INVENTORY
Circuit ID: ISP-P2P-FIBER-01
Transport: P2P fiber service, simulated handoff
Provider: Training ISP
Endpoints: HQ-R1 GigabitEthernet0/1 to BR-R1 GigabitEthernet0/1
WAN subnet: 10.0.0.0/30
HQ LAN subnet: 192.168.10.0/24
Branch LAN subnet: 192.168.20.0/24
Interface administrative and operational status: recorded from both routers
Date and time: recorded during lab

ACCEPTANCE TEST
HQ-R1 and BR-R1 show ip interface brief status: recorded
Ping 10.0.0.2: successful
HQ-PC ping 192.168.20.10: successful
HQ-PC tracert 192.168.20.10: reaches HQ-R1 and BR-R1 before BR-PC
Overall result: PASS
Note: simulated round-trip times are lab evidence only and are not a production SLA measurement.

INCIDENT RECORD
Problem and user impact: controlled outage of HQ-R1 GigabitEthernet0/1 interrupted HQ-to-branch traffic.
Expected behavior: HQ-PC reaches BR-PC through ISP-P2P-FIBER-01.
Observed behavior: ping and tracert to 192.168.20.10 failed while HQ-R1 GigabitEthernet0/1 was shut down.
Start time: recorded during lab.
Trigger or recent change: shutdown applied to HQ-R1 GigabitEthernet0/1.
Affected circuit and addressing: ISP-P2P-FIBER-01, 10.0.0.0/30, HQ-R1 10.0.0.1, BR-R1 10.0.0.2.
Test evidence: failed ping and tracert collected during outage.
Action taken: no shutdown applied to HQ-R1 GigabitEthernet0/1.
Recovery verification: ping 192.168.20.10 succeeded after interface restoration.

What should match?

Compare the three headings plus every evidence line with your saved file. The final recovery entry should confirm successful reachability after interface restoration.

That completes the drill. Your lab now has a passing baseline with documented recovery.

Secret mission

Diagnose the Branch Without a Spoiler

A branch user can lose remote access while the local network and carrier handoff remain healthy. Diagnose a deliberately incorrect default gateway through ordered tests. Restore connectivity and document the evidence in the incident record.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your local lab, pause your work, or remove it entirely. This project uses only local resources. Keeping them creates no cloud charges or ongoing service costs.

Resources you used:

  • The Cisco Packet Tracer 9.0.1 installation used to run your WAN topology.
  • The nadra-wan-operations.pkt file containing the operational HQ and branch network.
  • The wan-operations-record.txt file containing your inventory, acceptance results, incident evidence, and recovery record.

Keep everything running

No action is needed. Choose this option if you want to rerun the outage drills or practise troubleshooting the WAN again.

  • Keep Cisco Packet Tracer 9.0.1 installed for reopening the lab.
  • Retain nadra-wan-operations.pkt as your working network simulation.
  • Retain wan-operations-record.txt as your operations evidence.

Pause - I'll come back to this later

This option closes the local apps while keeping both saved files intact. You can resume later without rebuilding the topology.

  • Switch back to the Packet Tracer window from earlier.
  • Close Packet Tracer.
  • Switch back to the Windows Notepad window from earlier.
  • Close Notepad.

Resume Your Lab

Reopen nadra-wan-operations.pkt when you are ready to continue testing. Reopen wan-operations-record.txt when you are ready to add more evidence.

Delete - I don't want to use this again

This option removes both project files from your PC. It also removes Packet Tracer when you no longer need the lab.

  • Switch back to the Packet Tracer window from earlier.
  • Close Packet Tracer.
  • Switch back to the Notepad window from earlier.
  • Close Notepad.

Both apps are now closed. You can remove the saved project files without changing any other documents.

  • Use File Explorer to navigate to the folder where you saved both project files.
  • Select nadra-wan-operations.pkt plus wan-operations-record.txt.
  • Press the Delete key to remove the selected files.

Your topology and operations record are now removed. Finish the cleanup by uninstalling the simulator if you no longer plan to use it.

  • Open Windows Settings through Windows search.
  • Open the installed apps list.
  • Find Cisco Packet Tracer 9.0.1.
  • Select its uninstall option.
  • Follow the removal prompts.

Nice Work!

Nice Work!

You made it. You built a Cisco Packet Tracer lab that carries traffic between HQ and the branch across a point-to-point WAN as the foundation for later network operations projects.

What you learned:

  • Built a working two-site network across separate HQ and branch LANs. Applied an IPv4 addressing plan with host addresses, subnet masks, default gateways, and a /30 carrier handoff.
  • Exposed the missing-route failure using ping plus tracert. Restored end-to-end connectivity with reciprocal static routes.
  • Completed a link acceptance test followed by a controlled outage drill. Captured inventory, test evidence, corrective action, ISP escalation details, and recovery verification in wan-operations-record.txt.
  • Secret Mission: Isolated an incorrect default gateway on BR-PC while ISP-P2P-FIBER-01 remained healthy. Corrected the setting to 192.168.20.1. Proved recovery with successful branch-to-HQ tests.

Ready to quiz yourself?