Build a Secure Multi-Site Network

Configure OSPF, VLANs, and ACLs in a two-site enterprise network simulation.

Introduction

30 Second Summary

Every time you send a message to a coworker in another office, your data crosses routers, switches, and security filters that someone had to design and configure. Network engineers build these invisible highways that keep entire companies connected and secure.

In this project, you will build a two-site enterprise network in Cisco Packet Tracer, segment departments into VLANs, route between sites with multi-area OSPF, and enforce security policies with Access Control Lists.

What You'll Build

A simulated enterprise network connecting a headquarters and branch office through a core router, with full VLAN segmentation, inter-VLAN routing, OSPF-based reachability, and ACL-enforced security.

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

  • Full VLAN segmentation with 802.1Q trunking and router-on-a-stick inter-VLAN routing at both sites.
  • Multi-area OSPF configuration with an Area Border Router providing full inter-site connectivity.
  • Named ACLs enforcing security policies that restrict cross-department access and secure the management plane.
  • Secret Mission: Harden your WAN links with OSPF MD5 authentication and optimize inter-area routing with route summarization.

Are there any prerequisites?

This project assumes an intermediate understanding of IP addressing and subnetting. You should also have basic familiarity with the Cisco IOS CLI (navigating between modes, entering commands).

Build the Topology and Configure Base Settings

Every enterprise network starts with a solid physical foundation. Before configuring routing protocols or security policies, you need devices in place, cables connected, and baseline security applied to every piece of equipment.

In this step, you will build the two-site topology in Cisco Packet Tracer, apply hardening baselines to each device, and document an IP addressing scheme that will carry you through the rest of the project.

In this step, get ready to:
  • Place routers, switches, and PCs, then cable them into a two-site topology.
  • Apply base security settings (hostnames, passwords, banners) on all network devices.
  • Design and document your IP addressing scheme for all VLANs and WAN links.
Build the physical topology in Packet Tracer

Your network will consist of two sites (HQ and Branch) connected through a core router. Each site has its own switch and end devices representing different departments.

  • In your Packet Tracer workspace, click Network Devices at the bottom of the screen, then select Routers.
  • Find the 4331 ISR router in the list and drag three of them onto the workspace.
  • Space them horizontally with room for switches and PCs below.
  • Click each router and open the Config tab.
  • Set the display names to R1-HQ, R2-Core, and R3-Branch.

Why the 4331 ISR?

The 4331 has GigabitEthernet interfaces that support subinterfaces. You will need subinterfaces later for router-on-a-stick inter-VLAN routing.

The interface naming uses three numbers separated by slashes (slot/subslot/port), so the first two ports are GigabitEthernet0/0/0 and GigabitEthernet0/0/1.

  • Click Network Devices, then select Switches.
  • Drag two 2960 switches onto the workspace below R1-HQ and R3-Branch.
  • Rename them SW1-HQ and SW2-Branch in the Config tab.
  • Click End Devices at the bottom and drag five PCs onto the workspace.
  • Rename them: PC-Mgmt-HQ, PC-Sales-HQ, Server-HQ, PC-Mgmt-Branch, and PC-Ops-Branch.
  • Place the three HQ PCs below SW1-HQ and the two Branch PCs below SW2-Branch.

Now you need to cable all the connections. Use Copper Straight-Through cables for switch-to-PC and router-to-switch connections. Use Copper Cross-Over cables for router-to-router WAN links.

  • Click the lightning bolt icon (Connections) at the bottom of the workspace.
  • Select Copper Straight-Through cable.
  • Connect R1-HQ GigabitEthernet0/0/0 to SW1-HQ GigabitEthernet0/1. This is the HQ trunk link.
  • Connect R3-Branch GigabitEthernet0/0/0 to SW2-Branch GigabitEthernet0/1. This is the Branch trunk link.
  • Now select Copper Cross-Over cable for the WAN links.
  • Connect R1-HQ GigabitEthernet0/0/1 to R2-Core GigabitEthernet0/0/0.
  • Connect R2-Core GigabitEthernet0/0/1 to R3-Branch GigabitEthernet0/0/1.
  • Switch back to Copper Straight-Through for the PC connections.
  • Connect SW1-HQ FastEthernet0/1 to PC-Mgmt-HQ.
  • Connect SW1-HQ FastEthernet0/2 to PC-Sales-HQ.
  • Connect SW1-HQ FastEthernet0/3 to Server-HQ.
  • Connect SW2-Branch FastEthernet0/1 to PC-Mgmt-Branch.
  • Connect SW2-Branch FastEthernet0/2 to PC-Ops-Branch.

After a few seconds, the link lights between switches and PCs should turn green. The router links will stay red or orange until interfaces are enabled in later steps.

Links showing red between switch and PCs?

Make sure you used Copper Straight-Through cables (not cross-over) for switch-to-PC connections. If you picked the wrong cable type, click the connection, delete it, and re-cable with the correct type.

Also confirm you connected to the correct port numbers. PC ports only have one option (FastEthernet0), but switches have many ports to choose from.

Still stuck? Help me troubleshoot my Packet Tracer cable connections.

Configure base settings on all routers and switches

Every network device needs baseline security before anything else touches it. You will set hostnames, passwords, login requirements, and a warning banner on all five devices.

  • Click R1-HQ and open the CLI tab.
  • If the router shows a Would you like to enter the initial configuration dialog? prompt, type no and press Enter.
  • Enter privileged EXEC mode and then global configuration mode by entering these commands:
enable
configure terminal
  • Apply the base configuration by entering the following commands:
