Restore a Dual-Stack Office Network

Build and troubleshoot a dual-stack office network in Cisco Packet Tracer.

Introduction

30 Second Summary

A network can look healthy while one kind of traffic quietly stops reaching its destination. Without a clear baseline, every part of the network can feel equally suspicious.

In this project, you will build a two-LAN office network in Cisco Packet Tracer that routes dual-stack traffic. You will recover from a deliberate IPv6 default gateway fault for a public GitHub incident case study that shows IPv4 remained healthy.

What You'll Build

You will open your public case study to show a working office topology alongside the failed test that led to a verified repair.

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

  • A working dual-stack topology where ping returns four replies for each protocol family.
  • An evidence-led troubleshooting workflow that isolates PC-B's wrong IPv6 gateway from healthy router interfaces.
  • A public GitHub incident case study that lets another person inspect every stage of the recovery from the runnable lab through the screenshots.
  • Secret Mission: An optional challenge to diagnose an administratively down router interface from command output before documenting the recovery.

Are there any prerequisites?

You need a Mac with internet access.

The first step covers Cisco Packet Tracer installation plus Cisco Networking Academy and GitHub account access.

Before We Start

This opening checkpoint turns the lab into a clear commitment before the hands-on work begins. Your portfolio-ready case study will demonstrate a controlled dual-stack failure from diagnosis through repair.

Prepare Packet Tracer and GitHub

Your dual-stack case study needs a reliable simulator before the timed network build begins. Repository access also needs to be ready before you publish the evidence.

Cisco Packet Tracer gives you the workspace for the network lab. GitHub gives your finished case study a public home.

In this step, get ready to:
  • Launch an authenticated Cisco Packet Tracer session.
  • Prepare GitHub access in Safari.
  • Verify every required device in the Packet Tracer palette.
Install or launch Cisco Packet Tracer

The macOS installer arrives as a .dmg from the Cisco Networking Academy Resource Hub. Your path depends on whether Packet Tracer already exists on your Mac.

  • Open Spotlight by pressing Cmd+Space.
  • Type Cisco Packet Tracer into Spotlight.
  • Press Enter.

✔️ Cisco Packet Tracer opens

Cisco Packet Tracer is already available on your Mac. The app is ready for the authentication check.

  • Leave Cisco Packet Tracer open at the login window or Logical workspace.

ⓧ Cisco Packet Tracer is not installed

The official Resource Hub provides the current macOS build. This avoids relying on an outdated installer.

  • Open Spotlight by pressing Cmd+Space.
  • Type Safari into Spotlight.
  • Press Enter.
  • Open Cisco Networking Academy in Safari.
  • Sign in to the Resource Hub.
  • Complete the Cisco account form if account creation is required.
  • Choose the current download for macOS.
  • Select the completed .dmg download in Safari.

The disk image now hands the installation to macOS. Follow the installer controls in order.

  • Select Open.
  • Select Continue.
  • Accept the License Agreement.

macOS may request your administrator password when installation begins. That approval stays on your Mac.

  • Select Install.
  • Complete the macOS authorization if prompted.
  • Select Done when the installation finishes.
  • Open Spotlight by pressing Cmd+Space.
  • Type Cisco Packet Tracer into Spotlight.
  • Press Enter.

You should see the Cisco Packet Tracer Login window or a blank Logical workspace.

Packet Tracer Won't Launch?

  • Confirm that the .dmg download completed before reopening it.
  • Relaunch Cisco Packet Tracer through Spotlight after the installer closes.
  • Help me troubleshoot Cisco Packet Tracer on macOS.
Authenticate your accounts

Packet Tracer uses browser authentication to connect the desktop app to your Cisco account. GitHub uses a separate account for the case-study repository.

Packet Tracer may remember a previous session. Choose the tab that matches the screen in front of you.

✔️ The blank Logical workspace is open

Packet Tracer has accepted your existing session. The blank Logical workspace confirms the simulator is authenticated.

ⓧ The Cisco Packet Tracer Login window is open

  • Select LOGIN in the Cisco Packet Tracer Login window.
  • Complete the Cisco authentication in Safari.

Safari should report You have successfully logged in to Cisco Packet Tracer. You may close this tab..

  • Return to Cisco Packet Tracer.

You should now see the blank Logical workspace.

The simulator session is ready. Your next account check prepares the publishing destination.

✔️ I have a GitHub account

  • Switch to Safari.
  • Open GitHub.
  • Sign in with your GitHub credentials.
  • Check the page header for your profile menu.

A visible profile menu confirms that GitHub access is ready.

ⓧ I need a GitHub account

  • Switch to Safari.
  • Open https://github.com/signup.
  • Complete the account details.
  • Finish the verification process if GitHub requests it.
  • Return to the GitHub home page.
  • Check the page header for your profile menu.

