OSPF Network Types and Neighbors on Cisco: How to Read What the Router Is Doing

1. Introduction: Why OSPF Network Types and Neighbors Matter

In CCNA study and real Cisco operations, OSPF network type is one of those topics that looks simple until it breaks. The network type on an interface changes neighbor discovery, whether a DR and BDR are elected, how many adjacencies should become Full, and what “normal” looks like in show ip ospf neighbor. If you misread that behavior, you troubleshoot the wrong thing.

A classic example is Ethernet. Engineers often see 2WAY/DROTHER and assume OSPF is broken, when on a healthy broadcast multiaccess segment that can be expected. On the other hand, if a true point-to-point link sits in 2WAY, ExStart, or Exchange, that is a real problem. Understanding the network type lets you tell the difference between a normal control-plane state and an actual fault.

This article stays in CCNA 200-301 scope and focuses on OSPFv2 for IPv4. OSPFv3 is for IPv6 and has different configuration style, but the neighbor logic is conceptually similar. What I’m really after here is the practical stuff: being able to read the neighbor table without second-guessing it, understand what each network type actually changes, and use Cisco IOS verification commands to get to the answer fast.

2. Quick OSPF Refresher: What Neighbors, Adjacencies, and Packets Are Really Doing

OSPF’s a link-state protocol, so routers aren’t just tossing routes back and forth like sticky notes in a noisy NOC. They’re actually building the same map of the network, piece by piece. They’re actually sharing topology details so each router can build the same picture of the network. So instead of only comparing best routes, the routers build a link-state database, or LSDB, which is basically the shared blueprint of the area. Once that LSDB is in sync, each router runs SPF—Dijkstra’s algorithm—to figure out the best paths for itself.

A neighbor is a router discovered through OSPF Hello packets. An adjacency is a deeper relationship in which routers exchange and synchronize LSDB information. Not every discovered neighbor becomes fully adjacent. That point matters a lot on broadcast and NBMA networks, where DR/BDR behavior affects who reaches Full.

OSPFv2 uses five packet types:

Hello discovers neighbors and maintains them. Database Description (DBD) summarizes LSDB contents during adjacency formation. Link-State Request (LSR) asks for specific LSAs that are missing. Link-State Update (LSU) carries LSAs. Link-State Acknowledgment (LSAck) confirms receipt.

A simple way to keep the packet flow straight is this: Hellos discover neighbors, DBDs compare what each side knows, LSRs ask for anything that’s missing, LSUs send the missing pieces, and LSAcks confirm everything was received. If a neighbor gets stuck before Full, the packet type in use usually tells you where the process is failing.

3. How OSPF Neighbors Form, from Hello all the way to Full

Neighbor formation starts the moment OSPF comes up on an interface and the router begins sending Hello packets. On Cisco IOS, OSPF can be enabled either with the classic network command under the OSPF process or directly on the interface with ip ospf process-id area area-id. Either way, the outcome’s the same: that interface becomes part of OSPF.

For CCNA, remember an important correction about the network command: it does not directly advertise a route by itself. It matches interfaces whose addresses fall inside the wildcard range and enables OSPF on those interfaces in the area you specify. Once OSPF is active on those interfaces, their connected subnets get advertised.

When a Hello shows up, the receiving router checks whether that neighbor is actually a valid match. If the key settings line up, the routers walk through the neighbor state machine and eventually sync their databases. If they don’t match, you either never see the neighbor at all or you catch it stuck halfway through the process.

Neighbor Formation Requirements Checklist

