Build Your First OSPF Network in GNS3

Configure a 3-router OSPF network in GNS3 and watch routes propagate automatically.

Introduction

30 Second Summary

When you add a new device to your home Wi-Fi, every other device can reach it instantly. But in enterprise networks with dozens of routers, adding a new network segment means manually updating routing tables on every single device.

In this project, you will build a three-router network in GNS3, experience firsthand why static routes break at scale, and then replace them with OSPF so your routers automatically share route information with each other.

What You'll Build

When you're done, you'll add a brand-new network to one router, switch to another router's terminal, and watch the new route appear in its routing table within seconds with zero manual configuration.

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

  • A three-router enterprise topology (HQ, Branch1, Branch2) running in GNS3 with VyOS routers connected by point-to-point links.
  • Static routes configured first so you feel the pain of manual route management, then OSPF Area 0 replacing them with routers that automatically discover neighbors and exchange routes.
  • A live demonstration proving OSPF self-heals when a link fails and adapts when new networks appear.
  • Secret Mission: extend your network with a stub area to see how real enterprises keep branch routers lean and fast.

Are there any prerequisites?

You should have a basic understanding of the OSI model and IP addressing. You'll also need a Windows PC with 8+ GB RAM and virtualization enabled in BIOS.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. In this project you'll feel the pain of static routing firsthand, then replace it with OSPF and watch your routers learn routes automatically.

Install GNS3 and Import VyOS

Before you can simulate any network, you need a lab environment running on your machine. GNS3 is a network emulation tool that lets you design and run virtual router topologies as if they were real hardware.

In this step you will install GNS3, set up the GNS3 VM inside VirtualBox, and import a VyOS router image so you can spin up routers on demand. VyOS is an open-source network operating system with full OSPF support, perfect for building your lab.

In this step, get ready to:
  • Install GNS3 and VirtualBox on your Windows PC.
  • Import and start the GNS3 VM.
  • Create and verify a VyOS router template you can reuse across projects.
Install GNS3 on Windows

GNS3 version 2.2.61 is the latest stable release and the version this project uses. The 3.x branch requires a Linux-only server, so you need the 2.2.x line on Windows.

  • Press the Windows key to open your search bar.
  • Type GNS3 and check whether it appears in your installed programs.

✔️ I see GNS3 version 2.2.x

You already have a compatible version installed. Open GNS3 and click Help then About to confirm the version number starts with 2.2.

Skip ahead to the VirtualBox check below.

ⓧ I see GNS3 version 3.x

GNS3 3.x requires a Linux server and is not compatible with this project's local-VM workflow. You need to install 2.2.61 alongside it or replace it.

  • Open your browser and go to gns3.com/software/download.
  • Download the 2.2.61 All-in-One Windows installer (you may need to scroll to older releases or visit the GitHub releases page).
  • Right-click the downloaded installer and select Run as administrator.
  • Accept all defaults during installation. This bundles QEMU and Wireshark automatically.

ⓧ GNS3 is not installed

  • Open your browser and go to gns3.com/software/download.
  • Download the GNS3 2.2.61 All-in-One Windows installer.
  • Right-click the downloaded file and select Run as administrator.
  • Accept all defaults during installation. The installer bundles QEMU and Wireshark so you do not need to install them separately.
  • When the installer finishes, launch GNS3 to confirm it opens without errors.

What does the All-in-One installer include?

The Windows installer packages everything GNS3 needs: the GUI client, the local server, QEMU (for running virtual routers), and Wireshark (for packet capture). You get a complete lab environment from a single download.

Installer fails or won't start?

Make sure you right-clicked and chose Run as administrator. Without elevated privileges the installer cannot register drivers.

If your antivirus blocks the installer, temporarily disable real-time scanning during the install, then re-enable it.

Help me fix my GNS3 installation

Install VirtualBox and start the GNS3 VM

GNS3 offloads heavy emulation to a dedicated Linux VM called the GNS3 VM. This VM runs inside VirtualBox on your machine.

  • Check whether VirtualBox is already installed by pressing the Windows key and typing VirtualBox.

✔️ VirtualBox appears in my programs

You already have VirtualBox installed. Any recent version (6.x or 7.x) works for the GNS3 VM. Skip to importing the GNS3 VM below.

