Build and Troubleshoot OSPF

Build a three-router OSPF network and troubleshoot a Hello timer mismatch.

Introduction

30 Second Summary

When a connection fails, the final error rarely tells you where the problem began. A reliable fix comes from following the evidence back to the first disagreement.

In this project, you will build a three-router broadcast network in PNETLab with OSPFv2 area 0. You will use the Cisco IOS CLI to trace packet exchanges into neighbor state, link-state data, and reachable loopbacks before diagnosing an intentional timer mismatch.

What You'll Build

Your finished lab answers every remote-loopback ping while live Cisco IOS evidence traces each successful path from packet exchange to installed route.

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

A working area 0 network where all three routers reach every loopback across the shared Ethernet segment.
A packet-to-route explanation that traces reachability from Hello packets through Type 1 Router LSAs plus Type 2 Network LSAs into installed O routes.
A repeatable repair workflow that exposes an OSPF Hello-timer mismatch from live evidence before restoring full reachability.
Secret Mission: Capture a fresh adjacency sequence to classify the packet types and state changes observed while the neighbor relationship reforms.

Are there any prerequisites?

You need a working PNETLab deployment with three instances of your Cisco IOL Layer 3 image running Cisco IOS Software 15.4(2)T4. No software installation is required.

Before We Start

Before any configuration begins, commit to the three-router OSPFv2 broadcast network you are about to build in PNETLab. Your goal is to trace evidence from packets through neighbor state, LSAs, and installed routes so troubleshooting follows a repeatable path.

Verify and Wire the Cisco Lab

Before you trust an OSPF failure, the physical lab needs a known baseline. A missing link can look like a routing problem.

You will build that baseline in PNETLab. You will confirm the Cisco IOS Software release. You will also identify the interface that carries the shared link.

In this step, get ready to:

Create a dedicated PNETLab lab with three Cisco IOL Layer 3 routers.
Connect every router to one shared Layer 2 broadcast segment.
Verify the IOS release plus the shared Ethernet interface.

Create the dedicated lab

A dedicated lab keeps this topology separate from your other PNETLab projects. Clear router names also make the later command output easier to follow.

Go to your existing PNETLab deployment in a browser.
Sign in with your existing PNETLab account.
Create a dedicated lab through the lab creation control in the workspace.
Add three instances of your existing Cisco IOL Layer 3 image to the lab.
Name the first node R1.
Name the second node R2.
Name the third node R3.
Confirm the lab canvas shows all three named routers.

Your dedicated lab now gives every router a clear identity. That makes each later neighbor check easier to trace.

Connect the shared segment

The three routers need one common Ethernet LAN. This layout creates the broadcast behavior that the project investigates.

Why one shared segment?

A shared segment creates one multiaccess Ethernet LAN. This gives the later OSPF process a single place to discover neighbors.

That layout supports DR plus BDR elections. Point-to-point links would also remove the Type 2 Network LSA that represents the shared network.

Add one shared Layer 2 segment to the lab canvas through the segment creation control.
Connect Ethernet0/0 on R1 to the shared segment.
Connect Ethernet0/0 on R2 to the shared segment.
Connect Ethernet0/0 on R3 to the shared segment.
Start R1 from its node control.
Start R2 from its node control.
Start R3 from its node control.
Wait for all three node indicators to show that the routers are running.

Good progress. Your three routers now share one broadcast LAN.

Verify the software and interface

The release check confirms the intended software target. The interface inventory confirms which port belongs to the shared segment.

Open the console for R1 from its node on the PNETLab canvas.
Collect the R1 baseline by running these commands:

show version
show ip interface brief

What do these commands show?

The show version command identifies the running Cisco IOS Software release.
The show ip interface brief command shows each interface's primary IP address. It also shows the interface status.

Confirm 15.4(2)T4 appears in the R1 version output.
Locate Ethernet0/0 in the R1 interface list.
Switch to the R2 console.
Collect the R2 baseline by running the command pair shown above.
Confirm 15.4(2)T4 appears in the R2 version output.
Locate Ethernet0/0 in the R2 interface list.

The first two routers now match the intended software target. They also expose the same shared-segment interface.

Switch to the R3 console.

Before you run the final check, do you expect the third router to report the same release plus interface name?

Collect the R3 baseline by running these commands:

show version
show ip interface brief

What does the final baseline prove?

Matching software release strings prove that all three routers use the intended IOS target.
Seeing Ethernet0/0 on every router proves that one interface name can be used throughout the lab.

You should see 15.4(2)T4 in the version output. You should also see Ethernet0/0 in the interface list.

Does one router look different?

Check that the affected node uses the same Cisco IOL Layer 3 image as the other two routers.
Inspect the affected node's link endpoint if Ethernet0/0 is absent from the interface list.
Reconnect that node's shared-segment link to Ethernet0/0 if the endpoint is wrong.

Help me diagnose my lab baseline.

✔️ My lab matches the target

All three routers are running on one shared segment. Their CLI checks report the expected software release plus interface name.

ⓧ I'd like to double check the lab state

Compare your lab with this target state:

The dedicated PNETLab lab contains running Cisco IOL Layer 3 nodes named R1, R2, plus R3 on one common Layer 2 broadcast segment.
R1 runs Cisco IOS Software 15.4(2)T4. Its Ethernet0/0 interface connects to the shared segment. It has no project IP or OSPF configuration.
R2 runs Cisco IOS Software 15.4(2)T4. Its Ethernet0/0 interface connects to the shared segment. It has no project IP or OSPF configuration.
R3 runs Cisco IOS Software 15.4(2)T4. Its Ethernet0/0 interface connects to the shared segment. It has no project IP or OSPF configuration.

Your lab now has a trustworthy physical baseline. Next, you will assign IP addresses and expose the reachability limit that OSPF needs to solve.

Configure the Connected Network

Your PNETLab topology now has three running routers on one shared segment. The Cisco IOS consoles have confirmed Ethernet0/0 as the common interface.

A shared LAN gives the routers direct reachability once each interface has an address. The remote loopbacks still need OSPF. This step deliberately exposes that routing limit.

In this step, get ready to:

Assign a unique shared-LAN address to each router.
Create one loopback interface on each router.
Compare direct reachability with an unreachable remote loopback.

Address the shared Ethernet segment

An IPv4 address identifies each router on the shared LAN. The 255.255.255.0 mask places all three addresses inside the same directly connected network.

Complete each router tab below.

R1

Switch back to the R1 Cisco IOS CLI from earlier.
Configure R1's shared-LAN interface by running these commands:

enable
configure terminal
interface Ethernet0/0
ip address 10.0.0.1 255.255.255.0
no shutdown
end
show ip interface brief

What Does the R1 Configuration Do?

The enable command enters privileged EXEC mode.
The configure terminal command enters global configuration mode.
The interface Ethernet0/0 command selects the interface connected to the shared segment.
The ip address 10.0.0.1 255.255.255.0 command assigns R1's unique LAN address.
The no shutdown command enables the interface.
The end command returns to privileged EXEC mode.
The show ip interface brief command displays the address plus the interface status.

You should see Ethernet0/0 with the address 10.0.0.1. Its status should show that the interface is enabled.

R2

Switch back to the R2 Cisco IOS CLI from earlier.
Configure R2's shared-LAN interface by running these commands:

enable
configure terminal
interface Ethernet0/0
ip address 10.0.0.2 255.255.255.0
no shutdown
end
show ip interface brief

What Changes on R2?

The configuration selects R2's Ethernet0/0 interface.
The address 10.0.0.2 gives R2 a unique identity on the shared LAN.
The no shutdown command enables the interface.
The final command displays the address plus the interface status.

You should see Ethernet0/0 with the address 10.0.0.2. Its status should show that the interface is enabled.

R3

Switch back to the R3 Cisco IOS CLI from earlier.
Configure R3's shared-LAN interface by running these commands:

enable
configure terminal
interface Ethernet0/0
ip address 10.0.0.3 255.255.255.0
no shutdown
end
show ip interface brief

What Changes on R3?

The configuration selects R3's Ethernet0/0 interface.
The address 10.0.0.3 gives R3 a unique identity on the shared LAN.
The no shutdown command enables the interface.
The final command displays the address plus the interface status.

You should see Ethernet0/0 with the address 10.0.0.3. Its status should show that the interface is enabled.

Ethernet0/0 Still Disabled?

