Connect Two Enterprise Sites with OSPF and BGP

Build a multi-site enterprise network using VLANs, OSPF, and eBGP routing.

Introduction

30 Second Summary

When a company has offices in different cities, those offices still need to communicate as if they were one network. The challenge is that each site has its own departments, its own internal structure, and a third-party internet provider sitting between them.

In this project, you will build a two-site enterprise network in Cisco Packet Tracer where departments at a headquarters and a branch office can communicate across VLANs, internal routing protocols, and an ISP link.

What You'll Build

When you finish, you can sit at any PC in any department at either site and successfully ping any other PC across the entire network, watching packets cross VLAN, OSPF, and BGP boundaries along the way.

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

A working multi-site network where a PC in HR at Headquarters can reach a PC in Engineering at the Branch office, crossing VLAN, OSPF, and BGP boundaries in a single ping.
Routers that automatically discover new networks within each site using OSPF, so adding a department never requires manual route updates.
An ISP router that exchanges routes with both sites using BGP, the same protocol that connects every organization on the real internet.
Secret Mission: Add a third site and configure BGP to prefer one path over another using route redistribution with metrics.

Are there any prerequisites?

This project assumes you are comfortable with basic IP addressing and subnetting, have used the router and switch CLI before, and have experience with VLANs and inter-VLAN routing.

You will also need Cisco Packet Tracer installed on your machine. The project uses version 9.0, which is free for registered NetAcad users.

Before We Start

Before we start configuring routers and switches, let's lock in what you're about to build and why it matters.

Set Up the Network Topology

Every enterprise network starts with its physical foundation. Before routing protocols can move traffic between sites, you need the actual devices in place, cables connecting them, and basic addressing configured so interfaces can communicate.

In this step, you'll build the full two-site topology in Cisco Packet Tracer. You'll place routers, switches, and PCs, cable them together, segment each site into departments using VLANs, and configure inter-VLAN routing so traffic can flow between departments within each site.

In this step, get ready to:

Place all devices and connect them with the correct cable types.
Configure VLANs on both switches and assign IP addresses to all PCs.
Set up router-on-a-stick for inter-VLAN routing at each site.

Place devices and cable the topology

Your network needs three routers, two switches, and four PCs. Each device type lives in a different category in the Packet Tracer device panel at the bottom of the screen.

In the bottom-left device panel, click the Network Devices category icon (top row).
Click the Routers subcategory (bottom row).
Find the 2911 model and drag three of them onto the workspace.
Click each router and rename them using the Config tab: HQ-Router, Branch-Router, and ISP-Router.
Click the Switches subcategory and drag two 2960 switches onto the workspace.
Rename them HQ-Switch and Branch-Switch.
Click the End Devices category icon and drag four PC devices onto the workspace.
Rename them HQ-PC1, HQ-PC2, Branch-PC1, and Branch-PC2.

Arrange the devices so HQ-Router and HQ-Switch are on the left, Branch-Router and Branch-Switch are on the right, and ISP-Router sits in the middle between the two sites.

Why these specific models?

The 2911 router has multiple GigabitEthernet interfaces needed for both the LAN trunk link and the WAN connection. The 2960 switch supports VLANs and trunking out of the box.

Now connect the devices with cables. Different device pairings require different cable types.

In the device panel, click the Connections category (the lightning bolt icon).
Select Copper Straight-Through cable.
Connect HQ-Switch port FastEthernet0/1 to HQ-Router port GigabitEthernet0/0.
Connect Branch-Switch port FastEthernet0/1 to Branch-Router port GigabitEthernet0/0.
Connect HQ-PC1 to HQ-Switch port FastEthernet0/2.
Connect HQ-PC2 to HQ-Switch port FastEthernet0/3.
Connect Branch-PC1 to Branch-Switch port FastEthernet0/2.
Connect Branch-PC2 to Branch-Switch port FastEthernet0/3.

Now switch to a Copper Cross-Over cable for the router-to-router WAN links.

Select Copper Cross-Over cable from the Connections panel.
Connect HQ-Router port GigabitEthernet0/1 to ISP-Router port GigabitEthernet0/0.
Connect Branch-Router port GigabitEthernet0/1 to ISP-Router port GigabitEthernet0/1.

Why two cable types?

Straight-through cables connect different device types (switch to router, PC to switch). Cross-over cables connect the same device type (router to router). Routers transmit and receive on the same pins, so you need a cross-over to swap them.

You should see cable indicators on every connection. Green triangles mean the link is active. Orange triangles mean the interface is not yet configured, which is expected at this stage.

Seeing red X indicators on cables?

A red X means the cable is connected to the wrong port type. Double-check that you used the exact interface names listed above. Click the cable to see which ports it connects.

Help me fix my cable connections

Configure VLANs on switches and assign PC IPs

Each site has two departments: HR and Engineering. VLANs separate their traffic at the switch level so devices in different departments cannot communicate directly at Layer 2.

Click on HQ-Switch and open the CLI tab.
Configure the VLANs and port assignments by entering these commands:

enable
configure terminal
vlan 10
name HR
exit
vlan 20
name Engineering
exit
interface FastEthernet0/2
switchport mode access
switchport access vlan 10
exit
interface FastEthernet0/3
switchport mode access
switchport access vlan 20
exit
interface FastEthernet0/1
switchport mode trunk
exit
end