ⓧ VirtualBox is not installed

  • Go to virtualbox.org/wiki/Downloads.
  • Download the Windows hosts installer.
  • Run the installer and accept all defaults.
  • When it finishes, confirm VirtualBox opens from your Start menu.

Now import the GNS3 VM into VirtualBox.

  • Open GNS3.
  • If this is your first time opening GNS3, a Setup Wizard will appear. Select the option to run appliances in a virtual machine (the GNS3 VM).
  • Follow the wizard prompts to download and import the GNS3 VM into VirtualBox.
  • Once imported, click Next and then Finish to complete the wizard.

The GNS3 VM should start automatically. You will see a green indicator in the GNS3 toolbar confirming the VM is connected.

GNS3 VM not turning green?

Open VirtualBox directly and check whether the GNS3 VM is listed and running. If it shows as powered off, right-click it and select Start.

If you see a virtualization error, restart your PC, enter your BIOS/UEFI settings, and enable VT-x (Intel) or AMD-V.

Help me fix my GNS3 VM connection

Download VyOS and create the router template

With GNS3 running and the VM connected, you need a router image to emulate. VyOS provides free rolling release ISOs that include full OSPF support.

  • Download the VyOS rolling release ISO from vyos.net/get/nightly-builds/.
  • Choose the latest AMD64 ISO file and save it somewhere you can find it (your Downloads folder is fine).

Now create a QEMU VM template in GNS3 for VyOS.

  • In GNS3, click Edit in the menu bar, then Preferences.
  • In the left sidebar, expand QEMU and select QEMU VMs.
  • Click New to create a new QEMU VM template.
  • Set the name to VyOS.
  • Set the QEMU binary to qemu-system-x86_64.
  • Set RAM to 512 MB.
  • Set the console type to telnet.
  • Create a new disk image with a size of 2000 MiB.

Why 512 MB and 2000 MiB?

The official VyOS GNS3 guide recommends 512 MB RAM per router for initial installation. The 2000 MiB disk gives VyOS room to install its image and store configuration files.

  • Set the boot priority to CD/DVD-ROM (so VyOS boots from the ISO first).
  • Attach the VyOS ISO you downloaded as the CD/DVD image.
  • In the Network tab, set the adapter Name format to eth{0} and the Type to virtio-net-pci.
  • Click Finish to save the template.

Your VyOS template now appears in the QEMU VMs list inside Preferences.

Don't see the template in the list?

Make sure you clicked Finish (not Cancel) at the end of the wizard. If the template still does not appear, close Preferences, reopen it, and check under QEMU VMs again.

Help me fix my missing VyOS template

Install VyOS to disk and finalize the template

The template currently boots from the live ISO every time. You need to install VyOS onto the virtual disk so it persists across reboots.

  • Drag your new VyOS template from the device panel onto the GNS3 canvas.
  • Right-click the node and select Start.
  • Double-click the node to open its console.
  • Wait for the VyOS boot to complete. You will see a vyos login: prompt.
  • Log in with username vyos and password vyos.
  • Install VyOS to the virtual disk by running this command:
install image

What does install image do?

This command writes VyOS to the QEMU virtual hard disk you created (the 2000 MiB disk). Once installed, VyOS can boot from disk instead of the ISO.

  • Accept the default answers for each prompt the installer asks (press Enter for each).
  • When asked for a password, set it to vyos (same as the default).
  • After installation completes, shut down the router by running:
poweroff

The node will power off in GNS3. Now reconfigure the template so it boots from the installed disk instead of the ISO.

  • In GNS3, go to Edit then Preferences, and select your VyOS template under QEMU VMs.
  • Click Edit to modify the template.
  • Change the boot priority from CD/DVD-ROM to HDD.
  • Clear the CD/DVD image field (remove the ISO path).
  • In the Network tab, set the number of adapters to 4.
  • Check the box labeled Use as a linked base VM.
  • Click OK to save, then close Preferences.

Why enable linked base VM?

This setting lets you drag multiple VyOS routers onto the canvas, each running as an independent copy of the same base disk. Without it, you could only run one instance at a time.

