Multi-Site Enterprise Network in Packet Tracer

Build a two-site enterprise network with VLANs, OSPF, DHCP, and NAT.

Introduction

30 Second Summary

Every company with more than one office needs a reliable way for departments to communicate across locations, stay organized, and reach the internet. Building that network from scratch is one of the most valuable skills a network engineer can demonstrate.

In this project, you will build a two-site enterprise network in Cisco Packet Tracer from scratch. You will configure VLANs, OSPF routing, DHCP, and NAT to connect two offices with full dynamic routing, automatic addressing, and internet access.

What You'll Build

When you finish, you will ping from a Sales PC at headquarters to an Engineering PC at the branch office and trace the traffic through every layer of your network, from VLAN segmentation to OSPF routing to NAT translation.

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

  • A network where you can ping from any PC at HQ to any PC at the branch, with traffic routed through VLAN subinterfaces and OSPF-learned routes that the routers discovered on their own.
  • PCs that automatically receive IP addresses from DHCP pools you configured on the routers, replacing manual static configuration.
  • Internal traffic translated through NAT overload (PAT) so every PC can reach the simulated internet at 8.8.8.8, with translation entries you can inspect in real time.
  • Secret Mission: Lock down the network with extended ACLs that block Engineering from reaching the Sales subnet while keeping internet access alive.

Are there any prerequisites?

This project assumes CCNA-level networking knowledge and comfort with the Cisco IOS CLI. You need Cisco Packet Tracer 9.0.0 installed on your computer, available from the NetAcad Resource Hub.

Before We Start

Before We Start...

Before we start configuring routers and switches, let's lock in exactly what you're building and why each piece matters.

You're about to build a two-site enterprise network from scratch, connecting a headquarters and a branch office with VLANs, OSPF, DHCP, and NAT. Understanding the purpose of each technology now will make every CLI command click into place once you start configuring.

Build the Topology and Cable the Network

Every network begins with physical infrastructure. Before you can configure a single VLAN or routing protocol, you need the right devices in place with cables connecting them.

In this step, you will build a two-site enterprise topology in Cisco Packet Tracer. You will place three routers, two switches, and four PCs, then cable everything together using the correct cable types.

In this step, get ready to:
  • Place and rename all nine network devices across the HQ, Branch, and ISP sites.
  • Cable every connection using the correct cable type (straight-through or cross-over).
  • Verify all link lights turn green.
Place and rename the network devices

The topology needs three 2911 routers, two 2960 switches, and four PCs. You will place each device from the device panel at the bottom of the screen and rename it so the topology is easy to read.

  • In the bottom-left device panel, click the Network Devices category icon in the top row.
  • In the bottom row of subcategories, click Routers.
  • Find 2911 in the device list that appears.
  • Click 2911, then click in the left side of the workspace to place the router.
  • Click on the router you just placed to open its properties window.
  • Click the Config tab.
  • In the Display Name field, change the name to HQ-R1.
  • Close the properties window by clicking the X in the top-right corner.

How do I place and rename devices?

This is the pattern you will repeat for every device. Choose a category (Network Devices for routers and switches, End Devices for PCs), pick the model, click in the workspace to place it, then open its Config tab and set the Display Name.

Arrange HQ devices on the left, Branch devices on the right, and the ISP router at the top center. This layout makes the topology easier to follow as you cable and configure it.

Using the same process, place and rename the remaining eight devices. Use the table below to find the right category and model for each one.

  • HQ-SW1: Switches subcategory, model 2960. Place near HQ-R1 on the left.
  • HQ-Sales-PC: End Devices category, select PC. Place below HQ-SW1.
  • HQ-Eng-PC: End Devices category, select PC. Place below HQ-SW1, next to HQ-Sales-PC.
  • BR-R2: Routers subcategory, model 2911. Place on the right side of the workspace.
  • BR-SW1: Switches subcategory, model 2960. Place near BR-R2 on the right.
  • BR-Sales-PC: End Devices category, select PC. Place below BR-SW1.
  • BR-Eng-PC: End Devices category, select PC. Place below BR-SW1, next to BR-Sales-PC.
  • ISP: Routers subcategory, model 2911. Place at the top center of the workspace.

You should now see all nine devices in your workspace, each with the correct display name underneath it.

Don't see the correct names?

Click on any device and check the Config tab. Make sure the Display Name field matches the name listed above exactly. Capitalization and hyphens matter.

If you accidentally placed the wrong device model, right-click it and select Delete, then place the correct model.

Help me find or rename a device in Packet Tracer.

Cable the devices

Two cable types connect this topology. Straight-through cables connect different device types (switch to router, PC to switch). Cross-over cables connect same-type devices (router to router).

Why do cable types matter?

A straight-through cable wires pin 1 to pin 1 and pin 2 to pin 2. This works when one device transmits on pins that the other device receives on, which happens naturally between a switch and a router or a switch and a PC.

A cross-over cable swaps the transmit and receive pairs. Router-to-router connections need this because both devices transmit on the same pins. Choosing the wrong cable type in Packet Tracer results in a red link light.

Start with the first straight-through cable to learn the cabling process.

  • In the bottom-left device panel, click the Connections category (the lightning bolt icon).
  • Select Copper Straight-Through from the cable list.
  • Click on HQ-SW1 in the workspace. A pop-up menu of ports appears.
  • Select FastEthernet0/1 from the port list.
  • Click on HQ-R1. Another port list appears.
  • Select GigabitEthernet0/0. A cable now connects the two devices.

How does cabling work in Packet Tracer?

When you select a cable type and click a device, Packet Tracer shows every available port on that device. You pick one port on each end to complete the connection. Two small circles (link lights) appear at each end of the cable. They start amber and turn green once the connection is active.

Create the remaining five straight-through connections using the same process.

  • HQ-Sales-PC FastEthernet0 to HQ-SW1 FastEthernet0/2.
  • HQ-Eng-PC FastEthernet0 to HQ-SW1 FastEthernet0/3.
  • BR-SW1 FastEthernet0/1 to BR-R2 GigabitEthernet0/0.
  • BR-Sales-PC FastEthernet0 to BR-SW1 FastEthernet0/2.
  • BR-Eng-PC FastEthernet0 to BR-SW1 FastEthernet0/3.