What do these commands do?

The first section creates VLAN 10 (HR) and VLAN 20 (Engineering). Each VLAN is a separate broadcast domain.

The interface commands assign each PC port to its department's VLAN using access mode. The trunk port on FastEthernet0/1 carries tagged traffic from both VLANs to the router using 802.1Q automatically (the 2960 only supports 802.1Q, so no encapsulation command is needed on the switch).

Verify the VLAN configuration by running:

show vlan brief

You should see VLAN 10 with Fa0/2 listed under it and VLAN 20 with Fa0/3 listed under it.

Now configure the same VLANs on the Branch site switch.

Click on Branch-Switch and open the CLI tab.
Enter the same VLAN configuration:

enable
configure terminal
vlan 10
name HR
exit
vlan 20
name Engineering
exit
interface FastEthernet0/2
switchport mode access
switchport access vlan 10
exit
interface FastEthernet0/3
switchport mode access
switchport access vlan 20
exit
interface FastEthernet0/1
switchport mode trunk
exit
end

Verify with show vlan brief to confirm VLAN 10 and VLAN 20 appear with the correct port assignments.

VLANs not showing your ports?

Make sure you typed switchport mode access before switchport access vlan. If ports still show under VLAN 1, re-enter the interface commands.

Help me fix my VLAN port assignments

With VLANs in place, each PC needs an IP address and a default gateway so it knows where to send traffic destined for other networks.

Click on HQ-PC1 and open the Desktop tab.
Click IP Configuration.
Set the IP address to 192.168.10.10, subnet mask to 255.255.255.0, and default gateway to 192.168.10.1.
Repeat for each PC using this addressing plan:

HQ-PC2: IP 192.168.20.10, mask 255.255.255.0, gateway 192.168.20.1.
Branch-PC1: IP 192.168.30.10, mask 255.255.255.0, gateway 192.168.30.1.
Branch-PC2: IP 192.168.40.10, mask 255.255.255.0, gateway 192.168.40.1.

Why different subnets per VLAN?

Each VLAN operates as a separate network. Devices in VLAN 10 at HQ use the 192.168.10.0/24 subnet, while VLAN 20 uses 192.168.20.0/24. This separation means a router must forward traffic between them.

Configure router-on-a-stick for inter-VLAN routing

PCs in different VLANs cannot talk to each other without a router. The router-on-a-stick pattern uses a single physical interface split into virtual subinterfaces. Each subinterface handles one VLAN's traffic.

Click on HQ-Router and open the CLI tab.
Configure the subinterfaces and WAN link by entering these commands:

enable
configure terminal
interface GigabitEthernet0/0
no shutdown
exit
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/1
ip address 10.0.0.1 255.255.255.252
no shutdown
exit
end

What do these commands do?

The no shutdown on GigabitEthernet0/0 activates the physical interface so its subinterfaces can work.

Each subinterface (Gig0/0.10, Gig0/0.20) uses encapsulation dot1Q to tag traffic for its VLAN. The IP address on each subinterface becomes the default gateway for that VLAN's PCs.

The GigabitEthernet0/1 interface is the WAN link to the ISP with a /30 subnet (only two usable addresses for a point-to-point link).

Verify the interfaces are up by running:

show ip interface brief

You should see GigabitEthernet0/0, GigabitEthernet0/0.10, GigabitEthernet0/0.20, and GigabitEthernet0/1 all showing "up" in the Status column with their assigned IP addresses.

Now configure the Branch site router with its own subinterfaces and WAN link.

Click on Branch-Router and open the CLI tab.
Enter the following configuration:

enable
configure terminal
interface GigabitEthernet0/0
no shutdown
exit
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/1
ip address 10.0.0.5 255.255.255.252
no shutdown
exit
end

Run show ip interface brief to confirm all interfaces show "up" with the correct IPs.

Finally, configure the ISP router that connects the two sites.

Click on ISP-Router and open the CLI tab.
Enter the WAN interface configuration:

enable
configure terminal
interface GigabitEthernet0/0
ip address 10.0.0.2 255.255.255.252
no shutdown
exit
interface GigabitEthernet0/1
ip address 10.0.0.6 255.255.255.252
no shutdown
exit
end

What does the ISP router do?

The ISP router sits between the two sites, simulating a real internet service provider. It has one interface facing HQ (10.0.0.2) and one facing Branch (10.0.0.6). Right now it only provides Layer 3 connectivity between the WAN links. Routing protocols will come later.

Run show ip interface brief on ISP-Router to confirm both interfaces show "up" with their IPs assigned.

Interfaces showing "administratively down"?

This means no shutdown was not entered on that interface. Go back into configuration mode with configure terminal, enter the interface, and run no shutdown.

Help me bring my interfaces up

Before you move on, predict what will happen if you try to ping from HQ-PC1 to HQ-PC2 right now. Both PCs are at the same site but in different VLANs. Will the ping succeed?

Click on HQ-PC1, open the Desktop tab, and click Command Prompt.
Run the following ping command:

ping 192.168.20.10

You should see replies from 192.168.20.10. This confirms that router-on-a-stick is working. The traffic leaves VLAN 10, hits the router's subinterface, gets forwarded to the VLAN 20 subinterface, and arrives at HQ-PC2.

