Build a Resilient Enterprise Campus Network

Design a fault-tolerant campus network with HSRP, EtherChannel, OSPF, and QoS.

Introduction

30 Second Summary

When a company's network goes down, everything stops. Enterprise networks solve this by building in backup paths that activate automatically when something breaks.

In this project, you will build a fully simulated enterprise campus network in Cisco Packet Tracer that self-heals when links fail, blocks unauthorized traffic between departments, and prioritizes voice calls over bulk downloads.

What You'll Build

When you finish, you can pull a cable out of any switch and watch traffic seamlessly reroute through the backup path with zero disruption to any host on the network.

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

  • Two departments on separate VLANs with hosts that reach a shared server through redundant paths. You can disable a distribution switch and watch traffic re-route automatically through the standby gateway with HSRP failover.
  • Extended ACLs blocking unauthorized cross-department access while permitting all other traffic. You can ping from Sales to the server successfully, then try from Engineering and see the request denied.
  • QoS policies that classify and mark voice traffic as priority, ensuring real-time communication is never starved by bulk data transfers. You can verify the policy is active with a single show command.
  • Secret Mission: Add HSRP interface tracking so the network detects upstream link failures and triggers intelligent failover even when the switch itself stays online.

Are there any prerequisites?

You should have basic familiarity with the Cisco IOS CLI, including configuring interfaces, VLANs, and simple routing. You also need a free Cisco Networking Academy account to download Packet Tracer.

If you have used Packet Tracer before and can navigate the IOS command line, you are ready to go.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. This is your chance to commit to the goal before any hands-on configuration begins.

Set Up the Topology in Packet Tracer

Every enterprise campus network starts with a solid physical foundation. Without the right devices in the right places and the right cables between them, none of the redundancy protocols you configure later will have anything to run on.

In this step, you will place all the devices for a three-tier campus architecture (core, distribution, access), cable them with redundant links, and configure the VLANs that segment your two departments.

In this step, get ready to:
  • Build the three-tier topology with all devices and cabling in Packet Tracer.
  • Create VLANs 10 and 20, assign access and trunk ports, and configure SVIs for inter-VLAN routing.
  • Verify all links are green and VLAN assignments are correct.
Place devices and build the three-tier topology

A three-tier campus design separates the network into core (high-speed backbone), distribution (policy and redundancy), and access (end-user connections) layers.

  • In Packet Tracer, click the Routers category in the device panel at the bottom of the screen.
  • Drag a 2911 router into the centre of the workspace. This is your Core router.
  • Click the router, go to the Config tab, and change the Display Name to Core.
  • Click the Switches category and drag two 3650-24PS multilayer switches below the Core router. Name them DSW1 (left) and DSW2 (right).
  • Drag two 2960 switches below the distribution layer. Name them ASW1 (left) and ASW2 (right).
  • Click the End Devices category. Drag two PCs below the access switches and name them PC-Sales (under ASW1) and PC-Eng (under ASW2).
  • Drag one Server near the Core router and name it Corp-Server.

Why a three-tier design?

Separating core, distribution, and access means each layer can be optimised for its job. The core handles fast switching between buildings. Distribution applies policy (ACLs, QoS, redundancy). Access connects end users.

This is the architecture Cisco recommends for campus networks with more than two distribution blocks.

Now connect the devices with copper straight-through cables. Select the Connections category (lightning bolt icon) and choose Copper Straight-Through.

  • Connect DSW1 GigabitEthernet1/0/1 to Core GigabitEthernet0/0.
  • Connect DSW1 GigabitEthernet1/0/2 to Core GigabitEthernet0/1. These two links will form an EtherChannel in the next step.
  • Connect DSW2 GigabitEthernet1/0/1 to Core GigabitEthernet0/2.

What about the second link to DSW2?

The 2911 router only has three built-in GigabitEthernet ports. You need to add a hardware module for the fourth uplink.

You will power off the router, install a HWIC-4ESW module, then power it back on. This gives the router additional FastEthernet ports you can use for the second link to DSW2.

  • Click the Core router, then click the Physical tab.
  • Click the power switch on the router image to turn it off.
  • From the module list on the left, find HWIC-4ESW and drag it into an empty EHWIC slot on the router.
  • Click the power switch again to turn the router back on.
  • Now connect DSW2 GigabitEthernet1/0/2 to Core FastEthernet0/1/0 (the first port on the HWIC-4ESW module).

Continue cabling the rest of the topology:

  • Connect DSW1 GigabitEthernet1/0/23 to ASW1 GigabitEthernet0/1.
  • Connect DSW1 GigabitEthernet1/0/24 to ASW2 GigabitEthernet0/1.
  • Connect DSW2 GigabitEthernet1/0/23 to ASW1 GigabitEthernet0/2.
  • Connect DSW2 GigabitEthernet1/0/24 to ASW2 GigabitEthernet0/2.
  • Connect PC-Sales FastEthernet0 to ASW1 FastEthernet0/1.
  • Connect PC-Eng FastEthernet0 to ASW2 FastEthernet0/1.
  • Connect Corp-Server FastEthernet0 to Core FastEthernet0/1/1 (the second port on the HWIC-4ESW module).

Wait a few seconds for all link indicators to turn green. All links should show green (up/up) in the topology view.

Seeing orange or red link lights?

Orange means the port is in STP blocking or listening state. Wait 30 seconds for STP to converge. Red means the interface is shut down. Click the device, go to CLI, and run no shutdown on the interface. Router ports are administratively shut down by default.