Parameter Must Match? Where to Verify Common Symptom if Wrong
Area ID Yes show ip ospf interface No stable neighbor, Hello rejection
Area type options (stub/NSSA flags) Yes show ip ospf interface, debug Adjacency will not form
Hello/Dead timers Yes show ip ospf interface Neighbor not forming or flapping
Authentication type and key Yes show run interface, show ip ospf interface Hellos seen but adjacency fails
Subnet/mask expectations Normally yes on broadcast/NBMA show ip interface brief No neighbor or unstable adjacency
Network type compatibility Should be compatible show ip ospf interface 2WAY, ExStart, or no adjacency
MTU Should match show interface, show ip ospf interface ExStart/Exchange
Router ID uniqueness Must be unique show ip ospf, show ip ospf neighbor Adjacency instability, LSDB issues
OSPF enabled on interface Yes show ip ospf interface brief No neighbor entry
Passive interface status Must not be passive if adjacency is needed show ip protocols No Hellos, no neighbor

If Hello exchange fails completely, think broadly: Layer 2 failure, wrong IP addressing, area mismatch, timer mismatch, authentication mismatch, passive interface, ACL or firewall blocking IP protocol 89, or OSPF simply not enabled on one side. If Hellos work but the routers stall later, think MTU, DBD negotiation, or less commonly duplicate router IDs.

Router ID deserves special attention. It is the OSPF identity, not just a cosmetic value. Duplicate router IDs can create unstable adjacencies and LSDB confusion. In practice, setting router IDs manually is a good habit. Also remember that after changing the router ID, the OSPF process usually must be reset with clear ip ospf process for the new ID to take effect.

4. OSPF Neighbor State Machine Reference

The OSPF state machine is one of the best troubleshooting maps in CCNA routing. Read the state as a clue, not just a label.

State Meaning Where Commonly Seen Healthy or Problem?
Down No Hellos received; often no neighbor entry is shown at all Any network type Problem
Attempt Router is trying to contact a manually configured neighbor NBMA Usually problem if persistent
Init Hello received, but bidirectional communication not confirmed Any network type Problem if persistent
2WAY Bidirectional Hellos established Normal between DROTHER routers on broadcast/NBMA Sometimes healthy
ExStart Master/slave DBD negotiation begins Adjacency formation Temporary; problem if stuck
Exchange DBD packets are being exchanged Adjacency formation Temporary; problem if stuck
Loading Routers are requesting and receiving missing LSAs Adjacency formation Temporary; problem if stuck
Full LSDBs are synchronized Stable adjacency Healthy

The transition from ExStart to Exchange is where routers negotiate master and slave roles for DBD exchange. The router with the higher router ID typically becomes master for the exchange. If that negotiation fails, ExStart is where you often get stuck. MTU mismatch is the classic reason. Duplicate router IDs are possible, but much less common.

5. OSPF Network Types Explained

OSPF network type tells the router how to behave on an interface. It affects neighbor discovery, whether DR/BDR election happens, whether manual neighbors are needed, and what stable states you should expect.

Broadcast Multiaccess

And on an Ethernet LAN, that’s completely normal. OSPF uses multicast Hellos to 224.0.0.5 (AllSPFRouters). That’s why routers can discover each other automatically on that kind of segment. Because many routers can share the segment, OSPF elects a DR and BDR to reduce adjacency overhead. DROTHER routers typically form Full adjacencies with the DR and BDR, but remain in 2WAY with other DROTHER routers.

Non-Broadcast Multiaccess (NBMA)

NBMA supports multiple routers on one logical network, but the medium does not provide broadcast-style discovery like Ethernet. Legacy Frame Relay is the classic CCNA example. On Cisco, manual neighbor statements are commonly required. DR/BDR election still occurs, which is one reason NBMA can be awkward in hub-and-spoke designs.

Point-to-Point

This is the simplest model: one link, two routers, no DR/BDR election. A full adjacency is expected. Serial links, PPP links, and many routed WAN handoffs fit this behavior. If a true point-to-point link is not reaching Full, treat it as abnormal.

Point-to-Multipoint

This treats a multiaccess transport as a set of logical point-to-point relationships. No DR/BDR election occurs. It’s often a really good fit for hub-and-spoke designs because you avoid the weirdness of NBMA DR/BDR behavior, but you can still have one interface talk to multiple neighbors.

Point-to-Multipoint Non-Broadcast: a practical OSPF mode for non-multicast transports