Now switch to cross-over cables for the two router-to-router links.

  • In the Connections panel, select Copper Cross-Over.
  • Connect HQ-R1 GigabitEthernet0/1 to BR-R2 GigabitEthernet0/1. This is the WAN link between sites.
  • Connect HQ-R1 GigabitEthernet0/2 to ISP GigabitEthernet0/0. This is the ISP uplink.

You should now see cables connecting every device in the workspace. Each cable has two small link-light circles at its endpoints.

See a red X on a cable?

A red link light means the cable type is wrong for that connection. Delete the cable by clicking on it and pressing the Delete key, then re-create it with the correct type. Straight-through cables connect switch-to-router and PC-to-switch. Cross-over cables connect router-to-router.

Double-check the port numbers too. If you connected to the wrong port, delete the cable and re-create it with the correct ports from the lists above.

Help me fix a cable connection in Packet Tracer.

Verify all link lights are green

Before you check, take a guess: do you expect all link lights to be green right away, or will some take time to change from amber?

  • Look at every cable in your workspace and check the small circles at each end.
  • Wait 30 to 60 seconds for all amber lights to transition to green. Packet Tracer simulates the Spanning Tree Protocol convergence process, which takes time on switch ports.

All link lights should now be green. This confirms that every physical connection is valid and active.

Why do link lights start amber?

Switch ports run Spanning Tree Protocol (STP) when they first come up. STP checks for loops in the network before allowing traffic to flow. During this process the link light stays amber. Once STP finishes, the port moves to forwarding state and the light turns green.

Router ports do not run STP, so router-to-router cross-over links may turn green faster than switch-to-device links.

✔️ All lights are green

Your physical topology is complete. Every device is placed, named, and cabled correctly. Save your Packet Tracer file now by pressing Ctrl+S (Windows) or Cmd+S (macOS).

ⓧ Some lights are still amber or red

  • If a light is amber, wait another 30 seconds. Switch ports can take up to 50 seconds to converge.
  • If a light is red, the cable type or port number is wrong. Click the cable, press Delete, and re-create it with the correct cable type and port numbers from the lists above.
  • If a light stays off entirely, click the device and verify the interface is not administratively shut down. For routers, interfaces are down by default until you enter no shutdown in the CLI. You will do this in a later step, so a down router interface is expected for now.

Help me troubleshoot link lights in Packet Tracer.

ⓧ I'd like to double check my topology

Verify each device and connection matches this checklist.

Devices (9 total):

  • HQ-R1 (2911 router), HQ-SW1 (2960 switch), HQ-Sales-PC (PC), HQ-Eng-PC (PC).
  • BR-R2 (2911 router), BR-SW1 (2960 switch), BR-Sales-PC (PC), BR-Eng-PC (PC).
  • ISP (2911 router).

Straight-through cables (6):

  • HQ-SW1 Fa0/1 to HQ-R1 Gi0/0.
  • HQ-Sales-PC Fa0 to HQ-SW1 Fa0/2.
  • HQ-Eng-PC Fa0 to HQ-SW1 Fa0/3.
  • BR-SW1 Fa0/1 to BR-R2 Gi0/0.
  • BR-Sales-PC Fa0 to BR-SW1 Fa0/2.
  • BR-Eng-PC Fa0 to BR-SW1 Fa0/3.

Cross-over cables (2):

  • HQ-R1 Gi0/1 to BR-R2 Gi0/1 (WAN link).
  • HQ-R1 Gi0/2 to ISP Gi0/0 (ISP uplink).

Your physical network is built. In the next step, you will create VLANs on each switch to segment departments, and discover firsthand why VLANs alone are not enough for full connectivity.

Configure VLANs and Trunking

Right now, every device on each site shares a single broadcast domain. A broadcast from HQ-Sales-PC hits HQ-Eng-PC, the switch, and the router. In a real enterprise, Sales and Engineering traffic should be isolated from each other.

VLANs solve this by segmenting a single switch into separate Layer 2 networks. In this step, you will create a Sales VLAN and an Engineering VLAN on each switch, assign the correct ports, and set up 802.1Q trunk links so the router can see both VLANs over a single cable.

In this step, get ready to:
  • Create VLAN 10 (Sales) and VLAN 20 (Engineering) on HQ-SW1 and BR-SW1.
  • Assign access ports and configure trunk links on both switches.
  • Test VLAN isolation with a cross-VLAN ping and observe it fail.
Configure VLANs and access ports on HQ-SW1

Each switch needs two VLANs: VLAN 10 for Sales and VLAN 20 for Engineering. After creating the VLANs, you assign each PC's port to the correct VLAN and configure the uplink to the router as a trunk.

  • Click on HQ-SW1 in your Packet Tracer workspace.
  • Click the CLI tab at the top of the device window.
  • Press Enter to get to the command prompt.
  • Create the VLANs and assign the access ports by entering these commands:
enable
configure terminal
vlan 10
name Sales
vlan 20
name Engineering
exit
interface FastEthernet0/2
switchport mode access
switchport access vlan 10
interface FastEthernet0/3
switchport mode access
switchport access vlan 20
exit

What do these commands do?

The enable command enters privileged EXEC mode, and configure terminal enters global configuration mode where you can make changes to the switch.

The vlan 10 and vlan 20 commands create the two VLANs. The name command gives each VLAN a human-readable label so you can identify them later.

For each interface, switchport mode access tells the port it connects to a single device (not another switch). The switchport access vlan command places that port into the specified VLAN.

  • Now configure the trunk port on Fa0/1 (the link to HQ-R1) by entering these commands:
interface FastEthernet0/1
switchport mode trunk
switchport trunk allowed vlan 10,20
end

What is a trunk port?

A trunk port carries traffic from multiple VLANs over a single physical cable. The switchport mode trunk command puts the port into trunking mode.