A visible profile menu confirms that the new account is ready.

Authentication Not Completing?

  • Retry the Packet Tracer login from the original app window if Safari finishes without returning you to the workspace.
  • Use GitHub's account-recovery process if your existing credentials are rejected.
  • Help me resolve the account setup problem.
Verify the Logical workspace and device palette

The upcoming topology depends on a router with two specific interfaces. It also needs an access switch plus two PC end devices.

  • Return to Cisco Packet Tracer.
  • Confirm that the blank Logical workspace fills the center of the app.
  • Select the router category in the device palette at the bottom of the app.
  • Confirm that a 4221 router is listed for R1.
  • Confirm that a 4300 family router is available if the current palette labels the preferred router differently.

Why Check the Router Now?

The required interface names are GigabitEthernet0/0/0 plus GigabitEthernet0/0/1. Cisco's CCNA lab maps these names to the router families you just checked.

The 4221 is the preferred match. A 4300 family router is the bounded fallback.

  • Select the switch category in the bottom device palette.
  • Confirm that a 2960 switch is available for S1.
  • Select the end-device category in the bottom device palette.
  • Confirm that the PC end device is available for PC-A plus PC-B.

One PC palette item is enough because you place the same device type twice during the network build.

Before the final check, which missing sign would tell you that this setup is incomplete?

  • Confirm that Packet Tracer still shows the blank Logical workspace.
  • Confirm that the required router choice remains available in the device palette.
  • Confirm that the 2960 switch remains available in the device palette.
  • Confirm that the PC end device remains available in the device palette.
  • Switch to Safari.
  • Confirm that your GitHub profile menu is available.

You should see the blank Logical workspace in Packet Tracer. Safari should show your signed-in GitHub page with the profile menu available.

That setup hurdle is behind you. Every tool required for the timed build is ready.

Next, you'll place the four network devices and prove that IPv4 traffic can cross both LANs.

Build the IPv4 Baseline

Your setup is ready. The blank Cisco Packet Tracer workspace now needs a network you can trust before you introduce the IPv6 fault.

A successful IPv4 path gives you a known-good baseline. It proves traffic can cross both LANs through R1.

In this step, get ready to:
  • Assemble the four-device topology with copper straight-through links.
  • Apply the full IPv4 address plan.
  • Prove end-to-end IPv4 connectivity between PC-A and PC-B.
Assemble the topology

The topology places PC-A behind an access switch. PC-B connects directly to the other routed interface on R1.

  • Drag the suitable router from the bottom-left device palette into the upper middle of the Logical workspace.
  • Drag the 2960 switch into the workspace beneath the router.
  • Drag the first PC into the lower-left area of the workspace.
  • Drag the second PC into the lower-right area of the workspace.

You should now see one router, one switch, plus two PCs in the Logical workspace.

  • Rename the router R1 through its device configuration window.
  • Rename the switch S1 through its device configuration window.
  • Rename the left PC PC-A through its device configuration window.
  • Rename the right PC PC-B through its device configuration window.
  • Connect PC-A's Ethernet port to an available Ethernet port on S1 with a copper straight-through cable.
  • Connect an available Ethernet port on S1 to GigabitEthernet0/0/1 on R1 with a copper straight-through cable.
  • Connect PC-B's Ethernet port directly to GigabitEthernet0/0/0 on R1 with a copper straight-through cable.

You should see three cables forming a path from PC-A through S1 to R1, with a separate link from R1 to PC-B.

Why Use Two LANs?

PC-A and PC-B belong to different IPv4 networks. R1 provides the routed path between them.

A successful ping across this layout proves more than local connectivity. It proves the complete office path works.

Missing a Device or Cable?

  • Confirm the workspace contains exactly one router, one 2960 switch, plus two PCs.
  • Check that PC-A reaches R1 through S1.
  • Check that PC-B connects directly to GigabitEthernet0/0/0 on R1.

Help me correct my Packet Tracer topology.

Configure IPv4 on R1

R1 needs one IPv4 address in each LAN. Those addresses become the local router destinations used by the two PCs.

  • Select R1 in the Logical workspace.
  • Select the CLI tab in the R1 window.
  • Configure the router hostname plus both IPv4 interfaces by entering these commands:
enable
configure terminal
hostname R1
interface GigabitEthernet0/0/0
ip address 192.168.0.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/0/1
ip address 192.168.1.1 255.255.255.0
no shutdown
end

What Does This Configuration Do?

  • The hostname line identifies the router as R1 in the CLI.
  • The GigabitEthernet0/0/0 block gives PC-B's LAN the router address 192.168.0.1.
  • The GigabitEthernet0/0/1 block gives PC-A's LAN the router address 192.168.1.1.
  • The activation lines bring both routed interfaces online.
  • Wait for all three cable links to show an active state.
  • Verify the IPv4 addresses plus interface states by running this command:
show ip interface brief

What Does This Command Show?

  • The interface summary gives you one compact view of every IPv4 interface on R1.
  • The assigned address beside each routed interface confirms that R1 accepted the address plan.
  • The interface status confirms whether each router port can carry traffic.

You should see 192.168.0.1 beside GigabitEthernet0/0/0. You should see 192.168.1.1 beside GigabitEthernet0/0/1.

Router Interfaces Still Inactive?

  • Compare both interface address values with the configuration block above.
  • Confirm each interface block includes its activation line.
  • Inspect the cable path connected to each named router interface.

Help me troubleshoot my R1 interface configuration.

Address the PCs and test the path

Each PC needs an address on its local network. A default gateway is the router address a PC uses to reach the other LAN.

  • Select PC-A in the Logical workspace.
  • Select the Desktop tab in the PC-A window.
  • Select IP Configuration.
  • Enter 192.168.1.3 as PC-A's IPv4 address.
  • Enter 255.255.255.0 as PC-A's subnet mask.
  • Enter 192.168.1.1 as PC-A's default gateway.
  • Close the PC-A window.

PC-A now belongs to the 192.168.1.0/24 LAN. Its gateway points to R1's interface on that network.

  • Select PC-B in the Logical workspace.
  • Select the Desktop tab in the PC-B window.
  • Select IP Configuration.
  • Enter 192.168.0.3 as PC-B's IPv4 address.
  • Enter 255.255.255.0 as PC-B's subnet mask.
  • Enter 192.168.0.1 as PC-B's default gateway.
  • Close the PC-B window.

Both PCs now know how to send off-subnet traffic toward R1.

  • Select PC-A in the Logical workspace.
  • Select the Desktop tab in the PC-A window.
  • Select Command Prompt.
  • Inspect PC-A's applied settings by running this command:
ipconfig /all

What Should You Confirm?

  • The IPv4 address should identify PC-A as 192.168.1.3.
  • The subnet mask should be 255.255.255.0.
  • The default gateway should point to 192.168.1.1.

Take a moment to predict whether PC-A can reach PC-B through R1.

  • Test the complete IPv4 path from PC-A by running this command:
ping 192.168.0.3

What Does This Test Prove?

Ping uses ICMP echo messages to test reachability. Replies from 192.168.0.3 prove that PC-A can cross R1 to reach PC-B's LAN.

You should see four replies from 192.168.0.3 in PC-A's Command Prompt.

That is your first working network path. IPv4 traffic now crosses both LANs through R1.

Not Seeing Four Replies?

  • Retry the ping after every cable link shows an active state.
  • Compare both PCs' IPv4 values with the address plan above.
  • Confirm both R1 interfaces still show an operational state in the interface summary.

Help me diagnose my failed IPv4 ping.

Your IPv4 baseline is working across both LANs. Next, you'll layer IPv6 onto this healthy network before creating the protocol-specific fault.

Create the IPv6 Incident

Your Cisco Packet Tracer network already carries IPv4 traffic between both LANs. This known-good baseline gives you a control when you add IPv6.

A host-side default gateway fault creates a separate failure domain for IPv6. You will use this controlled incident to capture the split symptom before any repair begins.

In this step, get ready to:
  • Configure IPv6 routing and addresses on R1.
  • Assign IPv6 settings to PC-A and PC-B.
  • Prove the protocol-specific failure and capture the evidence.
Configure IPv6 on R1

R1 needs IPv6 forwarding plus an address on each LAN. The two interfaces use the same link-local address because each one belongs to a separate network.

  • Select R1 in the Logical workspace.
  • Select the CLI tab.
  • Add IPv6 routing and interface addressing by entering this command sequence:
enable
configure terminal
ipv6 unicast-routing
interface GigabitEthernet0/0/0
ipv6 address fe80::1 link-local
ipv6 address 2001:db8:acad::1/64
exit
interface GigabitEthernet0/0/1
ipv6 address fe80::1 link-local
ipv6 address 2001:db8:acad:1::1/64
end

What does this configuration do?

  • The ipv6 unicast-routing command enables R1 to forward IPv6 traffic between its interfaces.
  • Each fe80::1 address serves as a link-local gateway on its own LAN.
  • The 2001:db8:acad::1/64 address places GigabitEthernet0/0/0 on PC-B's LAN.
  • The 2001:db8:acad:1::1/64 address places GigabitEthernet0/0/1 on PC-A's LAN.
  • Check the command sequence for any rejected input.

You should return to R1's privileged prompt without a rejected command. R1 now has IPv6 addressing alongside its existing IPv4 configuration.

Did R1 reject a command?

  • Confirm you selected R1 before entering the configuration.
  • Confirm R1 provides GigabitEthernet0/0/0.
  • Confirm R1 also provides GigabitEthernet0/0/1.