This works a lot like point-to-multipoint, but it doesn’t depend on multicast to find neighbors. On Cisco, manual neighbor statements are required. It’s a handy option when you want the simpler point-to-multipoint style of operation, but the underlying transport doesn’t really play nicely with multicast.

Loopback

Loopbacks don’t form OSPF adjacencies, and that’s normal. They are advertised into OSPF, and by default OSPFv2 advertises a loopback as a /32 host route regardless of the configured mask. If you want OSPF to advertise that loopback using the interface’s configured subnet mask instead of a /32, you can change the loopback’s OSPF network type to point-to-point.

6. Cisco Default Network Types and Interface Behavior

For CCNA, know the common Cisco defaults:

Interface/Media Typical Default OSPF Network Type
Ethernet Broadcast
Serial PPP/HDLC point-to-point links Point-to-point
Legacy Frame Relay physical interface Often NBMA
Frame Relay point-to-point subinterface Point-to-point
Loopback Loopback

Those defaults matter because many engineers assume the router sees the network the same way they do. A loopback doesn’t form OSPF neighbors, and that’s completely normal. Always verify the actual OSPF network type with show ip ospf interface. Also note that on Ethernet, ip ospf network broadcast is usually redundant because broadcast is already the default; it is fine to configure it explicitly for teaching or documentation clarity.

7. OSPF Network Type Comparison Table

Network Type Hello Method Manual Neighbors DR/BDR Expected Stable State Common Use
Broadcast Multicast to 224.0.0.5 No Yes Full with DR/BDR, 2WAY with other DROTHERs Ethernet LANs
NBMA Usually unicast Hellos to configured neighbors Usually yes Yes Depends on DR/BDR role Legacy WAN clouds
Point-to-point In most cases, it sends Hello packets using multicast to 224.0.0.5. No No Full True two-router links
Point-to-multipoint Platform/design dependent, commonly multicast-capable No No Full per neighbor Hub-and-spoke simplification
Point-to-multipoint non-broadcast Unicast to configured neighbors Yes No Full per neighbor Hub-and-spoke without multicast
Loopback N/A No No No adjacency Router ID, stable reachability

8. Broadcast, NBMA, and DR/BDR Behavior

OSPF, not Cisco specifically, elects a DR and BDR on broadcast and NBMA multiaccess segments. The reason is scaling. If every router on a shared segment formed a Full adjacency with every other router, LSDB exchange and flooding overhead would grow quickly. The DR/BDR model reduces that burden.

On a broadcast LAN, Hellos go to 224.0.0.5. Some updates on DR/BDR segments are sent to 224.0.0.6 (AllDRouters). Both multicast addresses are link-local, so they stay on the local segment. They don’t get routed beyond that link. That matters when you troubleshoot discovery across devices that filter or isolate multicast.

DROTHER routers do not build full adjacency with every other DROTHER. Instead of building Full adjacencies with every router on the segment, routers build Full adjacencies with the DR and BDR. After that, LSA flooding follows those DR and BDR rules. The DR isn’t a best-path router, it isn’t a default gateway, and it has nothing to do with HSRP or VRRP. Honestly, that mix-up comes up all the time. It is a control-plane role.

DR/BDR Election Rules

Election is per multiaccess segment. Interface priority is considered first; highest priority wins among eligible routers. Priority 0 means the router is ineligible to become DR or BDR. If priorities tie, the highest router ID wins. One more exam-relevant point: the election is non-preemptive. If a better candidate appears later, it does not automatically take over. A reelection normally requires a failure event or a reset of OSPF on the segment.

A common misconception is that interface bandwidth or OSPF cost influences DR election. A loopback doesn’t form OSPF neighbors, and that’s completely normal. Cost affects path selection, not DR/BDR election.

9. Design Guidance: Choosing the Right Network Type

Use the simplest network type that matches reality.

Ethernet LAN: Broadcast is usually correct. Let OSPF discover neighbors automatically and let it handle the DR/BDR process for you.