Ping shows "Request timed out"?

The first one or two pings may time out while ARP resolves. Try running the ping command again. If all four still fail, check these common causes:

Verify the trunk link is active. On HQ-Switch, run show interfaces trunk and confirm Fa0/1 appears as a trunk.
Verify the subinterface VLAN tags match. On HQ-Router, run show ip interface brief and confirm Gig0/0.10 and Gig0/0.20 both show "up".
Verify the PC gateway matches the subinterface IP. HQ-PC1's gateway must be 192.168.10.1.

Help me troubleshoot my inter-VLAN ping

✔️ Awesome, I've got everything!

Great. All devices are placed, cabled, and configured. Your topology is ready for routing protocols.

ⓧ I'd like to double check the full configuration

Run these show commands on each device to verify the expected state:

On HQ-Switch and Branch-Switch, run show vlan brief. Confirm VLAN 10 (HR) has Fa0/2 and VLAN 20 (Engineering) has Fa0/3.

On HQ-Router, run show ip interface brief. Confirm:

Gig0/0.10: 192.168.10.1, status up.
Gig0/0.20: 192.168.20.1, status up.
Gig0/1: 10.0.0.1, status up.

On Branch-Router, run show ip interface brief. Confirm:

Gig0/0.10: 192.168.30.1, status up.
Gig0/0.20: 192.168.40.1, status up.
Gig0/1: 10.0.0.5, status up.

On ISP-Router, run show ip interface brief. Confirm:

Gig0/0: 10.0.0.2, status up.
Gig0/1: 10.0.0.6, status up.

Your two-site topology is fully built and locally connected. Next up, you'll attempt to reach across sites and discover why dynamic routing is essential.

Verify Local Connectivity and Hit the Routing Wall

In the last step, you built the entire physical topology and configured VLANs, subinterfaces, and WAN links. Every device is cabled and addressed.

But here is the question: can traffic actually flow between sites? Your router-on-a-stick handles inter-VLAN routing within each site, but routers only know about networks directly attached to them. Without something telling HQ-Router that 192.168.30.0 exists on the other side of the ISP, packets have nowhere to go. In this step, you will prove that gap by watching a cross-site ping fail.

In this step, get ready to:

Confirm inter-VLAN routing works within each site.
Attempt a cross-site ping and observe it fail.
Inspect the routing table to understand why cross-site traffic cannot reach its destination.

Test intra-site connectivity

Before worrying about cross-site traffic, you need to confirm that each site's internal routing works. If a PC in HR can ping a PC in Engineering at the same site, the router-on-a-stick subinterfaces are doing their job.

Click on HQ-PC1 in your Packet Tracer workspace.
Click the Desktop tab at the top of the device window.
Click Command Prompt to open the PC's terminal.
Ping HQ-PC2 (which is in a different VLAN at the same site) by running this command:

ping 192.168.20.10

You should see replies coming back from 192.168.20.10 with TTL values. This proves HQ-Router is forwarding traffic between VLAN 10 and VLAN 20 using the subinterfaces you configured.

What does a successful ping look like?

You will see four reply lines, each showing the bytes received, the time in milliseconds, and the TTL. If all four show Reply from 192.168.20.10, the connection is working.

Now verify the Branch site works the same way. Click on Branch-PC1 in your workspace.
Open its Desktop tab and click Command Prompt.
Ping Branch-PC2 by running:

ping 192.168.40.10

You should see four successful replies from 192.168.40.10. Both sites have working inter-VLAN routing internally.

Not getting replies?

If you see Request timed out for intra-site pings, check these common causes:

Confirm the trunk port on the switch (Fa0/1) is set to trunk mode, not access mode. Run show interfaces trunk on the switch CLI to verify.
Confirm the router subinterface has the correct encapsulation. Run show ip interface brief on the router and check that the subinterfaces show up/up status.
Verify the PC's default gateway matches the subinterface IP (e.g., 192.168.10.1 for HQ-PC1).

My intra-site pings are failing even though trunks show up. What should I check next?

Attempt cross-site communication and observe the failure

Both sites work internally. Now the real test: can a PC at Headquarters reach a PC at the Branch office? The answer reveals the fundamental problem that routing protocols exist to solve.

Switch back to HQ-PC1's Command Prompt.

Before you run the next command, think about this: HQ-PC1 wants to reach 192.168.30.10 (Branch-PC1). Does HQ-Router know that network exists? What do you think will happen?

Attempt to ping Branch-PC1 by running:

ping 192.168.30.10

You will see Request timed out for all four attempts. The ping fails completely.

Why does the cross-site ping fail?

HQ-PC1 sends the packet to its default gateway (HQ-Router). HQ-Router looks at the destination 192.168.30.10 and checks its routing table. It finds no entry for 192.168.30.0/24, so it drops the packet.

Routers only know about networks directly connected to their own interfaces. Without being told otherwise, HQ-Router has no idea that a network called 192.168.30.0 even exists.

Now let's prove this by looking at what HQ-Router actually knows.

Click on HQ-Router in your workspace.
Click the CLI tab to open the router's command line.
View the routing table by running:

show ip route

You will see only networks marked with C (Connected) and L (Local):