Help me troubleshoot the rejected R1 IPv6 command.

Address PC-A and PC-B

Each PC needs a global IPv6 address from its local /64 network. Its IPv6 gateway points toward a router address on that link.

  • Select PC-A in the Logical workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Enter 2001:db8:acad:1::3 as the IPv6 address.
  • Enter 64 as the prefix length.
  • Enter fe80::1 as the IPv6 gateway.

You have the first host ready for dual-stack traffic. Its existing IPv4 settings remain unchanged.

  • Close the PC-A device window.
  • Select PC-B in the Logical workspace.
  • Select the Desktop tab.
  • Select IP Configuration.
  • Enter 2001:db8:acad::3 as the IPv6 address.
  • Enter 64 as the prefix length.
  • Enter fe80::2 as the IPv6 gateway.

Both hosts now have IPv6 addresses. The first end-to-end test exposes the effect of their gateway values.

Can't find the IPv6 settings?

Confirm you selected the Desktop tab on the PC. Select IP Configuration to display its addressing settings.

Help me find the IPv6 settings in Packet Tracer.

Test IPv4 and IPv6

An ICMP reachability test checks each protocol stack independently. Comparing both results shows whether the incident affects the whole path or one protocol.

  • Close the PC-B device window.
  • Select PC-A in the Logical workspace.
  • Select the Desktop tab.
  • Select Command Prompt.

Before you run the tests, consider whether the two protocols will reach PC-B in the same way.

  • Test both protocol paths from PC-A by running these commands:
ping 192.168.0.3
ping 2001:db8:acad::3

What should you see?

  • The IPv4 command returns four replies from PC-B.
  • The IPv6 command fails to reach PC-B.
  • This contrast proves that the IPv4 baseline remains operational while the IPv6 incident is active.
  • Keep the failed IPv6 result visible in the Command Prompt window.
  • Press Shift-Command-4 on your Mac to start a selection screenshot.
  • Drag across the Command Prompt area containing the failed IPv6 test.
  • Rename the captured image to ipv6-failure.png in Finder.

You now have a clean before-repair record in ipv6-failure.png.

Seeing different ping results?

  • If the IPv6 ping succeeds, return to PC-B's IP Configuration window.
  • Confirm PC-B's IPv6 gateway is fe80::2.
  • If both pings fail, check that every link in the Logical workspace remains active.

Help me reproduce the split IPv4 and IPv6 symptom.

Your controlled incident now preserves IPv4 while IPv6 fails end to end. Next up, you will use router evidence to isolate the fault before making a repair.

Restore Dual-Stack Connectivity

You proved the split symptom in Cisco Packet Tracer: IPv4 still reaches PC-B while IPv6 fails. The next goal is a repair supported by evidence.

Healthy router interfaces plus connected routes clear the network path. That evidence narrows the fault to PC-B's host configuration before you change anything.

In this step, get ready to:
  • Use router evidence to narrow the fault.
  • Correct PC-B's IPv6 default gateway.
  • Package the verified recovery as local evidence.
Inspect the router evidence

A layered troubleshooting workflow starts with the network devices that carry traffic between the two LANs. Operational interfaces plus both connected IPv6 networks would show that R1 already has a valid route to each host.

Before you run these checks, which layer do you expect the router evidence to clear?

  • Return to R1's CLI tab from earlier.
  • Inspect R1's interface state and IPv6 routes by running these commands:
show ip interface brief
show ipv6 interface brief
show ipv6 route

What does this evidence show?

  • The show ip interface brief output checks whether both routed interfaces can carry IPv4 traffic.
  • The show ipv6 interface brief output checks the same interface state for IPv6.
  • The show ipv6 route output confirms that R1 knows how to reach both IPv6 LANs.

You'll see both routed interfaces reporting up/up. You'll also see connected routes for 2001:db8:acad::/64 and 2001:db8:acad:1::/64.

That is a strong result: R1 can reach both IPv6 LANs through active interfaces.

Router evidence looks different?

  • Confirm you entered the commands at R1's privileged prompt.
  • Check the two routed links if either interface does not report up/up.
  • Verify each routed interface still contains no shutdown before continuing.

Help me interpret my R1 interface and IPv6 route output.

Correct PC-B's IPv6 gateway

The healthy router evidence places the fault at the edge of the network. PC-B's link-local default gateway determines where traffic leaves its local IPv6 network.

  • Select PC-B in the Logical workspace.
  • Select the Desktop tab.
  • Select Command Prompt.
  • Inspect PC-B's complete address settings by running this command:
ipconfig /all

What does this host check prove?

  • The address 2001:db8:acad::3/64 places PC-B on the correct IPv6 network.
  • The gateway fe80::2 does not match R1's link-local address on that network.
  • The correct next hop for PC-B is fe80::1.
  • Return to PC-B's Desktop tab.
  • Select IP Configuration.
  • Replace the value in the IPv6 gateway field with fe80::1.
  • Return to PC-B's Command Prompt.
  • Confirm the corrected host setting by running this command:
ipconfig /all

What changed on PC-B?

PC-B keeps its global IPv6 address of 2001:db8:acad::3/64. Its default gateway now points to R1 at fe80::1.

You'll now see fe80::1 as PC-B's IPv6 gateway. The host has a valid next hop for traffic returning to PC-A.

Still seeing the wrong gateway?

  • Confirm you changed the IPv6 gateway on PC-B.
  • Check that the new value is exactly fe80::1.
  • Reopen IP Configuration if the old value remains in the command output.

Help me correct PC-B's IPv6 gateway in Packet Tracer.

Verify and preserve the recovery

An end-to-end ICMP test now checks the host settings plus both routed links. Successful tests over both protocols prove that the repair preserved the working IPv4 baseline.

Before you test, do you expect both protocols to reach PC-B after changing only its IPv6 gateway?

  • Return to PC-A in the Logical workspace.
  • Select the Desktop tab.
  • Select Command Prompt.
  • Test both protocols from PC-A by running these commands:
ping 192.168.0.3
ping 2001:db8:acad::3

What do the two pings prove?

  • The IPv4 ping confirms that the original working path remains intact.
  • The IPv6 ping confirms that PC-B can now return traffic through R1's fe80::1 link-local address.
  • Together, the tests prove end-to-end dual-stack connectivity between the two LANs.

You'll see four replies from PC-B for each ping. The restored IPv6 replies close the incident with visible proof.

  • Press Shift-Command-4 to start a partial screenshot.
  • Drag over the successful IPv6 ping result.
  • Rename the captured image to ipv6-restored.png.

The live result proves the network is repaired. Persistent files preserve that result after Packet Tracer closes.

The router save command prompts for a destination filename. The default target is the correct one for this lab.

  • Return to R1's CLI tab.
  • Save the running configuration by running this command:
copy running-config startup-config

What does this save protect?

The command copies R1's active settings into its startup configuration. Those interface addresses plus IPv6 routing remain available after the router restarts.

  • Press Enter to accept the default destination filename.

You'll see confirmation that the configuration copy completed.

Configuration copy did not complete?

  • Confirm R1 is showing its privileged prompt.
  • Run copy running-config startup-config again if the prompt returned before the copy completed.
  • Press Enter when Packet Tracer asks for the destination filename.

Help me save R1's running configuration in Packet Tracer.

  • Use Packet Tracer's file menu to save the lab as dual-stack-office-recovery.pkt.
  • Confirm the Packet Tracer window title includes dual-stack-office-recovery.pkt.
  • Return to R1's CLI tab.
  • Display R1's active configuration by running this command:
show running-config

Why capture the running configuration?

The running configuration records the settings that produced the successful tests. A plain-text copy lets another person inspect the router without opening the Packet Tracer lab.

  • Press Cmd+Space to open your Mac's search bar.
  • Type TextEdit and press Enter.
  • Select New Document if TextEdit shows a document picker.
  • Select Format in the top menu bar.
  • Select Make Plain Text.
  • Copy the matching sections from R1 into the document so the file reads exactly as follows:
hostname R1
!
ipv6 unicast-routing
!
interface GigabitEthernet0/0/0
 ip address 192.168.0.1 255.255.255.0
 ipv6 address fe80::1 link-local
 ipv6 address 2001:db8:acad::1/64
 no shutdown
!
interface GigabitEthernet0/0/1
 ip address 192.168.1.1 255.255.255.0
 ipv6 address fe80::1 link-local
 ipv6 address 2001:db8:acad:1::1/64
 no shutdown
!
end

What does this record preserve?

  • The hostname identifies the router as R1.
  • The global IPv6 routing setting allows traffic to pass between the two IPv6 LANs.
  • The two interface sections preserve the final IPv4 addresses plus the final IPv6 addresses.
  • Each no shutdown line records that the routed interface is enabled.
  • Select File in the TextEdit menu bar.
  • Select Save.
  • Enter R1-final-config.txt as the document name.
  • Choose the same local folder that contains dual-stack-office-recovery.pkt.
  • Select Save.

You'll see R1-final-config.txt in the TextEdit title bar. The file now matches the router configuration used for the successful tests.

Configuration file saved in the wrong format?

  • Confirm the TextEdit document uses plain text.
  • Check that the saved filename ends with .txt.
  • Compare every address in the file with the R1 output before saving again.

Help me save the final R1 configuration as a plain-text file.

✔️ Awesome, I've got everything!

Your final R1 configuration is saved as R1-final-config.txt beside the recovered Packet Tracer lab.

ⓧ I'd like to double check the full code

  • Compare R1-final-config.txt with this complete configuration record.
