OSPF Neighbor States – All 7 FSM States with Packets, Timers, and Troubleshooting

1. The OSPF Neighbor Finite State Machine (FSM)

Before two OSPF routers can exchange routing information they must form a neighbour relationship and, in most cases, a full adjacency. The process is governed by a Finite State Machine (FSM) — a strict sequence of seven states that every pair of OSPF routers progresses through. Each state has a specific purpose, uses specific OSPF packet types, and has defined conditions that must be met before advancing to the next state.

Understanding where in the FSM a neighbour relationship is stuck, and why, is one of the most important OSPF troubleshooting skills and a frequently tested CCNA topic.

  OSPF Neighbour FSM — State Progression:

  [DOWN] ──Hello──→ [INIT] ──own RID seen──→ [2-WAY]
                                                 │
                              DR/BDR elected here │ (on broadcast networks)
                                                 │
                                            [EXSTART] ──DBD──→ [EXCHANGE]
                                                                     │
                                                          LSR/LSU/LSAck
                                                                     │
                                                             [LOADING] ──→ [FULL]

  On point-to-point links: skip DR/BDR — go directly 2-Way → ExStart → ... → Full
  DROTHERs on broadcast: reach Full only with DR/BDR; stay 2-Way with each other

2. OSPF Packet Types — What Gets Sent in Each State

OSPF uses five distinct packet types, each serving a specific role in the neighbour formation process. All OSPF packets share a common 24-byte header containing version, type, router ID, area ID, and authentication fields.

Type	Packet Name	Purpose	States Used	Sent To
1	Hello	Discovers neighbours; establishes and maintains adjacency; carries parameters that must match for adjacency to form (Area ID, Hello/Dead timers, subnet mask, authentication, stub flag, MTU)	Down → Init → 2-Way; periodic keepalive throughout	224.0.0.5 (AllSPFRouters multicast) on broadcast; 224.0.0.6 (AllDRouters) on some types; unicast on NBMA
2	Database Description (DBD)	Describes the headers of LSAs in the sender's LSDB — a "table of contents" that the neighbour uses to identify which LSAs it is missing; also used in ExStart for master/slave negotiation	ExStart (negotiation); Exchange (header exchange)	Unicast to neighbour
3	Link-State Request (LSR)	Requests the full content of specific LSAs identified as missing after the DBD exchange	Loading	Unicast to neighbour
4	Link-State Update (LSU)	Delivers the full LSA content requested by an LSR, or floods a new/updated LSA to all neighbours	Loading (in response to LSR); also used for normal topology updates after Full state	Unicast (LSR response) or multicast (topology update)
5	Link-State Acknowledgement (LSAck)	Reliably acknowledges receipt of LSUs — OSPF flooding is reliable because every LSU must be acknowledged	Loading; also after topology updates in Full state	Unicast or multicast

Hello Packet — Key Fields That Must Match

A Hello packet carries several parameters. Mismatches in any of the following prevent adjacency formation — the relationship will stay stuck at Down or Init:

Hello Field	Must Match?	Notes
Area ID	Yes	Both routers must be in the same OSPF area on that interface
Subnet mask	Yes (broadcast); No (P2P)	On point-to-point links the mask is ignored; on broadcast it must match exactly
Hello interval	Yes	Default: 10s (broadcast), 30s (NBMA/P2P)
Dead interval	Yes	Default: 4× Hello interval (40s broadcast, 120s NBMA)
Authentication type & key	Yes	None, plain-text, or MD5 — both sides must agree
Stub area flag	Yes	If one router has the area configured as stub and the other does not, adjacency fails at the Hello level

3. The Seven Neighbour States — In Depth

State 1 — Down

The Down state is the initial state of every OSPF neighbour relationship. It means either no Hello packet has ever been received from this neighbour, or a previously active neighbour's Dead interval has expired without receiving a Hello — causing the relationship to drop back to Down.

  Down state behaviour:
  ┌─────────┐                              ┌─────────┐
  │ Router A│                              │ Router B│
  │ (Down)  │ ──Hello→ 224.0.0.5 ────────► │         │
  │         │    (RID of A in Hello)        │         │
  └─────────┘                              └─────────┘
  Router A sends Hello multicast even in Down state to try to discover neighbours.
  Trigger to leave Down: receive a Hello from a neighbour → move to Init.

When seen as a stuck state: The relationship stays Down if the physical link is down, the neighbour is unreachable at Layer 2, or the remote router has not enabled OSPF on the relevant interface.

State 2 — Init