192.168.10.0/24 (HQ VLAN 10, directly connected via Gig0/0.10).
192.168.20.0/24 (HQ VLAN 20, directly connected via Gig0/0.20).
10.0.0.0/30 (WAN link to ISP, directly connected via Gig0/1).

There is no entry for 192.168.30.0 or 192.168.40.0. HQ-Router simply does not know the Branch networks exist.

Now check ISP-Router. Click on ISP-Router and open its CLI tab.
View its routing table by running:

show ip route

ISP-Router only knows about its two WAN links (10.0.0.0/30 and 10.0.0.4/30). It has zero knowledge of any site's internal networks.

What is the routing gap?

Each router is an island. HQ-Router knows its own VLANs. Branch-Router knows its own VLANs. ISP-Router only knows the point-to-point links between them. Nobody has the full picture.

You could add static routes manually on every router for every remote network. But if you added a new VLAN tomorrow, you would need to update every router by hand. This is the exact problem that dynamic routing protocols like OSPF solve automatically.

You have confirmed the gap: each site is an island with no knowledge of the other. In the next step, you will configure OSPF to make routers automatically discover and share network information, closing this gap without a single static route.

Configure OSPF Within Each Site

In the last step, you proved that cross-site pings fail. HQ-Router has no idea that 192.168.30.0 or 192.168.40.0 even exist.

You could fix this with static routes, manually typing every remote network into every router. But if you add a new VLAN tomorrow, you would need to update every router by hand. OSPF solves this by letting routers automatically discover and share network information with each other.

In this step, get ready to:

Enable OSPF on all three routers so they exchange routing information automatically.
Verify that OSPF neighbor adjacencies form between routers.
Test that cross-site pings now succeed end-to-end.

Enable OSPF on HQ-Router

OSPF uses a process ID to identify the routing instance on the router, and a router ID to uniquely identify the router in the OSPF domain. You will also use network statements with wildcard masks to tell OSPF which interfaces to activate on.

Click on HQ-Router in Packet Tracer and open the CLI tab.
Enter the following commands to enable OSPF and advertise all HQ networks into Area 0:

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.0.0.0 0.0.0.3 area 0
 exit

What do these commands do?

router ospf 1 starts OSPF process number 1. The number is locally significant and does not need to match across routers.
router-id 1.1.1.1 gives HQ-Router a stable identity in the OSPF domain. Without it, the router picks one automatically, which can change unpredictably.
network 192.168.10.0 0.0.0.255 area 0 tells OSPF to activate on any interface whose IP falls within that range and place it in Area 0.
The wildcard mask 0.0.0.255 matches a /24 subnet. The WAN link uses 0.0.0.3 because it is a /30 subnet.

Confirm OSPF is active on HQ-Router by running:

show ip protocols

You should see OSPF listed as a routing protocol with process ID 1, router ID 1.1.1.1, and your three network statements.

Not seeing OSPF in the output?