Confirm that you entered no shutdown under Ethernet0/0 on the affected router.
Check the shared segment in PNETLab to confirm that all three router links remain connected.
Verify that each router uses a different final address value.

Help me diagnose an Ethernet0/0 interface that is not enabled in this three-router Cisco IOS lab.

Good progress. All three physical interfaces now have a unique address inside 10.0.0.0/24.

Create stable loopback interfaces

Each loopback provides a fixed /32 destination for later routing tests. Its address belongs only to that router.

Complete each router tab below.

R1

Switch back to the R1 Cisco IOS CLI from earlier.
Create R1's loopback by running these commands:

enable
configure terminal
interface Loopback0
ip address 10.255.0.1 255.255.255.255
no shutdown
end
show ip interface brief

What Does the R1 Loopback Configuration Do?

The interface Loopback0 command creates or selects R1's loopback.
The address 10.255.0.1 becomes R1's unique loopback destination.
The 255.255.255.255 mask represents one host address.
The final command confirms that Loopback0 is enabled.

You should see Loopback0 with the address 10.255.0.1. Its status should show that the interface is enabled.

R2

Switch back to the R2 Cisco IOS CLI from earlier.
Create R2's loopback by running these commands:

enable
configure terminal
interface Loopback0
ip address 10.255.0.2 255.255.255.255
no shutdown
end
show ip interface brief

What Does the R2 Loopback Configuration Do?

The configuration creates or selects R2's Loopback0 interface.
The address 10.255.0.2 becomes R2's unique loopback destination.
The 255.255.255.255 mask represents one host address.
The final command confirms that the loopback is enabled.

You should see Loopback0 with the address 10.255.0.2. Its status should show that the interface is enabled.

R3

Switch back to the R3 Cisco IOS CLI from earlier.
Create R3's loopback by running these commands:

enable
configure terminal
interface Loopback0
ip address 10.255.0.3 255.255.255.255
no shutdown
end
show ip interface brief

What Does the R3 Loopback Configuration Do?

The configuration creates or selects R3's Loopback0 interface.
The address 10.255.0.3 becomes R3's unique loopback destination.
The 255.255.255.255 mask represents one host address.
The final command confirms that the loopback is enabled.

You should see Loopback0 with the address 10.255.0.3. Its status should show that the interface is enabled.

Loopback0 Missing or Unaddressed?

Confirm that the interface name is Loopback0 on each router.
Check that each loopback uses the 255.255.255.255 mask.
Verify that the final address value matches the router number.

Help me fix a missing or unaddressed Loopback0 interface in this Cisco IOS lab.

That gives every router a local test destination. The next check reveals which destinations R1 can reach with connected routes alone.

✔️ Awesome, I've got everything!

All six interfaces are addressed. Confirm that each router still shows both interfaces as enabled.

ⓧ I'd like to double check the full code

Compare the commands applied to R1 with this complete sequence:

enable
configure terminal
interface Ethernet0/0
ip address 10.0.0.1 255.255.255.0
no shutdown
interface Loopback0
ip address 10.255.0.1 255.255.255.255
no shutdown
end

Compare the commands applied to R2 with this complete sequence:

enable
configure terminal
interface Ethernet0/0
ip address 10.0.0.2 255.255.255.0
no shutdown
interface Loopback0
ip address 10.255.0.2 255.255.255.255
no shutdown
end

Compare the commands applied to R3 with this complete sequence:

enable
configure terminal
interface Ethernet0/0
ip address 10.0.0.3 255.255.255.0
no shutdown
interface Loopback0
ip address 10.255.0.3 255.255.255.255
no shutdown
end

Test connected reachability

R1 reaches R2 through the shared LAN because both interfaces belong to the same connected network. This first ping tests that local path.

Before you test it, predict whether R1 can reach R2 without a routing protocol:

Switch back to the R1 Cisco IOS CLI from earlier.
Test R2's shared-LAN address by running this command:

ping 10.0.0.2

What Does This Ping Test?

The command sends echo requests from R1 to R2's address on the shared segment. A reply proves that both Ethernet interfaces can exchange traffic across the Layer 2 connection.

You should see ! characters for the replies. The summary should report Success rate is 100 percent.

Shared-LAN Ping Failing?

Confirm that R1 uses 10.0.0.1 on Ethernet0/0.
Confirm that R2 uses 10.0.0.2 on Ethernet0/0.
Check that both interfaces are enabled with the 255.255.255.0 mask.

