OSPF Network Types and Neighbors for CCNA 200-301: A Practical Cisco Guide

1. Introduction: Why OSPF Network Types Matter

When I teach OSPF for CCNA 200-301, I try to keep one idea front and center: OSPF is not just “enabled” on an interface.

What the router’s really trying to do is discover who’s out there, figure out whether it needs a full adjacency with that neighbor, sync up the link-state database, and then use all of that information to calculate the best routes.

Network type affects every part of that behavior.

This article is about OSPFv2 for IPv4 on Cisco IOS. That scope matters because the commands, multicast addresses, and examples here are the CCNA-style IPv4 ones.

If you ignore network type, OSPF can look random. A router on Ethernet may stop at 2-Way with another DROTHER and be perfectly healthy. A point-to-point link should usually reach Full directly. An NBMA segment may need manual neighbor configuration. Same protocol, different rules based on the interface model.

The practical goal is simple: know what normal looks like, know what state you should expect, and know which command proves it.

2. OSPF Neighbor Basics and Requirements

A neighbor is a router discovered through Hello packets. An adjacency is a deeper relationship where routers synchronize their link-state databases.

On some topologies, every neighbor ends up fully adjacent. On others, not so much — and that’s where people start scratching their heads.

On broadcast multiaccess networks, that is not always true.

Before two routers can form an OSPF adjacency, check these basics:

Requirement	What must be true	Common symptom if wrong	Useful command
Area ID	Must match on both sides	No neighbor or unstable neighbor	`show ip ospf interface`
Hello/Dead timers	Must match	Neighbor usually does not form at all	`show ip ospf interface`
Authentication	Method and key must match	Neighbor does not form	`show ip ospf interface`
Router ID	Must be unique	Unstable or broken adjacency	`show ip ospf`
Stub flag	Must agree where relevant	Neighbor rejection	`debug ip ospf adj`
Transit interface passive state	Must not be passive	No Hellos, no neighbors	`show ip protocols`
Link/segment expectations	Routers must exchange Hellos on the same OSPF-enabled link	No neighbor	`show ip interface brief`, `show ip ospf interface`
MTU in practice	Should match for clean database exchange	Often stuck in ExStart/Exchange	`show interface`

One CCNA trap: OSPF process ID on Cisco IOS is locally significant. It does not need to match between neighbors.

Router ID selection follows this order at OSPF process start: manually configured router-id, then highest loopback IP, then highest active non-loopback IP.

If you add a better loopback later, OSPF doesn’t automatically go back and change the RID on its own. You usually have to reset the process before it’ll notice the new choice.

In labs, that usually means clear ip ospf process with caution.

Another important point: a passive interface does not send or receive OSPF Hellos, so it forms no neighbors, but its connected network can still be advertised into OSPF. That is why passive-interface is useful on user-facing LANs but dangerous on transit links.

3. Neighbor State Machine: What the State Really Means

The OSPF neighbor states are Down, Init, 2-Way, ExStart, Exchange, Loading, and Full. For CCNA, you should know both the definition and the likely troubleshooting direction.

State	Meaning	Common cause if stuck
Down	No Hellos received yet	Link down, wrong area, passive interface, no OSPF on interface
Init	Hello received, but your RID is not listed back	One-way communication, subnet/media issue, Hello rejection
2-Way	Bidirectional Hello exchange established	Normal final state between DROTHERs on broadcast/NBMA
ExStart	Master/slave DBD negotiation begins	MTU mismatch, duplicate RID, unstable link
Exchange	DBD packets are being exchanged	MTU mismatch, packet loss, DBD negotiation issue
Loading	Missing LSAs requested with LSRs and delivered with LSUs	LSA flooding or retransmission problem
Full	LSDBs synchronized	Expected end state when full adjacency is required

The big exam reminder is this: 2-Way is not always failure. On Ethernet, two DROTHER routers often remain 2-Way with each other and still operate normally through the DR/BDR model.

4. OSPF Network Types and Cisco Defaults

OSPF network type affects Hello behavior, neighbor discovery, DR/BDR election, default timers, and expected final state.

Network Type	DR/BDR	Default Timers	Discovery	Expected Final State	Common Cisco Notes
Broadcast	Yes	10/40	Multicast Hellos	Full with DR/BDR, often 2-Way with other DROTHERs	Default on Ethernet
Non-broadcast (NBMA)	Yes	30/120	Often manual neighbors	Adjacency centered on DR/BDR model	Legacy Frame Relay style
Point-to-point	No	10/40	Direct neighbor discovery	Full	Common on serial links; Ethernet is not this by default
Point-to-multipoint	No	10/40	Per-neighbor logic	Full per spoke	Useful for hub-and-spoke
Point-to-multipoint non-broadcast	No	30/120 commonly seen	Manual neighbors	Full per spoke	Hybrid legacy case
Loopback	No	N/A	Not for normal adjacency	Advertised as host route	Advertised as /32 by default

Two details matter a lot on the exam:

Ethernet defaults to OSPF broadcast on Cisco IOS, even if only two routers are connected.
Loopbacks are advertised as /32 host routes by default, regardless of the configured mask, unless the OSPF network type is changed.

5. Broadcast, NBMA, Point-to-Point, and Point-to-Multipoint

Broadcast is the normal Ethernet/VLAN case. OSPF sends Hellos to 224.0.0.5 (AllSPFRouters), elects a DR and BDR, and reduces adjacency scaling by having routers form full adjacencies with the DR/BDR rather than every router on the segment.

NBMA is the classic legacy WAN model.

It still uses DR/BDR logic, but multicast discovery may not work the way Ethernet does, so you often need manual neighbor statements. That’s one of the big reasons NBMA doesn’t feel like Ethernet at all.

In partial-mesh hub-and-spoke designs, NBMA can be awkward because DR/BDR behavior assumes a more complete reachability model than the topology may actually provide.

Point-to-point is the simplest case: two routers, no DR/BDR, direct Full adjacency. If you use a dedicated Ethernet link between two routers, remember the physical Ethernet interface still defaults to broadcast unless you manually change it with

ip ospf network point-to-point

Point-to-multipoint is often cleaner for hub-and-spoke OSPF than classic NBMA. There is no DR/BDR election, and the hub treats each spoke more like an individual point-to-point neighbor relationship.

Loopback is mainly for stable addressing and router IDs, not normal neighbor formation.

6. DR/BDR Mechanics and Multicast Precision

On broadcast and NBMA multiaccess networks, the DR/BDR model reduces the number of full adjacencies that must be maintained. The DR is not the default gateway and not the “best” forwarding router. Its OSPF job is to act as the focal point for flooding synchronization on that segment, and the DR also originates the Type 2 Network LSA for the multiaccess network.

Election rules are straightforward:

Highest OSPF priority wins
Tie goes to highest router ID
Priority 0 means ineligible for DR/BDR
The election is non-preemptive

Operationally, a later-arriving router with better priority does not automatically take over. In labs, if you want to force a new election, reset the OSPF process or bounce the segment carefully.

Packet destination details should be precise:

OSPF Hellos on multicast-capable broadcast and point-to-point media are sent to 224.0.0.5 (AllSPFRouters).
224.0.0.6 (AllDRouters) is used mainly when DROTHERs need to send certain OSPF packets to the DR/BDR.

That is why saying “OSPF just multicasts to everyone all the time” is too loose. Packet destination depends on the packet type and the router’s role on the segment.

7. How Adjacencies Form: Packet Flow That Matters

The packet sequence is worth knowing because it maps directly to neighbor states:

Hello packets discover and maintain neighbors: Down, Init, 2-Way
DBD packets summarize LSDB contents: ExStart, Exchange
LSR packets request missing LSAs
LSU packets deliver LSAs
LSAck packets acknowledge receipt: Loading to Full

If a router is stuck in ExStart or Exchange, think first about MTU mismatch, duplicate router ID, packet loss, or master/slave DBD negotiation issues. Timer mismatch and authentication mismatch usually prevent neighbor formation much earlier during Hello processing.

8. Cisco IOS Configuration Examples

Broadcast Ethernet with DR preference

! R1

8. Cisco IOS Configuration Examples

Broadcast Ethernet with DR preference! R1

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1 ip address 10.1.1.1 255.255.255.0

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1 ip ospf priority 100 ! router ospf 1 router-id 1.1.1.1 ! R2

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1 ip address 172.16.12.1 255.255.255.252 ip ospf network point-to-point

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1! interface GigabitEthernet0/1 ip address 172.16.12.2 255.255.255.252 ip ospf network point-to-point

This removes DR/BDR behavior on a dedicated Ethernet link and usually gives you a simple Full adjacency.

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1 ip address 10.1.1.3 255.255.255.0

Notice the intentional trap: R2 uses process ID 99 and can still become a neighbor because process IDs do not need to match.

8. Cisco IOS Configuration Examples

Broadcast Ethernet with DR preference! R1

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1 ip address 172.16.12.1 255.255.255.252 ip ospf network point-to-point

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1! interface GigabitEthernet0/1 ip address 172.16.12.2 255.255.255.252 ip ospf network point-to-point

This removes DR/BDR behavior on a dedicated Ethernet link and usually gives you a simple Full adjacency.

8. Cisco IOS Configuration Examples

Broadcast Ethernet with DR preference! R1

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1 ip address 10.1.1.3 255.255.255.0

Notice the intentional trap: R2 uses process ID 99 and can still become a neighbor because process IDs do not need to match.

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1 ip address 172.16.12.1 255.255.255.252 ip ospf network point-to-point

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1! interface GigabitEthernet0/1 ip address 172.16.12.2 255.255.255.252 ip ospf network point-to-point

This removes DR/BDR behavior on a dedicated Ethernet link and usually gives a simple Full adjacency.

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast

Corrected NBMA hub example! Hub interface Serial0/1/0 ip address 192.168.10.1 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 10.10.10.10 neighbor 192.168.10.2 neighbor 192.168.10.3 ! Spoke1 interface Serial0/1/0 ip address 192.168.10.2 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 2.2.2.2 neighbor 192.168.10.1 ! Spoke2 interface Serial0/1/0 ip address 192.168.10.3 255.255.255.0 ip ospf network non-broadcast ip ospf 1 area 0 ! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1! router ospf 1 router-id 3.3.3.3 neighbor 192.168.10.1

Authentication exampleinterface Serial0/0/0 ip ospf message-digest-key 1 md5 CISCO ip ospf authentication message-digest

Passive-interface patternrouter ospf 1 router-id 1.1.1.1 passive-interface default no passive-

8. Cisco IOS Configuration Examples

Broadcast Ethernet with DR preference! R1

Two-router Ethernet converted to point-to-pointinterface GigabitEthernet0/1

9. Verification Commands That Actually Help

show ip ospf neighbor is the first command I check.Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 50 FULL/BDR 00:00:35 10.1.1.2 Gi0/0 3.3.3.3 1 2WAY/DROTHER 00:00:33 10.1.1.3 Gi0/0

The format is State/Neighbor role. From the local router’s perspective, this means one neighbor is fully adjacent and is the BDR, while another is only 2-Way and is a DROTHER. On broadcast Ethernet, that can be perfectly normal.

Other useful commands:

show ip ospf interface — area, timers, network type, DR/BDR, priority
show ip ospf — router ID, process details
show ip ospf interface brief — quick interface summary
show ip ospf database — LSDB view, including Type 2 network LSAs
show ip protocols — passive interfaces and protocol status
show interface — MTU and line status
show ip route ospf — confirms learned OSPF routes

Use debug carefully after the show commands:debug ip ospf hello debug ip ospf adj

10. Common Troubleshooting Patterns

1. 2-Way on Ethernet
If both routers are DROTHERs on a broadcast segment, 2-Way may be the correct final state. Verify DR/BDR roles before assuming failure.

2. No neighbor at all
Check interface up/up, area, passive-interface, authentication, and Hello/Dead timers. A timer mismatch usually prevents adjacency from forming at all.

3. Stuck in Init
You are receiving Hellos but not seeing your own RID reflected back. Think one-way communication, subnet or media expectation mismatch, or rejected Hellos.

4. Stuck in ExStart or Exchange
This is where MTU mismatch belongs on your short list. Compare show interface on both sides. Also check duplicate RID, unstable links, and DBD negotiation problems. Use ip ospf mtu-ignore only as a lab tool or with a clear reason.

5. Full adjacency but no routes
Then the problem is no longer neighbor formation. Check whether the remote network is actually being advertised into OSPF, whether the interface is passive in the correct place, and whether the LSDB contains the expected information.

6. NBMA discovery problems
If the media does not support multicast discovery the way Ethernet does, OSPF may need explicit neighbor statements or a different network type such as point-to-multipoint.

11. OSPF Defaults That CCNA Loves to Test

Administrative distance for OSPF: 110
Broadcast and point-to-point default timers: Hello 10 / Dead 40
NBMA default timers: Hello 30 / Dead 120
Ethernet default OSPF network type: broadcast
Process ID on Cisco IOS: locally significant
DR/BDR election: priority first, then router ID
Election behavior: non-preemptive
Loopback advertisement: /32 by default
Passive interface: no Hellos, no adjacency, but prefix can still be advertised

12. CCNA Exam Traps and Quick Review

These are the mistakes I see most often:

Thinking every neighbor must reach Full
Thinking process IDs must match
Thinking the DR is the default gateway
Forgetting Ethernet defaults to broadcast even on a two-router link
Missing MTU mismatch as a cause of ExStart/Exchange problems
Forgetting that loopbacks advertise as /32 routes by default

Quick mental checklist by topology:

Broadcast Ethernet: DR/BDR exists, 10/40 timers, 2-Way can be normal between DROTHERs
NBMA: DR/BDR exists, often 30/120 timers, neighbors may need manual configuration
Point-to-point: no DR/BDR, direct Full expected
Point-to-multipoint: no DR/BDR, Full per spoke
Loopback: /32 advertisement, not a normal neighbor link

Fast troubleshooting order for labs: check interface state, IP addressing, OSPF enabled and area, passive state, network type, timers, authentication, RID uniqueness, then MTU if the state is ExStart or Exchange.

13. Conclusion

OSPF network types matter because they change how neighbors are discovered, whether DR/BDR elections occur, which timers are used, and what final state is actually normal. Once you tie the topology to the expected state, OSPF becomes much easier to read.

For CCNA, remember the big ideas: Ethernet defaults to broadcast, 2-Way is often normal on multiaccess networks, point-to-point should usually go Full, passive interfaces still advertise prefixes, and ExStart/Exchange should make you think about MTU before you blame timers.

If you can identify the network type, decode the neighbor state, and verify with the right show commands, you are thinking like an engineer instead of guessing like a test taker.