True two-router WAN link: Point-to-point is usually best. It removes DR/BDR and makes troubleshooting cleaner.

Hub-and-spoke without reliable multicast: Point-to-multipoint non-broadcast or classic NBMA with manual neighbors can work, but point-to-multipoint designs are often easier to operate.

Need to avoid DR/BDR on a spoke topology: Point-to-multipoint is often better than NBMA.

Legacy Frame Relay concepts: Know NBMA for the exam, but understand that many modern designs avoid its complexity by using point-to-point subinterfaces or point-to-multipoint behavior instead.

10. Cisco IOS Configuration and Verification: the commands you’ll actually use

Here are a few compact Cisco IOS examples I’d actually use in a lab or a real network.

Classic Process Configuration

router ospf 1 router-id 1.1.1.1 gives the router a fixed OSPF identity. sets the router ID explicitly, which is a lot more predictable than letting OSPF choose one for you. network 10.1.1.0 0.0.0.255 area 0 matches the 10.1.1.0/24 interface range, enables OSPF on those interfaces, and places them in Area 0.

What that really means is the router looks for interfaces in the 10.1.1.0/24 range, enables OSPF there, and then advertises that connected network into Area 0.

Interface-Based Configuration

interface GigabitEthernet0/0 is the interface context where you apply OSPF directly. ip address 10.1.1.1 255.255.255.0 gives the interface its Layer 3 address and mask. ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0. ip ospf priority 100 raises the interface priority, which can help that router win a DR or BDR election on a broadcast segment.

On Ethernet, you usually do not need ip ospf network broadcast because broadcast is already the default.

Point-to-Point Example: a simpler WAN-style OSPF setup

interface Serial0/0/0 ip address 10.12.12.1 255.255.255.252 assigns the point-to-point link address. ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0. ip ospf network point-to-point tells OSPF to treat the link as point-to-point, which keeps the behavior simple and avoids DR/BDR election.

NBMA Manual Neighbor Example

router ospf 1 router-id 1.1.1.1 gives the router a fixed OSPF identity. sets the router ID explicitly, which is a lot more predictable than letting OSPF choose one for you. network 172.16.123.0 0.0.0.255 area 0 enables OSPF for interfaces in that subnet and places them in Area 0. neighbor 172.16.123.2 manually defines the first spoke neighbor. tells OSPF to build a neighbor relationship with that specific router. neighbor 172.16.123.3 manually defines the second spoke neighbor. does the same for the second neighbor.

On Cisco NBMA, you’ll usually need manual neighbor statements because you can’t rely on dynamic multicast discovery to do the job for you.

Point-to-Multipoint Non-Broadcast: a practical OSPF mode for non-multicast transports Example

interface Serial0/0/0 ip address 172.16.123.1 255.255.255.0 sets the hub-side address on the shared WAN segment. ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0. ip ospf network point-to-multipoint non-broadcast tells OSPF not to depend on multicast discovery on that interface. router ospf 1 neighbor 172.16.123.2 manually defines the first spoke neighbor. tells OSPF to build a neighbor relationship with that specific router. neighbor 172.16.123.3 manually defines the second spoke neighbor. does the same for the second neighbor.

Passive Interface Best Practice

router ospf 1 passive-interface default no passive-interface GigabitEthernet0/0 is the interface context where you apply OSPF directly. no passive-interface Serial0/0/0

That’s a really solid operational habit. Passive interfaces don’t send Hellos and they won’t form adjacencies, but if OSPF is enabled on those interfaces, the connected networks are still advertised.

Authentication Examples

Simple password authentication exists, but it is weak and mainly exam knowledge now.

interface GigabitEthernet0/0 is the interface context where you apply OSPF directly. ip ospf authentication ip ospf authentication-key cisco

MD5 message-digest authentication is stronger and commonly referenced in Cisco study.

interface GigabitEthernet0/0 is the interface context where you apply OSPF directly. ip ospf message-digest-key 1 md5 CCNAkey ip ospf authentication message-digest