Help me diagnose why R1 cannot ping R2 across the shared 10.0.0.0/24 LAN.

The shared-LAN ping proves that the physical segment plus the interface configuration work. A remote loopback asks R1 to reach beyond its connected networks.

Before you test the loopback, predict whether R1 can reach R3 at 10.255.0.3 with no dynamic routing protocol configured:

Test R3's remote loopback from R1 by running this command:

ping 10.255.0.3

Why Does This Test Reach Further?

The destination exists on R3's Loopback0 interface. R1 currently knows only its local loopback plus the directly connected shared LAN.

No dynamic routing protocol has exchanged the remote loopback route. R1 has no path for forwarding this traffic to R3.

You will see the ping fail. This is the intended result.

Your connected network works. Next, you will add OSPF so R1 can learn the remote loopback routes.

Form OSPF Adjacencies

The shared LAN already carries traffic between R1 and R2. R1 still has no route to R3's loopback.

The next layer is OSPF. OSPF exchanges topology information so each router can install routes to the remote loopbacks.

In this step, get ready to:

Form OSPF neighbors on the shared LAN.
Advertise each loopback through area 0 without sending Hellos from Loopback0.
Verify learned remote routes with a successful ping.

Enable OSPF on the shared LAN

Each router needs the same OSPF process and area on the shared Ethernet network. The process begins exchanging Hello packets when its network statement matches Ethernet0/0.

Switch back to R1's Cisco IOS CLI.
Configure R1's shared-LAN OSPF process by running:

enable
configure terminal
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
end

What does this configuration do?

The OSPF process uses the locally significant process ID 1.
The network statement matches R1's 10.0.0.1 address through the wildcard mask.
The matched Ethernet interface joins area 0.
The final command returns R1 to privileged EXEC mode.

Switch back to R2's Cisco IOS CLI.
Configure R2's shared-LAN OSPF process by running:

enable
configure terminal
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
end

How does R2 join the area?

R2 starts its own OSPF process with the local process ID 1.
The shared-LAN statement matches R2's 10.0.0.2 address.
R1 and R2 can now discover each other through area 0 Hello packets.

The first adjacency can take a few Hello exchanges to settle. A brief pause here is expected.

Before you check R1, which router ID do you expect to appear as its first neighbor?

Switch back to R1's Cisco IOS CLI.
Inspect R1's first OSPF neighbor by running:

show ip ospf neighbor

What does the neighbor table prove?

The neighbor table shows which routers exchanged compatible OSPF Hellos. It also shows the neighbor state and elected broadcast role.

You should see router ID 10.255.0.2 in R1's neighbor table. The adjacency should reach a FULL state.

Switch back to R3's Cisco IOS CLI.
Configure R3's shared-LAN OSPF process by running:

enable
configure terminal
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
end

What changes when R3 joins?

R3 joins the same broadcast network through area 0. The three routers can now elect DR and BDR roles for the segment.

Switch back to R1's Cisco IOS CLI.
Inspect R1's updated neighbor table by running:

show ip ospf neighbor

How do broadcast neighbor states work?

A router forms a FULL adjacency with the DR and BDR. Two DROTHER routers can remain in the 2-WAY state.

The role suffixes identify the DR, BDR, or DROTHER position. The exact election result depends on which router joined first.

You should now see router IDs 10.255.0.2 and 10.255.0.3 in R1's neighbor table.

Missing an OSPF neighbor?

Confirm the missing router still has an enabled Ethernet0/0 interface on the shared LAN.
Compare the shared-LAN network statement with the reference later in this step.
Check that every shared interface uses an address from 10.0.0.0/24.

Help me diagnose the missing OSPF neighbor.

Advertise the loopbacks without Hellos

The shared-LAN statement forms neighbors. Each loopback also needs an exact host statement before other routers can learn its /32 route.

A passive interface remains advertised through OSPF. It stops OSPF Hello packets from leaving that interface.

Switch back to R1's Cisco IOS CLI.
Advertise R1's loopback through area 0 by running:

configure terminal
router ospf 1
network 10.255.0.1 0.0.0.0 area 0
passive-interface Loopback0
end

Why use an exact host match?