If a cable connection option is greyed out, make sure you turned the router back on after installing the HWIC module. help me troubleshoot why my links are not coming up

Configure VLANs and assign ports on the distribution switches

With the physical topology in place, you need to create the logical segmentation. VLAN 10 (Sales) and VLAN 20 (Engineering) will separate department traffic.

  • Click DSW1, then click the CLI tab. Press Enter to get a prompt.
  • Configure VLANs, trunk ports, SVIs, and enable routing on DSW1 by entering these commands:
enable
configure terminal
vlan 10
name Sales
exit
vlan 20
name Engineering
exit
interface GigabitEthernet1/0/23
switchport mode trunk
exit
interface GigabitEthernet1/0/24
switchport mode trunk
exit
ip routing
interface Vlan 10
ip address 10.10.10.2 255.255.255.0
no shutdown
exit
interface Vlan 20
ip address 10.10.20.2 255.255.255.0
no shutdown
exit
end

What does this configuration do?

You create two VLANs (10 for Sales, 20 for Engineering), then set the downlinks to the access switches as trunks so both VLANs can traverse those links.

The ip routing command enables Layer 3 routing on the multilayer switch. The SVIs (interface Vlan 10 and interface Vlan 20) give each VLAN a gateway IP address so devices in those VLANs can reach other networks.

  • Verify the VLANs were created on DSW1 by running:
show vlan brief

You should see VLAN 10 (Sales) and VLAN 20 (Engineering) listed alongside the default VLANs.

  • Now click DSW2, open the CLI tab, and enter the equivalent configuration:
enable
configure terminal
vlan 10
name Sales
exit
vlan 20
name Engineering
exit
interface GigabitEthernet1/0/23
switchport mode trunk
exit
interface GigabitEthernet1/0/24
switchport mode trunk
exit
ip routing
interface Vlan 10
ip address 10.10.10.3 255.255.255.0
no shutdown
exit
interface Vlan 20
ip address 10.10.20.3 255.255.255.0
no shutdown
exit
end

Why different IPs on DSW2?

DSW1 uses 10.10.10.2 and DSW2 uses 10.10.10.3 on the same VLAN. Each switch needs its own unique real IP address. In Step 3, you will configure a shared virtual IP (10.10.10.1) with HSRP that floats between them for gateway redundancy.

Configure VLANs and ports on the access switches
  • Click ASW1, open the CLI tab, and configure it:
enable
configure terminal
vlan 10
name Sales
exit
vlan 20
name Engineering
exit
interface FastEthernet0/1
switchport mode access
switchport access vlan 10
exit
interface GigabitEthernet0/1
switchport mode trunk
exit
interface GigabitEthernet0/2
switchport mode trunk
exit
end

What does this do on the access switch?

The PC-Sales port (FastEthernet0/1) is set to access mode in VLAN 10, so only Sales traffic flows to that host. The uplinks to DSW1 and DSW2 (GigabitEthernet0/1 and GigabitEthernet0/2) are trunks carrying all VLANs up to the distribution layer.

  • Click ASW2, open the CLI tab, and configure it:
enable
configure terminal
vlan 10
name Sales
exit
vlan 20
name Engineering
exit
interface FastEthernet0/1
switchport mode access
switchport access vlan 20
exit
interface GigabitEthernet0/1
switchport mode trunk
exit
interface GigabitEthernet0/2
switchport mode trunk
exit
end
  • Finally, configure Corp-Server with a static IP. Click Corp-Server, go to the Desktop tab, and select IP Configuration.
  • Set the IPv4 Address to 10.10.30.10 and Subnet Mask to 255.255.255.0.
Verify the topology and VLAN configuration

Before you run this verification command, what do you expect to see in the VLAN listing for ASW1?

  • Click ASW1, open the CLI tab, and run:
show vlan brief

You should see VLAN 10 listed with Fa0/1 (the PC-Sales port) assigned to it. VLAN 20 should appear with no access ports assigned on this switch.

  • Check the topology view. All physical links between devices should show green indicators, meaning up/up status.

VLAN not showing or port not assigned?

If show vlan brief does not list VLAN 10, you may have forgotten to create it on ASW1. Re-enter configure terminal and run vlan 10 again.

If Fa0/1 is not under VLAN 10, verify you entered switchport access vlan 10 on that interface. Run show running-config interface FastEthernet0/1 to confirm. Help me figure out why my VLAN assignment is not showing up on ASW1

Your physical and logical foundation is in place. Next up, you will bundle those redundant links into EtherChannels and enable Rapid PVST+ to prevent loops while maximising bandwidth.

Build the Redundant Foundation with EtherChannel and Rapid PVST+

Your topology has two physical links running from each distribution switch up to the Core router. Right now, Spanning Tree Protocol sees these parallel links and blocks one to prevent loops. That means half your uplink bandwidth is sitting idle.

EtherChannel solves this by bundling both physical links into a single logical link. Rapid PVST+ then ensures any remaining redundant paths in the topology converge quickly if a topology change occurs.

In this step, get ready to:
  • Configure LACP EtherChannel on DSW1, DSW2, and the Core router.
  • Enable Rapid PVST+ and designate DSW1 as the STP root bridge.
  • Test that the EtherChannel survives a single link failure.
Configure LACP EtherChannel on DSW1