hostname R1
!
ipv6 unicast-routing
!
interface GigabitEthernet0/0/0
 ip address 192.168.0.1 255.255.255.0
 ipv6 address fe80::1 link-local
 ipv6 address 2001:db8:acad::1/64
 no shutdown
!
interface GigabitEthernet0/0/1
 ip address 192.168.1.1 255.255.255.0
 ipv6 address fe80::1 link-local
 ipv6 address 2001:db8:acad:1::1/64
 no shutdown
!
end

That is the recovery locked in: both protocols work again plus every local artifact records how you proved it. Next, you'll turn this evidence into a public GitHub incident case study.

Publish the Incident Case Study

Your dual-stack network now carries IPv4 and IPv6 traffic again. The saved Cisco Packet Tracer lab proves the repair on your Mac.

A working lab becomes useful evidence when another person can inspect its topology. It becomes reproducible when they can follow the same verification path.

A clear README preserves the reasoning behind your repair. You'll publish the evidence to GitHub as a public incident case study.

In this step, get ready to:
  • Capture the final topology evidence.
  • Create the public case-study repository.
  • Publish the incident files through a complete README.
Capture the final topology

The final topology screenshot connects your test evidence to the network that produced it. A quick artifact review makes the public upload safer.

  • Switch back to Cisco Packet Tracer.
  • Arrange R1, S1, PC-A, PC-B, and their active links in one clear view of the Logical workspace.
  • Press Shift-Command-4 to turn the pointer into a screenshot crosshair.
  • Drag the crosshair around the complete topology.
  • Rename the new screenshot to topology.png.
  • Inspect topology.png to confirm that every device name and link is readable.

What makes a useful topology image?

The screenshot should show how the two LANs connect through R1. Clear device names let a reviewer connect the addressing plan to the correct interfaces.

  • Press Cmd+Space to open your Mac search bar.
  • Type Finder and press Enter.
  • Use Finder search to locate topology.png, ipv6-failure.png, ipv6-restored.png, dual-stack-office-recovery.pkt, and R1-final-config.txt.
  • Review the five files for personal or secret information.
  • Check that dual-stack-office-recovery.pkt is below 25 MiB.

Your evidence pack should now contain five readable files. Each file is ready for a public browser upload.

Create the public repository

The repository gives your local evidence pack a public home. Its file history also records how the case study develops.

Public visibility means anyone can download the files you commit. The artifact review you just completed is your final safeguard.

  • Switch back to GitHub in Safari.
  • Select New repository from your GitHub home page.
  • Enter packet-tracer-dual-stack-incident as the repository name.
  • Choose Public for the repository visibility.
  • Select Add README.
  • Select Create repository.

You should see the new packet-tracer-dual-stack-incident repository with an initial README.md file.

Your case study now has a public home. The next upload fills it with the lab and its repair evidence.

Publish the case-study files

A README is the Markdown front page for your repository. It connects the raw files to the symptom, evidence, root cause, repair, and final checks.

Every selected file becomes public when you commit the upload.

  • Select Add file in the repository.
  • Select Upload files.
  • Choose topology.png, ipv6-failure.png, ipv6-restored.png, dual-stack-office-recovery.pkt, and R1-final-config.txt from your Mac.
  • Select Commit changes after all five filenames appear in the upload list.

You should return to the repository file list. The five uploaded artifacts should appear beside README.md.

Is an artifact missing?

Check that dual-stack-office-recovery.pkt is below 25 MiB. Retry the upload if the file was omitted.

Compare every uploaded filename with the five names above. Relative README links depend on exact spelling.

Help me troubleshoot my missing GitHub upload

The complete evidence pack is online. Now the README can turn those files into a clear troubleshooting story.

  • Select README.md from the repository file list.
  • Open the file editor for README.md.
  • Replace the default text with the opening and addressing plan below:
# Dual-Stack Office Network Incident

This Cisco Packet Tracer break/fix lab demonstrates IPv4 and IPv6 connectivity across two directly connected LANs. The incident left IPv4 working while IPv6 failed because PC-B had the wrong link-local default gateway.

![Completed topology](topology.png)

## Addressing plan

| Device | Interface | IPv4 | IPv6 | Default gateway |
| --- | --- | --- | --- | --- |
| R1 | G0/0/0 | 192.168.0.1/24 | 2001:db8:acad::1/64, fe80::1 | N/A |
| R1 | G0/0/1 | 192.168.1.1/24 | 2001:db8:acad:1::1/64, fe80::1 | N/A |
| PC-A | NIC | 192.168.1.3/24 | 2001:db8:acad:1::3/64 | 192.168.1.1, fe80::1 |
| PC-B | NIC | 192.168.0.3/24 | 2001:db8:acad::3/64 | 192.168.0.1, fe80::1 |