If authentication type or key does not match, adjacency will fail even if basic IP reachability exists.

11. Verification Workflow That Actually Works

When OSPF is not behaving, use a sequence instead of guessing.

1. show ip ospf neighbor
Confirms whether a neighbor exists and what state it is in.

2. show ip ospf interface brief
Quickly shows which interfaces are participating in OSPF.

3. show ip ospf interface
Best command for network type, area, timers, priority, DR/BDR, authentication, and MTU-related context.

4. show ip protocols
Useful for process-level details such as router ID, passive interfaces, and what networks are matched by OSPF. It is not the best timer command.

5. show ip route ospf
Shows whether learned OSPF routes made it into the routing table.

6. show ip ospf database
Confirms LSDB contents and whether LSAs are actually being flooded after adjacency reaches Full.

7. Targeted debug
Use debug ip ospf adj or debug ip ospf hello carefully in labs or during controlled troubleshooting windows.

Reading show ip ospf neighbor

R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:31 10.1.1.2 GigabitEthernet0/0
3.3.3.3 1 2WAY/DROTHER 00:00:39 10.1.1.3 GigabitEthernet0/0

Neighbor ID is the neighbor’s router ID. Pri is the OSPF interface priority. State shows adjacency state and role. Dead Time is how long until the neighbor is declared down if Hellos stop. Address is the neighbor source IP on that link. Interface is the local interface where the neighbor is seen.

FULL/DR means fully adjacent with the DR. FULL/BDR means fully adjacent with the BDR. FULL/- is common on point-to-point links. 2WAY/DROTHER on Ethernet is often healthy. Persistent 2WAY/- on a point-to-point link is not.

12. Using show ip ospf database in Neighbor Troubleshooting

If neighbors are Full but routes are still missing, stop staring only at the neighbor table. Check the LSDB.

R1# show ip ospf database

If expected router LSAs and network LSAs are present, OSPF flooding is likely healthy and the issue may be path selection, area design, or route preference. If the LSDB is missing expected entries even though a neighbor appears Full, look for unstable adjacency, authentication problems, packet loss, or unusual filtering or policy outside normal intra-area OSPF behavior.

At CCNA level, the key takeaway is simple: neighbor Full tells you adjacency succeeded; the OSPF database tells you whether the topology information is actually present.

13. Common OSPF Mismatch Table

Mismatch Likely Symptom Common State Best Verification Fix
Area mismatch No stable adjacency No neighbor or Init show ip ospf interface Put both interfaces in same area
Hello/dead timer mismatch Neighbor not forming Init or no neighbor show ip ospf interface Match timers
Authentication mismatch Hellos fail validation No neighbor or Init show run, show ip ospf interface Match auth type and key
MTU mismatch DBD exchange fails ExStart/Exchange show interface Match MTU; avoid relying on ip ospf mtu-ignore
Network type mismatch Unexpected state behavior 2WAY or ExStart show ip ospf interface Use compatible network types
Passive interface No Hellos sent No neighbor show ip protocols Remove passive setting where adjacency is needed
Duplicate router ID Unstable adjacency/LSDB issues Varies show ip ospf Assign unique router IDs and reset OSPF
Wrong subnet on Ethernet-style segment No neighbor Down/Init show ip interface brief Correct addressing and mask

14. Troubleshooting Common Neighbor Problems

No Neighbor Entry

If no neighbor appears at all, check whether OSPF is enabled on the interface, whether the interface is up/up, whether it is passive, whether the routers share normal Layer 3 reachability, and whether protocol 89 is being blocked. On Ethernet-style links, verify they are in the same subnet. Use show ip ospf interface brief, show ip interface brief, and show ip protocols.

Neighbor Stuck in Attempt

This is mainly an NBMA clue. It means the router is sending Hellos to a configured neighbor but has not received one back. Check manual neighbor statements, reachability across the WAN cloud, and whether the far end is actually running OSPF on that interface.

Neighbor Stuck in Init