Before you run this final check, what do you expect to see when you start a fresh VyOS node?

  • Delete the existing node from the canvas (right-click, Delete).
  • Drag a fresh VyOS node from the device panel onto the canvas.
  • Right-click it and select Start.
  • Double-click the node to open its console.

You should see VyOS boot from the hard disk and present the vyos login: prompt. No ISO is needed because VyOS is now installed to disk.

Still booting from the ISO or seeing an error?

Go back to Edit > Preferences > QEMU VMs and confirm the boot priority is set to HDD and the CD/DVD image field is empty.

If you see a GRUB error or "no bootable device", the install image step may not have completed successfully. Revert boot priority to CD/DVD-ROM, reattach the ISO, boot again, log in, and re-run install image.

Help me fix my VyOS boot issue

Your lab environment is ready. You have GNS3 running with a reusable VyOS router template that can spawn as many routers as your project needs. Next up, you will build a 3-router topology and wire it with static routes.

Build Your Topology and Configure Static Routes

Your GNS3 environment is ready with a working VyOS template. Now it's time to build a real network.

You'll wire up three routers and configure static routes between them by hand. This works for small topologies. Pay attention to how much manual effort each new route requires, because that's the exact limitation OSPF solves.

In this step, get ready to:
  • Wire three VyOS routers (HQ, Branch1, Branch2) into a triangle topology.
  • Configure IP addresses on all router interfaces.
  • Add static routes and verify end-to-end connectivity.
Create the project and wire the topology

A network topology describes how routers are connected. You'll create a triangle where every router has a direct link to every other router, simulating a small enterprise with HQ, Branch1, and Branch2 offices.

  • In GNS3, click File in the top menu bar.
  • Click New blank project.
  • Name the project ospf-lab and click OK.
  • From the left toolbar, click the Browse all devices icon (the screen icon at the top of the device list).
  • Drag three VyOS nodes onto the canvas.
  • Right-click the first node and select Change hostname. Name it HQ.
  • Rename the second node to Branch1 and the third to Branch2.

Now wire the routers together. Each link uses a /30 subnet (4 addresses, 2 usable), which is standard for point-to-point router links.

  • Click the Add a link icon in the left toolbar (the cable icon).
  • Click on HQ and select eth0. Then click on Branch1 and select eth0.
  • Click on HQ and select eth1. Then click on Branch2 and select eth0.
  • Click on Branch1 and select eth1. Then click on Branch2 and select eth1.
  • Press Escape to exit link mode.

What do these links represent?

Each cable simulates a dedicated connection between two offices. HQ eth0 to Branch1 eth0 is the 10.0.0.0/30 link. HQ eth1 to Branch2 eth0 is the 10.0.1.0/30 link. Branch1 eth1 to Branch2 eth1 is the 10.0.2.0/30 link.

  • Start all routers by clicking the green Play button in the top toolbar (or right-click the canvas and select Start All Nodes).
  • Wait about 30-60 seconds for all three VMs to boot.
  • Double-click HQ to open its console. You should see the vyos login: prompt.

Console shows a blank screen?

Press Enter a couple of times in the console window. VyOS may have finished booting but the prompt scrolled off-screen. If you still see nothing after 60 seconds, right-click the router and select Stop, wait 5 seconds, then Start again.

Help me troubleshoot my VyOS console

Configure IP addresses on each router

Each router interface needs an IP address so it can send and receive traffic on its links. You'll configure two interfaces per router, one for each connected link.

  • In the HQ console, log in with username vyos and password vyos.
  • Configure HQ's interfaces by entering these commands:
configure
set interfaces ethernet eth0 address 10.0.0.1/30
set interfaces ethernet eth1 address 10.0.1.1/30
commit
save

What do these commands do?

  • configure enters configuration mode where you can make changes to the router.
  • set interfaces ethernet eth0 address 10.0.0.1/30 assigns IP 10.0.0.1 to the interface connecting HQ to Branch1.
  • commit applies your changes to the running configuration.
  • save writes the configuration to disk so it survives a reboot.
  • Open the Branch1 console by double-clicking it on the canvas.
  • Log in with vyos / vyos and configure Branch1's interfaces:
configure
set interfaces ethernet eth0 address 10.0.0.2/30
set interfaces ethernet eth1 address 10.0.2.1/30
commit
save