Make sure you typed router ospf 1 (with a space before 1) and not routerospf1.
Confirm you are in global configuration mode (the prompt shows (config)#) before entering the OSPF commands.
help me troubleshoot OSPF not appearing in show ip protocols on my Packet Tracer router

Enable OSPF on ISP-Router and Branch-Router

The ISP-Router only has WAN links, so it only advertises those /30 subnets. Branch-Router advertises both its VLAN subnets and its WAN link, just like HQ-Router did.

Click on ISP-Router and open the CLI tab.
Enter the following commands to configure OSPF on ISP-Router:

enable
configure terminal
router ospf 1
 router-id 2.2.2.2
 network 10.0.0.0 0.0.0.3 area 0
 network 10.0.0.4 0.0.0.3 area 0
 exit

Why does ISP-Router only advertise WAN links?

ISP-Router sits between the two sites. It has no local VLANs or end users. Its job is to forward traffic between HQ and Branch, so it only needs OSPF active on the interfaces facing each site.

Now click on Branch-Router and open the CLI tab.
Enter the following commands to configure OSPF on Branch-Router:

enable
configure terminal
router ospf 1
 router-id 3.3.3.3
 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.4 0.0.0.3 area 0
 exit

What does this configure?

Branch-Router mirrors the HQ-Router pattern. It advertises its two VLAN subnets (192.168.30.0/24 and 192.168.40.0/24) plus its WAN link (10.0.0.4/30) into Area 0. All three routers now share a common OSPF area and can exchange routes.

With all three routers configured, OSPF neighbor adjacencies should form automatically. Before you check, think about this:

Do you think HQ-Router will show one OSPF neighbor or two? Why?

Switch back to HQ-Router's CLI and verify the adjacency by running:

show ip ospf neighbor

You should see ISP-Router (router ID 2.2.2.2) listed with a state of FULL. HQ-Router only has one direct OSPF link (to ISP-Router), so you see one neighbor.

Now check which routes OSPF has learned by running:

show ip route ospf

You should see Branch's networks (192.168.30.0 and 192.168.40.0) marked with O for OSPF. These appeared without you typing a single static route.

OSPF convergence in Packet Tracer

Packet Tracer sometimes takes 30-40 seconds to form OSPF adjacencies. If you do not see neighbors yet, wait a moment and run the command again. If adjacencies appear stuck after a minute, save and reopen the .pkt file.

Time for the real test. In Step 2, HQ-PC1 pinging Branch-PC1 failed. Do you think it will succeed now?

Click on HQ-PC1, open the Desktop tab, and open Command Prompt.
Ping Branch-PC1 by running:

ping 192.168.30.10

You should see replies coming back from 192.168.30.10. Cross-site connectivity now works because OSPF shared all the routes across the network.

Ping still failing?

Run show ip ospf neighbor on ISP-Router. You should see two neighbors (1.1.1.1 and 3.3.3.3). If one is missing, double-check that router's OSPF configuration.
Verify the WAN link is up by pinging 10.0.0.2 from HQ-Router. If this fails, the physical link or interface IP is misconfigured.
The first ping attempt may time out while ARP resolves. Try pinging a second time before troubleshooting further.
help me figure out why my cross-site OSPF ping is not working in Packet Tracer

✔️ Awesome, I've got everything!

Great. Make sure you save your Packet Tracer file before moving on.

ⓧ I'd like to double check the full config

Here is the OSPF configuration for each router. Verify yours matches by running show ip ospf neighbor and show ip route ospf on each device.

HQ-Router:

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

ISP-Router:

router ospf 1
 router-id 2.2.2.2
 network 10.0.0.0 0.0.0.3 area 0
 network 10.0.0.4 0.0.0.3 area 0

Branch-Router:

router ospf 1
 router-id 3.3.3.3
 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.4 0.0.0.3 area 0

Understand what OSPF accomplished and its limitation

OSPF just solved your cross-site connectivity problem automatically. No static routes needed.

Why can't we just use OSPF for everything?

OSPF works perfectly when all routers are under the same administrative control. Every OSPF router shares its entire topology database with every other router in the area.

In the real world, HQ and Branch would connect through a third-party ISP. ISPs do not run OSPF with their customers because that would expose their internal network topology to outsiders. They also cannot trust that a customer's misconfiguration will not flood their network with bad routes.

This is where BGP enters. BGP lets separate organizations exchange routes without sharing internal details, giving each side control over what they advertise.

Your network is fully connected now. In the next step, you will restructure it to match reality: OSPF running inside each site, and BGP connecting the sites through the ISP.

Replace the Inter-Site Link with BGP

Your network works end-to-end right now because OSPF shares every route with every router. That is fine when you own all the routers, but in the real world, HQ and Branch connect through a third-party ISP.

ISPs do not run OSPF with their customers because OSPF requires full trust. Every router in an OSPF domain sees the entire topology database. BGP solves this by giving each site autonomous control over what routes it advertises, matching how the real internet works.

In this step, get ready to:

Remove OSPF from WAN links to simulate separate administrative domains.
Configure eBGP between each site and the ISP using private autonomous system numbers.
Set up route redistribution between OSPF and BGP so both protocols work together.

Remove OSPF from the WAN links and restructure

Right now, OSPF advertises the WAN link subnets (10.0.0.0/30 and 10.0.0.4/30) alongside your internal VLANs. You need to pull those WAN links out of OSPF so BGP can take over the inter-site role.

Click on HQ-Router in Packet Tracer and open the CLI tab.
Remove the WAN link from OSPF by entering these commands:

enable
configure terminal
router ospf 1
no network 10.0.0.0 0.0.0.3 area 0
end

What does this command do?

The no network command removes a network statement from the OSPF process. After this, HQ-Router stops sending OSPF hello packets out its Gig0/1 (WAN) interface. OSPF still runs for the internal VLANs (192.168.10.0 and 192.168.20.0).

Click on Branch-Router and open the CLI tab.
Remove the WAN link from OSPF on Branch-Router by entering:

enable
configure terminal
router ospf 1
no network 10.0.0.4 0.0.0.3 area 0
end

Run this command on Branch-Router to confirm the OSPF neighbor with ISP is dropping:

show ip ospf neighbor

You may see ISP-Router still listed with a countdown timer (the default OSPF dead interval is 40 seconds). Wait about 40 seconds for the adjacency to time out, or proceed to the next device.

Click on ISP-Router and open the CLI tab.
Since ISP-Router has no internal VLANs, remove the OSPF process entirely by entering:

enable
configure terminal
no router ospf 1
end

Why remove OSPF completely on ISP-Router?

ISP-Router only had WAN links in its OSPF process. With no internal networks to advertise via OSPF, the entire process is unnecessary. This matches reality. ISPs do not run interior gateway protocols with their customers.

Before you test, think about what will happen when HQ-PC1 tries to reach Branch-PC1 now. HQ-Router no longer has an OSPF route to the Branch subnets. What do you expect to see?

Click on HQ-PC1 and open the Desktop tab, then Command Prompt.
Attempt to ping Branch-PC1 by running:

ping 192.168.30.10

The ping fails with "Request timed out." This is the designed obstacle. HQ-Router only knows about its directly connected networks and its local VLANs now. It has no idea that 192.168.30.0 exists or how to reach it.

Confirm this by clicking HQ-Router and running:

show ip route

The routing table shows only connected (C) and OSPF (O) routes for local VLANs. No paths to the 192.168.30.0 or 192.168.40.0 networks exist. BGP will close this gap.

Still seeing OSPF routes to Branch?

OSPF takes up to 40 seconds (the dead interval) to drop a neighbor. Wait a moment and run show ip route again. If routes persist, close and reopen your .pkt file to force convergence.

Why aren't my OSPF routes disappearing?

Configure eBGP on all three routers

Each site becomes its own autonomous system (AS). An AS is a network under a single administrative authority. BGP exchanges routes between autonomous systems, letting each organization control exactly what it advertises.

What are the AS numbers?

HQ-Router: AS 65001 (private AS for Headquarters).
Branch-Router: AS 65002 (private AS for Branch office).
ISP-Router: AS 10000 (public AS for the Internet Service Provider).

Private AS numbers (64512-65534) are used for organizations that connect to the internet through a single ISP. The ISP uses a public AS number.

Click on HQ-Router and open the CLI tab.
Configure eBGP on HQ-Router by entering these commands:

enable
configure terminal
router bgp 65001
bgp log-neighbor-changes
no synchronization
neighbor 10.0.0.2 remote-as 10000
network 192.168.10.0
network 192.168.20.0
end

What does this configuration do?

router bgp 65001 starts the BGP process and assigns this router to AS 65001.
neighbor 10.0.0.2 remote-as 10000 tells HQ-Router that its BGP peer (ISP-Router) lives at 10.0.0.2 and belongs to AS 10000.
network 192.168.10.0 and network 192.168.20.0 advertise the HQ VLAN subnets to BGP neighbors.
no synchronization allows BGP to advertise routes without waiting for an IGP to confirm them.

Click on ISP-Router and open the CLI tab.
Configure eBGP on ISP-Router with neighbors pointing to both sites:

enable
configure terminal
router bgp 10000
bgp log-neighbor-changes
no synchronization
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.5 remote-as 65002
end

Why does ISP-Router have two neighbors?

ISP-Router acts as a transit point between the two sites. It peers with HQ (AS 65001) on one interface and Branch (AS 65002) on the other. Routes learned from one peer are automatically re-advertised to the other. This is standard eBGP behavior.

Verify that the HQ-Router to ISP-Router BGP session is forming by running on ISP-Router:

show ip bgp summary

You should see the neighbor 10.0.0.1 with a state column showing a number (indicating prefixes received) or transitioning toward Established. The neighbor 10.0.0.5 will show Active or Idle because Branch-Router is not configured yet.

Click on Branch-Router and open the CLI tab.
Configure eBGP on Branch-Router by entering:

enable
configure terminal
router bgp 65002
bgp log-neighbor-changes
no synchronization
neighbor 10.0.0.6 remote-as 10000
network 192.168.30.0
network 192.168.40.0
end

Return to ISP-Router and verify both BGP sessions are now Established by running:

show ip bgp summary

Both neighbors (10.0.0.1 and 10.0.0.5) should now show a number in the State/PfxRcd column, confirming the sessions are Established and prefixes are being exchanged.

Seeing Active or Idle instead of Established?

BGP sessions can take 30-60 seconds to establish in Packet Tracer. Wait a moment and run show ip bgp summary again.

If the session stays in Active state, double-check that the remote-as number matches the peer's actual AS. For example, HQ-Router must point to remote-as 10000 (the ISP's AS), not its own.