Init means you heard the neighbor, but the neighbor did not list you back in its Hello. Think one-way communication, ACL asymmetry, multicast or unicast delivery problem, passive interface, or parameter mismatch. debug ip ospf hello can be useful here in a lab.

Neighbor Stuck in 2WAY

On broadcast and NBMA, this may be completely normal between DROTHER routers. On a true point-to-point link, persistent 2WAY is abnormal. Verify the network type first before declaring failure.

Neighbor Stuck in ExStart or Exchange

Think MTU first. On many implementations, OSPF includes the interface MTU in DBD exchange, and a mismatch can stop the adjacency. Check show interface on both sides. If necessary, ip ospf mtu-ignore can be used as a temporary workaround, but matching the real MTU is the better fix. Also verify network type compatibility and unique router IDs.

Neighbor Stuck in Loading

Loading means routers agreed on DBD exchange but are still requesting missing LSAs. Persistent Loading often points to packet loss, retransmission problems, or LSDB synchronization trouble. Check interface errors, WAN quality, and debug output if needed.

Neighbor Full but No OSPF Routes

If the adjacency is Full but routes are missing, check show ip route ospf and show ip ospf database. The issue may be that the neighbor is not advertising the expected prefix, the interface is passive but not actually enabled in OSPF, or another route source has a better administrative distance.

15. Practical Mini-Labs

Lab 1: Broadcast Ethernet with Healthy 2WAY/DROTHER

Topology: R1, R2, and R3 share VLAN 10 on 10.1.1.0/24.

R1
interface g0/0 ip address 10.1.1.1 255.255.255.0 gives the interface its Layer 3 address and mask. ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0. R2
interface g0/0 ip address 10.1.1.2 255.255.255.0 ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0. ip ospf priority 100 raises the interface priority, which can help that router win a DR or BDR election on a broadcast segment. R3
interface g0/0 ip address 10.1.1.3 255.255.255.0 ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0.

Expected result: R2 becomes DR. One router may show the other non-DR router as 2WAY/DROTHER. That is healthy. Verify with show ip ospf neighbor and show ip ospf interface.

Topology: R1 and R2 on 10.12.12.0/30.

R1
interface s0/0/0 ip address 10.12.12.1 255.255.255.252 assigns the point-to-point link address. mtu 1500 ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0. R2
interface s0/0/0 ip address 10.12.12.2 255.255.255.252 mtu 1400 ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0.

Symptom: neighbor stuck in ExStart or Exchange. Verify with show interface s0/0/0 and show ip ospf neighbor. Fix by matching MTU. Temporary workaround:

interface s0/0/0 ip ospf mtu-ignore

Use that only when you understand the risk; the better fix is to correct the actual MTU inconsistency.

Lab 3: NBMA Neighbor in Attempt

Topology: Hub R1 with spokes R2 and R3 over an NBMA cloud.

R1
router ospf 1 network 172.16.123.0 0.0.0.255 area 0 enables OSPF for interfaces in that subnet and places them in Area 0. neighbor 172.16.123.2 manually defines the first spoke neighbor. tells OSPF to build a neighbor relationship with that specific router. neighbor 172.16.123.3 manually defines the second spoke neighbor. does the same for the second neighbor.

If the cloud cannot reach R3 or the far end is not configured correctly, R1 may show the neighbor in Attempt. Fix the reachability or OSPF configuration, then the state should progress.

Lab 4: Authentication Mismatch

R1
interface g0/0 ip ospf message-digest-key 1 md5 CCNAkey ip ospf authentication message-digest R2
interface g0/0 ip ospf message-digest-key 1 md5 WrongKey ip ospf authentication message-digest

Symptom: no stable adjacency. Fix the key so both sides match exactly.

Lab 5: Loopback /32 Behavior

interface Loopback0 ip address 10.10.10.1 255.255.255.0 ip ospf 1 area 0 enables OSPF process 1 in Area 0. activates OSPF on that serial link in Area 0. enables OSPF process 1 on that interface and places it in Area 0.