HQ and Branch1 now share the 10.0.0.0/30 link. Verify that they can talk to each other directly.

  • On Branch1, ping HQ's directly connected interface by running:
run ping 10.0.0.1 count 3

You should see three replies from 10.0.0.1. This confirms the HQ-to-Branch1 link is alive.

  • Open the Branch2 console by double-clicking it on the canvas.
  • Log in with vyos / vyos and configure Branch2's interfaces:
configure
set interfaces ethernet eth0 address 10.0.1.2/30
set interfaces ethernet eth1 address 10.0.2.2/30
commit
save
  • Verify the HQ-to-Branch2 link by pinging from Branch2:
run ping 10.0.1.1 count 3

Three replies from 10.0.1.1 confirm the second link is working.

Pings are failing?

Double-check that you selected the correct eth ports when wiring. If HQ eth0 was accidentally connected to Branch2 instead of Branch1, the IP addresses won't match. Right-click a link in GNS3 and select Delete to remove it, then re-create the correct connection.

Help me fix my ping failure

Add static routes and verify end-to-end connectivity

Right now each router only knows about its own directly connected links. HQ can reach Branch1 and Branch2 directly, but it has no idea how to reach the Branch1-to-Branch2 link (10.0.2.0/30). You need to manually tell each router where to send traffic for remote networks.

  • In the HQ console, add a static route to the Branch1-Branch2 link:
set protocols static route 10.0.2.0/30 next-hop 10.0.0.2
commit
save

What does this route mean?

This tells HQ: to reach any address in the 10.0.2.0/30 subnet, forward the packet to 10.0.0.2 (Branch1). Branch1 is directly connected to that subnet, so it can deliver the packet.

  • In the Branch1 console, add its static route to the HQ-Branch2 link:
set protocols static route 10.0.1.0/30 next-hop 10.0.0.1
commit
save

Before you run the next ping, think about what should happen. HQ now has a route to 10.0.2.0/30, meaning it can reach Branch1's eth1 address. Do you think the ping will succeed?

  • Switch back to the HQ console and test by running:
run ping 10.0.2.1 count 3

You should see three replies. HQ sends traffic for 10.0.2.1 to Branch1 (via the static route), and Branch1 responds because 10.0.2.1 is its own interface.

  • In the Branch2 console, add its static route to the HQ-Branch1 link:
set protocols static route 10.0.0.0/30 next-hop 10.0.1.1
commit
save

All three routers now have routes to every subnet. Before you verify, what do you expect to see in HQ's routing table?

  • Confirm full connectivity by running this on HQ:
run show ip route

You should see entries marked C for directly connected networks (10.0.0.0/30 and 10.0.1.0/30) and an entry marked S for your static route (10.0.2.0/30 via 10.0.0.2).

What do the route codes mean?

In VyOS routing tables, C means connected (the router has an interface on that network). S means static (you manually configured this route). Later, you'll see O for OSPF-learned routes.

✔️ Awesome, I've got everything!

Great. Make sure you've saved the configuration on all three routers. Each router should show commit and save completed without errors.

ⓧ I'd like to double check the full configuration

Here is the complete configuration entered on each router. Scroll up and confirm each block matches what you typed.

HQ:

configure
set interfaces ethernet eth0 address 10.0.0.1/30
set interfaces ethernet eth1 address 10.0.1.1/30
set protocols static route 10.0.2.0/30 next-hop 10.0.0.2
commit
save

Branch1:

configure
set interfaces ethernet eth0 address 10.0.0.2/30
set interfaces ethernet eth1 address 10.0.2.1/30
set protocols static route 10.0.1.0/30 next-hop 10.0.0.1
commit
save

Branch2:

configure
set interfaces ethernet eth0 address 10.0.1.2/30
set interfaces ethernet eth1 address 10.0.2.2/30
set protocols static route 10.0.0.0/30 next-hop 10.0.1.1
commit
save

Your three-router network is fully connected with static routes. Every router can reach every subnet. But notice what it took: you had to log into each router individually and manually specify where to forward traffic. Next up, you'll see exactly how this manual approach falls apart the moment you add a new network.

Watch Static Routing Break