A router enters Init state when it receives a Hello packet from a neighbour — but the received Hello does not contain the local router's own Router ID in its neighbour list. This means communication is currently one-directional: we can hear them, but they have not yet confirmed they can hear us.

  Init state:
  ┌─────────┐                              ┌─────────┐
  │ Router A│ ◄────────────────────────── │ Router B│
  │ (Init)  │   Hello from B received      │         │
  │         │   (A's RID NOT in B's list)   │         │
  └─────────┘                              └─────────┘
  A sees B's Hello → A transitions to Init.
  A's RID is not yet in B's neighbour list field.
  Trigger to leave Init: receive a Hello from B that now includes A's RID → 2-Way.

When seen as a stuck state: The relationship stays Init when Hellos are only flowing in one direction — typically caused by a Layer 2 asymmetry (one direction of the physical link works, the other does not), a firewall blocking OSPF multicast in one direction, or an ACL filtering inbound OSPF traffic on one router.

State 3 — 2-Way

2-Way is the first truly bidirectional state. A router enters 2-Way when it receives a Hello from a neighbour that contains its own Router ID in the neighbour list — confirming that both routers can hear each other. This is the state where the DR/BDR election occurs on broadcast (multi-access) networks.

  2-Way state:
  ┌─────────┐  ←───── Hello (contains A's RID) ──── ┌─────────┐
  │ Router A│                                         │ Router B│
  │ (2-Way) │  ──────── Hello (contains B's RID) ──►  │ (2-Way) │
  └─────────┘                                         └─────────┘
  Both routers list each other's RID in their Hello neighbour fields.
  Bidirectional communication confirmed ✓

  DR/BDR election happens here (broadcast networks):
  Highest OSPF priority → DR (default priority = 1)
  Second highest priority → BDR
  All others → DROTHER (stay in 2-Way with each other)

  Trigger to move beyond 2-Way:
  - On broadcast: DROTHERs advance to ExStart only with DR/BDR (not each other)
  - On point-to-point: both routers immediately proceed to ExStart

2-Way is a valid steady-state — it is NOT a stuck state when seen between two DROTHER routers on an Ethernet segment. DROTHERs intentionally remain in 2-Way with each other to reduce adjacency overhead. Only the relationship between a DROTHER and the DR or BDR advances to Full.

State 4 — ExStart

ExStart is the first step of actual database synchronisation. Before exchanging LSA headers, the two routers must agree on a master/slave relationship to control the sequencing of DBD packets. This is negotiated using empty DBD packets containing only sequence numbers.

  ExStart — master/slave negotiation:
  Both routers initially claim to be master, proposing their own sequence number.
  The router with the HIGHER Router ID wins and becomes the Master.

  Example: R1 (RID 1.1.1.1) vs R2 (RID 2.2.2.2):
  R2 wins → Master   (higher RID)
  R1 loses → Slave

  Master controls the DBD sequence numbers and drives the exchange.
  Slave echoes the master's sequence numbers in its DBD replies.

  Trigger to leave ExStart: both routers agree on master/slave roles
  and the initial sequence number → transition to Exchange.

When seen as a stuck state: ExStart stalls most commonly due to an MTU mismatch — if one router's interface MTU is larger than the other's, DBD packets may be fragmented or silently dropped. Also caused by duplicate Router IDs or a one-sided authentication configuration.

State 5 — Exchange

In the Exchange state, the two routers exchange their full LSDB "table of contents" using DBD (Database Description) packets. Each DBD packet contains the headers of LSAs in the sender's LSDB — the LSA type, link-state ID, advertising router, age, and sequence number — but not the full LSA content.

  Exchange state:
  ┌─────────┐  ──── DBD (LSA headers from R2's LSDB) ──→  ┌─────────┐
  │  R1     │  ←──── DBD (LSA headers from R1's LSDB) ───  │  R2     │
  │(Slave)  │                                               │(Master) │
  └─────────┘                                               └─────────┘
  Each router compares received DBD headers against its own LSDB.
  Any LSA in the neighbour's DBD that is newer or missing locally
  is added to a "request list."

  Trigger to leave Exchange:
  - If all DBDs processed and no missing LSAs → skip Loading → go directly to Full
  - If missing LSAs detected → move to Loading

State 6 — Loading

In the Loading state, routers request the full content of LSAs identified as missing or outdated during the Exchange state. This is the actual data transfer phase.

  Loading state:
  ┌─────────┐  ──── LSR (request specific LSA) ──────────►  ┌─────────┐
  │  R1     │  ◄──── LSU (delivers full LSA content) ──────  │  R2     │
  │         │  ──── LSAck (acknowledges receipt) ───────────► │         │
  └─────────┘                                                 └─────────┘
  Each missing LSA goes through: LSR → LSU → LSAck.
  This is reliable — LSUs must be acknowledged; unacknowledged LSUs are retransmitted.

  Trigger to leave Loading: all requested LSAs received and acknowledged → Full.

When seen as a stuck state: Loading stalls when LSUs are being lost or corrupted in transit — caused by authentication mismatches (one side authenticating, other side not), packet loss on unreliable links, or LSA database corruption. The router in Loading continuously retransmits LSRs until either the LSU arrives or the Dead interval expires.

State 7 — Full

Full is the goal state — it means the two routers have completely identical LSDBs for their shared area and the adjacency is fully established. From Full state, both routers run the SPF algorithm on their synchronised LSDB to compute the routing table.

  Full state:
  ┌─────────┐                                               ┌─────────┐
  │  R1     │ ←───────── Hello (keepalive every 10s) ──────► │  R2     │
  │  FULL   │   LSDBs identical ✓  SPF runs ✓  Routes ✓      │  FULL   │
  └─────────┘                                               └─────────┘

  In Full state:
  - Hello packets continue as keepalives (Dead interval = 40s)
  - If a topology change occurs: new LSA flooded via LSU → SPF re-runs
  - If a Hello is missed for Dead interval: adjacency drops back to Down

Full is the only normal steady-state for an adjacency. Seeing any other state (Init, Exchange, Loading) as a persistent condition on a router is a troubleshooting signal.

4. State Transition Summary

From	To	Trigger	Key Action
Down	Init	Hello received from neighbour	Router adds neighbour to neighbour table
Init	2-Way	Hello received containing our own Router ID in the neighbour list	Bidirectionality confirmed; DR/BDR election begins on broadcast networks
2-Way	ExStart	Decision to form full adjacency (P2P always; broadcast only with DR/BDR)	Master/slave negotiation begins using empty DBD packets
ExStart	Exchange	Master/slave roles and initial sequence number agreed	Full DBD exchange of LSA header summaries begins
Exchange	Loading	DBD exchange complete; missing LSAs identified	LSR sent for each missing/outdated LSA; LSU received; LSAck sent
Exchange	Full	DBD exchange complete; no missing LSAs (LSDBs already identical)	Skip Loading; proceed directly to Full
Loading	Full	All requested LSAs received and acknowledged	LSDBs synchronised; SPF algorithm runs; routing table populated
Full	Down	Dead interval expires (no Hello received for 40s); interface goes down; neighbour explicitly removed	Adjacency torn down; LSAs flushed; SPF re-runs; routes removed

5. OSPF Hello and Dead Interval Timers

OSPF uses Hello packets for both neighbour discovery and keepalive maintenance. The Dead interval determines how long a router waits without receiving a Hello before declaring the neighbour down. Both timers must match exactly on both sides — a mismatch prevents adjacency formation.

Network Type	Hello Interval	Dead Interval	DR/BDR Election?
Broadcast (Ethernet, Token Ring)	10 seconds	40 seconds	Yes
Point-to-Point (serial, GRE tunnel)	10 seconds	40 seconds	No
Non-Broadcast Multi-Access (NBMA, Frame Relay)	30 seconds	120 seconds	Yes (manual neighbour config needed)
Point-to-Multipoint	30 seconds	120 seconds	No

  ! View current timers on an interface:
  Router# show ip ospf interface GigabitEthernet0/0
  ! Look for: "Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5"

  ! Change Hello interval (Dead interval does not auto-adjust — change both):
  Router(config-if)# ip ospf hello-interval 5
  Router(config-if)# ip ospf dead-interval 20

  ! Verify timers match on both routers — mismatch is the most common
  ! reason neighbours stay in Down/Init state despite correct IP config.

6. DR and BDR — Impact on Neighbour States

On broadcast multi-access networks (Ethernet), OSPF elects a Designated Router (DR) and a Backup Designated Router (BDR) to reduce the number of full adjacencies required. Without DR/BDR, every router on a segment would need a full adjacency with every other router — on a 10-router segment that would be n(n-1)/2 = 45 adjacencies. With DR/BDR it reduces to n-1 = 9.

  5 routers on a broadcast segment (R1–R5):
  R1 = DR (highest priority or RID)
  R2 = BDR (second highest)
  R3, R4, R5 = DROTHER

  Adjacency matrix:
  R3 ──FULL──→ R1 (DR)     ✓  R3 ──FULL──→ R2 (BDR)  ✓
  R4 ──FULL──→ R1 (DR)     ✓  R4 ──FULL──→ R2 (BDR)  ✓
  R5 ──FULL──→ R1 (DR)     ✓  R5 ──FULL──→ R2 (BDR)  ✓
  R3 ──2-WAY── R4           ✗ (not Full — DROTHER to DROTHER)
  R3 ──2-WAY── R5           ✗
  R4 ──2-WAY── R5           ✗

  Total Full adjacencies: 6  (instead of 10 without DR/BDR)
  DROTHER–DROTHER pairs: 3  (stay in 2-Way — normal and expected)

DR election process (happens at 2-Way state):

Step 1: Router with the highest OSPF interface priority wins (default priority = 1; range 0–255; priority 0 = never DR).
Step 2: Tie-break: highest Router ID wins.
The DR election is non-preemptive — a new router with a higher priority joining the segment will NOT displace an existing DR. The existing DR keeps its role until it fails.

See: OSPF Overview & DR/BDR Election

7. Point-to-Point vs Broadcast — Adjacency Difference

Feature	Broadcast (Ethernet)	Point-to-Point (Serial, GRE)
DR/BDR election	Yes — at 2-Way state	No — skipped entirely
Full adjacencies formed	Only with DR and BDR; DROTHERs stay 2-Way with each other	Always Full between the two directly connected routers
Hello multicast destination	224.0.0.5 (AllSPFRouters); DR/BDR also use 224.0.0.6	224.0.0.5
2-Way as final state?	Yes — between DROTHERs (normal, not a problem)	No — 2-Way is always transient; both proceed to Full
Expected steady-state output in show ip ospf neighbor	Some neighbours: FULL/DR or FULL/BDR; others: 2WAY/DROTHER	All neighbours: FULL/-

8. Verification and Monitoring Commands

  ! Show all OSPF neighbours with their states — the primary OSPF check:
  Router# show ip ospf neighbor

  Neighbor ID     Pri   State           Dead Time   Address         Interface
  2.2.2.2           1   FULL/DR         00:00:35    10.0.0.2        Gi0/0
  3.3.3.3           1   FULL/BDR        00:00:38    10.0.0.3        Gi0/0
  4.4.4.4           1   2WAY/DROTHER    00:00:32    10.0.0.4        Gi0/0

  ! Columns:
  ! Neighbor ID  = Router ID of the neighbour
  ! Pri          = OSPF interface priority
  ! State        = current FSM state / role (FULL/DR means Full state with the DR)
  ! Dead Time    = countdown until neighbour declared down (resets with each Hello)
  ! Address      = neighbour's IP address on the shared link
  ! Interface    = local interface through which this neighbour is reached

  ! Show detailed OSPF interface information:
  Router# show ip ospf interface GigabitEthernet0/0
  ! Shows: area, cost, DR/BDR addresses, Hello/Dead timers, neighbour count,
  !        network type, authentication type

  ! Show full OSPF process information:
  Router# show ip ospf
  ! Shows: process ID, Router ID, area count, SPF statistics, reference bandwidth

  ! Show OSPF routes in the routing table:
  Router# show ip route ospf

  ! Check MTU on an interface (mismatch causes ExStart stuck):
  Router# show interface GigabitEthernet0/0 | include MTU
  MTU 1500 bytes, BW 1000000 Kbit/sec

9. Debug Commands for Active Troubleshooting

  ! Debug OSPF adjacency events (Hello exchanges, state transitions):
  Router# debug ip ospf adj

  ! Sample output during Init → 2-Way transition:
  OSPF: Rcv hello from 2.2.2.2 area 0 from GigabitEthernet0/0 10.0.0.2
  OSPF: End of hello processing
  OSPF: 2 Way Communication to 2.2.2.2 on GigabitEthernet0/0, state 2WAY

  ! Debug Hello packet sending and receiving:
  Router# debug ip ospf hello

  ! Debug all OSPF events (high volume — use with care):
  Router# debug ip ospf events

  ! IMPORTANT: Turn off debug immediately after capturing what you need:
  Router# no debug ip ospf adj    (or: undebug all)
  ! On a busy router, leaving debug running can cause CPU overload.

10. Troubleshooting Stuck Neighbour States

When a neighbour relationship is stuck in a state other than Full (for non-DROTHER pairs) or 2-Way (for DROTHER pairs), the following table provides a systematic diagnostic approach.

Stuck State	Root Cause	Diagnostic / Fix
Down	Physical link down; OSPF not enabled on the remote interface; firewall or ACL blocking OSPF multicast (224.0.0.5 / protocol 89)	Check physical connectivity; verify `network` command matches the interface; check ACLs for protocol 89 or IP multicast filters; `show ip ospf interface`
Init	Unidirectional communication — Hello is received from neighbour but the neighbour is not receiving our Hello; Layer 2 asymmetry; ACL blocking in one direction	Check for ACLs on both interfaces; verify both interfaces can reach the multicast address; check for duplex mismatch causing one-way packet loss; use `debug ip ospf hello` to confirm Hellos are being sent
2-Way (unexpected — between DR and DROTHER)	Area mismatch; Hello/Dead timer mismatch; subnet mask mismatch; authentication mismatch; stub flag mismatch	`show ip ospf interface` on both routers — compare area ID, Hello/Dead timers, network type, and authentication; all parameters must match exactly
ExStart	MTU mismatch (most common — DBD packets too large to traverse the link); duplicate Router IDs in the area	`show interface \| include MTU` on both sides; if different, add `ip ospf mtu-ignore` to the interface (or fix the actual MTU); `show ip ospf` to check for duplicate RID alerts
Exchange	DBD packet loss; neighbour reset mid-exchange; very large LSDB causing timeout during exchange	`debug ip ospf adj` to observe DBD exchange; check interface error counters with `show interface`; verify no MTU issues on intermediate links
Loading	Authentication mismatch causing LSU rejection; LSA corruption; packet loss preventing LSAck from reaching the sender; very large LSDB with many LSRs timing out	Verify authentication config on both routers; `debug ip ospf adj` to watch LSR/LSU exchange; check interface for errors; `clear ip ospf process` to force full OSPF restart if corruption suspected

Quick Diagnostic Decision Tree

  Neighbour not in Full state?
  │
  ├── State = Down?
  │   → Check physical link, OSPF network command, ACL/firewall
  │
  ├── State = Init?
  │   → One-way communication. Check ACL in BOTH directions, Layer 2
  │
  ├── State = 2-Way (but should be Full)?
  │   → Mismatched Hello field. Check: Area ID, timers, mask, auth, stub flag
  │   → Show ip ospf interface on both sides and compare line by line
  │
  ├── State = ExStart?
  │   → MTU mismatch (most common) or duplicate RID
  │   → show interface | include MTU on both sides
  │   → ip ospf mtu-ignore as temporary fix
  │
  ├── State = Exchange?
  │   → DBD packet loss. Check errors on interface. Consider debug ip ospf adj
  │
  └── State = Loading?
      → Authentication mismatch or LSA loss. Check auth, check errors.
      → clear ip ospf process as last resort

11. Complete Scenario — Full Adjacency Formation Trace

Two routers (R1 and R2) connect via a shared Ethernet segment (GigabitEthernet0/0 on each). Both have OSPF enabled in Area 0. Here is the complete state progression from power-up to Full.

  T=0s  R1 powers up, OSPF enabled on Gi0/0
        R1 state: DOWN (no Hellos received)
        R1 sends Hello → 224.0.0.5 (contains: RID=1.1.1.1, Area=0,
          Hello=10s, Dead=40s, Mask=255.255.255.0, Neighbour list: empty)

  T=1s  R2 receives R1's Hello
        R2 checks: Area, mask, timers, auth — all match ✓
        R2 adds R1 to neighbour table
        R2 state (for R1): INIT

  T=1s  R2 sends Hello → 224.0.0.5
        (contains: RID=2.2.2.2, Neighbour list: [1.1.1.1])

  T=2s  R1 receives R2's Hello — sees own RID (1.1.1.1) listed
        R1 state: 2-WAY ✓ (bidirectionality confirmed)

  T=2s  R2 receives R1's Hello — sees own RID (2.2.2.2) listed
        R2 state: 2-WAY ✓

  T=2s  DR/BDR election runs:
        R1 priority=1, RID=1.1.1.1
        R2 priority=1, RID=2.2.2.2  → R2 wins → DR
        R1 → BDR  (only two routers — BDR needed)

  T=3s  R1 (BDR) and R2 (DR) begin ExStart
        R2: "I am Master" (higher RID wins)
        R1: "I am Slave"
        Agree on sequence number = 1001

  T=3s  Exchange begins:
        R2 (Master) sends DBD (seq=1001): lists headers of all LSAs
        R1 (Slave)  sends DBD (seq=1001): lists headers of all LSAs
        Each compares received headers against own LSDB
        R1: "R2 has LSA for 10.2.0.0/24 — I don't have it → add to request list"

  T=4s  Loading:
        R1 sends LSR: "Please send full content of 10.2.0.0/24 LSA"
        R2 sends LSU: full LSA content for 10.2.0.0/24
        R1 sends LSAck: "Received ✓"
        (Similar exchange in other direction if needed)

  T=5s  All LSAs exchanged and acknowledged
        R1 state: FULL  ✓
        R2 state: FULL  ✓
        Both run SPF → routing tables updated
        show ip ospf neighbor shows: FULL/DR (R2) and FULL/BDR (R1)

12. Exam Tips & Key Points

Know all seven states in order: Down → Init → 2-Way → ExStart → Exchange → Loading → Full.
Init = we received their Hello but they have not confirmed they received ours. One-way communication.
2-Way = both routers list each other in their Hello neighbour fields. DR/BDR election happens here. 2-Way is the normal final state between DROTHER routers on Ethernet — it is NOT a problem when seen in that context.
ExStart = master/slave negotiation using empty DBD packets. The router with the higher Router ID becomes Master. The most common stuck-at-ExStart cause is an MTU mismatch.
Exchange = DBD packets carry LSA headers only (not full content). After comparison, any missing or outdated LSAs go on the request list.
Loading = LSR requests missing LSAs; LSU delivers them; LSAck acknowledges. Stuck-at-Loading is usually caused by authentication mismatch or packet loss.
Full = the only goal state. LSDBs are identical and SPF has run. If not Full (and not 2-Way between DROTHERs), something is wrong.
Parameters that must match in the Hello: Area ID, subnet mask (broadcast), Hello interval, Dead interval, authentication, stub flag. Any mismatch keeps the state at Down or Init.
Default timers: Hello 10s, Dead 40s on broadcast; Hello 30s, Dead 120s on NBMA. Timers must match — they do NOT auto-negotiate.
show ip ospf neighbor is the go-to command. The State column shows the FSM state plus the neighbour's role (e.g., FULL/DR means Full state with the DR).

13. Summary Reference Table

State	What It Means	Key Packet	Normal Final State?	Stuck Cause
Down	No Hello received; initial or reset state	—	No	Link down, OSPF not enabled, ACL blocking
Init	Hello received but our RID not in neighbour's list yet	Hello	No	One-way communication, Layer 2 asymmetry
2-Way	Bidirectional Hello; DR/BDR elected	Hello	Yes — between DROTHERs	Parameter mismatch (if should be Full)
ExStart	Master/slave negotiation for DBD sequence control	DBD (empty)	No	MTU mismatch, duplicate Router IDs
Exchange	Exchanging LSA header summaries (DBD)	DBD	No	DBD packet loss, reset mid-exchange
Loading	Requesting and receiving missing full LSA content	LSR, LSU, LSAck	No	Auth mismatch, LSA corruption, packet loss
Full	LSDBs fully synchronised; SPF run; routing operational	Hello (keepalive)	Yes — always for DR/BDR pairs and P2P	N/A — this is the goal state

OSPF Neighbour States Quiz

1. What does the OSPF Down state mean, and what event causes a router to leave it?

A. Down means no Hello has been received from this neighbour — the router leaves Down and enters Init the moment a Hello arrives from that neighbour B. Down means the router has received a Hello but the bidirectional exchange has not completed yet C. Down means the physical interface is administratively shut down and OSPF cannot run D. Down means the LSDB exchange failed and the relationship must be restarted

Correct answer is A. The Down state is the initial and reset state of every OSPF neighbour entry. It does not necessarily mean the physical link is down — it means no Hello packet has been received from this specific neighbour within the dead interval. A router in Down state still sends Hello packets out its OSPF-enabled interfaces (to 224.0.0.5) in an attempt to discover neighbours. The transition from Down to Init occurs the moment a Hello is received from a new neighbour — the local router adds the sender to its neighbour table and moves the entry to Init state. If a previously Full neighbour stops sending Hellos for the full Dead interval (default 40s), its entry drops back to Down and the adjacency is torn down.

2. What is the critical difference between Init and 2-Way states, and what specific event triggers the transition from Init to 2-Way?

A. Init uses DBD packets; 2-Way uses Hello packets — the transition occurs when DBD exchange begins B. Init is when the DR has been elected; 2-Way is when the BDR is elected C. Init means the LSDBs are partially synchronised; 2-Way means synchronisation is complete D. Init means only one-way Hello reception (we hear them but they haven't confirmed they hear us); the transition to 2-Way occurs when we receive a Hello from the neighbour that includes our own Router ID in its neighbour list — confirming bidirectionality

Correct answer is D. The Init → 2-Way transition is fundamentally about confirming bidirectionality. In Init state, the local router has received a Hello from a neighbour but has not yet seen its own Router ID in that neighbour's Hello. This means the neighbour has not yet acknowledged receiving the local router's Hellos. The transition to 2-Way occurs when the local router receives a Hello from that same neighbour and finds its own Router ID listed in the neighbour's "neighbour list" field of the Hello packet. This confirms that communication is working in both directions. The 2-Way state is significant because it is where the DR/BDR election occurs on broadcast networks, and where the decision is made whether to proceed to full adjacency.

3. During which OSPF state do routers negotiate master and slave roles, and how is the winner determined?

A. Exchange state — the router with the lower Router ID becomes the Master B. Loading state — the router that initiates the LSR becomes the Master C. ExStart state — the router with the higher Router ID becomes the Master using empty DBD packets to negotiate sequence numbers D. Full state — the router that completed synchronisation first becomes the Master

Correct answer is C. ExStart is the first state of actual database synchronisation. Before exchanging the contents of their LSDBs, the two routers must agree on a Master/Slave relationship to control the sequencing of DBD packets. Both routers initially claim to be Master, each proposing its own sequence number in an empty DBD packet. The router with the higher Router ID wins and becomes the Master. The Master controls the sequence numbers for the DBD exchange — it increments the sequence number with each DBD it sends, and the Slave echoes that sequence number in its DBD replies. This prevents duplicate or out-of-order DBD packets. The transition from ExStart to Exchange occurs when both routers agree on the master/slave assignment and the initial sequence number.

4. What does a DBD packet contain during the Exchange state, and what happens after the exchange is complete?

A. DBD packets contain the full content of every LSA in the LSDB; after exchange, the LSDB is immediately synchronised and the state becomes Full B. DBD packets contain LSA headers only (type, ID, age, sequence number — no actual route data); after exchange, each router compares the received headers to its own LSDB and moves to Loading if any LSAs are missing, or directly to Full if LSDBs are already identical C. DBD packets contain Hello parameters used to verify adjacency requirements; after exchange, OSPF timers are synchronised between the two routers D. DBD packets contain routing table entries; after exchange, both routers merge their routing tables

Correct answer is B. During Exchange state, DBD (Database Description) packets serve as a "table of contents" for each router's LSDB. They contain only the headers of LSAs — specifically the LSA type, Link-State ID, Advertising Router, age, and sequence number. The full LSA content (the actual route and link information) is NOT in the DBD. After exchanging DBDs, each router compares the received LSA headers against its own database. Any LSA that is in the neighbour's DBD but absent or outdated (lower sequence number) in the local LSDB is added to a "request list." If the request list is empty (LSDBs are identical), the router skips Loading and proceeds directly to Full. If there are missing LSAs, the router transitions to Loading and begins sending LSR packets.

5. What three packet types are used in the Loading state, and in what order do they flow?

A. LSR (Link-State Request) → LSU (Link-State Update) → LSAck (Link-State Acknowledgement) — the requesting router sends LSR to ask for specific LSAs, the neighbour replies with LSU containing the full LSA content, and the requester sends LSAck to confirm receipt B. DBD → LSU → LSAck — the DBD is first used to request missing LSAs before updates are sent C. Hello → LSR → LSU — Hello packets are used to request missing LSAs from the neighbour D. LSU → LSAck → LSR — the update is sent first, acknowledged, then the missing LSAs are specifically requested

Correct answer is A. The Loading state uses a reliable three-step exchange for each missing LSA. First, the router with the missing LSA sends a Link-State Request (LSR) packet specifying exactly which LSA it needs (by type, Link-State ID, and Advertising Router). The neighbour responds with a Link-State Update (LSU) containing the full content of the requested LSA — this is the actual topology data. The requesting router then sends a Link-State Acknowledgement (LSAck) to confirm receipt. If the LSAck is not received, the sender retransmits the LSU — making OSPF flooding reliable. Multiple LSRs can be outstanding simultaneously. The transition from Loading to Full occurs when all outstanding LSRs have been satisfied and acknowledged.

6. On a broadcast Ethernet segment with five OSPF routers, why do DROTHER routers remain in 2-Way state with each other rather than advancing to Full?

A. DROTHERs do not send Hello packets, so they cannot establish bidirectional communication with each other B. DROTHERs are on different subnets from each other and cannot form direct adjacencies C. DROTHERs are not allowed to exchange routing information with any other router D. To prevent unnecessary LSA flooding and adjacency overhead — on a segment with n DROTHERs, full adjacencies between all DROTHER pairs would create n(n-1)/2 adjacencies; the DR/BDR model reduces this to a star topology where only DR and BDR form full adjacencies, and DROTHERs stay in 2-Way with each other

Correct answer is D. The DR/BDR model exists specifically to solve the scalability problem of full-mesh adjacencies on broadcast segments. If all n routers formed full adjacencies with each other, the number of adjacencies would be n(n-1)/2 — on a 10-router segment that is 45 adjacencies, each requiring an LSDB synchronisation and SPF recalculation. Instead, the DR collects all topology updates from the segment and re-floods them to all other routers using the 224.0.0.5 multicast — effectively acting as a hub. DROTHERs only form full adjacencies with the DR and BDR. They stay in 2-Way with each other, which confirms bidirectionality but avoids the overhead of a full database exchange. Seeing 2WAY/DROTHER in show ip ospf neighbor between two non-DR/BDR routers on the same Ethernet segment is completely normal.

7. An engineer notices two OSPF routers are stuck in ExStart state. What are the two most likely causes, and how would you diagnose each?

A. Authentication mismatch and Hello interval mismatch — check show ip ospf interface for matching auth and timer values B. MTU mismatch (DBD packets are too large to cross the link) or duplicate Router IDs in the area — diagnose with "show interface | include MTU" and "show ip ospf" looking for duplicate RID warnings C. No Hello packets received and the link being physically down — check physical connectivity D. Missing network command and incorrect area assignment — check the OSPF configuration on both routers

Correct answer is B. ExStart stuck is the most diagnostically specific OSPF stuck state. The two dominant causes are: (1) MTU mismatch — DBD packets are generated based on the local interface MTU. If one router has MTU 1500 and the other has MTU 9000 (jumbo frames), the larger router's DBD packets are too big for the smaller MTU link and are silently dropped. The smaller-MTU router keeps retransmitting its empty DBD without receiving a valid response. Diagnose with show interface Gi0/0 | include MTU on both sides; fix with ip ospf mtu-ignore (or correct the MTU). (2) Duplicate Router IDs — two routers in the same OSPF area have been configured with the same RID; the master/slave negotiation produces inconsistent results. Diagnose with show ip ospf which reports duplicate RID detection. Authentication mismatches (option A) typically cause issues at the Hello level (Down/Init), not ExStart.

8. What does the output "2.2.2.2 1 FULL/DR 00:00:35 10.0.0.2 Gi0/0" in show ip ospf neighbor indicate?

A. The neighbour with Router ID 2.2.2.2 is in Full state (fully adjacent, LSDB synchronised) and is the Designated Router on the Gi0/0 segment; its Dead Time countdown shows 35 seconds remaining before it would be declared down B. The neighbour is in Full state but the DR election has not yet completed — "DR" indicates it is a candidate, not the elected DR C. The neighbour's OSPF process has been running for 35 seconds and reached the Full state with DR capabilities D. The neighbour failed and will be removed from the routing table after 35 seconds unless a Hello is received

Correct answer is A. The show ip ospf neighbor output columns read as: Neighbor ID (Router ID = 2.2.2.2), Pri (OSPF interface priority = 1), State (FULL/DR = the neighbour relationship is in Full state AND this neighbour is the Designated Router on the shared segment), Dead Time (00:00:35 = countdown timer showing how long until this neighbour is declared down if no Hello is received — it resets with every Hello), Address (10.0.0.2 = neighbour's IP on the shared link), Interface (Gi0/0 = the local interface). FULL/DR is the correct healthy state for the DR neighbour. FULL/BDR would be the BDR. 2WAY/DROTHER would be a non-DR/BDR. The Dead Time counts down from 40s (default) and is continuously reset when each Hello arrives — if it reaches zero, the adjacency is dropped.

9. What is the default Hello interval on a broadcast network, and what happens if two OSPF routers have mismatched Hello intervals?

A. 5 seconds — mismatched timers are automatically negotiated to the lower value B. 40 seconds — the routers stay in Init state until the timers converge C. 10 seconds — a mismatch prevents adjacency formation entirely; the routers will never progress beyond Down/Init because the Hello fields do not match and OSPF does not auto-negotiate timers D. 30 seconds — the routers form a partial adjacency with degraded convergence

Correct answer is C. The default OSPF Hello interval on broadcast networks (Ethernet) is 10 seconds, with a Dead interval of 40 seconds (4× Hello by default). On NBMA networks, the defaults are 30s Hello and 120s Dead. Hello intervals and Dead intervals must match exactly on both sides of an adjacency — OSPF does not auto-negotiate these values. When a router receives a Hello packet, it checks the Hello interval in the packet against its own configured value. If they differ, the Hello is rejected and the neighbour relationship cannot progress beyond Down/Init. This is a very common misconfiguration — especially when one side has been manually tuned for faster convergence (ip ospf hello-interval 1) and the other side still uses the default 10s. Always verify with show ip ospf interface on both routers.

10. What does Full state signify, and what two types of neighbours on a broadcast segment legitimately show a state other than Full?

A. Full means the routing table is complete — no neighbour ever shows a state other than Full in a healthy OSPF deployment B. Full means the LSDBs are completely synchronised and the adjacency is fully established; on broadcast segments, DROTHER-to-DROTHER pairs legitimately show 2-Way/DROTHER because they intentionally do not form full adjacencies with each other C. Full means the Exchange state completed; Loading state is the legitimately visible state for newly joined routers D. Full means OSPF is converged — routers in the Init state are normal for backup connections

Correct answer is B. The Full state is the goal of OSPF adjacency formation. It means the two routers have completed all phases of LSDB synchronisation — their databases are identical, the SPF algorithm has run on the synchronised LSDB, and the resulting routes are in the routing table. Topology changes are handled by LSU floods, and Hello keepalives maintain the relationship. On broadcast Ethernet segments, it is completely normal and expected to see 2WAY/DROTHER in show ip ospf neighbor for DROTHER-to-DROTHER pairs. These routers confirm bidirectionality at 2-Way but intentionally do not advance to full adjacency — they rely on the DR to distribute topology information on their behalf. Misunderstanding this and treating 2WAY/DROTHER as a problem is a very common exam trap.

← Back to Home