By default, OSPF advertises this as 10.10.10.1/32. If you need the subnet mask to be advertised:

interface Loopback0 ip ospf network point-to-point tells OSPF to treat the link as point-to-point, which keeps the behavior simple and avoids DR/BDR election.

16. Security and Operational Hygiene

At CCNA level, three OSPF security habits matter most. First, use authentication where appropriate. Second, use passive interfaces on user-facing or non-routing interfaces. Third, make sure filters or control-plane policies allow OSPF protocol 89 where it is required.

Authentication mismatch prevents adjacency, so it is both a security control and a troubleshooting item. Passive-interface reduces unnecessary Hellos and limits the chance of an unauthorized neighbor forming on the wrong segment. In larger environments, control-plane protection and infrastructure ACLs are also relevant, but the exam-level lesson is simple: protect the routing control plane, not just the data plane.

17. CCNA Exam Tips, Traps, and Memory Aids

Must-know facts:

OSPFv2 uses five packet types. Neighbor states in order are Down, Attempt, Init, 2WAY, ExStart, Exchange, Loading, Full. 224.0.0.5 is AllSPFRouters. 224.0.0.6 is AllDRouters. OSPF uses IP protocol 89, not TCP or UDP ports. Broadcast and NBMA elect DR/BDR; point-to-point and point-to-multipoint do not. Priority 0 means ineligible for DR/BDR. Loopbacks do not form neighbors and are advertised as /32 by default.

Normal vs abnormal:

Observation Interpretation
2WAY/DROTHER on Ethernet Often normal
FULL/DR or FULL/BDR on broadcast Normal
FULL/- on point-to-point Normal
Persistent 2WAY on point-to-point Abnormal
Attempt state NBMA/manual neighbor issue
ExStart/Exchange on WAN Often MTU or DBD negotiation issue

Exam traps: The DR is not the default gateway. The DR is not chosen by bandwidth or cost. Full adjacency is not expected between every router on a broadcast LAN. Passive interface still allows the connected network to be advertised if OSPF is enabled on it. Loopbacks participate in OSPF advertisements, but not as neighbor interfaces.

Quick memory rule: “Broadcast and NBMA elect; point-to-point and point-to-multipoint don’t.”

18. Certification-Style Review Questions

1. On which OSPF network types does DR/BDR election occur?
Answer: Broadcast and NBMA.

2. A router on an Ethernet LAN shows a neighbor as 2WAY/DROTHER. Is that always a problem?
Answer: No. It is often normal on a broadcast segment.

3. What command is best for verifying OSPF hello and dead timers on a specific interface?
Answer: show ip ospf interface.

4. What is the most common cause of a neighbor stuck in ExStart or Exchange?
Answer: MTU mismatch.

5. What does OSPF priority 0 mean?
Answer: The router is ineligible to become DR or BDR.

6. Which multicast address is AllSPFRouters?
Answer: 224.0.0.5.

7. Which neighbor state is especially associated with NBMA and manual neighbors?
Answer: Attempt.

8. By default, how does OSPFv2 advertise a loopback interface?
Answer: As a /32 host route.

9. What protocol number does OSPF use?
Answer: IP protocol 89.

10. Does changing OSPF cost influence DR election?
Answer: No.

19. Conclusion

OSPF network type is not just a configuration detail. It changes discovery, adjacency expectations, DR/BDR behavior, and the meaning of what you see in the CLI. If you understand how neighbors move from Hello to Full, know which parameters must match, and can interpret states like Attempt, 2WAY, and ExStart correctly, you will troubleshoot faster and make better design choices.

For CCNA 200-301, focus on the patterns: broadcast and NBMA elect DR/BDR, point-to-point expects Full, 2WAY on Ethernet can be normal, ExStart often means MTU, and loopbacks advertise but do not become neighbors. Once you can look at show ip ospf neighbor and explain exactly why the output is healthy or broken, you are no longer memorizing terms. You are reading the control plane like an engineer.