Your static routes work perfectly right now. Every router can reach every link because you manually told each one where to send traffic. But what happens when something changes in the network?

In this step, you'll add a new server network to Branch1 and discover that HQ and Branch2 have no idea it exists. This is the exact pain point that OSPF was invented to solve.

In this step, get ready to:
  • Add a loopback interface to Branch1 simulating a server LAN.
  • Attempt to reach the new network from HQ and observe the failure.
  • Understand why static routing becomes unsustainable at scale.
Add a server network to Branch1

In a real enterprise, branch offices frequently add new networks. A new server VLAN, a guest Wi-Fi subnet, or a VoIP network might appear at any time. You'll simulate this by adding a loopback interface to Branch1 representing a server LAN at 192.168.10.0/24.

What is a loopback interface?

A loopback interface is a virtual network interface that exists entirely in software. It's always "up" regardless of physical link state, making it perfect for simulating additional networks in a lab without needing extra cables or hardware.

  • Open the console for Branch1 by double-clicking it in your GNS3 canvas.
  • Configure the loopback interface by running these commands:
configure
set interfaces loopback lo address 192.168.10.1/24
commit
save

What does this configuration do?

The configure command enters VyOS configuration mode. The set interfaces loopback lo address line creates a virtual interface with IP address 192.168.10.1/24. This represents a whole /24 subnet (254 usable addresses) that could host servers at a branch office.

The commit command applies the change immediately, and save persists it across reboots.

  • Confirm the loopback is active by running this command (still in configuration mode):
run show interfaces loopback lo

You should see lo listed with address 192.168.10.1/24 and state u/u (up/up).

Don't see the loopback interface?

Make sure you ran commit before checking. Without committing, VyOS stages the change but doesn't apply it.

If you see a syntax error, check that you typed loopback lo (lowercase L, then lowercase O) and not a number or uppercase letters.

Still stuck? Help me troubleshoot my VyOS loopback interface configuration.

Try to reach the new network from HQ

Branch1 now has a server network that HQ and Branch2 know nothing about. Your static routes were configured for the three point-to-point links only. Nobody told HQ that 192.168.10.0/24 exists.

  • Open the console for HQ by double-clicking it in your GNS3 canvas.

Before you run the next command, think about this: do you expect HQ to be able to reach 192.168.10.1? You never added a static route for that network on HQ. What do you think will happen?

  • Test connectivity to the new server network by running this command:
ping 192.168.10.1

The ping fails with Network is unreachable. HQ has no idea where to send packets destined for 192.168.10.0/24.

  • Confirm the missing route by examining HQ's routing table:
show ip route

You'll see routes for 10.0.0.0/30, 10.0.1.0/30, and 10.0.2.0/30. The 192.168.10.0/24 network is completely absent. HQ doesn't know it exists.

Why did this happen?

Static routes only know what you manually tell them. When you configured HQ's routing table in the previous step, you added a route to 10.0.2.0/30 because that link already existed. The 192.168.10.0/24 network was added afterwards, and static routes have no mechanism to detect or learn about new networks.

Understand the scaling problem

To fix this with static routes, you would need to log into HQ and add a route to 192.168.10.0/24. Then log into Branch2 and add the same route there. Every single router that needs to reach the new network requires a manual update.

Why is this unsustainable?

With 3 routers, manually updating routes is annoying. With 50 routers spread across 5 office sites, it becomes impossible to maintain. Every new subnet means logging into dozens of devices, and a single typo in one route can black-hole traffic for an entire office.

This is the exact problem that dynamic routing protocols like OSPF solve. OSPF lets routers discover new networks and share that information automatically, with zero manual intervention.

You've just experienced the fundamental limitation of static routing firsthand. In the next step, you'll replace those static routes with OSPF and watch the 192.168.10.0/24 network appear in HQ's routing table automatically.

Replace Static Routes with OSPF

In the last step, you saw the core problem with static routes: adding a new network to one router left the others completely unaware of it. That kind of manual maintenance is fine for three routers, but it falls apart fast in a real enterprise.

OSPF solves this by having routers automatically exchange route information with each other. Once enabled, any new network you add to any router appears in every other router's table within seconds. Zero manual intervention required.