The switchport trunk allowed vlan 10,20 command restricts the trunk to carry only VLANs 10 and 20. Without this, the trunk would carry all 4094 possible VLANs by default.

  • Verify the VLAN configuration by running:
show vlan brief

You should see VLAN 10 (Sales) with Fa0/2 listed under it, and VLAN 20 (Engineering) with Fa0/3 listed under it.

Don't see your VLANs?

  • Make sure you typed vlan 10 and vlan 20 in global configuration mode (the prompt shows (config)#). If you entered them from privileged EXEC mode (# prompt), the commands would not be recognized.
  • If Fa0/2 still appears under VLAN 1 instead of VLAN 10, re-enter the interface FastEthernet0/2 and switchport access vlan 10 commands.
  • Still stuck? Ask for help debugging your VLAN configuration.
Repeat the VLAN and trunk configuration on BR-SW1

The branch switch needs the exact same VLAN structure so both sites share a consistent network design.

  • Click on BR-SW1 in your workspace.
  • Click the CLI tab, then press Enter to reach the command prompt.
  • Create the VLANs and assign the access ports by entering these commands:
enable
configure terminal
vlan 10
name Sales
vlan 20
name Engineering
exit
interface FastEthernet0/2
switchport mode access
switchport access vlan 10
interface FastEthernet0/3
switchport mode access
switchport access vlan 20
exit
  • Configure the trunk port on Fa0/1 (the link to BR-R2) by entering these commands:
interface FastEthernet0/1
switchport mode trunk
switchport trunk allowed vlan 10,20
end
  • Verify by running:
show vlan brief

You should see the same layout as HQ-SW1: VLAN 10 (Sales) with Fa0/2, and VLAN 20 (Engineering) with Fa0/3.

BR-SW1 output looks different?

  • Double-check that you used the correct port numbers. Fa0/2 should be in VLAN 10 and Fa0/3 should be in VLAN 20.
  • If the trunk port does not appear under show vlan brief, that is correct behavior. Trunk ports are not listed in the show vlan brief output because they carry multiple VLANs. You can confirm the trunk is active with show interfaces trunk.
  • Help me check my BR-SW1 VLAN and trunk setup.
Test VLAN isolation with a cross-VLAN ping

Both switches now have VLANs configured. Before moving on, you need to prove that VLAN segmentation is actually working by testing whether PCs in different VLANs can talk to each other.

  • Click on HQ-Sales-PC in your workspace.
  • Click the Desktop tab at the top.
  • Click IP Configuration.
  • Select Static.
  • Enter 192.168.10.10 in the IP Address field.
  • Enter 255.255.255.0 in the Subnet Mask field.
  • Enter 192.168.10.1 in the Default Gateway field.
  • Now click on HQ-Eng-PC and repeat the same process with these values:
  • Set the IP Address to 192.168.20.10.
  • Set the Subnet Mask to 255.255.255.0.
  • Set the Default Gateway to 192.168.20.1.

Now for the real test. Before you run the ping, think about what you expect to happen. HQ-Sales-PC is in VLAN 10. HQ-Eng-PC is in VLAN 20. Do you think the ping will succeed or fail?

  • Go back to HQ-Sales-PC, click the Desktop tab, and click Command Prompt.
  • Try to ping HQ-Eng-PC by running:
ping 192.168.20.10

The ping fails. You should see "Request timed out" for every attempt. This is exactly what should happen.

Why does the ping fail?

VLANs create separate Layer 2 broadcast domains. HQ-Sales-PC (VLAN 10) and HQ-Eng-PC (VLAN 20) are on completely different networks from the switch's perspective. The switch will not forward traffic between VLANs.

To get traffic from one VLAN to another, you need a Layer 3 device (a router) to route between them. That is exactly what you will configure in the next step using router-on-a-stick.

Ping succeeded instead of failing?

  • If the ping works, the ports may still be in the default VLAN 1. Go back to HQ-SW1 and run show vlan brief to confirm that Fa0/2 is listed under VLAN 10 and Fa0/3 is listed under VLAN 20.
  • Make sure you set different subnets on the two PCs. HQ-Sales-PC should be 192.168.10.10 and HQ-Eng-PC should be 192.168.20.10.
  • My cross-VLAN ping succeeded when it should have failed. Help me debug.

Your switches are segmented. Sales and Engineering are isolated on both sites, and the failed ping proves it. In the next step, you will configure router-on-a-stick on HQ-R1 and BR-R2 so departments can communicate across VLANs.

Enable Inter-VLAN Routing and Configure the WAN

Your VLANs are working. Sales and Engineering traffic is now separated on each site's switch, and you proved it when that cross-VLAN ping failed.

But that separation created a problem. PCs in VLAN 10 cannot talk to PCs in VLAN 20 at all, because switches only operate at Layer 2. A router needs to step in and route traffic between VLANs. In this step, you will configure router-on-a-stick to solve this, and assign IP addresses to the WAN and ISP links so all three routers can communicate.

In this step, get ready to:
  • Configure router-on-a-stick subinterfaces on HQ-R1 and BR-R2 for inter-VLAN routing.
  • Assign IP addresses to the WAN link between sites and the ISP connection.
  • Verify that inter-VLAN pings succeed within a site while cross-site pings still fail.
Configure router-on-a-stick subinterfaces on HQ-R1

Router-on-a-stick works by creating virtual subinterfaces on a single physical router interface. Each subinterface is tagged with a VLAN ID using 802.1Q encapsulation, so the router knows which VLAN each frame belongs to.

The switch sends VLAN-tagged frames over the trunk link to the router. The router receives them on the matching subinterface, makes a routing decision, and sends the reply back down the correct subinterface.

  • Click on HQ-R1 in the workspace and go to the CLI tab.
  • Create the VLAN subinterfaces and enable the physical interface by entering these commands:
enable
configure terminal
interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
 exit
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
 exit
interface GigabitEthernet0/0
 no shutdown
 exit

What do these commands do?

  • interface GigabitEthernet0/0.10 creates a virtual subinterface numbered .10 on the physical Gi0/0 port. The number after the dot is just a label, but matching it to the VLAN ID keeps things readable.
  • encapsulation dot1Q 10 tells the subinterface to accept frames tagged with VLAN 10. This is the command that links the subinterface to a specific VLAN.
  • ip address 192.168.10.1 255.255.255.0 gives the subinterface its gateway IP. This is the address that PCs in VLAN 10 use as their default gateway.
  • no shutdown on the physical GigabitEthernet0/0 interface enables both it and all of its subinterfaces. Without this, the subinterfaces stay down.
  • Verify that the subinterfaces are up by running:
do show ip interface brief

You should see GigabitEthernet0/0.10 and GigabitEthernet0/0.20 listed with their IP addresses and a status of up.

Subinterfaces showing down?

  • Make sure you ran no shutdown on the physical GigabitEthernet0/0 interface, not just on the subinterfaces.
  • Check that the cable from HQ-SW1 Fa0/1 is connected to HQ-R1 GigabitEthernet0/0. A cable in the wrong port means the physical interface has no link.

Why are my subinterfaces still showing down?

Now add the WAN and ISP link addresses on HQ-R1. These are point-to-point connections that connect HQ to the branch site and to the ISP.

  • Configure the WAN and ISP physical interfaces by entering these commands (you should still be in global config mode on HQ-R1):
interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.252
 no shutdown
 exit
interface GigabitEthernet0/2
 ip address 203.0.113.1 255.255.255.252
 no shutdown
 exit

Why /30 subnets on point-to-point links?

A /30 subnet (255.255.255.252) provides exactly two usable host addresses. That is all you need on a link that connects only two routers. Using a larger subnet would waste address space.

The WAN link uses 10.0.0.0/30 (private addressing between your own routers). The ISP link uses 203.0.113.0/30, which comes from the RFC 5737 documentation range reserved for examples and lab use.

  • Verify all interfaces on HQ-R1 are up by running:
do show ip interface brief

You should now see five interfaces with IP addresses and a status of up: the two subinterfaces (Gi0/0.10, Gi0/0.20), the physical trunk port (Gi0/0), the WAN link (Gi0/1), and the ISP link (Gi0/2).

GigabitEthernet0/1 or 0/2 showing down?

  • Check that you used a cross-over cable (not straight-through) for the router-to-router connections. HQ-R1 Gi0/1 connects to BR-R2 Gi0/1, and HQ-R1 Gi0/2 connects to ISP Gi0/0.
  • Confirm you ran no shutdown on each interface. Interfaces are administratively down by default on Cisco routers.

Why is my WAN or ISP interface still down on HQ-R1?

✔️ Awesome, I've got everything!

Great. Make sure you see all five interfaces with status up before moving on.

ⓧ I'd like to double check the full config

Here is the complete set of commands you should have entered on HQ-R1 in this substep. Compare each line against what you typed.

enable
configure terminal
interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
 exit
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
 exit
interface GigabitEthernet0/0
 no shutdown
 exit
interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.252
 no shutdown
 exit
interface GigabitEthernet0/2
 ip address 203.0.113.1 255.255.255.252
 no shutdown
 exit
Configure router-on-a-stick on BR-R2

BR-R2 needs the same subinterface pattern, but with the branch site's IP subnets. It also needs an IP on its WAN interface so it can talk to HQ-R1.

  • Click on BR-R2 in the workspace and go to the CLI tab.
  • Configure the VLAN subinterfaces and WAN link by entering these commands:
enable
configure terminal
interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 ip address 192.168.30.1 255.255.255.0
 exit
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 192.168.40.1 255.255.255.0
 exit
interface GigabitEthernet0/0
 no shutdown
 exit
interface GigabitEthernet0/1
 ip address 10.0.0.2 255.255.255.252
 no shutdown
 exit

What is different on BR-R2?

The command structure is identical to HQ-R1. The only differences are the IP subnets. Branch Sales (VLAN 10) uses 192.168.30.0/24 and Branch Engineering (VLAN 20) uses 192.168.40.0/24.

The WAN interface gets 10.0.0.2, the other end of the /30 link from HQ-R1's 10.0.0.1. BR-R2 does not need an ISP interface because all internet traffic will route through HQ-R1.

  • Verify that BR-R2's interfaces are up by running:
do show ip interface brief

You should see Gi0/0.10, Gi0/0.20, Gi0/0, and Gi0/1 all showing up with their correct IP addresses.

  • Test the WAN link by pinging HQ-R1 from BR-R2:
do ping 10.0.0.1

You should see successful replies. This confirms the WAN link between the two sites is working at Layer 3.

Ping to 10.0.0.1 failing?

  • Confirm that HQ-R1's GigabitEthernet0/1 has IP 10.0.0.1 and is showing up in show ip interface brief.
  • Check the cable between HQ-R1 Gi0/1 and BR-R2 Gi0/1. It must be a cross-over cable since this is a router-to-router link.
  • Make sure both ends have no shutdown applied. Both interfaces must be up for the ping to work.

Why is my WAN ping between HQ-R1 and BR-R2 failing?

Configure the ISP router and verify inter-VLAN routing

The ISP router simulates your internet connection. It needs an IP on its link to HQ-R1, a loopback interface to act as an internet destination, and a static route so it can send return traffic back to your enterprise.

  • Click on ISP in the workspace and go to the CLI tab.
  • Configure the ISP's interface, loopback, and static route by entering these commands:
enable
configure terminal
interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.252
 no shutdown
 exit
interface Loopback0
 ip address 8.8.8.8 255.255.255.255
 exit
ip route 203.0.113.0 255.255.255.252 203.0.113.1
end

What is the loopback interface for?

A loopback interface is a virtual interface that is always up. By assigning it 8.8.8.8, you create a simulated internet destination that your PCs can ping later to test internet connectivity through NAT.

  • Verify the ISP link works by clicking on HQ-R1, going to the CLI tab, and pinging the ISP:
ping 203.0.113.2

You should see successful replies, confirming that HQ-R1 can reach the ISP.

Now for the moment of truth. In Step 2, pinging between VLANs failed because there was no Layer 3 device to route the traffic. Router-on-a-stick should have fixed that.

  • Click on HQ-Sales-PC and go to the Desktop tab.
  • Open Command Prompt.
  • Ping HQ-Eng-PC to test inter-VLAN routing within the HQ site:
ping 192.168.20.10

The ping succeeds. Traffic from VLAN 10 (Sales) is now routed through HQ-R1's subinterfaces to reach VLAN 20 (Engineering). The same ping that failed in Step 2 now works.

Before you run the next command, predict what will happen. Do you think HQ-Sales-PC can ping a device on the branch site's Sales subnet (192.168.30.10)?

  • Try pinging the branch Sales subnet from HQ-Sales-PC:
ping 192.168.30.10

The ping fails. This is expected and intentional.

Why does the cross-site ping fail?

HQ-R1 only knows about its directly connected subnets (192.168.10.0/24, 192.168.20.0/24, 10.0.0.0/30, 203.0.113.0/30). It has no idea that 192.168.30.0/24 exists on the other side of the WAN link.

Without a routing protocol to share subnet information between routers, each router is blind to the other site's networks. That is exactly what OSPF will solve in the next step.

Inter-VLAN routing is working within each site, and both routers can reach each other across the WAN. Next up, you will configure OSPF so the routers automatically learn each other's subnets and cross-site pings finally succeed.

Configure OSPF for Dynamic Routing Between Sites

In the last step, you proved that inter-VLAN routing works within each site. You also saw that cross-site pings fail. Each router only knows about its own directly connected subnets.

You could solve this with static routes, but those break the moment a link goes down. OSPF dynamically discovers neighboring routers, exchanges route information, and adapts when the network changes. In this step, you will configure single-area OSPFv2 so every PC can reach every other PC across both sites.

In this step, get ready to:
  • Configure single-area OSPFv2 on HQ-R1 with network statements and passive interfaces.
  • Configure OSPF on BR-R2 with matching area 0 settings.
  • Verify OSPF neighbor adjacency and test cross-site pings between all four PCs.
Configure single-area OSPFv2 on HQ-R1

OSPF needs three things to start working: a process ID, a router ID to uniquely identify the router, and network statements that tell OSPF which interfaces to activate on. You will also mark the LAN-facing subinterfaces as passive so OSPF does not waste bandwidth sending hello packets where no OSPF neighbor exists.

  • Click on HQ-R1 in the Packet Tracer workspace.
  • Select the CLI tab.
  • Configure OSPF process 1 with network statements for all three subnets by entering these commands:
enable
configure terminal

! Start OSPF process 1 and set a unique router ID
router ospf 1
router-id 1.1.1.1

! Advertise HQ subnets and the WAN link into area 0
network 192.168.10.0 0.0.0.255 area 0
network 192.168.20.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.3 area 0

! Stop OSPF hellos on LAN subinterfaces (no OSPF neighbor there)
passive-interface GigabitEthernet0/0.10
passive-interface GigabitEthernet0/0.20
end

What do these commands do?

  • router ospf 1 starts OSPF process 1. The number is a local identifier, not shared between routers.
  • router-id 1.1.1.1 gives HQ-R1 a unique identity in the OSPF domain. No two routers can share the same router ID.
  • Each network statement uses a wildcard mask (the inverse of a subnet mask) to match interfaces. OSPF activates on every interface whose IP falls within that range.
  • passive-interface stops OSPF from sending hello packets on the VLAN subinterfaces. Those links connect to end-user PCs, not to other OSPF routers.

Why OSPF instead of static routes?

Static routes require you to manually update every router whenever a subnet is added or a link goes down. OSPF handles this automatically by exchanging link-state advertisements between neighbors.

OSPF is also the routing protocol covered in CCNA exam topic 3.4, which falls under the IP Connectivity domain (25% of the exam).

  • Confirm OSPF is running on HQ-R1 by entering this command:
show ip protocols

You should see Routing Protocol is "ospf 1" in the output, along with the three networks you just configured.

Not seeing OSPF in the output?

  • Make sure you typed router ospf 1 (not router ospf without a process number). The process ID is required.
  • Check that you ran end after the OSPF commands to return to privileged EXEC mode before running show ip protocols.
  • Verify your network statements match the subnets exactly. A wrong wildcard mask like 0.0.0.255 matches a /24, while 0.0.0.3 matches a /30.

Still stuck? Help me troubleshoot why OSPF is not showing up in show ip protocols on HQ-R1.

Configure OSPF on BR-R2

BR-R2 needs the same OSPF setup, but with a different router ID and network statements that match the branch subnets. Once both routers are running OSPF on the shared WAN link, they will automatically discover each other.

  • Click on BR-R2 in the workspace.
  • Select the CLI tab.
  • Configure OSPF on BR-R2 with the branch subnets by entering these commands:
enable
configure terminal

! Start OSPF process 1 with a unique router ID for BR-R2
router ospf 1
router-id 2.2.2.2

! Advertise branch subnets and the WAN link into area 0
network 192.168.30.0 0.0.0.255 area 0
network 192.168.40.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.3 area 0

! Stop OSPF hellos on LAN subinterfaces
passive-interface GigabitEthernet0/0.10
passive-interface GigabitEthernet0/0.20
end

What is different about this configuration?

The structure is identical to HQ-R1, but the router ID is 2.2.2.2 (each router needs a unique ID) and the network statements match the branch subnets (192.168.30.0 and 192.168.40.0) instead of the HQ subnets.

The WAN link (10.0.0.0 0.0.0.3) appears on both routers. This is the shared link where OSPF hello packets are exchanged to form the neighbor adjacency.

OSPF adjacency takes about 10 to 15 seconds to form in Packet Tracer. Wait a moment, then verify.

  • Switch back to HQ-R1 and check for the OSPF neighbor by entering this command:
show ip ospf neighbor

You should see BR-R2 listed with Neighbor ID 2.2.2.2 and a state of FULL/-. The FULL state means the routers have fully exchanged their link-state databases. The /- means there is no DR/BDR election on this point-to-point link.

No neighbor showing up?

  • Wait 15 to 20 seconds and try show ip ospf neighbor again. OSPF needs time to exchange hellos and reach FULL state.
  • Verify that both routers advertise the WAN link (network 10.0.0.0 0.0.0.3 area 0). If either router is missing this statement, OSPF cannot send hellos across the WAN.
  • Make sure the area number matches on both routers. Both must use area 0. A mismatch prevents adjacency from forming.

Still stuck? Help me troubleshoot why my OSPF neighbor adjacency is not forming between HQ-R1 and BR-R2.

✔️ Awesome, I've got everything!

Great. Make sure you see FULL/- in the show ip ospf neighbor output before moving on.

ⓧ I'd like to double check the full code

Here is the complete OSPF configuration for both routers. Compare each section against your own setup.

! === HQ-R1 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 10.0.0.0 0.0.0.3 area 0
 passive-interface GigabitEthernet0/0.10
 passive-interface GigabitEthernet0/0.20

! === BR-R2 OSPF Configuration ===
router ospf 1
 router-id 2.2.2.2
 network 192.168.30.0 0.0.0.255 area 0
 network 192.168.40.0 0.0.0.255 area 0
 network 10.0.0.0 0.0.0.3 area 0
 passive-interface GigabitEthernet0/0.10
 passive-interface GigabitEthernet0/0.20
Assign branch PC IPs and verify cross-site connectivity

OSPF is now sharing routes between the two sites. Before you can test cross-site pings, the branch PCs need IP addresses. You will assign static IPs to both branch PCs, then prove that traffic flows end-to-end.

  • Click on BR-Sales-PC in the workspace.
  • Select the Desktop tab, then click IP Configuration.
  • Select the Static radio button.
  • Enter 192.168.30.10 for the IP Address.
  • Enter 255.255.255.0 for the Subnet Mask.
  • Enter 192.168.30.1 for the Default Gateway.
  • Click on BR-Eng-PC in the workspace.
  • Open Desktop > IP Configuration.
  • Select Static.
  • Enter 192.168.40.10 for the IP Address.
  • Enter 255.255.255.0 for the Subnet Mask.
  • Enter 192.168.40.1 for the Default Gateway.

Both branch PCs are now configured. Time to see if OSPF is doing its job.

  • First, check what routes OSPF learned. Click on HQ-R1, open the CLI tab, and run this command:
show ip route ospf

You should see routes marked with O for the branch subnets 192.168.30.0/24 and 192.168.40.0/24. The O prefix means OSPF learned these routes dynamically from BR-R2.

What does the O route prefix mean?

Cisco IOS uses letter codes in the routing table to show where each route came from. C means directly connected. S means static. O means OSPF. Seeing O routes for the branch subnets confirms that OSPF is working and HQ-R1 now knows how to reach the other site.

Before you run the cross-site ping, predict what you think will happen. Will a ping from HQ-Sales-PC to BR-Eng-PC succeed now that OSPF is sharing routes?

  • Click on HQ-Sales-PC in the workspace.
  • Select the Desktop tab, then click Command Prompt.
  • Test cross-site connectivity by entering this command:
ping 192.168.40.10

The ping succeeds. HQ-Sales-PC is reaching BR-Eng-PC across two routers and two sites. The first ping reply may time out (this is normal in Packet Tracer due to ARP resolution), but the remaining replies should all succeed.

All pings timing out?

  • Verify the branch PC IPs are correct. On BR-Eng-PC, the IP should be 192.168.40.10 with gateway 192.168.40.1. A wrong gateway means the PC does not know where to send traffic.
  • Run show ip ospf neighbor on HQ-R1 again. If the neighbor is not in FULL state, OSPF is still converging. Wait a few more seconds and retry.
  • Check that the trunk links on both switches are still up. Run show interfaces trunk on HQ-SW1 and BR-SW1 to confirm.

Still stuck? Help me troubleshoot why my cross-site ping from HQ-Sales-PC to BR-Eng-PC is failing.

Every PC can now reach every other PC across both sites. OSPF discovered the routes automatically, with no static entries needed. Next up, you will replace those static PC IPs with DHCP for automatic addressing and add NAT so your PCs can reach the simulated internet.

Configure DHCP and NAT for Internet Access

Your two-site network is fully connected. OSPF dynamically routes traffic between HQ and Branch, and every PC can ping every other PC across both sites.

There are two problems left. First, every PC has a manually assigned static IP. In a real enterprise with hundreds of devices, that does not scale. Second, none of your PCs can reach the internet because HQ-R1 has no default route and no address translation. In this step, you will configure DHCP to hand out IP addresses automatically and NAT overload (PAT) to let all internal traffic share a single public IP for internet access.

In this step, get ready to:
  • Configure DHCP pools on HQ-R1 and BR-R2 for automatic IP assignment.
  • Set up NAT overload (PAT) on HQ-R1 so internal traffic can reach the simulated internet.
  • Verify that all PCs receive DHCP addresses and can ping 8.8.8.8.
Configure DHCP pools on both routers

A DHCP pool defines a range of IP addresses that the router hands out to devices automatically. You need one pool per VLAN so each department gets addresses from the correct subnet.

  • Click on HQ-R1 in the Packet Tracer workspace, then select the CLI tab.
  • Configure the HQ DHCP pools by entering these commands:
enable
configure terminal
! Exclude gateway IPs so the router never hands them out
ip dhcp excluded-address 192.168.10.1
ip dhcp excluded-address 192.168.20.1
! DHCP pool for the HQ Sales department
ip dhcp pool HQ-SALES
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 8.8.8.8
 exit
! DHCP pool for the HQ Engineering department
ip dhcp pool HQ-ENGINEERING
 network 192.168.20.0 255.255.255.0
 default-router 192.168.20.1
 dns-server 8.8.8.8
 exit
exit

What do these commands do?

  • ip dhcp excluded-address tells the router to never assign the gateway IP to a PC. Without this, a PC could grab the router's own address.
  • ip dhcp pool HQ-SALES creates a named pool. The network line defines which subnet to draw addresses from.
  • default-router tells DHCP clients which gateway to use. dns-server tells them where to resolve domain names.
  • Verify the pools exist by running this command:
show ip dhcp pool

You should see two pools listed: HQ-SALES with subnet 192.168.10.0/24 and HQ-ENGINEERING with subnet 192.168.20.0/24. No addresses are leased yet because all PCs still have static IPs.

Not seeing both pools?

  • Make sure you typed exit after each pool's dns-server line. Missing the exit means the second pool's commands got added inside the first pool.
  • Check that the subnet mask is 255.255.255.0, not a wildcard mask like 0.0.0.255. DHCP pools use subnet masks, not wildcard masks.
  • help me troubleshoot my DHCP pool configuration on HQ-R1

Now repeat the same pattern on BR-R2 for the branch subnets.

  • Click on BR-R2 in the workspace, then select the CLI tab.
  • Configure the branch DHCP pools by entering these commands:
enable
configure terminal
! Exclude gateway IPs from the branch pools
ip dhcp excluded-address 192.168.30.1
ip dhcp excluded-address 192.168.40.1
! DHCP pool for the Branch Sales department
ip dhcp pool BR-SALES
 network 192.168.30.0 255.255.255.0
 default-router 192.168.30.1
 dns-server 8.8.8.8
 exit
! DHCP pool for the Branch Engineering department
ip dhcp pool BR-ENGINEERING
 network 192.168.40.0 255.255.255.0
 default-router 192.168.40.1
 dns-server 8.8.8.8
 exit
exit

Why configure DHCP on each router separately?

Each router serves as the DHCP server for its own directly connected subnets. HQ-R1 owns the 192.168.10.0/24 and 192.168.20.0/24 subnets, so it serves those pools. BR-R2 owns 192.168.30.0/24 and 192.168.40.0/24, so it serves those.

  • Verify the branch pools by running:
show ip dhcp pool

You should see BR-SALES with subnet 192.168.30.0/24 and BR-ENGINEERING with subnet 192.168.40.0/24.

Configure NAT overload (PAT) on HQ-R1

Your PCs use private IP addresses (192.168.x.x) that are not routable on the public internet. NAT overload (also called PAT) translates all internal private addresses to a single public IP. It uses unique port numbers to keep track of which internal device sent each packet.

  • Return to the CLI tab on HQ-R1.
  • Create the ACL, enable NAT overload, and mark the inside/outside interfaces by entering these commands:
enable
configure terminal
! ACL identifies which internal subnets get translated
access-list 1 permit 192.168.10.0 0.0.0.255
access-list 1 permit 192.168.20.0 0.0.0.255
access-list 1 permit 192.168.30.0 0.0.0.255
access-list 1 permit 192.168.40.0 0.0.0.255
! Translate matched traffic using the ISP-facing interface
ip nat inside source list 1 interface GigabitEthernet0/2 overload
! Mark which interfaces face internal networks
interface GigabitEthernet0/0.10
 ip nat inside
interface GigabitEthernet0/0.20
 ip nat inside
interface GigabitEthernet0/1
 ip nat inside
! Mark the ISP-facing interface as the outside
interface GigabitEthernet0/2
 ip nat outside
exit

What does this NAT configuration do?

  • access-list 1 is a standard ACL that matches all four internal subnets (both HQ and Branch). Only traffic from these subnets will be translated.
  • ip nat inside source list 1 interface GigabitEthernet0/2 overload tells the router to translate any traffic matching ACL 1 using GigabitEthernet0/2's public IP. The overload keyword enables PAT so multiple devices share that one address.
  • ip nat inside and ip nat outside labels tell the router which direction traffic flows. Internal subnets are "inside" and the ISP link is "outside".

Why does ACL 1 include the branch subnets?

Branch PCs send internet-bound traffic through OSPF to HQ-R1, which is the network's single exit point to the ISP. HQ-R1 must translate branch traffic too, so the ACL includes 192.168.30.0/24 and 192.168.40.0/24 alongside the HQ subnets.

  • Confirm the NAT configuration is in place by running:
show ip nat statistics

You should see GigabitEthernet0/0.10, GigabitEthernet0/0.20, and GigabitEthernet0/1 listed as inside interfaces. GigabitEthernet0/2 should appear as the outside interface. No translations exist yet because no traffic has flowed to the ISP.

Not seeing the correct interfaces?

  • If an interface is missing, re-enter its configuration mode and apply ip nat inside or ip nat outside again. A typo in the interface name silently creates a new subinterface instead of modifying the existing one.
  • Make sure you applied ip nat inside on GigabitEthernet0/1 (the WAN link to BR-R2). Branch traffic arrives on this interface, so it must be marked as inside.
  • help me fix my NAT interface configuration on HQ-R1

NAT is ready to translate, but HQ-R1 still has no idea where to send internet-bound traffic. You need a default route pointing to the ISP, and you need to share that route with BR-R2 through OSPF.

  • Add the default route and redistribute it into OSPF by entering these commands on HQ-R1:
configure terminal
! Default route sends all unknown traffic to the ISP
ip route 0.0.0.0 0.0.0.0 203.0.113.2
! Tell OSPF to advertise this default route to BR-R2
router ospf 1
 default-information originate
 exit
exit

What does default-information originate do?

By default, OSPF does not advertise static routes to its neighbors. The default-information originate command tells HQ-R1 to inject the default route into its OSPF updates. BR-R2 receives the default route automatically and forwards internet-bound branch traffic toward HQ-R1.

  • Verify the default route exists by running:
show ip route

Look for a line starting with S* followed by 0.0.0.0/0 pointing to 203.0.113.2. The S* means it is a static default route.

✔️ I see the S* 0.0.0.0/0 route

The default route is in place and OSPF is advertising it to BR-R2. Time to test everything end to end.

ⓧ I don't see a default route

  • Re-enter global configuration mode and type the default route command again:
configure terminal
ip route 0.0.0.0 0.0.0.0 203.0.113.2
exit
  • Make sure the next-hop IP 203.0.113.2 matches the ISP router's GigabitEthernet0/0 address exactly.
  • Run show ip route again to confirm.
Switch all PCs to DHCP and verify end to end

Everything is configured. The DHCP pools are ready on both routers, NAT overload is active on HQ-R1, and the default route is shared via OSPF. Now you will switch each PC from its static IP to DHCP mode and test the full network.

  • Click on HQ-Sales-PC in the workspace.
  • Select the Desktop tab, then click IP Configuration.
  • Click the DHCP radio button (it is currently set to Static).

After a moment, the IP address field fills in automatically with an address in the 192.168.10.0/24 range. The gateway should show 192.168.10.1 and the DNS server should show 8.8.8.8.

  • Repeat this process for the remaining three PCs. Click each PC, open Desktop > IP Configuration, and switch to DHCP:
  • HQ-Eng-PC should receive an address in the 192.168.20.0/24 range.
  • BR-Sales-PC should receive an address in the 192.168.30.0/24 range.
  • BR-Eng-PC should receive an address in the 192.168.40.0/24 range.

PC not getting an IP address?

  • If the IP field shows 0.0.0.0 or stays blank, click the Static radio button, wait a second, then click DHCP again to force a new request.
  • Verify the trunk link between the switch and router is still up. If the link light on Fa0/1 is not green, the DHCP request cannot reach the router.
  • Check that the PC's switch port is in the correct VLAN. Run show vlan brief on the switch to confirm Fa0/2 is in VLAN 10 and Fa0/3 is in VLAN 20.
  • help me troubleshoot why my PC is not receiving a DHCP address
  • Verify the DHCP leases on HQ-R1 by clicking on HQ-R1, opening the CLI tab, and running:
show ip dhcp binding

You should see two entries: one for HQ-Sales-PC in the 192.168.10.0/24 range and one for HQ-Eng-PC in the 192.168.20.0/24 range.

Now for the big test. Before you run the next command, predict the outcome: do you think HQ-Sales-PC can reach 8.8.8.8 on the simulated internet? What has to happen for that ping to succeed?

  • Click on HQ-Sales-PC, select the Desktop tab, then click Command Prompt.
  • Test internet connectivity by running:
ping 8.8.8.8

You should see replies coming back from 8.8.8.8. The first one or two pings may time out while ARP resolves. That is normal.

What just happened behind the scenes?

HQ-Sales-PC sent the ping to its default gateway (HQ-R1). HQ-R1 checked its routing table, found the default route pointing to 203.0.113.2 (the ISP), and translated the source address from 192.168.10.x to 203.0.113.1 using NAT overload. The ISP router received the packet, hit its Loopback0 (8.8.8.8), and sent the reply back.

  • Confirm NAT translated the traffic by returning to HQ-R1's CLI tab and running:
show ip nat translations

You should see at least one entry showing HQ-Sales-PC's private address mapped to 203.0.113.1 with a unique port number. This is PAT in action.

  • Test internet connectivity from the remaining three PCs. Open the Command Prompt on each PC (Desktop > Command Prompt) and run ping 8.8.8.8.

All four PCs should receive replies from 8.8.8.8.

Pings to 8.8.8.8 failing?

  • First check that HQ-R1 itself can reach the ISP. On HQ-R1's CLI, run ping 203.0.113.2. If this fails, the GigabitEthernet0/2 interface may be down or the IP address is incorrect.
  • Check that the ISP router has its static route. On the ISP CLI, run show ip route and look for the route to 203.0.113.0/30. Without this, the ISP cannot send replies back.
  • If HQ PCs work but Branch PCs fail, verify that BR-R2 received the default route from OSPF. On BR-R2's CLI, run show ip route and look for a line starting with O*E2 for the default route. If it is missing, return to HQ-R1 and re-enter default-information originate under router ospf 1.
  • help me troubleshoot why my PCs cannot ping 8.8.8.8 through NAT

Secret mission

Lock Down the Network with Extended ACLs

Your network is wide open. Any PC can reach any subnet with no restrictions. Can you write an extended ACL that blocks Engineering from accessing Sales while keeping internet access alive?

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 resources to come back later, pause them to free up memory, or delete them entirely.

Resources you used:

  • Your Packet Tracer topology file (.pkt) containing the full two-site enterprise network.

Keep everything running

No action needed. Choose this if you are still actively building or want to extend this topology further.

  • Your .pkt file stays on your computer. You can reopen it in Packet Tracer any time.
  • This topology is a great foundation to build on. You could add more sites, introduce IPv6 addressing, or configure port security on the switches.

Pause - I'll come back to this later

Close Packet Tracer to free up memory on your computer. Your topology is already saved in the .pkt file.

  • Make sure you have saved your topology. In Packet Tracer, press Ctrl+S to save.
  • Close Packet Tracer by clicking File, then Exit.
  • When you are ready to continue, double-click your .pkt file to reopen it in Packet Tracer with all your configurations intact.

Delete - I don't want to use this again

Remove your project file to start fresh. This permanently deletes your topology and all device configurations.

  • Close Packet Tracer if it is still open.
  • Open File Explorer and navigate to the folder where you saved your .pkt file.
  • Right-click the .pkt file and select Delete.
  • Empty your Recycle Bin if you want to reclaim the disk space immediately.

Nice Work!

Nice Work!

Nice work! You just built a complete two-site enterprise network from scratch in Packet Tracer, connecting a headquarters and branch office with every core networking layer configured and verified.

You've learned how to:

  • Segment two office sites into department VLANs with 802.1Q trunking and configure router-on-a-stick inter-VLAN routing so departments can communicate over a single trunk link.
  • Deploy single-area OSPFv2 to dynamically route traffic between HQ and Branch, so routers discover and maintain paths without manual static route configuration.
  • Configure DHCP pools for automatic IP addressing and NAT overload (PAT) for internet access, then verify every network layer with show commands and end-to-end ping tests.
  • Secret Mission: Applied extended ACLs to enforce department-level access control, blocking Engineering from reaching the Sales subnet while preserving internet access.

Ready to quiz yourself?