What does this section establish?

  • The opening gives the reader the protocol-specific symptom before they inspect the evidence.
  • The relative topology.png path keeps the image connected to the repository file.
  • The addressing table gives every device a known-good reference value.
  • Use the editor preview to inspect the opening section.

You should see the project title, the completed topology image, and a five-column addressing table.

Is the table misaligned?

Count five cells in every table row. Keep each vertical bar in place so GitHub can separate the columns.

Help me fix my README addressing table

  • Append the incident section below the final addressing-table row by pasting:
## Incident

Symptom: PC-A could ping PC-B over IPv4, but the IPv6 ping failed.

![IPv6 failure](ipv6-failure.png)

Tests performed:

1. Verified IPv4 interface state with `show ip interface brief`.
2. Verified IPv6 interface state with `show ipv6 interface brief`.
3. Verified both `/64` networks with `show ipv6 route`.
4. Compared PC-B's `ipconfig /all` output with the address plan.

Root cause: PC-B used `fe80::2` as its IPv6 default gateway instead of R1's link-local address, `fe80::1`.

Resolution: Corrected PC-B's IPv6 gateway to `fe80::1` and repeated the end-to-end test.

![IPv6 restored](ipv6-restored.png)

How does this document the diagnosis?

  • The symptom records that IPv4 survived while IPv6 failed.
  • The command list preserves the interface, route, and host evidence used during diagnosis.
  • The root cause identifies the wrong link-local gateway.
  • The resolution records the exact corrected gateway.
  • Use the editor preview to inspect the incident section.

You should see the failed IPv6 screenshot above the diagnosis. The restored screenshot should appear below the resolution.

Is an incident image missing?

Compare the image paths with ipv6-failure.png and ipv6-restored.png in the repository file list.

Check the filename capitalization. Relative image paths must match the uploaded files.

Help me fix a missing README image

  • Append the verification, project files, and skills sections below the restored image by pasting:
## Verification

| Test | Result |
| --- | --- |
| PC-A to PC-B IPv4 | Passed |
| PC-A to PC-B IPv6 before repair | Failed as designed |
| PC-A to PC-B IPv6 after repair | Passed |
| R1 routed interfaces | Up/up |
| R1 connected IPv6 routes | Present |

## Project files

- [Packet Tracer lab](dual-stack-office-recovery.pkt)
- [R1 final configuration](R1-final-config.txt)

## Skills demonstrated

- IPv4 and IPv6 interface addressing
- Link-local default gateway use
- Cisco IOS interface and route verification
- Layered troubleshooting and root-cause isolation
- Technical incident documentation

What does the final section prove?

  • The verification table contrasts the designed failure with the repaired result.
  • The project links let another person download the runnable lab and final router configuration.
  • The skills list connects the technical work to a repeatable troubleshooting method.
  • Use the editor preview to inspect the complete README.

You should see the verification table, two project-file links, and five demonstrated skills.

Are the project links broken?

Compare each link target with dual-stack-office-recovery.pkt and R1-final-config.txt in the repository file list.

Remove any extra spaces from the link paths. Keep the capitalization identical to the uploaded files.

Help me repair my README file links

✔️ Awesome, I've got everything!

Great. Double-check that the complete README.md is still visible in the editor preview.

ⓧ I'd like to double check the full code

Compare your complete README.md with this reference:

# Dual-Stack Office Network Incident

This Cisco Packet Tracer break/fix lab demonstrates IPv4 and IPv6 connectivity across two directly connected LANs. The incident left IPv4 working while IPv6 failed because PC-B had the wrong link-local default gateway.

![Completed topology](topology.png)

## Addressing plan

| Device | Interface | IPv4 | IPv6 | Default gateway |
| --- | --- | --- | --- | --- |
| R1 | G0/0/0 | 192.168.0.1/24 | 2001:db8:acad::1/64, fe80::1 | N/A |
| R1 | G0/0/1 | 192.168.1.1/24 | 2001:db8:acad:1::1/64, fe80::1 | N/A |
| PC-A | NIC | 192.168.1.3/24 | 2001:db8:acad:1::3/64 | 192.168.1.1, fe80::1 |
| PC-B | NIC | 192.168.0.3/24 | 2001:db8:acad::3/64 | 192.168.0.1, fe80::1 |

## Incident

Symptom: PC-A could ping PC-B over IPv4, but the IPv6 ping failed.

![IPv6 failure](ipv6-failure.png)

Tests performed:

1. Verified IPv4 interface state with `show ip interface brief`.
2. Verified IPv6 interface state with `show ipv6 interface brief`.
3. Verified both `/64` networks with `show ipv6 route`.
4. Compared PC-B's `ipconfig /all` output with the address plan.

Root cause: PC-B used `fe80::2` as its IPv6 default gateway instead of R1's link-local address, `fe80::1`.