Help me troubleshoot my BGP neighbor stuck in Active state.

Configure route redistribution between OSPF and BGP

BGP sessions are up and the routers exchange their directly advertised networks. Route redistribution takes this further by dynamically injecting OSPF-learned routes into BGP and BGP-learned routes back into OSPF.

Why do we need redistribution if we already used network commands?

The network command in BGP works, but you must manually list every subnet. If you add a new VLAN tomorrow, you would need to update BGP configuration on the router.

Redistribution automates this. Any new subnet that OSPF discovers internally is automatically advertised into BGP without touching the BGP config. In enterprise networks with dozens of VLANs, this is essential.

Click on HQ-Router and open the CLI tab.
Configure two-way redistribution between OSPF and BGP by entering:

enable
configure terminal
router bgp 65001
redistribute ospf 1
exit
router ospf 1
redistribute bgp 65001 metric 1 subnets
end

What does two-way redistribution do?

redistribute ospf 1 (under BGP) takes routes learned by OSPF and injects them into BGP advertisements sent to the ISP.
redistribute bgp 65001 metric 1 subnets (under OSPF) takes routes learned from BGP and injects them into OSPF. This lets any internal router learn about remote sites.
metric 1 assigns a cost of 1 to redistributed routes. subnets ensures subnets (not just classful networks) are redistributed.

Click on Branch-Router and open the CLI tab.
Configure the same two-way redistribution on Branch-Router:

enable
configure terminal
router bgp 65002
redistribute ospf 1
exit
router ospf 1
redistribute bgp 65002 metric 1 subnets
end

Before you test, predict the result. OSPF handles routing within each site. BGP carries routes between sites through the ISP. Redistribution bridges the two. Do you think HQ-PC1 can now reach Branch-PC1?

Click on HQ-PC1 and open Command Prompt from the Desktop tab.
Test end-to-end connectivity by pinging Branch-PC1:

ping 192.168.30.10

The ping succeeds. Packets travel from HQ-PC1 through HQ-Router (OSPF to BGP), across ISP-Router (BGP transit), to Branch-Router (BGP to OSPF), and down to Branch-PC1.

