Connect a Two-Site Company Network
Build a VLAN-segmented, OSPF-routed, ACL-secured network in Packet Tracer.
Introduction
30 Second Summary
Every company with more than one office faces the same problem. How do employees at different locations share files, access internal tools, and communicate without exposing sensitive systems to the wrong people?
In this project, you will build a two-site company network in Cisco Packet Tracer, connecting a Headquarters (with Sales and Engineering departments) to a Branch Office using VLANs, OSPF dynamic routing, and ACLs.
What You'll Build
You type a ping from a Branch Office PC, and within milliseconds it reaches the Sales department at HQ but gets blocked cold from Engineering servers. That is your network enforcing real security policies, and you built it from scratch.
By the end of this project, you'll have:
- A working inter-VLAN routing setup where Sales PCs can ping Engineering PCs through a router-on-a-stick configuration.
- A Branch Office that can reach Sales resources but is blocked from Engineering servers, proving your access control list is doing its job.
- A network where adding a new site only requires plugging in a router and enabling OSPF. No manual static routes needed.
- Secure SSH remote management so you can configure any router from any PC on the network.
- Secret Mission: Add a third Data Center site that auto-discovers all routes via OSPF and implement named ACLs for granular traffic control.
Are there any prerequisites?
You should have a basic understanding of networking fundamentals like IP addressing, subnetting, and the OSI model. You also need Cisco Packet Tracer installed on your computer (it requires a free Cisco Networking Academy account).
Before We Start
Before we dive in, let's lock in what you're about to build and why it matters.
Set Up the Topology
Every network starts with physical hardware. Without routers, switches, PCs, and cables connecting them, there is nothing to configure.
In this step, you will build the two-site company network from scratch in Packet Tracer. You will place all the devices, cable them together, configure basic security settings, and confirm the WAN link between sites is live.
In this step, get ready to:
- Place and cable all network devices in the Packet Tracer workspace.
- Configure hostnames, passwords, and IP addresses on each device.
- Verify the WAN link between the two routers with a ping test.
Build the topology in Packet Tracer
You will place six devices in the workspace and connect them with the correct cable types. Think of this as laying out all the physical equipment in a server room before turning anything on.
Place the routers
- In the bottom-left panel of Packet Tracer, click the Network Devices category (the icon that looks like a small switch/router).
- Click the Routers subcategory in the row below.
- Find the 2911 model in the device-specific selection box. Hover over devices to see their names.
- Click the 2911 icon, then click in the left side of your workspace to place the first router. This will be your HQ router.
- Click in the right side of your workspace to place the second router. This will be your Branch router.
Place the switch and PCs
- Click the Switches subcategory in the bottom-left panel.
- Find 2960-24TT and click to place it near the HQ router. This is your HQ switch.
- Click the End Devices category in the top row of the bottom-left panel.
- Click the PC icon (hover to confirm it says PC-PT) and place three PCs: two near the HQ switch (Sales-PC and Eng-PC) and one near the Branch router (Branch-PC).
Rename all devices
- Click the first router you placed (left side).
- In the window that opens, click the Config tab.
- In the Display Name field, type HQ-Router and press Enter.
- Repeat for the second router (Branch-Router), the switch (HQ-Switch), and the three PCs (Sales-PC, Eng-PC, Branch-PC).
Why rename devices?
Default names like Router0 and PC2 mean nothing when you are troubleshooting a network with dozens of devices. Display names help you identify devices at a glance in the workspace.
Cable the devices together
Now you will connect everything with the correct cable types. In networking, straight-through cables connect unlike devices (switch to PC, switch to router). Cross-over cables connect like devices (router to router).
- Click the Connections category in the bottom-left panel (the lightning bolt icon).
- Select Copper Straight-Through from the cable options.
- Click HQ-Switch, select FastEthernet0/1 from the pop-up menu. Then click HQ-Router and select GigabitEthernet0/0.
- With Copper Straight-Through still selected, click HQ-Switch, select FastEthernet0/2. Then click Sales-PC and select FastEthernet0.
- Click HQ-Switch, select FastEthernet0/3. Then click Eng-PC and select FastEthernet0.
- Now switch to Copper Cross-Over cable in the connections panel.
- Click HQ-Router, select GigabitEthernet0/1. Then click Branch-Router and select GigabitEthernet0/0.
- Switch back to Copper Straight-Through. Click Branch-Router, select GigabitEthernet0/1. Then click Branch-PC and select FastEthernet0.
Why a cross-over cable between routers?
Cross-over cables swap the transmit and receive pairs so two identical device types can communicate directly. Modern Cisco routers support auto-MDIX (automatic crossover detection), but using the correct cable type is a professional habit that the CCNA exam expects you to know.
Wait about 30 seconds. You should see all the link lights turn green on every connection. The switch ports may start amber while STP converges, then turn green.
Link lights still amber or red?
- Amber lights on switch ports are normal for 30 seconds while Spanning Tree Protocol converges. Wait a full minute before troubleshooting.
- Red or missing lights mean you chose the wrong cable type or connected to the wrong port. Delete the cable (click the Delete tool, then click the bad cable) and reconnect with the correct cable type and interface.
- Double-check that the HQ-Router to Branch-Router link uses a cross-over cable, not a straight-through cable.
help me figure out why my Packet Tracer link lights are not turning green
Configure basic device settings
Every network device needs a hostname (so you can identify it), passwords (so only authorized users can access it), and IP addresses on the interfaces that carry traffic. You will configure all three routers and the switch now.
Configure HQ-Router
- Click HQ-Router in the workspace.
- Click the CLI tab in the device window. Press Enter to get the router prompt.
- Enter the following commands to set the hostname, passwords, and WAN interface IP:
enable
configure terminal
hostname HQ-Router
enable secret class
line console 0
password cisco
login
exit
line vty 0 4
password cisco
login
exit
service password-encryption
banner motd #Unauthorized access prohibited#
interface GigabitEthernet0/1
ip address 10.10.30.1 255.255.255.252
no shutdown
exit
exit
What do these commands do?
- enable secret class sets the privileged mode password (encrypted by default).
- The line console 0 and line vty 0 4 sections protect physical and remote access with a password.
- service password-encryption encrypts all plaintext passwords stored in the running configuration.
- The GigabitEthernet0/1 interface connects HQ-Router to Branch-Router over the WAN link. The /30 subnet (255.255.255.252) provides exactly two usable addresses for a point-to-point link.
- Verify the interface is up by running this command:
show ip interface brief
You should see GigabitEthernet0/1 listed with IP 10.10.30.1 and Status/Protocol both showing up.
Interface showing down/down?
- Make sure you typed no shutdown on the interface. Without it, the interface stays administratively down.
- Confirm the cable is connected to GigabitEthernet0/1 (not GigabitEthernet0/0) by hovering over the cable endpoint on HQ-Router in the workspace.
help me troubleshoot why my HQ-Router interface shows down
Configure Branch-Router
- Click Branch-Router in the workspace and open the CLI tab.
- Enter these commands to set basic security and configure both interfaces:
enable
configure terminal
hostname Branch-Router
enable secret class
line console 0
password cisco
login
exit
line vty 0 4
password cisco
login
exit
service password-encryption
banner motd #Unauthorized access prohibited#
interface GigabitEthernet0/0
ip address 10.10.30.2 255.255.255.252
no shutdown
exit
interface GigabitEthernet0/1
ip address 192.168.30.1 255.255.255.0
no shutdown
exit
exit
What do these interfaces connect to?
- GigabitEthernet0/0 (10.10.30.2/30) is the WAN side, connecting back to HQ-Router.
- GigabitEthernet0/1 (192.168.30.1/24) is the LAN side, serving as the default gateway for Branch-PC.
- Verify both interfaces are up:
show ip interface brief
You should see both GigabitEthernet0/0 and GigabitEthernet0/1 showing up with their respective IP addresses.
Configure HQ-Switch
- Click HQ-Switch in the workspace and open the CLI tab.
- Enter these commands to set the hostname and passwords:
enable
configure terminal
hostname HQ-Switch
enable secret class
line console 0
password cisco
login
exit
line vty 0 4
password cisco
login
exit
service password-encryption
banner motd #Unauthorized access prohibited#
exit
Why no IP address on the switch?
Layer 2 switches forward frames based on MAC addresses, not IP addresses. HQ-Switch does not need an IP for traffic to flow through it. You would only assign a management IP (on VLAN 1) if you wanted to SSH into the switch remotely.
Your switch prompt now shows HQ-Switch# instead of the default Switch#. That confirms your configuration is active.
Assign Branch-PC its IP address
- Click Branch-PC in the workspace.
- Click the Desktop tab in the device window.
- Click IP Configuration.
- Enter the IP address: 192.168.30.10.
- Enter the subnet mask: 255.255.255.0.
- Enter the default gateway: 192.168.30.1.
- Close the Branch-PC window.
Why do PCs need a default gateway?
The default gateway tells Branch-PC where to send traffic that is not on its own subnet. Without it, Branch-PC can only talk to other devices on the 192.168.30.0/24 network. The gateway (192.168.30.1) is Branch-Router's LAN interface, which forwards traffic to other networks.
Verify the WAN link
Both routers now have IP addresses on the point-to-point link between them. Time to confirm they can talk to each other.
- Click HQ-Router and open the CLI tab.
- Before you run the next command, predict: will HQ-Router be able to reach Branch-Router at 10.10.30.2? Both interfaces are up and they share the same /30 subnet, so what do you think?
- Test the WAN link by running this ping:
ping 10.10.30.2
You should see five reply lines with ! characters, confirming the point-to-point link is live. The success rate should show 100 percent (5/5).
Seeing dots (.....) instead of exclamation marks?
- Verify both sides of the link have matching subnet masks. HQ-Router G0/1 should be 10.10.30.1 255.255.255.252 and Branch-Router G0/0 should be 10.10.30.2 255.255.255.252.
- Check that both interfaces show up/up in show ip interface brief. If either is administratively down, enter the interface and type no shutdown.
- The first ping attempt sometimes shows one dot followed by exclamation marks. This is normal. ARP needs one packet to resolve the MAC address.
help me figure out why my ping between HQ-Router and Branch-Router is failing
✔️ Awesome, I've got everything!
Great. Save your Packet Tracer file now (Ctrl+S or Cmd+S) so you do not lose your work.
ⓧ I'd like to double check the full configuration
Scroll up and confirm you completed each of these configuration blocks in order:
- HQ-Router: hostname set to HQ-Router, enable secret and line passwords configured, service password-encryption enabled, banner motd set, GigabitEthernet0/1 has IP 10.10.30.1/30 and is no shutdown.
- Branch-Router: hostname set to Branch-Router, enable secret and line passwords configured, service password-encryption enabled, banner motd set, GigabitEthernet0/0 has IP 10.10.30.2/30, GigabitEthernet0/1 has IP 192.168.30.1/24, both no shutdown.
- HQ-Switch: hostname set to HQ-Switch, enable secret and line passwords configured, service password-encryption enabled, banner motd set.
- Branch-PC: IP 192.168.30.10, mask 255.255.255.0, gateway 192.168.30.1.
- WAN ping from HQ-Router to 10.10.30.2 succeeds with 100% success rate.
Your physical foundation is in place. Both sites are connected and can reach each other over the WAN link. Next up, you will create VLANs to separate departments at HQ and discover why that breaks communication between them.
Create VLANs and Watch Them Fail
Right now, every device at HQ shares the same broadcast domain. That means any broadcast from Sales-PC floods to Eng-PC and vice versa. In a real company, departments like Sales and Engineering need their own isolated network segments.
VLANs solve the isolation problem by splitting a single switch into multiple virtual switches. In this step, you'll create two VLANs and assign each department's PC to its own VLAN. But there's a catch: isolation means the PCs can no longer talk to each other.
In this step, get ready to:
- Create VLAN 10 (Sales) and VLAN 20 (Engineering) on HQ-Switch.
- Assign each PC to its department's VLAN with the correct IP address.
- Test connectivity between VLANs and observe the designed failure.
Configure VLANs on HQ-Switch
A VLAN is a logical grouping of switch ports that creates a separate broadcast domain. Devices in VLAN 10 cannot communicate with devices in VLAN 20 without a router in between.
- Click on HQ-Switch in your topology, then select the CLI tab.
- Create VLAN 10 and VLAN 20 by entering these commands:
enable
configure terminal
vlan 10
name Sales
vlan 20
name Engineering
exit
What do these commands do?
- enable enters privileged EXEC mode (required before configuration).
- configure terminal enters global configuration mode where you can make changes.
- vlan 10 creates VLAN 10 and enters VLAN config mode.
- name Sales gives the VLAN a human-readable name so your team knows its purpose.
- Confirm your VLANs were created by running:
show vlan brief
You should see VLAN 10 (Sales) and VLAN 20 (Engineering) listed in the output with status active. No ports are assigned yet, so the port columns for these VLANs will be empty.
Don't see your VLANs listed?
- Make sure you typed exit after creating the VLANs to return to global config mode. Run show vlan brief from privileged EXEC mode (after typing end or pressing Ctrl+Z).
- Check that you didn't accidentally type vlan10 without the space. The VLAN ID and the command must be separated.
- help me troubleshoot missing VLANs on my switch
Now assign each PC's switch port to its VLAN so traffic is properly segmented.
- Assign Fa0/2 to VLAN 10 and Fa0/3 to VLAN 20 by entering these commands:
configure terminal
interface fa0/2
switchport mode access
switchport access vlan 10
interface fa0/3
switchport mode access
switchport access vlan 20
end
What do these port commands do?
- switchport mode access tells the port it connects to an end device (not another switch). Access ports carry traffic for only one VLAN.
- switchport access vlan 10 assigns that port to VLAN 10. Any device plugged into Fa0/2 is now in the Sales broadcast domain.
- Verify port assignments by running:
show vlan brief
You should now see Fa0/2 listed under VLAN 10 and Fa0/3 listed under VLAN 20.
Ports still showing under VLAN 1?
- Verify you typed switchport access vlan 10 while inside the correct interface (interface fa0/2). If you assigned the wrong port, re-enter the correct interface and reassign.
- Make sure you typed end to fully exit config mode before running show vlan brief.
- help me fix my VLAN port assignments
Assign PC IP addresses in their VLAN subnets
Each VLAN operates on its own subnet. Sales-PC needs an IP in the 192.168.10.0/24 range, and Eng-PC needs one in 192.168.20.0/24.
- Click on Sales-PC in your topology.
- Select the Desktop tab.
- Click IP Configuration.
- Set the IP address to 192.168.10.10.
- Set the subnet mask to 255.255.255.0.
- Set the default gateway to 192.168.10.1.
- Close the IP Configuration window.
Why set a gateway that doesn't exist yet?
The gateway 192.168.10.1 is the address the PC will use to reach other subnets. You haven't configured this IP on any router interface yet. That's part of why the upcoming ping will fail.
- Click on Eng-PC in your topology.
- Select the Desktop tab, then click IP Configuration.
- 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.
- Close the IP Configuration window.
- Verify Sales-PC's IP by clicking on Sales-PC, selecting the Desktop tab, opening Command Prompt, and running:
ipconfig
You should see the IP address 192.168.10.10 and default gateway 192.168.10.1 confirmed in the output.
Test and observe the failure
Both PCs are now on separate VLANs with IP addresses in different subnets. The switch has physically isolated their traffic into two separate broadcast domains.
Before you test, think about this: what would need to exist for traffic to cross between two different subnets on two different VLANs?
- On Sales-PC's command prompt (Desktop tab), run this ping:
ping 192.168.20.10
The ping fails with Request timed out. This is the expected result.
Why does the ping fail?
Two things are preventing communication here.
- VLAN isolation is working. The switch does not forward frames between VLAN 10 and VLAN 20. Sales-PC's traffic never reaches Eng-PC at the Layer 2 level.
- No router is bridging the subnets. Even if frames could cross, Sales-PC's gateway (192.168.10.1) doesn't exist on any device yet. There is nothing to route the packet to the 192.168.20.0/24 network.
This is the exact problem router-on-a-stick solves in the next step.
Seeing a reply instead of Request timed out?
- Double-check that you assigned Fa0/2 and Fa0/3 to different VLANs. Run show vlan brief on HQ-Switch to confirm.
- Verify that Sales-PC and Eng-PC have IPs in different subnets (192.168.10.x vs 192.168.20.x). If both are in the same subnet, the switch forwards the traffic without routing.
- help me figure out why my VLANs are not isolating traffic
✔️ Awesome, I've got everything!
Great. Make sure you've saved your Packet Tracer topology file before moving on.
ⓧ I'd like to double check the full configuration
Here's what your HQ-Switch configuration should look like at this point. Verify each section:
- VLAN 10 created, named Sales.
- VLAN 20 created, named Engineering.
- Fa0/2: access port in VLAN 10.
- Fa0/3: access port in VLAN 20.
- Sales-PC: IP 192.168.10.10/24, gateway 192.168.10.1.
- Eng-PC: IP 192.168.20.10/24, gateway 192.168.20.1.
- Ping from Sales-PC to 192.168.20.10 results in Request timed out.
Your VLANs are working exactly as designed. Traffic is isolated between departments. Next up, you'll fix the communication gap by configuring router-on-a-stick inter-VLAN routing on HQ-Router.
Enable Inter-VLAN Routing
In the last step, you proved that VLANs work. Sales and Engineering traffic is completely isolated. The problem is that isolation also means they can't communicate at all.
Router-on-a-stick solves this by splitting a single physical router interface into subinterfaces. Each subinterface handles traffic for one VLAN. The router forwards packets between them, restoring communication while keeping the VLANs logically separate.
In this step, get ready to:
- Configure a trunk link between HQ-Switch and HQ-Router.
- Create subinterfaces on HQ-Router for each VLAN.
- Test that Sales and Engineering PCs can now ping each other.
Configure the trunk link on HQ-Switch
The switch port connecting to HQ-Router needs to carry traffic from multiple VLANs. A trunk port tags each frame with its VLAN ID using the 802.1Q protocol, so the router knows which VLAN the traffic belongs to.
- Click on HQ-Switch in your Packet Tracer workspace.
- Go to the CLI tab.
- Configure Fa0/1 as a trunk port by entering these commands:
enable
configure terminal
interface FastEthernet0/1
switchport mode trunk
end
What do these commands do?
- interface FastEthernet0/1 selects the port connected to HQ-Router.
- switchport mode trunk tells the port to tag all frames with their VLAN ID before sending them to the router.
On a Cisco 2960 switch, 802.1Q is the only supported encapsulation. You do not need to specify it separately.
- Verify the trunk is active by running:
show interfaces trunk
You should see Fa0/1 listed with an encapsulation of 802.1q, a status of trunking, and VLANs 1-4094 in the allowed list.
Fa0/1 not showing as a trunk?
- Make sure you typed switchport mode trunk while inside the interface FastEthernet0/1 configuration. If you ran it in global config mode, it won't apply.
- Check that the cable between HQ-Switch Fa0/1 and HQ-Router Gi0/0 shows green link lights on both ends.
- help me troubleshoot my trunk configuration on HQ-Switch
Configure subinterfaces on HQ-Router
The router needs a separate logical interface for each VLAN. Each subinterface maps to one VLAN and acts as the default gateway for PCs in that VLAN.
- Click on HQ-Router in your workspace.
- Go to the CLI tab.
- Enable the physical interface and create both subinterfaces by entering these commands:
enable
configure terminal
interface GigabitEthernet0/0
no shutdown
interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
interface GigabitEthernet0/0.20
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0
end
What does this configuration do?
- no shutdown on the physical interface GigabitEthernet0/0 brings it up. Subinterfaces inherit the physical interface's state, so this must be enabled first.
- interface GigabitEthernet0/0.10 creates a subinterface. The .10 suffix is a convention matching the VLAN number for readability.
- encapsulation dot1Q 10 tells the subinterface to handle frames tagged with VLAN 10.
- ip address 192.168.10.1 255.255.255.0 assigns the default gateway IP that Sales-PC is already configured to use.
The same pattern repeats for VLAN 20 on subinterface G0/0.20, serving as the gateway for Eng-PC.
- Confirm the subinterfaces are up by running:
show ip interface brief
You should see GigabitEthernet0/0, GigabitEthernet0/0.10, and GigabitEthernet0/0.20 all showing up in both the Status and Protocol columns.
Subinterfaces showing down?
- If GigabitEthernet0/0 shows administratively down, you missed the no shutdown command on the physical interface. Go back into interface GigabitEthernet0/0 and enter no shutdown.
- Make sure the cable between HQ-Switch Fa0/1 and HQ-Router Gi0/0 is connected. A missing cable keeps the physical interface down.
- help me fix my router subinterfaces that are showing down
✔️ Awesome, I've got everything!
Great. Make sure both subinterfaces show as up before moving on to the test.
ⓧ I'd like to double check the full config
Here is what your HQ-Router interface configuration should look like at this point:
- GigabitEthernet0/0: no shutdown (no IP on the physical interface itself).
- GigabitEthernet0/0.10: encapsulation dot1Q 10, IP 192.168.10.1/24.
- GigabitEthernet0/0.20: encapsulation dot1Q 20, IP 192.168.20.1/24.
- GigabitEthernet0/1: IP 10.10.30.1/30, no shutdown (configured in Step 1).
On HQ-Switch, confirm Fa0/1 is a trunk by running show interfaces trunk.
Test inter-VLAN routing
Everything is wired up. The trunk carries tagged frames from both VLANs to the router, and the router has a subinterface ready for each one. Time to see if the departments can actually talk.
- Click on Sales-PC in your workspace.
- Go to the Desktop tab, then open Command Prompt.
Before you run the ping, predict: will Sales-PC be able to reach Eng-PC at 192.168.20.10 now?
- Test the connection by running:
ping 192.168.20.10
You should see replies coming back from 192.168.20.10. Inter-VLAN routing is working. Sales can now reach Engineering through the router.
- Now confirm the reverse direction. Click on Eng-PC, open Desktop then Command Prompt, and run:
ping 192.168.10.10
Replies from 192.168.10.10 confirm both directions work.
- Now try reaching the Branch Office. From either HQ PC, run:
ping 192.168.30.10
Before you check the result, predict: do you think this ping will succeed or fail? The branch is on a different router.
The ping fails with Request timed out. The routers do not know how to reach each other's local networks yet. HQ-Router has no route to 192.168.30.0/24, and Branch-Router has no route to 192.168.10.0/24 or 192.168.20.0/24.
Why can't the sites reach each other?
Each router only knows about its directly connected subnets. HQ-Router sees 192.168.10.0/24, 192.168.20.0/24, and 10.10.30.0/30. Branch-Router sees 192.168.30.0/24 and 10.10.30.0/30.
Neither router has been told about the other's local networks. You could add static routes manually, but that does not scale. OSPF solves this by letting routers share their route information automatically.
- Confirm what HQ-Router knows by running this on HQ-Router's CLI:
show ip route
You should see connected routes (marked with C) for 192.168.10.0/24, 192.168.20.0/24, and 10.10.30.0/30. There is no entry for the branch's 192.168.30.0/24 subnet.
Pings between HQ PCs still failing?
- Check that the trunk is active on HQ-Switch with show interfaces trunk. Fa0/1 must show as trunking.
- Verify subinterfaces are up on HQ-Router with show ip interface brief. All three (Gi0/0, Gi0/0.10, Gi0/0.20) must be up/up.
- Confirm the PC gateway addresses match the subinterface IPs. Sales-PC's gateway should be 192.168.10.1 and Eng-PC's gateway should be 192.168.20.1.
- help me troubleshoot inter-VLAN routing between Sales-PC and Eng-PC
Inter-VLAN routing is live. Sales and Engineering can communicate through the router while staying on separate VLANs. Next up, you'll connect both sites with OSPF so the routers automatically learn about each other's networks.
Connect the Sites with OSPF
Inter-VLAN routing is working. Sales-PC and Eng-PC can talk through the router-on-a-stick setup. But when you tried pinging Branch-PC from HQ, the request timed out.
The problem is straightforward. Neither router knows about the other's local networks. You could add static routes manually, but OSPF solves this at scale. OSPF automatically discovers neighboring routers and shares route information. When the network grows, new sites join the routing table without manual intervention.
In this step, get ready to:
- Configure OSPF on HQ-Router to advertise all HQ networks.
- Configure OSPF on Branch-Router to advertise branch networks.
- Verify full network reachability across both sites.
Configure OSPF on HQ-Router
HQ-Router needs to advertise three networks into OSPF: the Sales VLAN subnet, the Engineering VLAN subnet, and the WAN link connecting to Branch-Router.
- Click on HQ-Router in your Packet Tracer workspace.
- Select the CLI tab.
- Configure OSPF by entering the following commands:
enable
configure terminal
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.10.30.0 0.0.0.3 area 0
passive-interface GigabitEthernet0/0.10
passive-interface GigabitEthernet0/0.20
end
What does this configuration do?
- router ospf 1 starts an OSPF routing process. The 1 is a process ID that is locally significant to this router.
- router-id 1.1.1.1 assigns a fixed identifier to this router within OSPF. Without it, OSPF picks the highest IP on an active interface, which can change unexpectedly.
- Each network statement tells OSPF which interfaces to activate on, using a wildcard mask (the inverse of a subnet mask). All three networks are placed in area 0, the backbone area.
- passive-interface stops OSPF from sending hello packets out the VLAN subinterfaces. There are no OSPF neighbors on those LANs, only PCs.
- Verify OSPF is running by entering this command:
show ip protocols
You should see output showing OSPF process ID 1, router ID 1.1.1.1, and the three networks you advertised.
Not seeing OSPF in the output?
- Make sure you typed router ospf 1 (not router rip or another protocol). Check with show running-config | section router.
- Confirm you typed end to exit configuration mode before running the show command. Show commands only work in privileged exec mode.
- help me troubleshoot OSPF not appearing in show ip protocols on HQ-Router
✔️ Awesome, I've got everything!
Great. Make sure you saw OSPF listed with all three networks before moving on.
ⓧ I'd like to double check the full config
Run this command to see the OSPF section of your running configuration:
show running-config | section router ospf
You should see:
router ospf 1
router-id 1.1.1.1
passive-interface GigabitEthernet0/0.10
passive-interface GigabitEthernet0/0.20
network 192.168.10.0 0.0.0.255 area 0
network 192.168.20.0 0.0.0.255 area 0
network 10.10.30.0 0.0.0.3 area 0
Configure OSPF on Branch-Router
Branch-Router advertises two networks: its local LAN subnet and the WAN link shared with HQ-Router.
- Click on Branch-Router in your workspace.
- Select the CLI tab.
- Configure OSPF by entering the following commands:
enable
configure terminal
router ospf 1
router-id 2.2.2.2
network 192.168.30.0 0.0.0.255 area 0
network 10.10.30.0 0.0.0.3 area 0
passive-interface GigabitEthernet0/1
end
What does this configuration do?
- The OSPF process ID (1) is locally significant. It does not need to match HQ-Router's process ID, though using the same number keeps things readable.
- router-id 2.2.2.2 gives Branch-Router a unique identity within OSPF.
- passive-interface GigabitEthernet0/1 prevents OSPF hellos from going out to Branch-PC. The only OSPF neighbor is HQ-Router on the WAN link.
- Check that the OSPF adjacency has formed by entering this command:
show ip ospf neighbor
You should see HQ-Router listed as a neighbor with its router ID 1.1.1.1 and a state of FULL. This confirms the two routers are exchanging route information.
No neighbor showing up?
- Wait 30 seconds and run show ip ospf neighbor again. OSPF needs time to exchange hello packets and reach FULL state.
- Verify the WAN link is up. On Branch-Router, run ping 10.10.30.1. If this fails, the physical connection between routers is down.
- Confirm both routers advertise the WAN subnet (10.10.30.0 0.0.0.3 area 0). If one side is missing this network statement, OSPF cannot form an adjacency on that link.
- help me troubleshoot OSPF neighbor not forming between HQ-Router and Branch-Router
✔️ Awesome, I've got everything!
Great. Your OSPF adjacency is confirmed. The routers are sharing routes.
ⓧ I'd like to double check the full config
Run this command to see Branch-Router's OSPF configuration:
show running-config | section router ospf
You should see:
router ospf 1
router-id 2.2.2.2
passive-interface GigabitEthernet0/1
network 192.168.30.0 0.0.0.255 area 0
network 10.10.30.0 0.0.0.3 area 0
Verify OSPF adjacency and routing
Both routers have OSPF configured and the adjacency is up. Now confirm that routes are being shared and that the entire network is reachable end-to-end.
- On Branch-Router, view the OSPF-learned routes by entering:
show ip route ospf
You should see routes marked with O for 192.168.10.0/24 and 192.168.20.0/24. These are the HQ subnets that Branch-Router learned dynamically through OSPF.
What do the O routes mean?
In the routing table, O means the route was learned via OSPF. The administrative distance is 110. You did not type these routes manually. OSPF discovered them from HQ-Router and installed them automatically.
Before you run the final test, predict: will Branch-PC be able to ping Sales-PC now that OSPF is sharing routes?
- Click on Branch-PC in your workspace.
- Go to the Desktop tab, then open Command Prompt.
- Test full network connectivity by running:
ping 192.168.10.10
The ping succeeds. Branch-PC can now reach Sales-PC across the WAN link, through OSPF-learned routes.
- Also try pinging Eng-PC from Branch-PC to confirm full reachability:
ping 192.168.20.10
This also succeeds. Every PC on the network can now reach every other PC. OSPF eliminated the need for any static routes.
Pings still failing from Branch-PC?
- Run show ip route on Branch-Router. If you do not see O routes for 192.168.10.0 and 192.168.20.0, the OSPF adjacency is not fully established. Go back and check show ip ospf neighbor.
- Confirm Branch-PC's default gateway is set to 192.168.30.1. Without the correct gateway, traffic never reaches the router.
- On HQ-Router, check that GigabitEthernet0/0.10 is listed as a passive interface, not the WAN interface GigabitEthernet0/1. Making the WAN interface passive would block the OSPF adjacency.
- help me troubleshoot why Branch-PC cannot ping Sales-PC even though OSPF is configured
Your two-site network is fully connected. OSPF handles all route discovery automatically. Next up, you will lock down this open network with ACLs and configure SSH for secure remote management.
Secure the Network with ACLs and SSH
Your OSPF routing is working perfectly. Every PC on the network can reach every other PC across all sites.
That full connectivity is actually a problem. Right now, Branch-PC can freely reach the sensitive Engineering servers at HQ. In the real world, you restrict traffic with ACLs (Access Control Lists) and you manage routers securely over SSH instead of insecure Telnet.
In this step, get ready to:
- Create an extended ACL blocking branch-to-engineering traffic.
- Configure SSH for secure remote management of HQ-Router.
- Verify that access control and secure management are both working.
Create and apply an ACL to block branch-to-engineering traffic
Extended ACLs can filter traffic based on both source and destination IP addresses. You will create one that allows Branch-PC to reach the Sales department but blocks it from reaching Engineering.
Why apply the ACL on HQ-Router's WAN interface?
Extended ACLs should be placed as close to the traffic source as possible. Branch traffic enters HQ-Router through GigabitEthernet0/1 (the WAN link), so applying the ACL inbound on that interface stops unwanted packets before they travel any further into the HQ network.
Before configuring the ACL, confirm that Branch-PC currently has full access to Engineering.
- Click on Branch-PC and open the Desktop tab.
- Open Command Prompt.
- Ping the Engineering PC by running:
ping 192.168.20.10
The ping succeeds. Branch-PC can currently reach Engineering with no restrictions. Now you will block this access.
- Click on HQ-Router and open the CLI tab.
- Enter global configuration mode and create the ACL by running these commands:
enable
configure terminal
access-list 100 deny ip 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255
access-list 100 permit ip any any
What do these ACL commands do?
The first rule denies any IP traffic from the branch subnet (192.168.30.0/24) destined for the engineering subnet (192.168.20.0/24). The wildcard mask 0.0.0.255 means "match the first three octets exactly, ignore the last."
The second rule permits all other traffic. Without this explicit permit, the implicit deny at the end of every ACL would block everything.
- Apply the ACL inbound on the WAN interface by running:
interface GigabitEthernet0/1
ip access-group 100 in
exit
exit
What does ip access-group 100 in do?
This binds ACL 100 to the interface in the inbound direction. Every packet arriving on GigabitEthernet0/1 from the branch is now checked against the ACL rules before being routed further.
Now test whether the ACL is working.
- Return to Branch-PC's Command Prompt.
- First confirm you can still reach Sales-PC by running:
ping 192.168.10.10
This ping should succeed. The ACL only blocks traffic to Engineering, not to Sales.
- Now try to reach Eng-PC by running:
ping 192.168.20.10
This time the ping fails with "Destination host unreachable." Your ACL is blocking branch traffic from reaching Engineering exactly as intended.
Both pings failing?
If Branch-PC cannot reach Sales-PC either, the ACL's second rule (permit ip any any) may be missing. Without it, the implicit deny at the end blocks all traffic.
Run show access-lists on HQ-Router to confirm both rules are present. If only the deny line appears, re-enter access-list 100 permit ip any any in global configuration mode.
Also confirm the ACL is applied in the correct direction with show ip interface GigabitEthernet0/1. Look for "Inbound access list is 100" in the output.
Still stuck? Help me troubleshoot why my ACL is blocking all traffic instead of just branch-to-engineering.
Configure SSH on HQ-Router
Network engineers manage routers remotely over the network. SSH encrypts that management session so credentials and commands cannot be intercepted. Telnet sends everything in plain text, which is why modern networks require SSH.
- Click on HQ-Router and open the CLI tab.
- Configure SSH by running these commands:
enable
configure terminal
ip domain-name company.local
crypto key generate rsa general-keys modulus 1024
username admin secret cisco123
line vty 0 4
transport input ssh
login local
exit
exit
What does each SSH command do?
- ip domain-name company.local sets the domain name used to generate the RSA key pair.
- crypto key generate rsa general-keys modulus 1024 creates the encryption keys SSH needs. The router may ask you to confirm the key size.
- username admin secret cisco123 creates a local user account for SSH login.
- transport input ssh restricts VTY lines to SSH only, disabling Telnet access.
- login local tells the VTY lines to authenticate against the local username database.
RSA key prompt
When you run the RSA key command, Packet Tracer may ask "How many bits in the modulus?" If prompted, type 1024 and press Enter.
Seeing an error about the domain name?
RSA key generation requires a domain name to be set first. If you see an error when generating keys, make sure ip domain-name company.local was entered before the crypto key generate rsa command.
Need help? Why is my RSA key generation failing on HQ-Router?
Verify SSH access
The final test proves you can securely manage HQ-Router from any PC on the network. You will SSH in from Sales-PC using the credentials you just configured.
- Click on Sales-PC and open the Desktop tab.
- Open Command Prompt.
Before you run the next command, what do you expect to happen? Will Sales-PC be able to reach HQ-Router over SSH?
- Connect to HQ-Router via SSH by running:
ssh -l admin 192.168.10.1
- When prompted for the password, type cisco123 and press Enter.
You land in the HQ-Router CLI. The banner motd you configured earlier appears, confirming you are connected to the correct device over an encrypted SSH session.
Connection refused or timed out?
Make sure you are using the IP address 192.168.10.1 (HQ-Router's VLAN 10 subinterface). Sales-PC's gateway is this address, so it is directly reachable.
If you see "Connection refused," verify that transport input ssh is set on the VTY lines. Run show running-config | section line vty on HQ-Router to check.
Still stuck? Help me troubleshoot my SSH connection to HQ-Router from Sales-PC.
Let's confirm the full picture. Your network now enforces two security policies simultaneously.
- Return to Branch-PC's Command Prompt and run:
ping 192.168.10.10
This succeeds. Branch can reach Sales.
- Now run:
ping 192.168.20.10
This fails. Branch is blocked from Engineering by your ACL. Meanwhile, SSH gives you secure remote management from anywhere on the network.
- Save your topology by pressing Ctrl+S (Windows) or Cmd+S (macOS) in Packet Tracer.
✔️ Awesome, I've got everything!
Great. Your network is now fully secured with both ACL traffic filtering and SSH remote management.
ⓧ I'd like to double check the configuration
Run these verification commands on HQ-Router to confirm the full security configuration.
Check the ACL:
show access-lists
You should see:
Extended IP access list 100
10 deny ip 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255
20 permit ip any any
Check SSH status:
show ip ssh
You should see SSH version 1.99 or 2.0 enabled with the RSA key configured.
Verify the ACL is applied to the correct interface:
show running-config | include access-group
You should see ip access-group 100 in under the GigabitEthernet0/1 interface.
Secret mission
Add a Data Center Site
Real networks grow. Can you prove your OSPF skills scale by adding a third site and implementing named ACLs for more readable, granular security policies?
Clean Up Your Resources
Clean Up Your Resources
Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally in Cisco Packet Tracer, so there are no ongoing costs.
Resources you used:
- Your saved .pkt topology file (the two-site network plus the optional Data Center site).
Keep everything running
No action needed. Choose this if you plan to continue extending the topology, practicing OSPF tuning, or adding more VLANs and ACLs.
- Your .pkt file stays on your Desktop or wherever you saved it.
- Cisco Packet Tracer remains installed on your machine (it was a prerequisite for this project).
Pause - I'll come back to this later
Close Packet Tracer to free up memory. Your topology is already saved in the .pkt file and will reload exactly as you left it.
- Save your topology one more time with Ctrl+S (Windows) or Cmd+S (macOS) to capture any final changes.
- Close Cisco Packet Tracer.
- When you return, double-click the .pkt file to reopen your full topology with all configurations intact.
Delete - I don't want to use this again
Remove all project files and start fresh. This permanently deletes your topology and all device configurations.
- Close Cisco Packet Tracer if it is still open.
- Delete your .pkt topology file. On macOS or Linux, run:
rm ~/Desktop/*.pkt
On Windows, run:
Remove-Item ~\Desktop\*.pkt
- Confirm the file is gone by checking your Desktop. You should no longer see the .pkt file.
Nice Work!
Nice Work!
You just built a fully routed, VLAN-segmented, secured multi-site company network from scratch in Cisco Packet Tracer. This topology demonstrates the core skills hiring managers test in junior network engineer interviews: switching, routing, and security working together.
You've learned how to:
- Build a VLAN-segmented network and solve inter-VLAN communication failures with router-on-a-stick using 802.1Q subinterfaces on Cisco 2911 routers.
- Configure single-area OSPFv2 so multiple sites discover each other's networks automatically without manual static routes.
- Secure a network with extended ACLs blocking unauthorized cross-site traffic and enable SSH for secure remote device management.
- Secret Mission: Scaled the network by adding a Data Center site with OSPF auto-discovery and named ACLs for granular traffic control.
Ready to quiz yourself?