The all-zero wildcard mask matches only 10.255.0.1.
The passive setting advertises Loopback0 without trying to discover a neighbor there.
R1 uses the pre-existing loopback address as its stable router ID.

Switch back to R2's Cisco IOS CLI.
Advertise R2's loopback through area 0 by running:

configure terminal
router ospf 1
network 10.255.0.2 0.0.0.0 area 0
passive-interface Loopback0
end

What does R2 contribute?

R2 advertises 10.255.0.2 as an exact host network. Its pre-existing loopback also serves as router ID 10.255.0.2.

Switch back to R1's Cisco IOS CLI.
Check for R2's newly learned loopback route by running:

show ip route ospf

What does the route code show?

The routing table marks OSPF-derived routes with O. This proves R1 learned the prefix from OSPF instead of a connected interface.

You should see a route to 10.255.0.2 marked with O.

Switch back to R3's Cisco IOS CLI.
Advertise R3's loopback through area 0 by running:

configure terminal
router ospf 1
network 10.255.0.3 0.0.0.0 area 0
passive-interface Loopback0
end

What completes the route exchange?

R3 now advertises 10.255.0.3 through area 0. Its loopback address also serves as router ID 10.255.0.3.

✔️ Awesome, I've got everything!

Your three routers now share the LAN through OSPF. Each router also advertises its passive loopback.

ⓧ I'd like to double check the full code

Compare R1's OSPF section with this reference:

router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 10.255.0.1 0.0.0.0 area 0
passive-interface Loopback0

R1 configuration check

R1 joins the shared LAN through area 0. It advertises only its own loopback through the exact host statement.

Compare R2's OSPF section with this reference:

router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 10.255.0.2 0.0.0.0 area 0
passive-interface Loopback0

R2 configuration check

R2 uses the same shared-LAN statement. Its exact host statement advertises 10.255.0.2.

Compare R3's OSPF section with this reference:

router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 10.255.0.3 0.0.0.0 area 0
passive-interface Loopback0

R3 configuration check

R3 joins the same area through the shared LAN. Its passive loopback remains advertised as 10.255.0.3.

Verify OSPF and remote reachability

The neighbor tables prove that OSPF exchanges information across the broadcast segment. The route tables prove that each router can use that information to reach remote loopbacks.

Before you check the three neighbor tables, which two router IDs do you expect each router to list?

Check every router's neighbor table by running this command in each Cisco IOS CLI:

show ip ospf neighbor

What should the three tables show?

Each router should list the other two router IDs. The state and role columns should also identify the broadcast relationships.

Across the three outputs, you should see router IDs 10.255.0.1, 10.255.0.2, and 10.255.0.3. The role suffixes should show an elected DR and BDR.

Before you inspect the route tables, which two remote loopback addresses should each router learn?

Check every router's learned OSPF routes by running this command in each Cisco IOS CLI:

show ip route ospf

How do the routes connect the topology?

Each router should have two remote loopback routes marked O. The local loopback stays connected while OSPF supplies paths to the other two.

Before you run the final ping, do you expect the earlier loopback failure to continue?

Switch back to R1's Cisco IOS CLI.
Test the repaired path to R3's loopback by running:

ping 10.255.0.3

What does this test prove?

The ping tests the complete path from R1 to R3's loopback. A successful reply proves that OSPF installed a usable remote route.

You should see ! characters followed by Success rate is 100 percent. That earlier routing limit is gone because R1 now knows how to reach R3's loopback.

No O routes or ping replies?

Confirm R1's neighbor table includes router ID 10.255.0.3.
Compare R3's exact host statement with the full configuration reference.
Confirm Loopback0 on R3 still uses 10.255.0.3.

Help me find why the OSPF route or loopback ping is failing.

Your routers now turn OSPF neighbor relationships into reachable loopback routes. Next up, you will trace those routes back through broadcast roles, packet fields, and the link-state database.

Inspect Packets, Roles, and LSAs

R1, R2, and R3 now exchange routes through OSPF. That is a solid milestone: R1 can reach every remote loopback.

Troubleshooting gets faster when you can trace a route backward through the link-state database. Neighbor roles plus packet fields complete that trail.

Cisco IOS exposes each layer without changing the working topology. In this step, you will connect that evidence into one troubleshooting view.

In this step, get ready to:

Inspect the broadcast interface election evidence.
Match each router ID to the link-state database.
Capture one received Hello packet from the working adjacency.

Inspect the broadcast interface roles

The shared Ethernet segment requires an election among the attached routers. The interface view exposes that election result.

The same view shows the timing values every router must share. Matching timers keep neighbor communication healthy.

Inspect Ethernet0/0 on R1, R2, and R3 by running this command in each router's CLI:

show ip ospf interface Ethernet0/0

What Does the Interface View Prove?

The BROADCAST network type confirms that OSPF treats the shared Ethernet segment as a multiaccess network.
The DR role identifies the designated router for the segment.
The BDR role identifies the backup designated router.
The priority field provides part of the election evidence for each interface.
The Hello interval controls how often the router sends Hello packets.
The Dead interval controls how long a router waits before declaring a neighbor unavailable.

Each router should report BROADCAST for Ethernet0/0. The three interface states should reflect one DR plus one BDR.

The Hello interval should be 10 seconds. The Dead interval should be 40 seconds.

Compare the interface states across the three routers.
Record the elected DR router ID here: the elected DR router ID.
Record the elected BDR router ID here: the elected BDR router ID.
Record R1's interface priority here: R1's OSPF interface priority.
Record R2's interface priority here: R2's OSPF interface priority.
Record R3's interface priority here: R3's OSPF interface priority.
Record the Hello interval as 10 seconds.
Record the Dead interval as 40 seconds.

Not Seeing Consistent Interface Evidence?

Confirm that every Ethernet0/0 interface remains connected to the same shared Layer 2 segment.
Confirm that OSPF process 1 still includes Ethernet0/0 in area 0.

Help me compare my OSPF interface output.

Match router and network LSAs

A Type 1 Router LSA describes one router's links within an area. Your database should contain one for each of the three router IDs.

A Type 2 Network LSA describes the routers attached to the shared segment. The elected DR originates this LSA.

Inspect the Router LSA and Network LSA views on R1 by running these commands:

show ip ospf database router
show ip ospf database network

How the LSAs Divide the Topology

The Router LSA view shows topology information advertised by each router in area 0.
The Network LSA view shows the multiaccess segment created by the broadcast LAN.
The attached-router information connects the Network LSA back to the three participating router IDs.

Match 10.255.0.1 to its Router LSA entry.
Match 10.255.0.2 to its Router LSA entry.
Match 10.255.0.3 to its Router LSA entry.
Locate the Network LSA for the shared Ethernet segment.
Confirm that its attached-router information includes all three router IDs.
Compare the router that originated the Network LSA with the elected DR router ID.

You should find three Router LSAs with the loopback-based router IDs. The Network LSA should connect those routers to the shared segment.

Missing an Expected LSA?

Confirm that all three neighbor relationships remain established.
Compare the router IDs in the database with the three Loopback0 addresses.
Confirm that the earlier interface output still identifies the segment as BROADCAST.

Help me find the missing OSPF LSA.

Capture and decode a Hello packet

Packet debugging can look busy at first. You only need one received Hello packet to connect the live exchange to the evidence you have already inspected.

Before you start the capture, consider which packet type you expect during a quiet adjacency.

Enable packet-level OSPF debugging on R1 by running this command:

debug ip ospf packet

What Does This Command Reveal?

The command displays information about each received OSPF packet.
The v: field identifies the OSPF version.
The t: field identifies the packet type.
The l: field identifies the packet length.
The rid: field identifies the sending router.
The aid: field identifies the OSPF area.
The chk: field contains the packet checksum.
The aut: field identifies the authentication type.

The console may sit quietly for a few seconds. With a 10-second Hello interval, you should see a received packet line soon.

Wait for one received line containing fields such as v:2, t:1, rid:, and aid:.

The v:2 value identifies OSPF version 2. The t:1 value identifies a Hello packet.

Disable packet-level OSPF debugging immediately by running this command:

no debug ip ospf packet

Why Stop After One Packet?

Packet debugging continues to print received traffic until you disable it. Stopping after one useful line keeps R1's CLI readable while preserving the captured evidence in the terminal history.

Watch R1's CLI for at least 10 seconds.

You should see no new OSPF packet debug lines during the wait. This confirms that the debug is disabled.