In this step, get ready to:
  • Remove all static routes from HQ, Branch1, and Branch2.
  • Enable OSPF Area 0 on all three routers.
  • Verify OSPF adjacencies form and routes propagate automatically.
Remove static routes from all routers

Before enabling OSPF, you need to remove the static routes that currently handle routing. OSPF will take over their job entirely.

  • Switch to the HQ router console in GNS3.
  • Delete the static routes on HQ by running these commands:
configure
delete protocols static
commit
save
  • Switch to the Branch1 router console.
  • Delete the static routes on Branch1 by running these commands:
configure
delete protocols static
commit
save
  • Switch back to the HQ console and confirm the static route is gone by running:
run show ip route

You should see only the two directly connected routes (10.0.0.0/30 and 10.0.1.0/30). The static route to 10.0.2.0/30 is gone.

  • Switch to the Branch2 router console.
  • Delete the static routes on Branch2 by running these commands:
configure
delete protocols static
commit
save

What just happened?

You removed the hand-written directions that told each router how to reach non-adjacent networks. Right now, your routers can only reach their directly connected neighbors.

The Branch1 server network (192.168.10.0/24) is still unreachable from HQ. OSPF will fix that in the next substep.

Enable OSPF on all three routers

Now you will configure OSPF Area 0 on each router. Each router needs a unique router ID and a list of networks to advertise to its neighbors.

  • Switch to the HQ router console.
  • Enable OSPF on HQ by running these commands:
configure
set protocols ospf parameters router-id 10.0.0.1
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.0.1.0/30
commit
save

What do these commands do?

  • router-id 10.0.0.1 gives HQ a unique identity in the OSPF domain. Routers use this ID to identify each other.
  • area 0 network 10.0.0.0/30 tells OSPF to advertise the HQ-to-Branch1 link and listen for neighbors on it.
  • area 0 network 10.0.1.0/30 does the same for the HQ-to-Branch2 link.

Area 0 is the backbone area. All OSPF routers in a network must connect to Area 0, either directly or through a virtual link.

  • Switch to the Branch1 router console.
  • Enable OSPF on Branch1 by running these commands:
configure
set protocols ospf parameters router-id 10.0.0.2
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.0.2.0/30
set protocols ospf area 0 network 192.168.10.0/24
commit
save

Why does Branch1 advertise three networks?

Branch1 has links to both HQ and Branch2, plus the server LAN (192.168.10.0/24) on its loopback interface. By including all three in OSPF, Branch1 tells its neighbors that it can reach those networks.

This is the key difference from static routing. You only declare networks on the router that owns them, and OSPF propagates the information everywhere else automatically.

  • Switch back to the HQ console briefly and check if Branch1 has appeared as a neighbor by running:
run show ip ospf neighbor

You should already see Branch1 (10.0.0.2) listed with a state containing Full. This means HQ and Branch1 have formed a complete OSPF adjacency.

  • Switch to the Branch2 router console.
  • Enable OSPF on Branch2 by running these commands:
configure
set protocols ospf parameters router-id 10.0.1.2
set protocols ospf area 0 network 10.0.1.0/30
set protocols ospf area 0 network 10.0.2.0/30
commit
save
Verify OSPF adjacencies and test route propagation

OSPF needs 10 to 30 seconds to form adjacencies and exchange routing information. Give it a moment, then check the results on HQ.

  • Wait about 30 seconds for OSPF to converge.
  • Switch to the HQ router console.

Before you run the next command, think about what you expect to see. How many OSPF neighbors should HQ have?

  • Check HQ's OSPF neighbors by running:
show ip ospf neighbor

You should see two neighbors listed: 10.0.0.2 (Branch1) and 10.0.1.2 (Branch2). Both should show a State containing Full, proving the adjacencies formed successfully.

  • Now check whether the server network from Branch1 was learned automatically by running:
show ip route

Look for 192.168.10.0/24 in the output. It should be marked with O (meaning OSPF-learned). You never configured this route on HQ. OSPF distributed it from Branch1 automatically.

  • Confirm actual reachability by pinging Branch1's server network:
ping 192.168.10.1

The ping succeeds. Remember, this exact address was unreachable at the end of Step 3. OSPF fixed the problem with zero manual route configuration on HQ.