LACP (Link Aggregation Control Protocol) negotiates the bundle dynamically. Both ends must be set to active mode so they initiate negotiation with each other.

Identify your uplink interfaces

In the Packet Tracer topology view, hover your mouse over each end of the two cables connecting DSW1 to the Core router. A tooltip shows the interface name (for example, GigabitEthernet1/0/1). Note both interface names. The commands below use GigabitEthernet1/0/1 and GigabitEthernet1/0/2 as examples. Substitute your actual interfaces if they differ.

  • Click DSW1 in the topology, open the CLI tab, and configure the EtherChannel by entering these commands:
enable
configure terminal
interface range GigabitEthernet1/0/1-2
channel-group 1 mode active
exit
interface Port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk
end

What do these commands do?

  • channel-group 1 mode active assigns both physical ports to channel-group 1 using LACP in active negotiation mode.
  • The interface Port-channel1 block configures the logical bundle as an 802.1Q trunk so VLAN traffic can traverse the uplink.
  • Verify the EtherChannel formed on DSW1 by running:
show etherchannel summary

You should see Po1 listed with status (SU) and both member interfaces marked with P (bundled in port-channel). The protocol column shows LACP.

Port-channel showing (SD) or members showing (D)?

  • Make sure you used the correct interface names. Re-check by hovering over the cables in the topology view.
  • Confirm both member interfaces are physically up (green link in the topology). If a link shows orange, check the cable connection.
  • The Core router side is not configured yet. The port-channel may show (SD) until you configure the matching channel-group on the Core router in the next chunk.

Help me troubleshoot my EtherChannel on DSW1 in Packet Tracer. The port-channel is not coming up.

Configure LACP EtherChannel on DSW2 and the Core router

DSW2 uses the same approach but with channel-group 2 to keep it distinct. The Core router needs matching channel-groups on its side of each link pair.

  • Click DSW2, open the CLI tab, and configure its EtherChannel by entering:
enable
configure terminal
interface range GigabitEthernet1/0/1-2
channel-group 2 mode active
exit
interface Port-channel2
switchport trunk encapsulation dot1q
switchport mode trunk
end
  • Verify on DSW2 by running show etherchannel summary. You should see Po2(SU) with both members marked P.

Now configure the Core router. Hover over the cables in the topology to identify which Core interfaces connect to DSW1 and which connect to DSW2.

  • Click the Core router, open the CLI tab, and configure both channel-groups by entering:
enable
configure terminal
interface range GigabitEthernet0/0/0-1
channel-group 1 mode active
exit
interface range GigabitEthernet0/1/0-1
channel-group 2 mode active
end

What do these commands do?

Channel-group 1 on the Core matches channel-group 1 on DSW1. Channel-group 2 matches DSW2. Because both sides use mode active, LACP negotiates and brings the bundles up automatically.

The interface names (GigabitEthernet0/0/0-1 and GigabitEthernet0/1/0-1) are examples based on a 2911 with module slots. Substitute your actual interface names based on the tooltip hover in the topology view.

  • On the Core router, verify both EtherChannels by running:
show etherchannel summary

You should see two port-channels listed (Po1 and Po2) with their respective member interfaces marked P.

EtherChannel not forming between switch and router?

  • Both sides must use the same LACP mode. Confirm you typed channel-group X mode active on both the switch and the router.
  • The channel-group number does NOT need to match across devices. DSW1 uses group 1 and the Core also uses group 1 for those links. DSW2 uses group 2 and the Core uses group 2. What matters is that both ends of the same physical link pair share a mode.
  • If you see ports in (I) stand-alone state, verify the physical cables connect the correct interfaces on each device.

Help me troubleshoot why my EtherChannel between the Core router and DSW1 is not forming in Packet Tracer.

Enable Rapid PVST+ and set DSW1 as the STP root

With EtherChannel handling the bundled uplinks, Spanning Tree still runs on the remaining redundant paths (like the access-to-distribution links). Rapid PVST+ converges in under 6 seconds compared to the classic 50-second STP timer.

  • On DSW1, enable Rapid PVST+ and set it as root for both VLANs by entering:
enable
configure terminal
spanning-tree mode rapid-pvst
spanning-tree vlan 10,20 root primary
end
  • On DSW2, enable Rapid PVST+ (but do not set it as root) by entering:
enable
configure terminal
spanning-tree mode rapid-pvst
end

Why make DSW1 the root?

Placing the STP root at the distribution layer aligns forwarding paths with the HSRP active router you will configure in the next step. Traffic flows through DSW1 by default for both Layer 2 forwarding (STP) and Layer 3 routing (HSRP), avoiding suboptimal paths.

  • Confirm DSW1 is root by running this on DSW1:
show spanning-tree vlan 10

Look for This bridge is the root in the output. This confirms DSW1 won the STP root election for VLAN 10.

Test EtherChannel link failure resilience

The real value of EtherChannel is that it survives individual link failures without dropping traffic. Time to prove it.

  • Before you test, predict: if you shut down one of the two physical member links on DSW1, will the port-channel stay up or go down?
  • On DSW1, shut down one member interface to simulate a cable failure:
enable
configure terminal
interface GigabitEthernet1/0/1
shutdown
end
  • Run show etherchannel summary on DSW1 again.

The port-channel Po1 stays up because one member link is still active. You will see one interface marked (D) for down and the other still marked (P).

  • Now test end-to-end connectivity. Open the Desktop tab on PC-Sales, launch Command Prompt, and ping Corp-Server:
ping 10.10.30.10

The ping should succeed. Traffic routes through the surviving EtherChannel member link transparently.

  • Bring the interface back up so you are ready for the next step:
enable
configure terminal
interface GigabitEthernet1/0/1
no shutdown
end

Ping to Corp-Server fails even with the link up?

  • Verify that PC-Sales has an IP address in the 10.10.10.0/24 subnet and a default gateway set to the DSW1 SVI address (10.10.10.2).
  • Confirm the Core router has an IP address on the interface connecting to Corp-Server in the same subnet (10.10.30.0/24). Also ensure Corp-Server has its gateway pointing to the Core.
  • Check that ip routing is still enabled on DSW1 by running show ip route. If you see no routes toward 10.10.30.0, add a temporary static route (ip route 10.10.30.0 255.255.255.0 followed by the Core router's port-channel IP) until OSPF is configured in Step 4.

Help me troubleshoot why PC-Sales cannot ping Corp-Server through the EtherChannel in my Packet Tracer topology.

Your redundant link foundation is locked in. EtherChannel doubles your uplink bandwidth and survives cable failures. Rapid PVST+ keeps loop-free convergence fast. Next up, you will add HSRP so that even if an entire distribution switch fails, hosts never lose their default gateway.

Configure HSRP for Gateway Redundancy

Your EtherChannel bundles protect against individual link failures. But what happens if an entire distribution switch goes down?

Right now, each PC has a single default gateway pointing to one specific switch. If that switch fails, the PC has no way to reach the rest of the network. HSRP solves this by creating a virtual gateway IP shared between DSW1 and DSW2. Hosts point to the virtual IP, and HSRP handles which physical switch answers.

In this step, get ready to:
  • Configure HSRP version 2 on both distribution switches with DSW1 as the active router.
  • Set PC default gateways to the HSRP virtual IPs and add routing toward Corp-Server.
  • Test failover by shutting down DSW1's interface and confirming DSW2 takes over.
Configure HSRP on DSW1

DSW1 will be the active HSRP router because you will give it a higher priority (150) than DSW2's default of 100. The virtual gateway IP is what hosts will use as their default gateway.

  • Click on DSW1 in the topology, then go to the CLI tab.
  • Enter privileged exec mode and configure HSRP on both VLAN SVIs by running these commands:
enable
configure terminal
interface Vlan 10
 standby version 2
 standby 1 ip 10.10.10.1
 standby 1 priority 150
 standby 1 preempt
exit
interface Vlan 20
 standby version 2
 standby 2 ip 10.10.20.1
 standby 2 priority 150
 standby 2 preempt
exit
exit

What do these commands do?

Each VLAN SVI gets its own HSRP group. Group 1 protects VLAN 10's gateway, and group 2 protects VLAN 20's gateway.

  • standby version 2 enables HSRPv2, which supports a wider group range and includes the physical router's MAC in hello packets for easier troubleshooting.
  • standby 1 ip 10.10.10.1 sets the virtual IP that hosts will use as their default gateway. This IP is different from DSW1's real SVI address (10.10.10.2).
  • standby 1 priority 150 makes DSW1 preferred over DSW2 (which stays at the default priority of 100).
  • standby 1 preempt lets DSW1 reclaim the active role automatically if it recovers from a failure.
  • Verify HSRP is active on DSW1 by running:
show standby brief

You should see DSW1 listed as Active for both groups 1 and 2, with virtual IPs 10.10.10.1 and 10.10.20.1.

Not seeing Active state?

HSRP may take 10-30 seconds to stabilize after configuration. Wait a moment and run the command again. If you still see Init or Speak, ensure you configured the commands under interface Vlan 10 (an SVI), not under a physical switchport.

help me troubleshoot HSRP showing Init state on my 3650-24PS in Packet Tracer

Configure HSRP on DSW2 and set up routing

DSW2 acts as the standby router. It uses the same virtual IPs but keeps the default priority of 100, so it only becomes active when DSW1 is unavailable.

  • Click on DSW2 in the topology, then go to the CLI tab.
  • Configure HSRP on DSW2 by running these commands:
enable
configure terminal
interface Vlan 10
 standby version 2
 standby 1 ip 10.10.10.1
exit
interface Vlan 20
 standby version 2
 standby 2 ip 10.10.20.1
exit
exit

Why no priority or preempt on DSW2?

DSW2 uses the HSRP default priority of 100. Since DSW1 has priority 150, DSW1 always wins the active election. DSW2 does not need preempt because it only needs to become active when DSW1 disappears entirely.

  • Verify HSRP on DSW2 by running:
show standby brief

DSW2 should show Standby state for both groups, with the same virtual IPs as DSW1.

Now point the PCs to the virtual gateway and add a route so traffic can reach Corp-Server.

  • Click on PC-Sales in the topology.
  • Go to the Desktop tab, then click IP Configuration.
  • Set the IP address to 10.10.10.10, subnet mask to 255.255.255.0, and default gateway to 10.10.10.1 (the HSRP virtual IP).
  • Click on PC-Eng and repeat the process: set IP address to 10.10.20.10, subnet mask to 255.255.255.0, and default gateway to 10.10.20.1.

Why point to the virtual IP instead of a switch's real IP?

If you pointed PC-Sales at DSW1's real address (10.10.10.2) and DSW1 went down, the PC would lose connectivity. The virtual IP (10.10.10.1) is shared between both switches. HSRP ensures one switch always answers for that address, regardless of which physical switch is currently active.

Next, configure static routes on both distribution switches so they know how to reach Corp-Server's subnet (10.10.30.0/24) through the Core router. You also need to configure the Core router to reach the VLAN subnets.

  • On the Core router CLI, configure sub-interfaces so it can communicate with the distribution switches on VLAN 99 (a transit VLAN), then add return routes:
enable
configure terminal
interface GigabitEthernet0/0.99
 encapsulation dot1Q 99
 ip address 10.10.99.1 255.255.255.0
exit
interface GigabitEthernet0/1.99
 encapsulation dot1Q 99
 ip address 10.10.99.4 255.255.255.0
exit
ip route 10.10.10.0 255.255.255.0 10.10.99.2
ip route 10.10.20.0 255.255.255.0 10.10.99.2
exit

What is VLAN 99?

VLAN 99 is a dedicated transit VLAN that provides Layer 3 connectivity between the distribution switches and the Core router. The trunk links already carry this VLAN. The Core router uses sub-interfaces with encapsulation dot1Q 99 to tag and process these frames. This gives each side a routable IP address for the static route next-hop.

  • On DSW1 CLI, create VLAN 99 and its SVI, then add a static route pointing to Corp-Server's subnet:
enable
configure terminal
vlan 99
 name TRANSIT
exit
interface Vlan 99
 ip address 10.10.99.2 255.255.255.0
 no shutdown
exit
ip route 10.10.30.0 255.255.255.0 10.10.99.1
exit
  • On DSW2 CLI, do the same with a different SVI address:
enable
configure terminal
vlan 99
 name TRANSIT
exit
interface Vlan 99
 ip address 10.10.99.3 255.255.255.0
 no shutdown
exit
ip route 10.10.30.0 255.255.255.0 10.10.99.4
exit
  • Test connectivity by pinging Corp-Server from PC-Sales. Click on PC-Sales, go to the Desktop tab, and open Command Prompt.
  • Run the following ping:
ping 10.10.30.10

You should see replies from 10.10.30.10, confirming end-to-end connectivity through DSW1 to the Core and on to Corp-Server.

Ping to Corp-Server timing out?

  • Verify that PC-Sales has the correct default gateway (10.10.10.1) and that DSW1 shows Active in show standby brief.
  • Run show ip route on DSW1 to confirm the static route to 10.10.30.0 is present.
  • Confirm the Core router has a return route to 10.10.10.0 pointing at 10.10.99.2.
  • Check that VLAN 99 is allowed on the trunk between DSW1 and the Core by running show interfaces trunk on DSW1.

help me troubleshoot why my ping from PC-Sales to Corp-Server is timing out in my HSRP topology

Test HSRP failover

The real power of HSRP is seamless failover. You will now simulate a failure on DSW1 and confirm that DSW2 takes over the active gateway role without any change on the PCs.

Before you run the failover test, think about what you expect to happen. If you shut down DSW1's Vlan 10 interface, will DSW2 immediately become active, or will there be a delay?

  • On DSW1 CLI, shut down the VLAN 10 SVI to simulate DSW1 losing its gateway capability:
enable
configure terminal
interface Vlan 10
 shutdown
exit
exit
  • Quickly switch to DSW2 CLI and check its HSRP state:
show standby brief

DSW2 should now show Active for group 1. HSRP detected that DSW1's interface went down and promoted DSW2 within approximately 10 seconds (the default hold timer).

  • Confirm the failover works end-to-end. On PC-Sales Command Prompt, ping Corp-Server again:
ping 10.10.30.10

The ping should succeed. PC-Sales is still pointing at 10.10.10.1, but now DSW2 is answering for that virtual IP instead of DSW1.

What just happened?

When DSW1's VLAN 10 interface went down, it stopped sending HSRP hello packets. After the hold timer expired (10 seconds), DSW2 assumed the active role and began responding to ARP requests for 10.10.10.1 with the HSRP virtual MAC address. PC-Sales never needed a configuration change.

  • Restore DSW1 by bringing the interface back up. On DSW1 CLI:
enable
configure terminal
interface Vlan 10
 no shutdown
exit
exit
  • Verify DSW1 reclaims the active role by running:
show standby brief

DSW1 should return to Active state because preempt is enabled. DSW2 returns to Standby.

DSW1 not reclaiming Active?

Ensure you configured standby 1 preempt under interface Vlan 10 on DSW1 earlier. Without preempt, DSW1 will not take back the active role even though it has a higher priority. Re-enter the command and wait 10 seconds.

help me fix HSRP preemption not working on DSW1 in Packet Tracer

Your campus network now has gateway redundancy. If DSW1 goes down, DSW2 seamlessly takes over as the default gateway. Next up, you will replace those static routes with OSPF for dynamic, scalable routing that adapts automatically when the topology changes.

Add OSPF for Scalable Routing

Your distribution switches now have HSRP providing seamless gateway failover for both VLANs. But there is a gap in the routing plane: the static routes connecting your distribution layer to the Core router cannot adapt when topology changes.

If a link goes down, a static route keeps pointing traffic into a dead end. OSPF dynamically discovers routes and reconverges when topology changes, completing the fault-tolerant routing plane across all three tiers.

In this step, get ready to:
  • Enable OSPF process 1 on the Core router, DSW1, and DSW2.
  • Remove static routes and verify dynamic OSPF routing works end-to-end.
Enable OSPF on the Core router

OSPF needs to run on every device that participates in dynamic routing. You will start with the Core router because it connects to the Corp-Server subnet that the distribution switches need to learn about.

  • Click the Core router in your Packet Tracer topology and open the CLI tab.
  • Enable OSPF process 1 and advertise all connected 10.10.x.x networks into Area 0 by entering these commands:
enable
configure terminal
router ospf 1
network 10.10.0.0 0.0.255.255 area 0
exit
exit

What do these commands do?

  • router ospf 1 enables OSPF routing with process ID 1.
  • network 10.10.0.0 0.0.255.255 area 0 tells OSPF to activate on every interface whose IP falls within the 10.10.0.0/16 range, placing them all into the backbone area (Area 0).
  • This single statement covers the Corp-Server subnet (10.10.30.0/24) and the port-channel interfaces toward DSW1 and DSW2.
Enable OSPF on DSW1 and DSW2

Both distribution switches need the same OSPF configuration so they can form adjacencies with the Core and advertise their VLAN SVI subnets.

  • Click DSW1 in your topology and open the CLI tab.
  • Enter the OSPF configuration:
enable
configure terminal
router ospf 1
network 10.10.0.0 0.0.255.255 area 0
exit
exit
  • Now click DSW2 and open its CLI tab.
  • Enter the same OSPF configuration:
enable
configure terminal
router ospf 1
network 10.10.0.0 0.0.255.255 area 0
exit
exit

Why the same network statement on all three devices?

The wildcard mask 0.0.255.255 matches all interfaces in the 10.10.x.x range. On DSW1, that activates OSPF on the VLAN 10 SVI (10.10.10.2), VLAN 20 SVI (10.10.20.2), and the port-channel uplink to the Core.

Once both sides of a link run OSPF in the same area, they automatically form a neighbor adjacency and exchange route information.

  • Verify that OSPF adjacencies have formed by running this command on DSW1:
show ip ospf neighbor

You should see the Core router listed with a State of FULL. This confirms the two devices have fully synchronized their link-state databases.

Not seeing a FULL neighbor?

  • Wait 10-15 seconds and run the command again. OSPF needs time to exchange Hello packets and synchronize databases.
  • Confirm you typed network 10.10.0.0 0.0.255.255 area 0 on both the Core router and DSW1. A mismatched area number prevents adjacency.
  • Check that the port-channel interface between DSW1 and Core is up (green link in the topology view).

Still stuck? Help me troubleshoot my OSPF neighbor adjacency.

Remove static routes and verify OSPF routing

With OSPF running on all three devices, the routing tables now contain dynamically learned routes. Any static routes from earlier are redundant and could cause confusion if they disagree with OSPF.

  • On DSW1, check if any static routes exist by running:
show ip route static
  • If you see a static route pointing to the 10.10.30.0 network (Corp-Server subnet), remove it. Enter global configuration mode and negate the route. For example, if your static route was ip route 10.10.30.0 255.255.255.0 followed by a next-hop IP, prepend no to remove it:
enable
configure terminal
no ip route 10.10.30.0 255.255.255.0 10.10.40.1
exit

What if my next-hop IP is different?

Replace 10.10.40.1 with whatever next-hop address appears in your show ip route static output. If show ip route static returns nothing, you have no static routes to remove and can skip this command.

  • Repeat the same check and removal on DSW2.
  • Also check the Core router for static routes pointing to the VLAN subnets and remove any you find.

Now confirm that OSPF has taken over routing duties. Before you run the verification command, think about what you expect to see. Do you think DSW1 already knows how to reach the 10.10.30.0/24 (Corp-Server) subnet via OSPF?

  • On DSW1, run:
show ip route ospf

You should see at least one route marked with O pointing to the 10.10.30.0/24 subnet via the Core router. The [110/X] values show the OSPF administrative distance (110) and the metric (cost) to reach that network.

What does the O code mean?

In Cisco IOS routing tables, O means the route was learned via OSPF intra-area routing. O IA would mean inter-area. Since all your devices share Area 0, you will see plain O routes.

  • Now test end-to-end connectivity. On PC-Sales, open the Desktop tab and click Command Prompt.
  • Ping Corp-Server by running:
ping 10.10.30.10
  • Repeat the ping from PC-Eng's Command Prompt:
ping 10.10.30.10

Both pings should succeed with replies from 10.10.30.10. This confirms OSPF is dynamically routing traffic from both VLANs through the campus backbone to Corp-Server.

Pings timing out?

  • Run show ip route ospf on DSW2 as well. If it shows no OSPF routes, double-check that you entered router ospf 1 and the network statement on DSW2.
  • Confirm Corp-Server's default gateway is set to the Core router's interface IP (the interface on the 10.10.30.0/24 subnet).
  • Check that no leftover static routes are overriding OSPF. Static routes have a lower administrative distance (1 vs 110) and win by default.

Need more help? Help me debug why pings to Corp-Server are failing after configuring OSPF.

Your campus network now has a fully dynamic routing plane. Every device discovers its neighbors automatically and recalculates paths when something changes. Next up, you will add the security and QoS layers that turn this functional network into a production-ready one.

Secure and Prioritize Traffic with ACLs and QoS

Your campus network now has full dynamic routing with OSPF, and traffic flows seamlessly between all subnets. But there is a problem: every host can reach every resource.

In a real enterprise, the Engineering team should not be able to access the Sales department's server. And a large file transfer should never be allowed to starve a voice or video call. This step adds the security and traffic management layers that turn a functioning network into a production-ready one.

In this step, get ready to:
  • Create an extended ACL that blocks Engineering hosts from reaching Corp-Server.
  • Configure MQC-based QoS policies that classify and prioritize voice traffic.
  • Verify that security and prioritization are enforced end-to-end.
Create the extended ACL for inter-VLAN security

An extended ACL lets you filter traffic based on source address, destination address, and protocol. You will create one that denies the entire Engineering subnet from reaching Corp-Server, while permitting everything else.

  • Click on DSW1 in the topology to open it.
  • Switch to the CLI tab.
  • Create the extended ACL and apply it to the VLAN 20 SVI by entering these commands:
enable
configure terminal
ip access-list extended BLOCK-ENG-TO-SERVER
deny ip 10.10.20.0 0.0.0.255 host 10.10.30.10
permit ip any any
exit
interface Vlan 20
ip access-group BLOCK-ENG-TO-SERVER in
end

What do these commands do?

The ip access-list extended command creates a named ACL that can match on both source and destination.

The deny ip 10.10.20.0 0.0.0.255 host 10.10.30.10 line blocks any traffic from the Engineering subnet (10.10.20.0/24) destined for Corp-Server. The permit ip any any ensures all other traffic still flows normally.

Applying the ACL inbound on the Vlan 20 SVI means traffic is filtered right as it arrives from Engineering hosts, before it can be routed anywhere.

Before you think about what will happen, what do you predict a ping from PC-Eng to Corp-Server will show now?

  • Click on PC-Eng in the topology.
  • Switch to the Desktop tab, then open Command Prompt.
  • Test connectivity to Corp-Server by running:
ping 10.10.30.10

The ping should time out with Request timed out messages. The ACL on DSW1 is blocking this traffic as intended.

  • Now confirm that Sales traffic is unaffected by clicking on PC-Sales and opening the Command Prompt from the Desktop tab.
  • Test connectivity by running:
ping 10.10.30.10

This ping should succeed with replies from 10.10.30.10. The ACL only blocks Engineering traffic.

PC-Sales ping also failing?

Check that your ACL includes the permit ip any any line. Without it, Cisco's implicit deny-all at the end of every ACL blocks everything.

Also verify the ACL is applied on interface Vlan 20 only, not on Vlan 10. Run show running-config interface Vlan 20 on DSW1 to confirm.

Help me troubleshoot my ACL configuration on DSW1.

Now apply the same ACL on DSW2 so the block holds even during an HSRP failover.

  • Click on DSW2 and switch to the CLI tab.
  • Enter the same ACL configuration:
enable
configure terminal
ip access-list extended BLOCK-ENG-TO-SERVER
deny ip 10.10.20.0 0.0.0.255 host 10.10.30.10
permit ip any any
exit
interface Vlan 20
ip access-group BLOCK-ENG-TO-SERVER in
end

Why configure the ACL on both switches?

If DSW1 goes down, HSRP makes DSW2 the active gateway for VLAN 20. Without the ACL on DSW2, Engineering hosts would bypass the security policy during failover. Applying it to both distribution switches ensures the policy survives any single-device failure.

Configure MQC QoS for voice traffic priority

The Modular QoS CLI (MQC) framework uses three constructs: a class-map to classify traffic, a policy-map to define what happens to that traffic, and a service-policy to attach it to an interface. You will mark voice traffic with DSCP EF (Expedited Forwarding) so it receives priority treatment across the network.

  • Return to DSW1's CLI tab.
  • Configure the QoS class-map, policy-map, and apply the service-policy by entering these commands:
enable
configure terminal
class-map match-any VOICE
match ip dscp ef
exit
policy-map QOS-POLICY
class VOICE
set ip dscp ef
exit
exit
interface Port-channel1
service-policy input QOS-POLICY
end

What does this QoS configuration do?

The class-map match-any VOICE creates a traffic class that matches any packet already marked with DSCP EF (the standard marking for voice traffic).

The policy-map QOS-POLICY defines the action: when traffic matches class VOICE, set (or confirm) its DSCP value to EF for priority treatment at every hop.

Applying service-policy input on the port-channel uplink means traffic is classified as it enters the distribution switch from the core.

  • Verify the QoS policy is attached by running:
show policy-map interface Port-channel1

You should see the policy name QOS-POLICY listed with class VOICE shown beneath it. This confirms the policy is active on the interface.

QoS policy not showing on the port-channel?

Verify you typed the interface name correctly. Run show etherchannel summary to confirm the port-channel number on DSW1 (it should be Po1).

If Packet Tracer rejects the service-policy on the port-channel, apply it to the physical member interfaces instead. Some Packet Tracer versions require QoS on individual interfaces rather than the logical bundle.

Help me apply my QoS policy in Packet Tracer.

Now apply the same QoS configuration on DSW2.

  • Click on DSW2 and switch to the CLI tab.
  • Enter the QoS configuration:
enable
configure terminal
class-map match-any VOICE
match ip dscp ef
exit
policy-map QOS-POLICY
class VOICE
set ip dscp ef
exit
exit
interface Port-channel2
service-policy input QOS-POLICY
end
  • Confirm the policy is attached by running:
show policy-map interface Port-channel2

You should see QOS-POLICY listed with the VOICE class, just like on DSW1.

Verify ACLs and QoS are working end-to-end

Everything is configured. Time to run the final verification across all your security and QoS policies.

Before you run the tests below, predict: which PC will successfully ping Corp-Server, and which will be blocked?

  • Click on PC-Eng and open the Command Prompt from the Desktop tab.
  • Run the ping:
ping 10.10.30.10

The ping times out. The extended ACL is blocking Engineering from reaching Corp-Server.

  • Now click on PC-Sales and open the Command Prompt.
  • Run the same ping:
ping 10.10.30.10

This ping succeeds with replies from Corp-Server. Sales traffic passes through freely because the ACL only targets the Engineering subnet.

  • Return to DSW1's CLI to check the ACL hit counters by running:
show access-lists

Look at the deny line. You should see a non-zero match count in parentheses, confirming the ACL actively blocked packets from Engineering.

What do the match counts tell you?

Each time a packet hits a deny or permit rule, the counter increments. A non-zero count on the deny line proves the ACL intercepted real traffic from 10.10.20.0/24 headed for Corp-Server. If the permit line also has hits, that confirms other legitimate traffic (like Sales pings) is passing through normally.

Deny line showing zero matches?

If HSRP routed your test ping through DSW2 instead of DSW1, the hit count will appear on DSW2 rather than DSW1. Run show access-lists on DSW2 as well and check for matches there.

Also confirm that PC-Eng's default gateway is 10.10.20.1 (the HSRP virtual IP) and not a physical switch IP.

Help me figure out why my ACL hit count is zero.

✔️ Awesome, I've got everything!

Great work. Make sure you have saved your Packet Tracer topology.

ⓧ I'd like to double check the full configuration

Scroll up and confirm each of the following configuration chunks is present in your topology, in order:

  • DSW1: Extended ACL BLOCK-ENG-TO-SERVER with deny and permit lines, applied inbound on interface Vlan 20.
  • DSW2: Same extended ACL BLOCK-ENG-TO-SERVER with deny and permit lines, applied inbound on interface Vlan 20.
  • DSW1: Class-map VOICE, policy-map QOS-POLICY, and service-policy input QOS-POLICY on Port-channel1.
  • DSW2: Same class-map, policy-map, and service-policy input QOS-POLICY on Port-channel2.

On each switch you can run show running-config and search for BLOCK-ENG-TO-SERVER and QOS-POLICY to confirm they appear.

Your campus network now enforces security boundaries between departments and has QoS policies ready to prioritize voice traffic. These are the same production patterns that enterprise networks use to protect sensitive resources and guarantee call quality.

Ready for a bonus challenge? In the Secret Mission, you will add HSRP interface tracking so the active router automatically yields the gateway role when its uplink to the core fails.

Secret mission

Add HSRP Interface Tracking for Intelligent Failover

Your HSRP failover works when the active switch goes completely down. But what happens when DSW1 stays up but loses its uplink to the core? Right now, hosts keep routing through a distribution switch that has no path forward. Add interface tracking so HSRP responds to upstream link failures, not just device failures.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally in Cisco Packet Tracer, so there are no ongoing costs or cloud resources to manage. Decide whether to keep your topology file, save it for later, or delete it entirely.

Resources you used:

  • Your Packet Tracer topology file (.pkt) containing the full three-tier campus network with all device configurations.

Keep everything running

No action needed. Choose this if you are still actively building or want to keep practising failover scenarios.

  • Your topology stays open in Packet Tracer with zero cost.
  • You can continue experimenting with HSRP tracking values, adding new VLANs, or testing additional failure scenarios.
  • Save your work periodically with Ctrl+S to avoid losing progress.

Pause - I'll come back to this later

Save your topology file and close Packet Tracer to free up memory. You can reopen it anytime to pick up where you left off.

  • Press Ctrl+S to save your topology. Choose a location you can find easily, such as your Desktop.
  • Note the filename and location so you can reopen it later.
  • Close Packet Tracer. All device configurations are preserved inside the .pkt file.
  • To resume, open Packet Tracer and use File then Open to load your saved topology.

Delete - I don't want to use this again

Remove the topology file from your system entirely. You can always rebuild the network from scratch using this project.

  • If Packet Tracer is still open, close it without saving (click Don't Save when prompted).
  • If you already saved the .pkt file, delete it from your file system.

On Windows, open File Explorer, navigate to the folder where you saved the file, right-click the .pkt file, and select Delete.

On macOS or Linux, open a terminal and run:

rm ~/Desktop/your-topology-file.pkt

What about Packet Tracer itself?

Packet Tracer was already installed on your machine before this project. You do not need to uninstall it. It takes no ongoing resources when closed.

Nice Work!

Nice Work!

You just built a fully redundant enterprise campus network from the ground up. Your three-tier topology self-heals when links fail, blocks unauthorized traffic between departments, and prioritizes voice packets over bulk data.

Here's what you accomplished:

  • Built a complete three-tier campus network with EtherChannel (LACP) bundling redundant links and HSRP providing seamless default gateway failover between distribution switches.
  • Deployed multi-area OSPF for dynamic scalable routing, extended ACLs for inter-VLAN security, and MQC QoS policies that classify and mark voice traffic for priority treatment.
  • Tested live failover scenarios by shutting down interfaces and pulling links, proving the network self-heals with zero host-side disruption.
  • Secret Mission: Added HSRP interface tracking for intelligent failover that responds to upstream link failures, not just device failures.

Ready to quiz yourself?