Identify the version from v:2.
Identify the Hello packet type from t:1.
Identify the packet length from l:.
Match the rid: value to one of the neighboring router IDs.
Identify the area from aid:.
Identify the checksum from chk:.
Identify the authentication type from aut:.

No Hello Packet in the Output?

Confirm that R1 remains connected to the shared Ethernet segment.
Confirm that R1 still has established OSPF neighbors.
Repeat the stop command above if packet lines continue after the capture.

Help me troubleshoot my OSPF packet capture.

Strong work: you can now trace a received Hello through router roles into the LSDB.

Next, you will apply that evidence to a controlled timer mismatch.

Repair the Hello Timer Mismatch

You have traced OSPF from received Hello packets through the link-state database to installed routes. A timer disagreement can still prevent neighbors from reaching an established state.

In this step, you will create that disagreement on R3. Cisco IOS event debugging lets you identify the cause before you restore the healthy setting.

In this step, get ready to:

Force R3 to attempt a fresh adjacency with a five-second Hello interval.
Diagnose the failed adjacency from event debug output.
Recover full OSPF operation with the ten-second Hello interval.

Create the timer mismatch

OSPF neighbors on one Ethernet segment must agree on their Hello interval. They must also agree on their Dead interval.

R1, R2, and R3 currently use a 10-second Hello interval. They also use a 40-second Dead interval.

Resetting this lab interface briefly interrupts R3's neighbor relationships. The rest of your saved topology stays intact.

Switch back to R3's Cisco IOS CLI.
Apply the five-second Hello interval to R3 by entering these commands:

configure terminal
interface Ethernet0/0
ip ospf hello-interval 5
shutdown
no shutdown
end

What does this change do?

The five-second setting changes how often R3 sends OSPF Hello packets through Ethernet0/0.
The interface reset forces R3 to attempt a fresh neighbor relationship.
The final command returns R3 to privileged EXEC mode.

R3 now attempts to rebuild its OSPF neighbor relationships with a five-second Hello interval.

Did R3 reject a command?

Confirm that you entered the commands on R3.
Confirm that Ethernet0/0 is the interface connected to the shared segment.
Repeat the configuration block from privileged EXEC mode.

Help me correct the R3 timer configuration.

Diagnose the failed adjacency

R1's neighbor table can show that R3 is missing. The event stream reveals the timer values behind that symptom.

Live debugs can fill a console quickly. You will stop this one as soon as the invalid-timer evidence appears.

Switch back to R1's Cisco IOS CLI.

Before you enable the event debug, consider whether R1 will accept R3's Hello packets while the intervals differ.

Expose R1's OSPF event activity by running this command:

debug ip ospf events

What does the event debug reveal?

The event debug reports OSPF adjacency activity as it happens.
Invalid-timer events compare parameters received from R3 with R1's local settings.

The first matching event can take a few seconds while R1 waits for R3's next Hello packet.

Watch R1's CLI until you see a line containing OSPF:hello with invalid timers.
Compare the received Hello value with R1's configured value in the same event.

You'll see that R3's five-second Hello interval conflicts with R1's ten-second interval. This is the intended failure.

Disable the event debug immediately by running this command:

no debug ip ospf events

Why stop the debug now?

Disabling the event debug keeps the console readable after you have captured the evidence. Your diagnosis now comes from a controlled sample.

Check R1's current neighbor state by running this command:

show ip ospf neighbor

What does the neighbor table prove?

The neighbor table confirms whether R1 has established a working OSPF relationship with R3. It turns the packet-level timer rejection into a visible topology symptom.

You should see that R3 has not returned to an established neighbor relationship.

You have caught the exact cause. R1 rejects R3's Hello because the intervals differ.

No invalid-timer event?

Confirm that R3's Ethernet0/0 remains enabled.
Confirm that R3 still uses the five-second Hello interval.
Repeat the R3 interface reset if R1 receives no new Hello packets.

Help me capture the missing OSPF timer event.

Recover the OSPF topology

Matching Hello intervals let the routers process each other's Hello packets again. Restoring R3 to ten seconds keeps the segment aligned with its 40-second Dead interval.

Return to R3's Cisco IOS CLI.
Restore the ten-second Hello interval by entering these commands:

configure terminal
interface Ethernet0/0
ip ospf hello-interval 10
end

What does this repair change?