Resolution: Corrected PC-B's IPv6 gateway to `fe80::1` and repeated the end-to-end test.

![IPv6 restored](ipv6-restored.png)

## Verification

| Test | Result |
| --- | --- |
| PC-A to PC-B IPv4 | Passed |
| PC-A to PC-B IPv6 before repair | Failed as designed |
| PC-A to PC-B IPv6 after repair | Passed |
| R1 routed interfaces | Up/up |
| R1 connected IPv6 routes | Present |

## Project files

- [Packet Tracer lab](dual-stack-office-recovery.pkt)
- [R1 final configuration](R1-final-config.txt)

## Skills demonstrated

- IPv4 and IPv6 interface addressing
- Link-local default gateway use
- Cisco IOS interface and route verification
- Layered troubleshooting and root-cause isolation
- Technical incident documentation

GitHub may show a confirmation panel before it saves the README.

  • Select Commit changes.
  • Confirm with Commit changes if GitHub presents the confirmation panel.

Before you verify, which files and evidence images do you expect the public repository to show?

  • Return to the repository's main page in Safari.
  • Confirm the file list contains dual-stack-office-recovery.pkt, topology.png, ipv6-failure.png, ipv6-restored.png, R1-final-config.txt, and README.md.
  • Scroll through the rendered README.

You should see the topology, failed IPv6 test, and restored IPv6 test rendered as images. The Packet Tracer lab and R1 configuration links should open their repository files.

Strong finish. Your restored network is now a reproducible incident case study that another person can inspect and run.

Secret mission

Recover an Administratively Down Interface

Your dual-stack network is healthy again. Now create an interface outage that breaks both protocols. Use router evidence to isolate the fault, restore service, and publish a second incident record.

Clean Up Your Resources

Clean Up Your Resources

Your Cisco Packet Tracer lab plus GitHub case study have no ongoing cost. Choose whether to keep everything available, pause the public case study, or delete the project resources.

Resources you used:

  • Local Packet Tracer lab file: dual-stack-office-recovery.pkt.
  • Local evidence screenshots: topology.png, ipv6-failure.png, and ipv6-restored.png.
  • Local router configuration file: R1-final-config.txt.
  • Public GitHub repository: packet-tracer-dual-stack-incident.

Keep everything running

Your operational lab remains available for another troubleshooting session. Your public case study stays ready to share.

  • Keep the packet-tracer-dual-stack-incident repository public.
  • Retain dual-stack-office-recovery.pkt in its current saved location.
  • Retain the three screenshots plus R1-final-config.txt in their current saved locations.

Pause - I'll come back to this later

Closing the simulator ends the active session. Making the repository private hides your case study while preserving every committed file.

  • Close Cisco Packet Tracer.
  • Return to the packet-tracer-dual-stack-incident repository on GitHub.
  • Select Settings in the repository navigation.
  • Scroll to Danger Zone.
  • Select Change repository visibility.
  • Select Change visibility.
  • Select Make this repository private.

Your case study is now private. Your local evidence stays ready for the next session.

Delete - I don't want to use this again

This path removes your public case study. It also moves your local project files to Trash.

  • Close Cisco Packet Tracer.
  • Return to the packet-tracer-dual-stack-incident repository on GitHub.
  • Select Settings in the repository navigation.
  • Select General.
  • Scroll to Danger Zone.
  • Select Delete this repository.
  • Acknowledge the deletion warnings.
  • Type packet-tracer-dual-stack-incident when GitHub requests the repository name.
  • Select Delete this repository to confirm the deletion.

The public repository is now removed. Finish the cleanup by clearing the local copies from their saved locations.

  • Locate dual-stack-office-recovery.pkt in Finder.
  • Locate topology.png, ipv6-failure.png, and ipv6-restored.png in Finder.
  • Locate R1-final-config.txt in Finder.
  • Move the five project files to Trash.
  • Confirm that the five files no longer appear in their saved locations.

That completes the cleanup. Your public repository is gone while your local files are now in Trash.

Nice Work!

Nice Work!

You did it! You built a working dual-stack office network in Cisco Packet Tracer. Your public GitHub case study now proves how you diagnosed two different outages with evidence.

You've learned how to:

  • Build a two-LAN office network with IPv4 and IPv6 addressing. You verified traffic across both routed links in Cisco Packet Tracer.
  • Apply evidence-led troubleshooting to isolate a wrong link-local default gateway on PC-B. You compared interface state, connected routes, host settings, and ping results. That evidence led you to repair the IPv6 path without changing the working IPv4 path.
  • Publish a reproducible incident case study in GitHub. Your repository includes dual-stack-office-recovery.pkt, before-and-after screenshots, R1-final-config.txt, and a rendered README.md.
  • Secret Mission: Diagnose an administratively down interface from router output. You restored both protocols. You documented the second outage in incident-2.md.

Ready to quiz yourself?