! Set the device hostname
hostname R1-HQ
!
! Set the privileged EXEC password
enable secret class
!
! Encrypt all plain-text passwords in the config
service password-encryption
!
! Set a login warning banner
banner motd #Authorized Access Only#
!
! Secure the console line
line console 0
password cisco
login
exit
!
! Secure the VTY (remote access) lines
line vty 0 4
password cisco
login
transport input ssh telnet
exit

What do these commands do?

This baseline hardens the device against unauthorized access. enable secret sets an encrypted password for privileged mode. service password-encryption encrypts any passwords stored in plain text in the running config.

The console and VTY lines control who can access the device physically (console cable) and remotely (SSH/Telnet). The login command tells the device to actually prompt for the password you set.

The same base config applies to R2-Core and R3-Branch. The only difference is the hostname.

  • Click R2-Core, open the CLI tab, type no at the initial dialog if prompted, and enter the same commands above.
  • Replace the hostname line with hostname R2-Core.
  • Click R3-Branch, open the CLI tab, and enter the same commands.
  • Replace the hostname line with hostname R3-Branch.

The switches get the same baseline, but without the transport input ssh telnet line under VTY.

  • Click SW1-HQ, open the CLI tab, enter enable then configure terminal, and apply these commands:
! Set the device hostname
hostname SW1-HQ
!
! Set the privileged EXEC password
enable secret class
!
! Encrypt all plain-text passwords
service password-encryption
!
! Set a login warning banner
banner motd #Authorized Access Only#
!
! Secure the console line
line console 0
password cisco
login
exit
!
! Secure the VTY lines
line vty 0 4
password cisco
login
exit
  • Click SW2-Branch, open the CLI tab, and apply the same switch commands above.
  • Replace the hostname line with hostname SW2-Branch.
  • On each device, type end to return to privileged EXEC mode once you finish entering commands.

Why set these on every device?

In a real enterprise, an unsecured device is an open door for attackers. Even in a lab, building the muscle memory of applying baselines first is critical. Network engineer interviews often ask candidates to describe their device hardening process.

  • Verify your base settings on R1-HQ by running this command:
show running-config

You should see your hostname at the top, encrypted passwords (shown as hashed strings), and the MOTD banner configured.

Seeing 'Invalid input detected'?