R3 now sends Hello packets at the same interval as R1 and R2. Matching interface timers allow the adjacency process to continue normally.

Allow the neighbor relationship a short moment to reform.
Run this interface check in each router's Cisco IOS CLI:

show ip ospf interface Ethernet0/0

What should the interface check confirm?

The interface view reports the active OSPF network settings. Matching values remove the packet-level disagreement that blocked R3.

Each router should report a 10-second Hello interval. Each router should also report a 40-second Dead interval.

Switch back to R1's Cisco IOS CLI.

Before you run the final checks, consider whether R3's neighbor state and remote route should now return.

Verify the recovered topology by running these checks:

show ip ospf neighbor
show ip route ospf
ping 10.255.0.3

How do these checks prove recovery?

The neighbor table confirms that R3 has re-established its OSPF relationship with R1.
The route table filter confirms that R1 has installed remote loopback routes marked with O.
The ping confirms end-to-end reachability from R1 to R3's loopback.

You should see R3 in an established neighbor relationship. You should also see an O route to 10.255.0.3/32.

The ping should return ! characters with Success rate is 100 percent.

That is the incident repaired. Your area 0 topology is healthy again because you diagnosed the rejected Hello before changing the configuration.

Has R3 failed to recover?

Confirm that the event debug is disabled on R1.
Confirm that R3 reports a 10-second Hello interval on Ethernet0/0.
Reset R3's Ethernet0/0 once more if the neighbor relationship does not reform.

Help me recover the R3 OSPF adjacency.

Secret mission

Capture a Fresh Adjacency Sequence

Reset R3 while R1 watches the exchange that rebuilds their neighbor relationship. Classify the packet types you actually capture before proving that the route has recovered.

Clean Up Your Resources

Your OSPF lab stays inside your existing PNETLab environment, so this project adds no ongoing cloud costs. Decide whether to keep the lab available, pause its nodes, or delete it.

Resources you used:

A dedicated PNETLab lab containing Cisco IOL Layer 3 nodes R1, R2, and R3 on a shared Layer 2 broadcast segment.
Running Cisco IOS configurations on R1, R2, and R3.

Keep everything running

Preserve the lab for more OSPF practice. Save each running configuration before you leave.

Save R1's running configuration by entering this command in its Cisco IOS CLI:

copy system:running-config nvram:startup-config

What Does This Command Do?

The command copies the active running configuration into the startup configuration stored in NVRAM. R1 can load that saved configuration after it starts again.

Repeat the same command in the Cisco IOS CLI on R2.
Repeat the same command in the Cisco IOS CLI on R3.
Save the lab by using your established PNETLab configuration-saving workflow.

Your working OSPF topology now has a saved recovery point for your next lab session.

Pause - I'll come back to this later

Stop the three router nodes to free local compute resources. Keep the lab and its configurations for later practice.

Stop R1 by using your established PNETLab node-control workflow.
Stop R2 by using the same PNETLab workflow.
Stop R3 by using the same PNETLab workflow.
Confirm R1, R2, and R3 are shown as stopped in the dedicated lab.

The topology remains in PNETLab, ready for you to restart when you return.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently removes the topology and its saved configurations, so choose this only when you no longer need the lab.

Delete the dedicated lab containing R1, R2, R3, and the shared Layer 2 segment by using your established PNETLab lab-removal workflow.
Confirm the dedicated lab no longer appears in your PNETLab lab list.

Removing the lab also removes the three nodes and their saved Cisco IOS configurations.

Nice Work!

You did it! Your three-router OSPFv2 area 0 network is healthy in PNETLab.

You've learned how to:

Built a three-router OSPFv2 area 0 network on one broadcast segment. Proved the difference between connected reachability and dynamically learned remote routes.
Identified neighbor states from live Cisco IOS evidence. Matched each router ID to its Type 1 Router LSA. Explained the DR and BDR roles through the Type 2 Network LSA. Traced received OSPF packets into installed routes.
Reproduced an OSPF Hello-timer mismatch on R3. Diagnosed the failure from packet-level evidence. Restored matching timers to recover the adjacency. Confirmed remote loopback reachability.
Completed the optional Secret Mission by resetting R3's adjacency. Classified at least two observed OSPF packet types. Followed the state changes until the neighbor became established again.

Ready to quiz yourself?