Confirm the routing table tells the full story by running on HQ-Router:

show ip route

You should see OSPF routes marked "O" for your local VLANs (192.168.10.0 and 192.168.20.0), and BGP routes marked "B" for the remote site (192.168.30.0 and 192.168.40.0). Both protocols coexist in a single routing table.

Run the BGP-specific verification to see the full picture:

show ip bgp

The BGP table shows the Branch networks (192.168.30.0, 192.168.40.0) with their next-hop (10.0.0.2, the ISP) and AS path (10000 65002). The AS path tells you the route crossed AS 10000 (ISP) and originated in AS 65002 (Branch).

Ping still failing after redistribution?

Check that you configured redistribution on BOTH HQ-Router and Branch-Router. One-way redistribution means one site advertises but the other cannot route the reply back.

Run show ip bgp on ISP-Router to confirm it sees networks from both AS 65001 and AS 65002. If one is missing, revisit that site router's redistribution config.

Help me troubleshoot why my cross-site ping is still failing after BGP redistribution.

✔️ Awesome, I've got everything!

Great. Confirm you can see both O and B routes in show ip route on HQ-Router, and that pings to 192.168.30.10 succeed.

ⓧ I'd like to double check the full config

Scroll up and confirm each of these configuration blocks is present on the correct router:

HQ-Router: OSPF process 1 advertising only 192.168.10.0 and 192.168.20.0 in Area 0 (WAN link removed). BGP AS 65001 with neighbor 10.0.0.2 remote-as 10000. Redistribution both directions.
ISP-Router: OSPF process removed entirely. BGP AS 10000 with neighbor 10.0.0.1 remote-as 65001 and neighbor 10.0.0.5 remote-as 65002.
Branch-Router: OSPF process 1 advertising only 192.168.30.0 and 192.168.40.0 in Area 0 (WAN link removed). BGP AS 65002 with neighbor 10.0.0.6 remote-as 10000. Redistribution both directions.

Your two sites now communicate through BGP, the same protocol that connects every organization on the internet. Next, you will trace the full packet path and analyze exactly how each protocol contributes to the journey.

Verify and Trace the Full Path

Your network is fully operational. VLANs segment departments, OSPF handles internal routing, and BGP connects the sites through the ISP.

Configuration is only half the job. A network engineer must verify that traffic takes the expected path and confirm the routing table tells a consistent story. In this step, you'll prove end-to-end connectivity and read the routing tables to understand exactly how each packet reaches its destination.

In this step, get ready to:

Run ping tests from HQ-PC1 to verify connectivity to all destinations.
Run a traceroute to see the exact path packets take between sites.
Analyze routing tables and BGP tables to confirm protocol operation.

Run end-to-end verification tests

The ultimate proof that your network works is simple. Can a PC in one department at one site reach a PC in a different department at the other site?

Click on HQ-PC1 in your topology.
Go to the Desktop tab, then open Command Prompt.
Test local inter-VLAN routing by running this command:

ping 192.168.20.10

This pings HQ-PC2 in the Engineering VLAN at the same site. You should see replies confirming local inter-VLAN routing still works.

Now test cross-site connectivity by pinging Branch-PC1:

ping 192.168.30.10

You should see successful replies. This packet crossed a VLAN boundary, traveled through OSPF to the WAN link, hopped across BGP through the ISP, and arrived at the Branch site.

Test the final destination by pinging Branch-PC2:

ping 192.168.40.10

All four pings should succeed. Your network has full connectivity across VLANs, sites, and routing protocol boundaries.

Seeing Request timed out?

If local pings (to 192.168.20.10) fail, check that HQ-Router's subinterfaces are still up with show ip interface brief.

If cross-site pings fail but local pings work, verify BGP neighbors are still Established by running show ip bgp summary on HQ-Router. Also confirm redistribution is in place with show ip route and look for B routes.

Help me troubleshoot why my cross-site pings are failing in Packet Tracer with OSPF and BGP configured.

Pings confirm reachability, but they do not show you the path. A traceroute reveals every router hop between source and destination.

Still in HQ-PC1's Command Prompt, before you run the next command, think about this: how many router hops do you expect a packet to cross between HQ-PC1 and Branch-PC1?
Run the traceroute to see the actual path:

tracert 192.168.30.10

You should see exactly 3 hops listed before reaching the destination. Each hop represents a router your packet passed through: HQ-Router, ISP-Router, then Branch-Router.

What does the traceroute tell you?

Each hop in the output corresponds to one router in the path. The IP address shown for each hop is the router interface that received the packet.

Hop 1 is HQ-Router. Your packet left the VLAN and entered the routing domain.
Hop 2 is ISP-Router. The packet crossed the BGP boundary between AS 65001 and AS 10000.
Hop 3 is Branch-Router. The packet crossed another BGP boundary from AS 10000 into AS 65002 and was delivered to the destination subnet.

Packet Tracer traceroute quirks

Packet Tracer may show * * * for some hops or take longer than expected. This is a simulator limitation. If you see timeouts, wait a moment and try again. The path is correct as long as you eventually see 3 hops with IP addresses.

Analyze the routing tables and BGP table

Pings and traceroutes prove connectivity works. Now you will look under the hood at the routing tables to understand how each router knows where to send packets.

Click on HQ-Router in your topology and open its CLI tab.
View the full routing table by running:

show ip route

Look at the route codes on the left side of each entry. You should see two distinct types of routes in the table.

What do the route codes mean?

Routes marked with O are OSPF routes. These are the local VLAN networks (192.168.10.0/24 and 192.168.20.0/24) that OSPF discovered within your site.
Routes marked with B are BGP routes. These are the remote site networks (192.168.30.0/24 and 192.168.40.0/24) that BGP learned from the ISP.
Routes marked with C are directly connected networks. These are the interfaces physically attached to this router.

This single routing table tells the full story: OSPF handles the internal side, BGP handles the external side, and the router seamlessly forwards between them.

Now examine the BGP-specific table to see the AS path information:

show ip bgp

Look at the entries for 192.168.30.0 and 192.168.40.0. The AS path column shows 10000 65002 for the Branch networks. This means the routes traveled through AS 10000 (ISP) from AS 65002 (Branch).

Confirm the BGP neighbor relationship is healthy:

show ip bgp summary

You should see the ISP-Router neighbor (10.0.0.2) listed with a state showing a number in the State/PfxRcd column. A number means the neighbor is Established and exchanging prefixes. If you see Idle or Active, the peering has dropped.

What does State/PfxRcd tell you?

When a BGP neighbor is fully Established, the State/PfxRcd column shows the number of prefixes (routes) received from that neighbor. A value of 2 means you are receiving the two Branch VLAN networks from the ISP.

If the column shows a word like Idle or Active, the BGP session has not come up. Check that the neighbor IP and remote AS number are correct.

Finally, switch to ISP-Router to see the full picture from the provider's perspective. Click on ISP-Router and open its CLI tab.
View the ISP's BGP table:

show ip bgp

The ISP-Router's BGP table shows networks from both sites. You should see entries from AS 65001 (HQ networks like 192.168.10.0 and 192.168.20.0) and entries from AS 65002 (Branch networks like 192.168.30.0 and 192.168.40.0). The ISP is the meeting point where both organizations' routes come together.

Why does the ISP see both sides?

This is exactly how the real internet works. An ISP peers with multiple customer networks via BGP. Each customer advertises their own prefixes, and the ISP's routing table becomes the crossroads connecting them all. The ISP does not need to know about VLANs or OSPF. It only sees the summarized routes each customer chooses to advertise.

Not seeing BGP routes on ISP-Router?

If the ISP-Router's BGP table is empty, run show ip bgp summary to check whether both neighbors (10.0.0.1 and 10.0.0.5) are Established.

If a neighbor shows Idle, verify the neighbor command on both sides points to the correct IP and AS number. Also make sure the WAN interfaces are up with show ip interface brief.

Help me troubleshoot why my ISP-Router is not showing BGP routes from both sites.

You have now verified the entire network from every angle. Pings proved connectivity, traceroute showed the path, and the routing tables confirmed that OSPF and BGP are each doing their job. Your enterprise network is production-ready.

Next up, put your skills to the test with a Secret Mission that adds a third site and challenges you to control which path traffic prefers.

Secret mission

Add a Third Site and Control Traffic with Redistribution Metrics

Real networks have multiple paths. Can you add a third site to the topology, establish full connectivity with BGP, and then influence which path traffic takes by adjusting redistribution metrics? This challenge takes you from configuration to traffic engineering.

Clean Up Your Resources

This project runs entirely locally inside Cisco Packet Tracer, so there are no ongoing costs or cloud resources to worry about. Decide whether to keep your topology file for future reference, or delete it to free up disk space.

Resources you used:

Your saved .pkt topology file containing all routers, switches, PCs, and configurations.

Keep everything running

No action needed. Choose this if you plan to revisit or extend this topology.

Your .pkt file stays on your Desktop wherever you saved it.
You can reopen it any time in Packet Tracer to experiment with new configurations or protocols.

Pause - I'll come back to this later

Save your work and close Packet Tracer to free up system memory.

In Packet Tracer, click File then Save to make sure your latest changes are preserved.
Close Packet Tracer.
Your .pkt file remains on disk and you can double-click it to reopen the full topology later.

Delete - I don't want to use this again

Remove the project topology file from your machine entirely.

Close Packet Tracer if it is still open.
On macOS, open Terminal and run the following command to delete your topology file. Replace the filename if you saved it under a different name.

rm ~/Desktop/enterprise-ospf-bgp.pkt

On Windows, open PowerShell and run:

Remove-Item ~\Desktop\enterprise-ospf-bgp.pkt

Confirm the file is gone by listing your Desktop contents.

Nice Work!

You just built a fully routed multi-site enterprise network from scratch. Traffic now flows seamlessly between departments and sites, crossing VLAN, OSPF, and BGP boundaries exactly like a real enterprise WAN.

You've learned how to:

Segment departments with VLANs and configure router-on-a-stick for inter-VLAN routing across a multi-site enterprise network.
Configure OSPF for automatic internal route discovery and eBGP between autonomous systems to exchange routes the same way real ISPs connect organizations.
Perform route redistribution between OSPF and BGP, then verify the full data path using traceroute to confirm packets cross protocol boundaries correctly.
Secret Mission: Extended the network to three sites and applied redistribution metrics to influence BGP path selection.

Ready to quiz yourself?