Not seeing Full state or ping fails?

  • If the State column shows something other than Full (like Init or 2-Way), wait another 30 seconds and re-run show ip ospf neighbor. OSPF adjacencies take time to fully form.
  • If no neighbors appear at all, verify each router's OSPF network statements match the interface subnets exactly. For example, HQ's eth0 is 10.0.0.1/30, so the network statement must be 10.0.0.0/30 (the network address, not the interface address).
  • Make sure you deleted the static routes with delete protocols static and committed on all three routers before enabling OSPF.

help me troubleshoot OSPF neighbors not reaching Full state in VyOS

Your three routers are now exchanging route information automatically via OSPF. Next up, you will put OSPF to the ultimate test by adding a brand-new network and watching it appear on HQ without touching a single configuration line there.

Prove OSPF Works Automatically

Your OSPF adjacencies are formed and routes are flowing between all three routers. But the real test of a dynamic routing protocol is how it reacts to change without human intervention.

In this step, you'll add a brand-new network to one router and watch it appear on the others automatically. Then you'll deliberately break a link and watch OSPF reroute around the failure. This is exactly the demonstration you'd walk through in a network engineering interview.

In this step, get ready to:
  • Add a new network to Branch2 and verify it propagates to HQ automatically.
  • Disable a link and confirm OSPF reroutes traffic around the failure.
Add a new network on Branch2

To prove OSPF propagates routes automatically, you'll simulate a second office LAN on Branch2 using a loopback interface. You will not touch HQ or Branch1 at all.

  • Open the console for Branch2 in GNS3.
  • Add a loopback interface and advertise it into OSPF by running these commands:
configure
set interfaces loopback lo address 172.16.0.1/24
set protocols ospf area 0 network 172.16.0.0/24
commit
save

What do these commands do?

The loopback interface simulates a LAN network (like a server subnet) attached to Branch2. It doesn't require a physical link.

The set protocols ospf area 0 network 172.16.0.0/24 command tells OSPF to advertise this new network to all neighbors. You're not touching HQ or Branch1 at all.

Verify route propagation on HQ

If OSPF is working correctly, HQ should learn about the 172.16.0.0/24 network within seconds. You did not add any route to HQ manually.

  • Open the console for HQ in GNS3.
  • Before you run the next command, predict: will HQ know about the 172.16.0.0/24 network even though you never configured a route on HQ?
  • Check HQ's routing table by running:
show ip route

You should see 172.16.0.0/24 in the output with an O marker next to it. That O means OSPF learned this route automatically.

What does the O marker mean?

VyOS marks routes with a letter indicating how they were learned. O means OSPF. S means static. C means directly connected.

Seeing O next to 172.16.0.0/24 proves the route was distributed by OSPF, not by anything you typed on HQ.

  • Confirm end-to-end reachability by pinging Branch2's new network:
ping 172.16.0.1

The ping succeeds. You added a network to one router, and every other router learned it automatically. Zero manual intervention.

Not seeing 172.16.0.0/24 in the routing table?

  • Wait 10-30 seconds and run show ip route again. OSPF needs a few seconds to exchange link-state advertisements.
  • On Branch2, verify you committed the OSPF network statement. Run show protocols ospf to confirm 172.16.0.0/24 is listed under area 0.
  • Check that HQ still shows Branch2 as a neighbor in Full state with show ip ospf neighbor.

Why isn't the new OSPF route appearing on HQ?

Test OSPF failure recovery

Route propagation is powerful, but OSPF's real strength is self-healing. If a link goes down, OSPF finds an alternate path automatically. You'll prove this by deliberately breaking a connection.

  • On the HQ console, disable the direct link to Branch2 by running:
configure
set interfaces ethernet eth1 disable
commit

What does disabling eth1 simulate?

This simulates a cable being unplugged or a WAN link going down between HQ and Branch2. In a real network, this could be a fiber cut or a switch failure.

The direct path from HQ to Branch2 (10.0.1.0/30) is now dead. HQ can only reach Branch2 through Branch1.

  • Before checking the routing table, predict: will the route to 172.16.0.0/24 disappear entirely, or will OSPF find another path?
  • Wait 10-30 seconds for OSPF to detect the failure, then check the routing table:
show ip route

The route to 172.16.0.0/24 is still there. Look at the next-hop address. It now shows 10.0.0.2 (Branch1) instead of the direct path through Branch2. OSPF rerouted around the failure automatically.

Why does this matter?

In a static-route network, a link failure means traffic is simply dropped. Someone has to log in and manually update routes.

With OSPF, the protocol detects the dead link, recalculates the shortest path, and installs the new route. All within seconds and with zero human intervention.

  • Re-enable the link to restore your original topology:
delete interfaces ethernet eth1 disable
commit
save
  • Verify the link is back by running show ip route on HQ. You should see routes using both next-hops again.

Route still showing the old next-hop after re-enabling?

  • Wait 30 seconds for OSPF to re-establish the adjacency on the restored link. OSPF has timers that control how quickly it detects changes.
  • Run show ip ospf neighbor to confirm Branch2 appears as a neighbor again in Full state.

Why is OSPF taking a long time to reroute after I re-enabled the link?

You just proved the two core superpowers of OSPF. New networks propagate without manual route entries. Link failures trigger automatic rerouting without any human touching the affected routers. Your lab is now a complete demonstration of dynamic routing in action.

Secret mission

Add a Stub Area

In production networks with hundreds of subnets, not every router needs the full routing table. Configure OSPF Area 1 as a stub area on your lab to see how enterprise architects keep branch routers lean while maintaining full connectivity.

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, so there are no ongoing costs.

Resources you used:

  • GNS3 project with three VyOS routers (HQ, Branch1, Branch2).
  • GNS3 VM running in VirtualBox.
  • GNS3 application installed on Windows.
  • VirtualBox installed on Windows.
  • VyOS rolling release ISO file.

Keep everything running

No action needed. Choose this if you plan to use this topology in the follow-on Python automation project or want to continue experimenting with OSPF.

  • Leave the GNS3 project saved. You will use this exact topology in the follow-on Netmiko automation project.
  • The GNS3 VM and VirtualBox remain installed and ready for your next session.
  • Your VyOS router configurations are saved and will persist across reboots.

Pause - I'll come back to this later

Stop running processes to free up RAM while keeping all your files and configurations intact.

  • In GNS3, right-click an empty area of the canvas and select Stop All Nodes. This shuts down all three routers and frees their RAM.
  • Close GNS3. When prompted to save, click Yes to preserve your project state.
  • In VirtualBox, select the GNS3 VM and click Power Off to stop the VM and reclaim its memory.
  • When you return, start the GNS3 VM first, then open GNS3 and start all nodes. Your OSPF configuration will still be there.

Delete - I don't want to use this again

Remove all project resources to reclaim disk space. You can rebuild the lab from this guide if you change your mind.

  • In GNS3, go to File then click Delete Project. This removes the project and all associated router disk images.
  • In GNS3, go to Edit then Preferences then QEMU VMs. Select the VyOS template and click Delete to remove the router template.
  • In VirtualBox, right-click the GNS3 VM and select Remove. Choose Delete all files to reclaim the VM's disk space.
  • Delete the VyOS ISO file you downloaded. Find it in your Downloads folder and delete it permanently.
  • To uninstall GNS3, open Windows Settings, go to Apps then Installed apps. Find GNS3 in the list and click Uninstall.
  • To uninstall VirtualBox, follow the same path in Windows Settings. Find Oracle VM VirtualBox in the app list and click Uninstall.

Nice Work!

Nice Work!

You just built a fully functional OSPF network from scratch. Three routers, two areas, automatic route propagation, and self-healing failover. That is enterprise-grade dynamic routing running on your own machine.

Here's what you accomplished:

  • Built a 3-router enterprise topology in GNS3 with VyOS routers, configured static routes, and experienced firsthand why they don't scale when new networks are added.
  • Replaced static routes with OSPF Area 0 and watched new networks propagate automatically across all routers with zero manual intervention.
  • Proved OSPF self-heals by disabling a link and watching traffic reroute through an alternate path within seconds.
  • Secret Mission: Configured a stub area to reduce the routing table size on branch routers, replacing individual external prefixes with a single default route.

Ready to quiz yourself?