This error means you are in the wrong command mode. Make sure you are in global configuration mode (the prompt shows (config)#). If you see just Router>, type enable first, then configure terminal.

If you accidentally typed a command at the wrong level, type exit to back out one level and try again.

Need more help? Help me fix my Cisco IOS configuration errors.

✔️ Awesome, I've got everything!

Great. Make sure you have run the base config on all five devices (R1-HQ, R2-Core, R3-Branch, SW1-HQ, SW2-Branch) before moving on.

ⓧ I'd like to double check the full code

Here are the full base configurations for every device. Compare yours against these.

Router base config (R1-HQ, R2-Core, R3-Branch). Change the hostname line for each:

enable
configure terminal
hostname R1-HQ
enable secret class
service password-encryption
banner motd #Authorized Access Only#
line console 0
password cisco
login
exit
line vty 0 4
password cisco
login
transport input ssh telnet
exit

Switch base config (SW1-HQ, SW2-Branch). Change the hostname line for each:

enable
configure terminal
hostname SW1-HQ
enable secret class
service password-encryption
banner motd #Authorized Access Only#
line console 0
password cisco
login
exit
line vty 0 4
password cisco
login
exit
Plan your IP addressing scheme

Before configuring any interfaces, you need a documented plan for how IP addresses are allocated across your network. A clean addressing scheme makes troubleshooting and route summarization much easier later.

Your network needs addresses for five VLANs (department segments) and two WAN links (router-to-router connections).

  • Use distinct major networks per site so that route summarization is straightforward later.
  • Use /24 subnets for VLANs (room for 254 hosts per department).
  • Use /30 subnets for point-to-point WAN links (only 2 usable addresses needed).
  • Document your addressing scheme using the plan below. You will reference these addresses throughout the rest of the project.
! === HQ Site (Area 0) ===
! VLAN 10 - Management:   192.168.10.0/24  (gateway: 192.168.10.1)
! VLAN 20 - Sales:        192.168.20.0/24  (gateway: 192.168.20.1)
! VLAN 30 - Servers:      192.168.30.0/24  (gateway: 192.168.30.1)
!
! === Branch Site (Area 1) ===
! VLAN 10 - Management:   172.16.10.0/24   (gateway: 172.16.10.1)
! VLAN 40 - Operations:   172.16.40.0/24   (gateway: 172.16.40.1)
!
! === WAN Links ===
! R1-HQ to R2-Core:       10.0.12.0/30     (R1: .1, R2: .2)
! R2-Core to R3-Branch:   10.0.23.0/30     (R2: .1, R3: .2)

Why separate major networks per site?

HQ uses 192.168.x.x and Branch uses 172.16.x.x. This is deliberate. When you configure OSPF route summarization on the Area Border Router later, having all HQ subnets under one major network makes summarization a single command.

The WAN links use 10.0.x.x/30 subnets. A /30 gives exactly two usable host addresses, which is perfect for a point-to-point link between two routers.

Not sure how /30 subnetting works?

A /30 subnet mask (255.255.255.252) gives 4 total addresses: 1 network address, 2 usable hosts, and 1 broadcast. For the 10.0.12.0/30 subnet: .0 is the network, .1 and .2 are usable, .3 is the broadcast.

Want a refresher? Explain how /30 subnets work for WAN point-to-point links.

Your physical topology is built, every device is hardened, and your IP plan is ready. Next up, you will bring this network to life by creating VLANs and configuring inter-VLAN routing so departments can communicate through their router.

Configure VLANs and Inter-VLAN Routing

Your topology is cabled and every device has its base security settings in place. Now it is time to make this network actually useful by segmenting traffic into departments.

In a real enterprise, different departments need their own broadcast domains for security and performance. VLANs provide that segmentation at Layer 2, but departments still need to talk to each other. You will use router-on-a-stick to route between VLANs and then bring up the WAN links connecting your two sites.

In this step, get ready to:
  • Create VLANs on both switches and assign access ports with 802.1Q trunking.
  • Configure router-on-a-stick subinterfaces for inter-VLAN routing at HQ and Branch.
  • Bring up WAN interfaces and verify intra-site connectivity with ping tests.
Create VLANs on both switches and assign access ports

Each switch needs VLANs created and named, access ports assigned to those VLANs, and a trunk port configured to carry tagged traffic to the router.

  • Click on SW1-HQ in your topology to open it.
  • Select the CLI tab.
  • Enter privileged EXEC mode and then global configuration mode by running these commands:
enable
configure terminal
  • Create the three HQ VLANs and assign access ports by entering the following configuration:
! Create VLANs for each HQ department
vlan 10
 name Management
vlan 20
 name Sales
vlan 30
 name Servers

! Assign access ports to their respective VLANs
interface FastEthernet0/1
 switchport mode access
 switchport access vlan 10
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 20
interface FastEthernet0/3
 switchport mode access
 switchport access vlan 30

! Configure the uplink to R1-HQ as a trunk
interface GigabitEthernet0/1
 switchport mode trunk
end

What does this configuration do?

Each vlan command creates a Layer 2 broadcast domain. The name gives it a human-readable label so you can identify departments easily.

Access ports carry traffic for only one VLAN (untagged). The trunk port on GigabitEthernet0/1 carries traffic for all VLANs simultaneously using 802.1Q frame tagging. This is what allows a single physical link to the router to serve multiple VLANs.

  • Verify the VLAN assignments on SW1-HQ by running:
show vlan brief

You should see VLAN 10 (Management), VLAN 20 (Sales), and VLAN 30 (Servers) listed with the correct FastEthernet port assigned under each.

VLANs not showing the correct ports?

Make sure you typed switchport access vlan 10 (not just vlan 10) under each interface. The switchport access keyword is what assigns the port. Without it, the port stays in the default VLAN 1.

Also confirm you ran switchport mode access before switchport access vlan on each port.

Help me troubleshoot my VLAN port assignments on SW1-HQ

  • Now click on SW2-Branch in your topology and select the CLI tab.
  • Enter privileged EXEC and global configuration mode, then create the Branch VLANs and assign ports:
enable
configure terminal

! Create VLANs for Branch departments
vlan 10
 name Management
vlan 40
 name Operations

! Assign access ports to their respective VLANs
interface FastEthernet0/1
 switchport mode access
 switchport access vlan 10
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 40

! Configure the uplink to R3-Branch as a trunk
interface GigabitEthernet0/1
 switchport mode trunk
end

Why does Branch also have VLAN 10?

Both sites use VLAN 10 for Management. The VLAN IDs are locally significant to each switch, but using consistent numbering across sites makes your network easier to document and troubleshoot. Management devices at both locations belong to the same logical group.

  • Verify the VLAN assignments on SW2-Branch by running:
show vlan brief

You should see VLAN 10 (Management) with FastEthernet0/1, and VLAN 40 (Operations) with FastEthernet0/2.

Configure router-on-a-stick on R1-HQ and R3-Branch

With VLANs created, traffic is segmented. But devices in different VLANs cannot communicate yet because Layer 2 switches do not route between broadcast domains. You need a router to handle inter-VLAN traffic.

Why router-on-a-stick instead of Layer 3 switching?

Router-on-a-stick uses a single physical router interface divided into subinterfaces, each handling one VLAN. This approach explicitly teaches 802.1Q encapsulation configuration and aligns with CCNA exam topic 2.2 (interswitch connectivity, trunk ports, 802.1Q).

The 2960 switch in Packet Tracer does not support Layer 3 switching, so router-on-a-stick is the correct design pattern here.

  • Click on R1-HQ in your topology and select the CLI tab.
  • Enter privileged EXEC mode and global configuration mode.
  • Create the three subinterfaces on GigabitEthernet0/0/0 by entering this configuration:
enable
configure terminal

! Subinterface for VLAN 10 - Management gateway
interface GigabitEthernet0/0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0

! Subinterface for VLAN 20 - Sales gateway
interface GigabitEthernet0/0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0

! Subinterface for VLAN 30 - Servers gateway
interface GigabitEthernet0/0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0

! Enable the physical interface (subinterfaces inherit this state)
interface GigabitEthernet0/0/0
 no shutdown
end

What does encapsulation dot1Q do?

The encapsulation dot1Q 10 command tells the subinterface to handle frames tagged with VLAN 10. When a frame arrives on the trunk with a VLAN 10 tag, the router knows to process it on this subinterface.

The IP address on the subinterface becomes the default gateway for all devices in that VLAN. The physical interface GigabitEthernet0/0/0 must be brought up with no shutdown for any subinterfaces to work. Subinterfaces inherit the up/down state of their parent.

  • Verify the subinterfaces are up by running:
show ip interface brief

You should see GigabitEthernet0/0/0 as up/up, and all three subinterfaces (.10, .20, .30) also showing up/up with their assigned IP addresses.

Subinterfaces showing down/down?

The most common cause is forgetting no shutdown on the physical GigabitEthernet0/0/0 interface. Go back into configuration mode and run interface GigabitEthernet0/0/0 followed by no shutdown.

Also check that the cable between R1-HQ and SW1-HQ is connected to GigabitEthernet0/0/0 on the router side and GigabitEthernet0/1 on the switch side.

Help me troubleshoot my R1-HQ subinterfaces

  • Now click on R3-Branch in your topology and select the CLI tab.
  • Create the two subinterfaces on GigabitEthernet0/0/0 for the Branch site:
enable
configure terminal

! Subinterface for VLAN 10 - Management gateway
interface GigabitEthernet0/0/0.10
 encapsulation dot1Q 10
 ip address 172.16.10.1 255.255.255.0

! Subinterface for VLAN 40 - Operations gateway
interface GigabitEthernet0/0/0.40
 encapsulation dot1Q 40
 ip address 172.16.40.1 255.255.255.0

! Enable the physical interface
interface GigabitEthernet0/0/0
 no shutdown
end
  • Verify with show ip interface brief that both subinterfaces (.10 and .40) show up/up with their correct IP addresses.
Configure WAN interfaces and verify intra-site connectivity

The subinterfaces handle local VLAN routing, but your two sites are still isolated. You need to bring up the point-to-point WAN links between all three routers using the /30 subnets from your addressing scheme.

  • Return to R1-HQ's CLI and configure the WAN interface toward R2-Core:
enable
configure terminal

! WAN link toward R2-Core
interface GigabitEthernet0/0/1
 ip address 10.0.12.1 255.255.255.252
 no shutdown
end
  • Click on R2-Core and configure both WAN interfaces:
enable
configure terminal

! WAN link toward R1-HQ
interface GigabitEthernet0/0/0
 ip address 10.0.12.2 255.255.255.252
 no shutdown

! WAN link toward R3-Branch
interface GigabitEthernet0/0/1
 ip address 10.0.23.1 255.255.255.252
 no shutdown
end

Why /30 subnets for WAN links?

A /30 subnet provides exactly 2 usable host addresses, which is all you need for a point-to-point link between two routers. Using /30 subnets conserves address space. Each WAN link gets its own tiny subnet (10.0.12.0/30 between R1 and R2, 10.0.23.0/30 between R2 and R3).

  • Click on R3-Branch and configure its WAN interface toward R2-Core:
enable
configure terminal

! WAN link toward R2-Core
interface GigabitEthernet0/0/1
 ip address 10.0.23.2 255.255.255.252
 no shutdown
end
  • Verify the WAN link between R1-HQ and R2-Core is up by running this from R1-HQ:
ping 10.0.12.2

You should see successful replies from R2-Core. If the ping fails, check that both ends have no shutdown and that the subnet addresses match.

  • Now assign IP addresses to all five PCs. Click on each PC, select the Desktop tab, then open IP Configuration.
  • Configure PC-Mgmt-HQ: IP Address 192.168.10.10, Subnet Mask 255.255.255.0, Default Gateway 192.168.10.1.
  • Configure PC-Sales-HQ: IP Address 192.168.20.10, Subnet Mask 255.255.255.0, Default Gateway 192.168.20.1.
  • Configure Server-HQ: IP Address 192.168.30.10, Subnet Mask 255.255.255.0, Default Gateway 192.168.30.1.
  • Configure PC-Mgmt-Branch: IP Address 172.16.10.10, Subnet Mask 255.255.255.0, Default Gateway 172.16.10.1.
  • Configure PC-Ops-Branch: IP Address 172.16.40.10, Subnet Mask 255.255.255.0, Default Gateway 172.16.40.1.

Why does the default gateway point to the subinterface?

Each PC's default gateway is the router subinterface IP for its VLAN. When PC-Sales-HQ (VLAN 20) wants to reach a device in VLAN 10, it sends the packet to 192.168.20.1 (its gateway). The router receives it on the .20 subinterface and routes it out the .10 subinterface toward the destination.

  • Test intra-site routing by opening a Command Prompt on each PC (Desktop tab, then Command Prompt) and pinging its default gateway:
ping 192.168.10.1

Each PC should receive successful replies from its gateway. Repeat for all five PCs using their respective gateway IPs.

  • Verify trunking is working by returning to SW1-HQ's CLI and running:
show interfaces trunk

You should see GigabitEthernet0/1 listed as a trunk port in 802.1Q mode, with VLANs 1, 10, 20, and 30 allowed. Run the same command on SW2-Branch to confirm its trunk carries VLANs 1, 10, and 40.

Ping to gateway fails?

Check that the PC's default gateway IP matches the router subinterface IP for that VLAN exactly. For example, PC-Mgmt-HQ's gateway must be 192.168.10.1 (the R1-HQ .10 subinterface).

If the gateway is correct but the ping still times out, verify that show interfaces trunk on the switch shows the trunk is active. If the trunk is missing, re-enter switchport mode trunk on the switch's GigabitEthernet0/1 interface.

Help me troubleshoot why my PC cannot ping its default gateway

✔️ Awesome, I've got everything!

Great. All PCs can ping their gateways, and your trunk links are carrying the correct VLANs. Make sure you see successful pings from all five PCs before moving on.

ⓧ I'd like to double check the full configuration

Here is the complete configuration for each device at this point. Compare against your own.

! === SW1-HQ ===
vlan 10
 name Management
vlan 20
 name Sales
vlan 30
 name Servers

interface FastEthernet0/1
 switchport mode access
 switchport access vlan 10
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 20
interface FastEthernet0/3
 switchport mode access
 switchport access vlan 30

interface GigabitEthernet0/1
 switchport mode trunk
! === SW2-Branch ===
vlan 10
 name Management
vlan 40
 name Operations

interface FastEthernet0/1
 switchport mode access
 switchport access vlan 10
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 40

interface GigabitEthernet0/1
 switchport mode trunk
! === R1-HQ ===
interface GigabitEthernet0/0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0

interface GigabitEthernet0/0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0

interface GigabitEthernet0/0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0

interface GigabitEthernet0/0/0
 no shutdown

interface GigabitEthernet0/0/1
 ip address 10.0.12.1 255.255.255.252
 no shutdown
! === R2-Core ===
interface GigabitEthernet0/0/0
 ip address 10.0.12.2 255.255.255.252
 no shutdown

interface GigabitEthernet0/0/1
 ip address 10.0.23.1 255.255.255.252
 no shutdown
! === R3-Branch ===
interface GigabitEthernet0/0/0.10
 encapsulation dot1Q 10
 ip address 172.16.10.1 255.255.255.0

interface GigabitEthernet0/0/0.40
 encapsulation dot1Q 40
 ip address 172.16.40.1 255.255.255.0

interface GigabitEthernet0/0/0
 no shutdown

interface GigabitEthernet0/0/1
 ip address 10.0.23.2 255.255.255.252
 no shutdown
! === PC IP Assignments ===
! PC-Mgmt-HQ:     IP 192.168.10.10  Mask 255.255.255.0  Gateway 192.168.10.1
! PC-Sales-HQ:    IP 192.168.20.10  Mask 255.255.255.0  Gateway 192.168.20.1
! Server-HQ:      IP 192.168.30.10  Mask 255.255.255.0  Gateway 192.168.30.1
! PC-Mgmt-Branch: IP 172.16.10.10   Mask 255.255.255.0  Gateway 172.16.10.1
! PC-Ops-Branch:  IP 172.16.40.10   Mask 255.255.255.0  Gateway 172.16.40.1

Your VLANs are segmenting traffic and your routers are handling inter-VLAN routing locally. Next up, you will configure OSPF so that traffic can flow between HQ and Branch across the WAN links you just brought up.

Configure Multi-Area OSPF

Your VLANs are segmented, your trunks are carrying traffic, and every PC can reach its local gateway. But right now, HQ and Branch are isolated islands. A PC in HQ has no idea that Branch even exists.

To connect these two sites, you need a dynamic routing protocol that can share network information automatically. Multi-Area OSPF is the industry standard for enterprise networks of this scale. It divides your network into logical areas so each router only needs to know the full detail of its own area.

In this step, get ready to:
  • Enable OSPF on R1-HQ and advertise all HQ networks into Area 0.
  • Configure R2-Core as the Area Border Router bridging Area 0 and Area 1.
  • Enable OSPF on R3-Branch in Area 1 and verify full cross-site connectivity.
Enable OSPF on R1-HQ (Area 0)

R1-HQ sits at the headquarters and owns all three HQ VLANs plus the WAN link toward R2-Core. Every one of these networks belongs in Area 0, the OSPF backbone area.

  • Click on R1-HQ in your topology, then select the CLI tab.
  • Enter global configuration mode by running these commands:
enable
configure terminal
  • Configure the OSPF process, router ID, and network advertisements by entering:
router ospf 1
router-id 1.1.1.1
network 192.168.10.0 0.0.0.255 area 0
network 192.168.20.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 0
network 10.0.12.0 0.0.0.3 area 0
passive-interface GigabitEthernet0/0/0.10
passive-interface GigabitEthernet0/0/0.20
passive-interface GigabitEthernet0/0/0.30

What do these commands do?

  • router ospf 1 starts OSPF process 1. The process ID is locally significant and does not need to match other routers.
  • router-id 1.1.1.1 manually sets a unique identifier for this router within the OSPF domain.
  • Each network statement tells OSPF which interfaces to activate on, using a wildcard mask and area assignment.
  • passive-interface stops OSPF hello packets from being sent out toward end-user PCs. This is a security best practice.

Why passive interfaces?

Without passive interfaces, R1-HQ would broadcast OSPF hello messages out every LAN subinterface. End devices like PCs ignore these packets, so the hellos waste bandwidth and expose your routing topology unnecessarily.

  • Return to privileged exec mode and verify the OSPF configuration by running:
end
show ip ospf interface brief

You should see four interfaces listed under Area 0: your three subinterfaces (Gi0/0/0.10, Gi0/0/0.20, Gi0/0/0.30) and the WAN interface (Gi0/0/1).

Not seeing any OSPF interfaces?

  • Make sure you typed the wildcard masks correctly. For /24 subnets the wildcard is 0.0.0.255 and for the /30 WAN link it is 0.0.0.3.
  • Confirm the interfaces are up with show ip interface brief. If any show "administratively down", you missed a no shutdown in the previous step.
  • Check that you entered the network commands under router ospf 1 and not under an interface configuration.

Help me troubleshoot why OSPF interfaces are not showing up on R1-HQ.

Enable OSPF on R2-Core as the ABR

R2-Core connects HQ to Branch. It has one interface facing Area 0 (toward R1-HQ) and another facing Area 1 (toward R3-Branch). This makes it an Area Border Router (ABR).

  • Click on R2-Core and open its CLI tab.
  • Enter global configuration mode and configure OSPF by entering:
enable
configure terminal
router ospf 1
router-id 2.2.2.2
network 10.0.12.0 0.0.0.3 area 0
network 10.0.23.0 0.0.0.3 area 1

What makes R2-Core an ABR?

An Area Border Router has interfaces in more than one OSPF area. Here, R2-Core advertises 10.0.12.0/30 into Area 0 and 10.0.23.0/30 into Area 1.

The ABR is responsible for exchanging route summaries between areas. When R3-Branch needs to know about HQ subnets, R2-Core translates those Area 0 routes into inter-area advertisements for Area 1.

  • Return to privileged exec mode and verify by running:
end
show ip ospf interface brief

You should see two interfaces listed: Gi0/0/0 in Area 0 and Gi0/0/1 in Area 1.

OSPF neighbor not forming with R1-HQ?

  • Verify the WAN link is up on both sides with show ip interface brief. Both Gi0/0/1 on R1-HQ and Gi0/0/0 on R2-Core must show "up/up".
  • Confirm both routers advertise the same subnet (10.0.12.0 0.0.0.3) into Area 0. A mismatched area assignment prevents adjacency.

Help me troubleshoot why R2-Core is not forming an OSPF adjacency with R1-HQ.

Enable OSPF on R3-Branch and verify full adjacency

R3-Branch is the final piece of the puzzle. Once it joins Area 1, the ABR (R2-Core) will bridge the two areas and every router will learn routes to every subnet in the network.

  • Click on R3-Branch and open its CLI tab.
  • Enter global configuration mode and configure OSPF by entering:
enable
configure terminal
router ospf 1
router-id 3.3.3.3
network 172.16.10.0 0.0.0.255 area 1
network 172.16.40.0 0.0.0.255 area 1
network 10.0.23.0 0.0.0.3 area 1
passive-interface GigabitEthernet0/0/0.10
passive-interface GigabitEthernet0/0/0.40

What does this code do?

  • All three network statements place R3-Branch's subnets into Area 1. This keeps Branch traffic local to its own area.
  • The WAN-facing link (10.0.23.0/30) is also in Area 1, matching the area assignment on R2-Core's side.
  • Passive interfaces on Gi0/0/0.10 and Gi0/0/0.40 prevent OSPF hellos from reaching Branch PCs.
  • Return to privileged exec mode by typing end.
  • Verify OSPF adjacencies have formed by running:
show ip ospf neighbor

You should see one neighbor (R2-Core, router ID 2.2.2.2) in the FULL state.

  • Confirm that inter-area routes are being learned by running:
show ip route ospf

You should see HQ subnets (192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24) appear as O IA routes. The "IA" stands for inter-area, meaning they were learned through the ABR.

  • Also verify adjacencies on R2-Core by clicking on it and running:
show ip ospf neighbor

R2-Core should show two neighbors in FULL state: R1-HQ (1.1.1.1) and R3-Branch (3.3.3.3).

  • Run the ultimate cross-site connectivity test. Click on PC-Mgmt-HQ, go to the Desktop tab, and open Command Prompt.
  • Ping PC-Ops-Branch to test cross-site reachability:
ping 172.16.40.10

You should receive replies from 172.16.40.10. This confirms that OSPF is delivering full end-to-end routing between HQ and Branch across two areas.

Ping fails between sites?

  • Run show ip ospf neighbor on R2-Core. If it does not show two FULL neighbors, one of the adjacencies has not formed. Check that both sides of each WAN link advertise the same subnet into the same area.
  • Run show ip route ospf on R1-HQ. If you do not see Branch networks (172.16.x.x) as O IA routes, R2-Core is not propagating inter-area routes.
  • In Packet Tracer, the first ping often times out while ARP resolves. Try pinging a second time before troubleshooting further.

Help me figure out why cross-site pings are failing in my OSPF network.

✔️ Awesome, I've got everything!

Great. Make sure to save your configurations on all three routers with copy running-config startup-config.

ⓧ I'd like to double check the full config

Here is the complete OSPF configuration for each router. Compare yours against these:

R1-HQ OSPF configuration:

router ospf 1
router-id 1.1.1.1
network 192.168.10.0 0.0.0.255 area 0
network 192.168.20.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 0
network 10.0.12.0 0.0.0.3 area 0
passive-interface GigabitEthernet0/0/0.10
passive-interface GigabitEthernet0/0/0.20
passive-interface GigabitEthernet0/0/0.30

R2-Core OSPF configuration:

router ospf 1
router-id 2.2.2.2
network 10.0.12.0 0.0.0.3 area 0
network 10.0.23.0 0.0.0.3 area 1

R3-Branch OSPF configuration:

router ospf 1
router-id 3.3.3.3
network 172.16.10.0 0.0.0.255 area 1
network 172.16.40.0 0.0.0.255 area 1
network 10.0.23.0 0.0.0.3 area 1
passive-interface GigabitEthernet0/0/0.10
passive-interface GigabitEthernet0/0/0.40

Your two-site network now has full IP reachability through OSPF. Every subnet is dynamically advertised and reachable across the WAN. Next up, you will lock down this open connectivity with ACLs that enforce security policies between departments.

Implement and Test ACLs

Your network has full connectivity. Every PC can reach every other device across both sites thanks to OSPF.

In the real world, full connectivity is a starting point, not the goal. You need security policies that control who can access what. Access Control Lists (ACLs) are the traffic filters that enforce these policies on Cisco routers.

In this step, get ready to:
  • Create a named extended ACL that blocks the Sales department from reaching the Servers VLAN.
  • Create a named standard ACL that restricts VTY (remote management) access to Management VLANs only.
  • Verify ACL hit counters and confirm your security policies are enforced without disrupting OSPF.
Create a named extended ACL to block Sales from Servers

The Sales department should not have direct access to the Servers VLAN. An extended ACL can filter traffic based on both source and destination IP addresses, giving you precise control over which departments can communicate.

Why named ACLs instead of numbered?

Named ACLs are easier to read because the name tells you the purpose. They are also easier to maintain since you can delete individual entries without recreating the entire list.

Named ACLs are the recommended practice in production environments.

  • Return to R1-HQ's CLI in Packet Tracer.
  • Enter global configuration mode and create the extended ACL by entering these commands:
enable
configure terminal
ip access-list extended BLOCK-SALES-TO-SERVERS
 deny ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255
 permit ip any any
 exit

What do these commands do?

The ip access-list extended BLOCK-SALES-TO-SERVERS command creates a named extended ACL. The name tells you exactly what it does.

The deny ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255 entry blocks all IP traffic from the Sales subnet (192.168.20.0/24) destined for the Servers subnet (192.168.30.0/24). The 0.0.0.255 values are wildcard masks that match the last octet.

The permit ip any any at the end is critical. Without it, the ACL's implicit deny would block ALL traffic, not just Sales-to-Servers.

Why place extended ACLs close to the source?

Best practice says to apply extended ACLs as close to the traffic source as possible. This prevents unwanted traffic from consuming bandwidth across your network.

You will apply this ACL inbound on the Sales subinterface so denied packets are dropped before they even enter the router's forwarding logic.

  • Apply the ACL inbound on the Sales subinterface by entering these commands:
interface GigabitEthernet0/0/0.20
 ip access-group BLOCK-SALES-TO-SERVERS in
 exit

What does ip access-group do?

The ip access-group command binds an ACL to an interface. The in keyword means the ACL filters packets arriving on this interface (from Sales PCs heading into the router).

  • Test the ACL by switching to PC-Sales-HQ.
  • Click PC-Sales-HQ, go to the Desktop tab, and open Command Prompt.
  • Ping Server-HQ by entering:
ping 192.168.30.10
  • You should see Request timed out or Destination host unreachable. The ACL is blocking Sales from reaching the Servers VLAN.
  • Now verify that Management can still reach the server. Switch to PC-Mgmt-HQ, open Command Prompt, and ping Server-HQ:
ping 192.168.30.10
  • This ping should succeed with replies from 192.168.30.10. The ACL only blocks Sales traffic. All other traffic passes through.

Sales can still ping the server?

Verify the ACL is applied to the correct interface. Run show ip interface GigabitEthernet0/0/0.20 on R1-HQ and look for the line showing the inbound access list.

Also check the subnet and wildcard mask in your ACL. The source must be 192.168.20.0 0.0.0.255 and destination must be 192.168.30.0 0.0.0.255.

Help me troubleshoot why my extended ACL isn't blocking traffic between VLANs in Packet Tracer

Create a named standard ACL to restrict VTY access

Remote management access (via Telnet or SSH) should be restricted to trusted administrators only. A standard ACL applied to the VTY lines ensures that only devices on Management VLANs can connect remotely to your routers.

  • On R1-HQ (still in global configuration mode), create the VTY access ACL and apply it to the VTY lines by entering these commands:
ip access-list standard VTY-ACCESS
 permit 192.168.10.0 0.0.0.255
 permit 172.16.10.0 0.0.0.255
 exit
line vty 0 4
 access-class VTY-ACCESS in
 transport input ssh telnet
 exit

What do these commands do?

The standard ACL named VTY-ACCESS permits only two subnets: the HQ Management VLAN (192.168.10.0/24) and the Branch Management VLAN (172.16.10.0/24). All other sources are implicitly denied.

The access-class VTY-ACCESS in command applies the ACL specifically to VTY line connections (rather than to an interface). The transport input ssh telnet specifies which protocols are allowed on these lines.

  • Now apply the same VTY-ACCESS ACL on R2-Core. Click R2-Core, open the CLI tab, and enter:
enable
configure terminal
ip access-list standard VTY-ACCESS
 permit 192.168.10.0 0.0.0.255
 permit 172.16.10.0 0.0.0.255
 exit
line vty 0 4
 access-class VTY-ACCESS in
 transport input ssh telnet
 exit
  • Repeat on R3-Branch. Click R3-Branch, open the CLI tab, and enter the same commands:
enable
configure terminal
ip access-list standard VTY-ACCESS
 permit 192.168.10.0 0.0.0.255
 permit 172.16.10.0 0.0.0.255
 exit
line vty 0 4
 access-class VTY-ACCESS in
 transport input ssh telnet
 exit
  • Test VTY access from the Management VLAN. Switch to PC-Mgmt-HQ, open Command Prompt, and telnet to R1-HQ:
telnet 192.168.10.1
  • You should see a password prompt. Enter the VTY password (cisco if you followed the base config from Step 1). This confirms Management VLAN access is permitted.
  • Type exit to close the telnet session.
  • Now test from the Sales VLAN. Switch to PC-Sales-HQ, open Command Prompt, and attempt to telnet to R1-HQ:
telnet 192.168.10.1
  • This connection should be refused. You may see a message indicating the connection was denied or timed out. The VTY-ACCESS ACL is blocking non-Management VLANs from remote access.

Telnet from Sales PC still connects?

Verify the access-class is applied by running show running-config | section line vty on R1-HQ. You should see access-class VTY-ACCESS in listed under the VTY lines.

If the ACL exists but telnet still works from Sales, make sure you used access-class (for VTY lines), not ip access-group (which is for interfaces).

Help me troubleshoot why my VTY access-class ACL is not blocking telnet connections

Verify ACL operation and hit counts

ACLs maintain counters that track how many packets match each entry. These counters are your proof that the security policy is working as intended.

  • Return to R1-HQ's CLI and view the ACL statistics by running:
show access-lists

What should I see?

You should see both ACLs listed with match counts in parentheses after each entry. The deny entry in BLOCK-SALES-TO-SERVERS should show matches from your earlier ping test.

If you see zero matches on the deny line, try pinging Server-HQ from PC-Sales-HQ again to generate traffic, then re-run show access-lists.

  • Verify that your ACLs have not disrupted OSPF. On R1-HQ, check that adjacencies are still FULL:
show ip ospf neighbor
  • You should see R2-Core's neighbor entry with a state of FULL. The permit ip any any at the end of your extended ACL ensures OSPF hello packets still flow.

Why check OSPF after applying ACLs?

A common mistake is creating an ACL that inadvertently blocks OSPF hello packets (multicast to 224.0.0.5). If your ACL's last entry were deny ip any any instead of permit ip any any, OSPF would lose its adjacency and cross-site routing would collapse.

  • Run the final end-to-end test matrix. From PC-Mgmt-HQ, ping PC-Ops-Branch:
ping 172.16.40.10
  • This ping from PC-Mgmt-HQ to PC-Ops-Branch should succeed. Cross-site connectivity for Management is intact.
  • From PC-Sales-HQ, ping PC-Ops-Branch:
ping 172.16.40.10
  • This should also succeed. The ACL only blocks Sales-to-Servers traffic. Sales can still reach other destinations.
  • From PC-Sales-HQ, ping Server-HQ one final time to confirm the deny:
ping 192.168.30.10
  • This should fail. Your security policy is fully enforced.
  • Return to R1-HQ and run show access-lists one more time to confirm the deny counter incremented from your latest ping attempt.

OSPF adjacency dropped to DOWN?

If show ip ospf neighbor shows no neighbors or a state other than FULL, your ACL may be blocking OSPF. Verify your extended ACL ends with permit ip any any by running show access-lists.

If the permit entry is missing, re-enter global config and add it:

configure terminal
ip access-list extended BLOCK-SALES-TO-SERVERS
 permit ip any any
 exit

Help me fix my OSPF adjacency that dropped after I applied an ACL

✔️ Awesome, I've got everything!

Great. Make sure you have verified all your ping and telnet tests before moving on.

ⓧ I'd like to double check the full config

Here is the complete ACL configuration across all three routers.

R1-HQ ACL config:

ip access-list extended BLOCK-SALES-TO-SERVERS
 deny ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255
 permit ip any any

ip access-list standard VTY-ACCESS
 permit 192.168.10.0 0.0.0.255
 permit 172.16.10.0 0.0.0.255

interface GigabitEthernet0/0/0.20
 ip access-group BLOCK-SALES-TO-SERVERS in

line vty 0 4
 access-class VTY-ACCESS in
 transport input ssh telnet

R2-Core ACL config:

ip access-list standard VTY-ACCESS
 permit 192.168.10.0 0.0.0.255
 permit 172.16.10.0 0.0.0.255

line vty 0 4
 access-class VTY-ACCESS in
 transport input ssh telnet

R3-Branch ACL config:

ip access-list standard VTY-ACCESS
 permit 192.168.10.0 0.0.0.255
 permit 172.16.10.0 0.0.0.255

line vty 0 4
 access-class VTY-ACCESS in
 transport input ssh telnet

Secret mission

Harden WAN Links with OSPF MD5 Authentication and Route Summarization

Your network works, but is it secure against rogue routers? In this extension, you will configure OSPF MD5 authentication on all WAN links to prevent unauthorized route injection, then optimize your routing table with inter-area summarization on the ABR.

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 worry about.

Decide whether to keep your topology file for reference, or delete it to free up disk space.

Resources you used:

  • Packet Tracer topology file (.pkt) saved on your computer.
  • Cisco Packet Tracer 9.0 application installed on your computer.

Keep everything running

No action needed. Choose this if you want to keep your topology file for practice, interview prep, or future modifications.

  • Your .pkt file stays wherever you saved it.
  • Cisco Packet Tracer remains installed for future labs.
  • You can reopen the topology anytime to review configurations or practice show commands.

Pause - I'll come back to this later

Since this is a local simulation, there is nothing to pause. Your topology file and Packet Tracer installation take up minimal disk space and consume no resources when not in use.

  • Close Cisco Packet Tracer if it is still open.
  • Your .pkt file is saved and ready to reopen whenever you return.

Delete - I don't want to use this again

Remove all project files and optionally uninstall Cisco Packet Tracer.

  • Delete your .pkt topology file. On macOS, drag it to the Trash. On Windows, right-click the file and select Delete.
  • To uninstall Cisco Packet Tracer on Windows, open Settings, select Apps, then Apps & features, find Cisco Packet Tracer in the list, and click Uninstall.
  • To uninstall Cisco Packet Tracer on macOS, open Finder, go to Applications, and drag Cisco Packet Tracer to the Trash. Then empty the Trash.

Nice Work!

Nice Work!

Nice work! You just built and secured a multi-site enterprise network from the ground up in Cisco Packet Tracer.

You've learned how to:

  • Design and configure VLAN segmentation across two sites with 802.1Q trunking and router-on-a-stick inter-VLAN routing.
  • Implement multi-area OSPF with an Area Border Router, passive interfaces, and verified full inter-site connectivity.
  • Deploy named ACLs (standard and extended) to enforce department isolation and restrict management plane access.
  • Secret Mission: Hardened WAN links with OSPF MD5 authentication and optimized routing with inter-area route summarization on the ABR.

Ready to quiz yourself?