CCNA: OSPF Single-Area Configuration

May 26, 2026 54 min read Networking Deep Dives

ccnanetworkingospfroutingciscoiosigp

Contents

OSPF is the interior gateway protocol you will encounter everywhere — enterprise campuses, service provider cores, datacenter fabrics, CCNA exams, and every job interview that involves the word “routing.” It is also the protocol where most CCNA candidates first encounter the gap between memorizing facts and actually understanding how something works. You can recite the seven neighbor states without having any mental model of why those states exist, what triggers each transition, or what a stuck neighbor tells you about your network. This post attempts to close that gap.

Everything covered here maps to the CCNA 200-301 exam objectives, but the goal is not exam cramming. The goal is building the mental model that makes troubleshooting feel obvious rather than mysterious. When you finish reading you should be able to configure OSPF on a three-router topology from memory, read the output of show ip ospf neighbor and know exactly what every field means, and diagnose the six most common neighbor formation failures before you even touch the CLI.

Part 1: Why Link-State — The Problem With Distance-Vector

To understand why OSPF works the way it does, you need to understand what it was designed to replace.

Distance-Vector: Routing by Rumor

RIP — the canonical distance-vector protocol — works on a simple principle. Each router knows only two things about every destination: the distance (hop count) and the direction (which interface to exit). Periodically, every 30 seconds by default, each router broadcasts its entire routing table to its directly connected neighbors. Those neighbors incorporate the received information into their own tables and broadcast again. Eventually every router in the network has learned routes to every destination, all of it secondhand, passed router-to-router like gossip.

This is the “routing by rumor” mental model, and it captures the fundamental weakness. Router A doesn’t know the actual topology between itself and some distant destination. It only knows what Router B told it, and Router B only knows what Router C told it. The actual network graph is invisible to any individual router. The practical consequences are severe.

Slow convergence. When a link fails, the routers on that segment know immediately. But they can only inform their neighbors, who then wait for their next update cycle to inform their neighbors, and so on. In a large network, propagating a topology change from one end to the other can take minutes. During that window, routers are working with stale information and may be forwarding traffic into a black hole.

Routing loops. The canonical problem: R1 advertises a route to 10.0.0.0/8 with distance 1. R2 learns this and advertises it with distance 2. Now R1’s link to 10.0.0.0/8 fails. R1 removes the route. But before R1 can advertise the withdrawal, R2 sends its next periodic update, and R1 learns from R2 that 10.0.0.0/8 is reachable at distance 2. R1 installs this and advertises it with distance 3. R2 sees the distance increase and updates to 3+1=4. This is the count-to-infinity problem, and it causes a routing loop where traffic bounces between R1 and R2 until the hop count exceeds the maximum (15 for RIP, which is also why RIP networks cannot exceed 15 hops in diameter).

RIP employs band-aids: split horizon (don’t advertise a route back out the interface you learned it from), route poisoning (advertise a failed route with infinite metric), holddown timers (refuse to accept an inferior route for a period after a failure). These help but do not fully solve the problem. They also increase convergence time.

Scalability ceiling. Sending your entire routing table every 30 seconds to every neighbor is expensive. RIP is effectively unusable in networks with more than a few dozen routers.

Link-State: Building a Complete Map

OSPF takes a fundamentally different approach. Instead of advertising routes (destinations and distances), OSPF routers advertise links — the actual connections between routers, their states, and their costs. Every OSPF router in an area receives these link-state advertisements from every other router in the area and uses them to construct a complete, identical map of the network topology. This map is called the Link-State Database, or LSDB.

Once the LSDB is complete, each router independently runs Dijkstra’s Shortest Path First algorithm, using itself as the root, to compute the shortest path tree to every destination. It installs the results in the IP routing table. Because every router has the same LSDB, every router computes the same topology, and the results are loop-free by construction.

The key insight is this: OSPF routers share topology information, not route information. A router receiving an LSA does not think “here is a route I should install.” It thinks “here is a piece of the network graph I need to add to my map.” Route computation happens locally after the full map is assembled.

Fast convergence. When a link fails, the affected routers immediately flood a new LSA announcing the change. This LSA propagates throughout the area within seconds. Every router that receives it re-runs SPF and updates its routing table almost immediately. Convergence time is measured in seconds, not minutes.

No routing loops. Because every router computes routes from the same complete topology graph, all routers agree on paths. There is no mechanism for a loop to form, because routes are not derived from neighbor advertisements that could reflect a stale or incorrect view.

Scalability. LSA flooding is triggered by topology changes, not on a timer. A stable network generates essentially zero OSPF traffic after initial convergence. OSPF also introduces the concept of areas to limit the scope of flooding in large networks.

The tradeoff: OSPF is more complex to understand and configure than RIP. The link-state database, DR/BDR election, the neighbor state machine, LSA types — all of this is more machinery than distance-vector requires. For CCNA and for any real network, that complexity is worth it.

Part 2: OSPF Fundamentals

The RFC and Protocol Versions

OSPF for IPv4 is defined in RFC 2328. This is OSPFv2, and it is what every CCNA question refers to when it says “OSPF” without qualification. OSPFv3 (RFC 5340) was designed for IPv6 and has since been extended to support IPv4 as well, but you will not need it for CCNA. When this post says “OSPF,” it means OSPFv2.

OSPF runs directly over IP using protocol number 89. It does not use TCP or UDP.

Process ID

When you configure OSPF on a Cisco router, you specify a process ID:

router ospf 1

The process ID is locally significant only. It identifies the OSPF process on this router and has no meaning to any other router in the network. Two routers can successfully form an OSPF neighbor adjacency even if they are running different process IDs. Process IDs allow a single router to run multiple OSPF processes simultaneously, though you will almost never do this in practice.

Do not confuse the process ID with the area ID. They are entirely different concepts.

Router ID

Every OSPF router must have a Router ID (RID). The RID is a 32-bit value formatted like an IPv4 address and must be unique across the entire OSPF domain. It is used to identify each router’s LSAs in the LSDB and to break ties in DR/BDR election.

Cisco IOS selects the Router ID using this priority order:

Manually configured with router-id under the OSPF process (highest priority, always use this)
Highest IP address on any loopback interface that is up/up at the time OSPF starts
Highest IP address on any non-loopback interface that is up/up at the time OSPF starts

The RID is selected when OSPF first starts and does not change unless you force it with clear ip ospf process. This means that if no loopback exists and the highest physical interface IP is used as the RID, and that interface later goes down, the RID does not change — but losing that interface could cause problems. Best practice is to always configure a loopback interface for the RID and configure the RID explicitly:

interface Loopback0
 ip address 1.1.1.1 255.255.255.255

router ospf 1
 router-id 1.1.1.1

A /32 loopback is conventional. The 1.1.1.1/32 convention for Router 1, 2.2.2.2/32 for Router 2, and so on is purely a documentation aid — use whatever addressing makes sense for your network.

Areas and the Backbone

OSPF uses a hierarchical area structure to limit the scope of LSA flooding. An area is a group of routers and links that share the same LSDB. LSA flooding occurs within an area; routers outside the area do not see the detailed topology of that area (only summarized route information).

Every OSPF network must have an Area 0, called the backbone area. In multi-area OSPF, all non-zero areas must connect to Area 0. Routers that connect two areas are called Area Border Routers (ABRs). Routers that redistribute routes from another routing protocol into OSPF are called Autonomous System Boundary Routers (ASBRs).

For CCNA purposes, and for any network with fewer than roughly 50 routers, a single Area 0 is sufficient and simplest. You get the full benefit of OSPF’s link-state model without the additional complexity of ABRs, summary routes, and LSA type 3/4/5. This post focuses entirely on single-area OSPF in Area 0.

Part 3: OSPF Packet Types

OSPF uses five packet types, each with a specific role in forming and maintaining neighbor relationships and exchanging topology information. All OSPF packets share a common 24-byte header containing the OSPF version, packet type, router ID, area ID, checksum, and authentication fields.

Type	Name	Purpose
1	Hello	Neighbor discovery, neighbor keepalive, DR/BDR election
2	DBD (Database Description)	Summary of sender’s LSDB during initial exchange
3	LSR (Link-State Request)	Request specific LSAs not yet in local LSDB
4	LSU (Link-State Update)	Carry one or more LSAs — the actual topology data
5	LSAck (Link-State Acknowledgment)	Reliable acknowledgment of received LSAs

The Hello Packet in Detail

The Hello packet is the most fundamental OSPF packet. It serves three purposes: discovering neighbors on a segment, maintaining the neighbor relationship by acting as a keepalive, and participating in DR/BDR election. Understanding the fields in a Hello packet explains most of OSPF’s neighbor formation rules.

Hello Packet Field	Description
Router ID	Sender’s OSPF Router ID — identifies who sent this Hello
Hello Interval	How often this router sends Hellos (must match neighbor)
Dead Interval	How long to wait without a Hello before declaring neighbor dead (must match)
Area ID	The OSPF area of this interface (must match neighbor)
Router Priority	Used in DR/BDR election (0 = ineligible)
DR IP Address	Current DR on this segment (0.0.0.0 if unknown)
BDR IP Address	Current BDR on this segment (0.0.0.0 if unknown)
Authentication	Auth type and data (must match neighbor)
Neighbor List	RIDs of all OSPF routers from whom valid Hellos have been received

The Neighbor List field is critical: when Router A sends a Hello listing Router B’s RID in the Neighbor List, Router B knows that A can hear A’s Hellos. This is how bidirectional communication is confirmed, which drives the transition from Init state to 2-Way state (more on this shortly).

The fields that must match between neighbors for adjacency to form are: Hello Interval, Dead Interval, Area ID, and Authentication. Subnet and subnet mask must also match (both routers must be on the same subnet). A mismatch in any of these will prevent the neighbor relationship from forming.

The field that must be unique: Router ID. Duplicate RIDs cause significant OSPF problems and are a common source of confusion in misconfigured networks.

Part 4: The Seven OSPF Neighbor States

This is the section that most CCNA candidates memorize as a list without internalizing the logic. The seven states are not arbitrary — each one represents a specific milestone in the process of two routers going from knowing nothing about each other to having a fully synchronized LSDB. Work through the logic and the states become obvious.

The State Machine

  DOWN
    |
    | Hello received from neighbor
    v
  INIT
    |
    | My RID appears in neighbor's Hello (bidirectional)
    v
  2-WAY  <-------- DROther-to-DROther pairs STOP HERE
    |
    | DR/BDR election complete; adjacency will form
    v
  EXSTART
    |
    | Master/slave negotiated; DBD exchange begins
    v
  EXCHANGE
    |
    | DBD complete; LSR sent for missing LSAs
    v
  LOADING
    |
    | All LSRs satisfied; LSDB synchronized
    v
  FULL

Down

The neighbor does not exist in the OSPF neighbor table, or the last Hello from this neighbor was received more than the Dead Interval ago. This is the initial state before any communication, and also the state a neighbor returns to when it is declared dead.

Init

A Hello has been received from the neighbor, but the local router’s own RID does not appear in that Hello’s Neighbor List. This means the Hello was received, but communication is not yet confirmed as bidirectional — the neighbor hasn’t seen our Hellos yet (or hasn’t processed them). The state is called Init because it represents the beginning of the relationship from our perspective: we see them, but they haven’t acknowledged seeing us.

2-Way

A Hello has been received from the neighbor that includes our own RID in the Neighbor List. This confirms bidirectional communication — both routers can hear each other. At this point, on multi-access network segments (Ethernet), the DR/BDR election occurs.

The 2-Way state is also the final state for DROther-to-DROther relationships. On a multi-access segment with multiple routers, only certain routers form full adjacencies (more on this in the DR/BDR section). Two routers that are both DROthers will remain at 2-Way and never proceed further. This is normal and correct behavior.

For routers that will form a full adjacency — either because the link is point-to-point, or because at least one of them is the DR or BDR — they proceed past 2-Way.

Exstart

The two routers need to exchange their LSDBs. Before they can do this, they must agree on a master/slave relationship that controls the sequencing of DBD packets. In Exstart, the routers negotiate who is master and who is slave by exchanging empty DBD packets. The router with the higher Router ID becomes the master.

Exchange

The master sends numbered DBD packets; the slave responds with DBD packets of its own (and acknowledgment). Each DBD packet contains a summary of the sender’s LSDB — LSA headers describing what the router has, but not the full LSA content. After Exchange, each router knows what LSAs the other has.

Loading

Each router compares the received DBD summaries to its own LSDB and identifies LSAs it is missing. It sends LSR (Link-State Request) packets asking for the full content of those missing LSAs. The neighbor responds with LSU (Link-State Update) packets containing the requested LSAs. Each received LSU is acknowledged with an LSAck. This continues until both routers have received every LSA they were missing.

Full

Both routers have identical LSDBs. The adjacency is complete. This is the only healthy end state. From this point, SPF runs, routes are installed in the routing table, and the routers maintain the relationship with Hello keepalives and incremental LSA updates as the topology changes.

Summary Table

State	What It Means	Next Trigger
Down	No hellos received / neighbor timed out	Receive a Hello
Init	Their Hello received; they don’t see us yet	Our RID appears in their Hello
2-Way	Bidirectional confirmed; DR/BDR election done	Adjacency will form (not DROther-DROther)
Exstart	Master/slave negotiated via empty DBDs	Higher RID declared master; begin DBD exchange
Exchange	DBD summaries exchanged	DBDs complete; send LSRs for missing LSAs
Loading	LSR/LSU/LSAck — filling LSDB gaps	All LSRs satisfied
Full	LSDB synchronized	Steady state; maintained by Hellos

Why DROther Pairs Stop at 2-Way

On an Ethernet segment with five OSPF routers, if every router formed a full adjacency with every other router, you would have 5*(5-1)/2 = 10 adjacencies. Every time a topology change occurred, LSAs would need to be exchanged across all 10 adjacencies, creating a significant amount of flooding traffic that scales as O(n^2). The DR/BDR mechanism solves this by designating two routers — the DR and BDR — as central points for adjacency and flooding. All other routers (DROthers) form full adjacencies only with the DR and BDR, not with each other. DROther-to-DROther pairs stop at 2-Way: they know each other exist (bidirectional communication confirmed), but they do not exchange LSDBs. LSA flooding on the segment is centralized through the DR.

Part 5: DR/BDR Election

Why It Exists

The DR/BDR mechanism exists specifically for multi-access network types — primarily Ethernet (broadcast multi-access). On such a segment, multiple routers share the same physical medium. Without DR/BDR, every router would need to form a full adjacency with every other router on the segment, and every topology change would require exchanging LSAs with every neighbor, creating O(n^2) flooding traffic.

The Designated Router is the central flooding point for the segment. All routers send LSAs to the DR using the multicast address 224.0.0.6 (AllDRRouters). The DR then floods those LSAs to all routers on the segment using 224.0.0.5 (AllSPFRouters). The Backup Designated Router exists solely to take over if the DR fails. Only two full adjacencies per non-DR/BDR router are required: one with the DR, one with the BDR.

Ethernet Segment (192.168.1.0/24)
                                       
  R1 (DROther)                        
      \    Full adj to DR/BDR         
       \                              
  R2 (DROther) --- [DR: R4] --- [BDR: R3]
       /      2-Way to DROthers       
      /                               
  R5 (DROther)                        
                                       
  Adjacencies: 5 routers, 2 per DROther = 8 total
  Without DR/BDR: 5*(5-1)/2 = 10 adjacencies
  On larger segments the savings are dramatic.

Election Rules

Election occurs when routers on a segment first bring their OSPF interfaces up and reach 2-Way state with each other. There is a brief wait interval (the Wait Timer, equal to the Dead Interval) before the election completes, allowing all routers on the segment to announce themselves before a winner is declared.

The election follows this priority:

Highest OSPF priority wins DR. Default priority is 1. Range is 0-255. A priority of 0 means the router is ineligible to become DR or BDR. Set with ip ospf priority <value> on the interface.
Tie-break: highest Router ID. If two routers have the same priority, the one with the higher Router ID wins.

Router  Priority  Router ID       Result
------  --------  ---------       ------
R1      1         1.1.1.1         DROther
R2      1         2.2.2.2         DROther
R3      1         3.3.3.3         BDR
R4      1         4.4.4.4         DR

Router  Priority  Router ID       Result
------  --------  ---------       ------
R1      100       4.4.4.4         DR  (highest priority wins, RID irrelevant)
R2      50        3.3.3.3         BDR
R3      1         2.2.2.2         DROther
R4      0         1.1.1.1         Ineligible (priority 0)

Non-Preemptive Election

This is the most commonly misunderstood aspect of DR/BDR: the election is non-preemptive. Once a DR and BDR are elected and adjacencies are formed, they remain DR and BDR even if a new router with a higher priority or higher RID joins the segment. The new router becomes a DROther and waits.

The only way to force a new election is to clear the OSPF process on all routers on the segment (clear ip ospf process) or to power off the current DR. When the DR fails, the BDR immediately promotes itself to DR, and a new BDR election occurs among the remaining routers.

This design choice is intentional. Frequent DR changes would cause re-adjacency, SPF recalculations, and transient routing instability. Stability is preferred over always having the “best” router as DR.

The practical implication: if you want a specific router to be DR, you must configure it before bringing up OSPF on the segment, or you must accept that it will not become DR until the current DR fails or OSPF is cleared.

Point-to-Point Links: No Election Needed

On a point-to-point serial link or a point-to-point Ethernet (connecting exactly two routers), the flooding problem does not exist. There are only two routers and one adjacency. No DR or BDR is needed.

On Cisco IOS, physical serial interfaces that run PPP or HDLC use the point-to-point network type by default and skip the DR/BDR election. Ethernet interfaces default to the broadcast network type.

You can override the network type on an Ethernet interface to eliminate DR/BDR election:

interface GigabitEthernet0/0
 ip ospf network point-to-point

This is useful for Ethernet-based point-to-point links (direct fiber, cross-over cables between two routers). Both sides must use the same network type.

Multicast Addresses

Address	Name	Used For
224.0.0.5	AllSPFRouters	All OSPF routers — Hello packets, LSAs from DR
224.0.0.6	AllDRRouters	DR and BDR only — DROthers send LSAs here

These are link-local multicast addresses. They are not forwarded by routers; they are only processed on the local segment.

Part 6: Hello and Dead Timers

Default Values

The Hello interval controls how often an OSPF router sends Hello packets on an interface. The Dead interval controls how long a router waits without receiving a Hello before declaring the neighbor dead. By convention the Dead interval is four times the Hello interval, though this is configurable.

Network Type	Hello Interval	Dead Interval
Broadcast (Ethernet)	10 seconds	40 seconds
Point-to-Point	10 seconds	40 seconds
NBMA (Frame Relay, ATM)	30 seconds	120 seconds

The NBMA (Non-Broadcast Multi-Access) network type uses slower timers because older WAN technologies were more expensive and less reliable. You are unlikely to encounter NBMA in a modern network, but it appears on the CCNA exam.

Timer Matching Requirement

Hello and Dead intervals must match between neighbors. If R1 has Hello=10 and R2 has Hello=5, they will not form an adjacency. R1 will receive Hellos from R2 every 5 seconds, which is fine — it would form a neighbor relationship. But R2 expects Hellos from R1 every 5 seconds. When R1 sends at 10-second intervals, R2’s Dead timer (which is based on its own configuration) may expire before R1 sends another Hello, causing R2 to declare R1 dead.

More precisely: the timer values are carried in the Hello packet and Cisco IOS checks that the received values match the local values before allowing the neighbor to progress past Init. A mismatch produces a log message and the neighbor stays in Init.

This is a common source of misconfigured neighbors and one of the first things to check when troubleshooting stuck adjacencies.

Configuring Timers

Timers are configured per-interface, not globally under the OSPF process:

interface GigabitEthernet0/0
 ip ospf hello-interval 5
 ip ospf dead-interval 20

When you set the Hello interval, the Dead interval does not automatically adjust. Set both explicitly if you change the Hello interval.

Fast Hello: Sub-Second Failure Detection

For networks requiring very fast convergence, OSPF supports sub-second Hello intervals using the dead-interval minimal feature:

interface GigabitEthernet0/0
 ip ospf dead-interval minimal hello-multiplier 4

This sets the Dead interval to 1 second and sends Hello packets every 250ms (1 second / 4 multiplier). The sub-second intervals create more CPU load and are typically used only on critical links where convergence speed justifies the overhead.

Verifying Timers

R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 10.0.12.1
  Backup Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:06
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)

Note the Timer intervals line: Hello 10, Dead 40, Wait 40, Retransmit 5. The Wait timer equals the Dead timer and is used during the DR/BDR election. Retransmit (5 seconds) controls how long a router waits before retransmitting an unacknowledged LSA.

Part 7: LSA Types

Link-State Advertisements are the data that OSPF routers exchange to build the LSDB. Each LSA describes some portion of the network topology. For CCNA and for single-area OSPF, you primarily need to understand Types 1 and 2. Types 3, 4, and 5 become relevant in multi-area configurations.

Type 1: Router LSA

Every OSPF router generates exactly one Type 1 LSA describing itself: the router’s links, their states, and their costs. The Router LSA includes each interface that is participating in OSPF, the IP addresses, the neighbor relationships, and the cost to reach each link. It is flooded throughout the originating router’s area and no further.

The Router LSA is the fundamental building block of the LSDB. When every router has every other router’s Type 1 LSA, the complete topology graph is present and SPF can run.

Type 1 LSAs are identified by the originating Router ID.

Type 2: Network LSA

On a multi-access segment where a DR has been elected, the DR generates a Type 2 Network LSA representing the segment. This LSA lists all the routers attached to the segment (from the DR’s perspective). It is generated by the DR using the segment’s IP address as the identifier and is flooded throughout the area.

Without the Type 2 LSA, the transit network (the multi-access segment itself) would not be represented in the topology graph. The combination of Type 1 LSAs from each router and the Type 2 LSA from the DR gives SPF the complete picture of who is on the segment and how the segment connects routers together.

On point-to-point links there is no DR, so no Type 2 LSA is generated for those segments.

Type 3: Summary LSA

Generated by Area Border Routers (ABRs) to advertise networks from one area into another area. A Type 3 LSA says “network X.X.X.X/Y is reachable through me with cost Z.” It carries inter-area route information without exposing the detailed topology of the originating area.

In single-area OSPF, there are no ABRs, and therefore no Type 3 LSAs. All routes in the OSPF domain are intra-area routes (code O in the routing table, not O IA).

Type 4: ASBR Summary LSA

Generated by ABRs to inform routers in other areas about the location of an ASBR (a router redistributing external routes into OSPF). A Type 4 LSA says “the ASBR with Router ID X is reachable through me with cost Y.” Routers in other areas need this to know how to reach the ASBR so they can compute the cost to external destinations.

Not relevant for single-area OSPF.

Type 5: External LSA

Generated by ASBRs to advertise routes redistributed into OSPF from another routing protocol or from static routes. Type 5 LSAs are flooded throughout the entire OSPF domain (all areas), not just within a single area. They appear in the routing table with the code O E2 (external type 2, the default) or O E1 (external type 1).

Type 5 LSAs are visible in single-area OSPF if you redistribute any external routes. You might see them if you redistribute a default route into OSPF to provide internet access to OSPF routers.

Type 7: NSSA External LSA

Used in Not-So-Stubby Areas (NSSAs), a multi-area concept outside the scope of this post. Type 7 LSAs are converted to Type 5 LSAs by the ABR when leaving the NSSA.

LSA Type Summary for CCNA

Type	Name	Generated By	Flooded To	CCNA Relevance
1	Router LSA	Every router	Within area	Core — always present
2	Network LSA	DR on multi-access	Within area	Core — present on Ethernet
3	Summary LSA	ABR	Into other areas	Multi-area only
4	ASBR Summary LSA	ABR	Into other areas	Multi-area only
5	External LSA	ASBR	Entire domain	When redistributing
7	NSSA External LSA	ASBR in NSSA	Within NSSA	Advanced multi-area

Part 8: OSPF Cost and the SPF Algorithm

Cost Formula

OSPF selects paths based on cost. Lower cost is better. The cost of a path is the sum of the costs of all outgoing interfaces along the path from source to destination. The cost of an interface is calculated as:

cost = reference_bandwidth / interface_bandwidth

The default reference bandwidth is 100 Mbps (100,000,000 bps). The result is always rounded up to a minimum of 1.

Interface Type	Bandwidth	Default Cost
Serial (T1)	1.544 Mbps	64
Ethernet	10 Mbps	10
Fast Ethernet	100 Mbps	1
GigabitEthernet	1000 Mbps	1
10GigabitEthernet	10,000 Mbps	1

Notice the problem: with a default reference bandwidth of 100 Mbps, every interface faster than 100 Mbps gets the same cost of 1. OSPF cannot distinguish between a 100 Mbps path and a 10 Gbps path. In a modern network where GigE and 10GigE are standard, this means OSPF may make poor path selection decisions.

Fixing the Reference Bandwidth

The solution is to increase the reference bandwidth to a value higher than your fastest link:

router ospf 1
 auto-cost reference-bandwidth 10000

The value is in Mbps, so 10000 = 10 Gbps. With this setting:

Interface Type	Bandwidth	Cost (ref=10000)
Ethernet	10 Mbps	1000
Fast Ethernet	100 Mbps	100
GigabitEthernet	1000 Mbps	10
10GigabitEthernet	10,000 Mbps	1
40GigabitEthernet	40,000 Mbps	1 (minimum)

For networks with 100 GigE links, set the reference bandwidth to 100000 (100 Gbps). The critical requirement is that this setting must be consistent across all OSPF routers in the domain. If R1 uses the default 100 Mbps reference and R2 uses 10000 Mbps, they will compute different costs for the same paths, potentially leading to asymmetric routing or suboptimal path selection.

IOS reminds you of this with a warning message when you change the reference bandwidth:

R1(config-router)# auto-cost reference-bandwidth 10000
% OSPF: Reference bandwidth is changed.
        Please ensure reference bandwidth is consistent across all routers.

Per-Interface Cost Override

You can manually set the cost on any individual interface:

interface GigabitEthernet0/0
 ip ospf cost 10

Manual cost overrides take precedence over the formula. This is useful for traffic engineering — forcing traffic to prefer one path over another — and for making OSPF consistent when interfaces have incorrect bandwidth values configured.

SPF Path Selection

When SPF runs, it builds a tree rooted at the local router where every destination is reached by the lowest-cost path. If two paths to the same destination have equal cost, OSPF installs both routes (Equal-Cost Multi-Path, ECMP) and load-balances traffic across them. Cisco IOS supports up to 32 ECMP paths for OSPF by default, though you can adjust this with maximum-paths under the OSPF process.

Part 9: OSPF Configuration

There are two approaches to telling OSPF which interfaces to include: the classic network statement under the OSPF process, and the modern per-interface command. Both are valid for CCNA. Modern IOS documentation and best practice increasingly favors the per-interface approach because it is more explicit and easier to audit.

Classic: Network Statement

router ospf 1
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.3 area 0
 network 10.0.13.0 0.0.0.3 area 0
 network 1.1.1.1 0.0.0.0 area 0

The network command takes an IP address and a wildcard mask (the bitwise inverse of a subnet mask) and matches any interface whose IP address falls within the specified range. A wildcard mask of 0.0.0.0 matches exactly one address; 0.0.0.255 matches any address in a /24 range; 255.255.255.255 matches all addresses.

Wildcard mask derivation: subtract the subnet mask from 255.255.255.255.

/30 subnet mask = 255.255.255.252 → wildcard = 0.0.0.3
/24 subnet mask = 255.255.255.0 → wildcard = 0.0.0.255
/32 subnet mask = 255.255.255.255 → wildcard = 0.0.0.0

The network statement network 0.0.0.0 255.255.255.255 area 0 matches all interfaces and enables OSPF everywhere. Use it carefully — it will also try to send Hellos on interfaces you may not want participating in OSPF. Use passive-interface (covered next) to suppress Hellos on those interfaces.

Modern: Per-Interface Command

interface GigabitEthernet0/0
 ip ospf 1 area 0

interface GigabitEthernet0/1
 ip ospf 1 area 0

interface Loopback0
 ip ospf 1 area 0

The ip ospf <process-id> area <area-id> command directly enables OSPF on the interface. It is more explicit than network statements — there is no wildcard matching, no ambiguity about which interfaces are participating. The OSPF process must still exist (router ospf 1) but no network statements are needed under it.

You can mix both approaches on the same router, though this is rarely necessary.

Passive Interfaces

A passive interface in OSPF means: advertise the network on this interface, but do not send or process Hello packets on it. Passive interfaces appear in the LSDB as connected networks, contributing to other routers’ routing tables, but no neighbor adjacency can form on them.

Use passive interfaces on:

LAN interfaces facing end hosts (workstations, servers) — no OSPF router is there, Hellos are wasted
Loopback interfaces (Cisco IOS treats loopbacks as passive by default when configured with network statements, though per-interface configuration may differ)
Any interface where you want to advertise the network but prevent adjacency formation

router ospf 1
 passive-interface GigabitEthernet0/2
 passive-interface GigabitEthernet0/3

For routers with many interfaces where most are LAN-facing and only a few connect to other OSPF routers, the inverse approach is cleaner:

router ospf 1
 passive-interface default
 no passive-interface GigabitEthernet0/0
 no passive-interface GigabitEthernet0/1

passive-interface default makes all interfaces passive. The no passive-interface commands then selectively enable Hello transmission only on the interfaces that connect to other OSPF routers.

Common mistake: Accidentally configuring passive-interface on an interface that connects to another OSPF router. That router will never receive Hellos and the neighbor relationship will never form. The symptom is a neighbor that is completely absent from show ip ospf neighbor — not stuck in a state, simply not present. The fix is to remove the passive-interface configuration.

Default Route Origination

To advertise a default route into OSPF (for internet access, for example), use:

router ospf 1
 default-information originate

This requires that a default route already exists in the routing table (static ip route 0.0.0.0 0.0.0.0 <next-hop>). To advertise a default route unconditionally regardless of whether one exists:

router ospf 1
 default-information originate always

The default route appears in other routers’ tables as O*E2 0.0.0.0/0.

Part 10: OSPF Verification Commands

This section presents each verification command with annotated output and explains what to look for.

show ip ospf neighbor

The most important OSPF verification command. Shows the state of all OSPF neighbor relationships.

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/BDR        00:00:32    10.0.12.2       GigabitEthernet0/0
3.3.3.3           1   FULL/DR         00:00:38    10.0.13.2       GigabitEthernet0/1

Field-by-field annotation:

Field	Meaning
Neighbor ID	The neighbor’s Router ID
Pri	Neighbor’s OSPF interface priority
State	Neighbor state / DR role on this segment
Dead Time	Countdown to declaring this neighbor dead; resets on each Hello
Address	Neighbor’s interface IP address
Interface	Local interface this neighbor is reached through

The State field shows two pieces of information separated by a slash. The left side is the adjacency state (FULL, 2WAY, EXSTART, EXCHANGE, LOADING). The right side is the DR role of the neighbor on this segment: DR, BDR, or DROTHER.

Common states you should be able to interpret:

State/Role	Meaning
`FULL/DR`	Fully adjacent; neighbor is the DR
`FULL/BDR`	Fully adjacent; neighbor is the BDR
`FULL/DROTHER`	Fully adjacent; neighbor is a DROther (only from DR/BDR perspective)
`2WAY/DROTHER`	Bidirectional, no full adjacency; neighbor is DROther (normal for DROther-DROther pairs)
`INIT/-`	One-way communication; they haven’t seen our Hello yet
`EXSTART/-`	Stuck in master/slave negotiation (check MTU mismatch)
`EXCHANGE/-`	Stuck in DBD exchange (check MTU mismatch)
`LOADING/-`	Stuck waiting for LSAs (check MTU mismatch)

The Dead Time countdown is useful for confirming the Dead interval. If it is configured as 40 seconds, the Dead Time should fluctuate between 0 and 40, resetting every 10 seconds when a Hello arrives.

show ip ospf neighbor detail

Provides complete information about each neighbor relationship.

R1# show ip ospf neighbor detail

 Neighbor 2.2.2.2, interface address 10.0.12.2
    In the area 0 via interface GigabitEthernet0/0
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 1.1.1.1 BDR is 2.2.2.2
    Options is 0x12 in Hello (E-bit, L-bit)
    Options is 0x52 in DBD  (E-bit, L-bit, O-bit)
    Dead timer due in 00:00:38
    Neighbor is up for 00:15:42
    Index 1/1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Key fields: In the area 0 confirms both routers agree on area membership. DR is 1.1.1.1 BDR is 2.2.2.2 shows the current DR and BDR as seen by this router. Neighbor is up for 00:15:42 shows adjacency stability — a neighbor that has been up for only a few minutes may indicate a recent flap.

show ip ospf interface GigabitEthernet0/0

Detailed OSPF information for a specific interface.

R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0, Attached via Interface Enable
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 10.0.12.1
  Backup Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:03
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)

Key fields to note:

Cost: 1 — the interface cost used in SPF calculations
Network Type BROADCAST — confirms DR/BDR election is active
State DR — this router is the DR on this segment
Designated Router (ID) 1.1.1.1, Interface address 10.0.12.1 — DR is this router, R1
Timer intervals configured, Hello 10, Dead 40 — timer verification
Neighbor Count is 1, Adjacent neighbor count is 1 — one neighbor, one full adjacency

If the Neighbor Count and Adjacent neighbor count differ, that is a sign that some neighbors are not reaching Full state. On a segment with a DR/BDR, DROther-to-DROther pairs will show in Neighbor Count but not in Adjacent neighbor count (from a DROther’s perspective, only 2 neighbors — the DR and BDR — are Adjacent).

show ip ospf interface brief

Quick summary across all OSPF interfaces.

R1# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Gi0/0        1     0               10.0.12.1/30       1     DR    1/1
Gi0/1        1     0               10.0.13.1/30       1     DR    1/1
Lo0          1     0               1.1.1.1/32         1     LOOP  0/0

The Nbrs F/C column shows neighbors Full/Count — how many neighbors are in Full state versus the total number of OSPF neighbors detected. The loopback shows LOOP for State, which is the normal network type for loopback interfaces (they behave as stub networks, not participating in DR/BDR election).

show ip ospf

Shows OSPF process information, statistics, and area summary.

R1# show ip ospf
 Routing Process "ospf 1" with ID 1.1.1.1
 Start time: 00:15:00.000, Time elapsed: 00:22:18.540
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Supports NSSA (compatible with RFC 3101)
 Supports Database Exchange Summary List Optimization (RFC 5243)
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 3 (1 loopback)
        Area has no authentication
        SPF algorithm last executed 00:18:42.345 ago
        SPF algorithm executed 4 times
        Area ranges are
        Number of LSA 5. Checksum Sum 0x021B2A
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

Key fields: Reference bandwidth unit is 100 mbps (change this if you have GigE or faster links), SPF algorithm executed 4 times (high counts indicate network instability — frequent topology changes), Number of LSA 5 (expected: 3 Type 1 LSAs + 2 Type 2 LSAs for a 3-router topology with 2 multi-access segments).

show ip ospf database

Summary of the LSDB.

R1# show ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1023        0x80000005 0x00B4D2 4
2.2.2.2         2.2.2.2         1021        0x80000005 0x00A1C3 4
3.3.3.3         3.3.3.3         1019        0x80000004 0x009DE1 4

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.12.1       1.1.1.1         1023        0x80000002 0x00D4B1
10.0.13.1       1.1.1.1         1023        0x80000002 0x00C8A2

The Router Link States (Type 1) list shows one entry per router — Link ID is the Router ID of the originator, ADV Router is the same (a router always originates its own Type 1 LSA). The Net Link States (Type 2) show entries generated by the DR on each multi-access segment — Link ID is the DR’s interface IP, ADV Router is the DR’s Router ID.

Age is in seconds from 0 (fresh) to 3600 (MaxAge — the LSA will be purged and re-originated). Seq# increases with each re-origination. If you see LSAs with very high Ages but no corresponding refresh, that can indicate a problem with LSA flooding.

show ip ospf database router

Detail for Type 1 Router LSAs.

R1# show ip ospf database router

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 1091
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000005
  Checksum: 0xB4D2
  Length: 84
  Number of Links: 4

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.12.1
     (Link Data) Router Interface address: 10.0.12.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.13.1
     (Link Data) Router Interface address: 10.0.13.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

Each “Link connected to” entry describes one interface in the LSA. “Transit Network” means the interface connects to a multi-access segment with a DR; “Stub Network” means a loopback or a network with no OSPF neighbor. The Metrics value is the cost of that interface.

show ip route ospf

Shows only OSPF-learned routes in the routing table.

R1# show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2

      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2] via 10.0.12.2, 00:18:41, GigabitEthernet0/0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2] via 10.0.13.2, 00:18:41, GigabitEthernet0/1
      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O        10.0.23.0/30 [110/2] via 10.0.12.2, 00:18:41, GigabitEthernet0/0
                      [110/2] via 10.0.13.2, 00:18:41, GigabitEthernet0/1

Route code breakdown:

O — intra-area OSPF route (same area)
O IA — inter-area OSPF route (from another area via an ABR — not seen in single-area)
O E1 — external type 1 (cost includes internal OSPF cost to ASBR)
O E2 — external type 2 (cost is only the redistributed metric — default for redistributed routes)

The [110/2] notation: 110 is the administrative distance for OSPF (lower AD wins when multiple protocols advertise the same prefix), and 2 is the OSPF cost. For R1 reaching 2.2.2.2/32, the cost of 2 = cost of Gi0/0 (cost 1) + the loopback cost on R2 (cost 1 for the /32 stub link in R2’s Type 1 LSA).

clear ip ospf process

Forces OSPF to restart: drops all adjacencies, clears the LSDB, re-runs DR/BDR election, and re-establishes all neighbor relationships from scratch.

R1# clear ip ospf process
Reset ALL OSPF processes? [no]: yes

This is disruptive — all OSPF routes disappear from the routing table momentarily, causing packet loss. Use it in production only when necessary (after a configuration change that requires a new Router ID, or to force re-election after changing DR priority). In a lab environment, it is useful to force a fresh start when troubleshooting.

Debug Commands

For adjacency troubleshooting in a lab, debug commands show the OSPF state machine in real time.

R1# debug ip ospf events
OSPF: hello with invalid timers on interface GigabitEthernet0/0
  hello interval received 5 configured 10
  dead interval received 20 configured 40

This debug output reveals a timer mismatch immediately — you can see both the received value and the configured value.

R1# debug ip ospf adj
OSPF: 2 Way Communication to 2.2.2.2 on GigabitEthernet0/0, state 2WAY
OSPF: Backup Designated Router election on GigabitEthernet0/0
OSPF: Elect BDR 2.2.2.2
OSPF: Elect DR 1.1.1.1
OSPF: Neighbor change Event on interface GigabitEthernet0/0
OSPF: DR/BDR election and full neighbor list
OSPF: 2.2.2.2 address 10.0.12.2 on GigabitEthernet0/0 is now designated router

Always disable debug when done:

R1# undebug all

Debug in production is dangerous on high-traffic routers — the volume of output can consume all CPU.

Part 11: Complete Lab — Three Routers, Single Area 0

This lab demonstrates a complete single-area OSPF configuration on three routers connected in a full mesh, with loopback interfaces on each. You will configure OSPF, verify adjacencies, observe the routing table, and trace the cost calculations.

Topology

         Lo0: 1.1.1.1/32                 Lo0: 2.2.2.2/32
              |                                |
    Gi0/0     |     Gi0/0                      |
 +-----------R1-----------+         +----------R2-----------+
 |        10.0.12.1/30    |         |    10.0.12.2/30       |
 |                        +---------+                       |
 |                       10.0.12.0/30                       |
 |                                                           |
 |  Gi0/1              10.0.13.0/30              Gi0/1      |
 |  10.0.13.1/30               +-----------10.0.23.1/30     |
 +----------+                  |                   +--------+
            |                  |                   |
            |            R3----+               R3  |
            +----------->10.0.13.2/30<----------+  |
                    10.0.23.0/30: 10.0.23.2/30------+
                              Lo0: 3.3.3.3/32

Cleaner ASCII representation:

     1.1.1.1/32                                2.2.2.2/32
     [Lo0: R1]                                 [Lo0: R2]
          |                                         |
     Gi0/0: 10.0.12.1/30 ---[10.0.12.0/30]--- Gi0/0: 10.0.12.2/30
          |                                         |
     Gi0/1: 10.0.13.1/30                      Gi0/1: 10.0.23.1/30
          |                                         |
          +-------[10.0.13.0/30]---+   +----[10.0.23.0/30]-----+
                                   |   |
                              Gi0/0: 10.0.13.2/30
                              Gi0/1: 10.0.23.2/30
                                   |
                              [Lo0: R3]
                              3.3.3.3/32

Interface Summary

Router	Interface	IP Address	Connected To
R1	Loopback0	1.1.1.1/32	—
R1	GigabitEthernet0/0	10.0.12.1/30	R2 Gi0/0
R1	GigabitEthernet0/1	10.0.13.1/30	R3 Gi0/0
R2	Loopback0	2.2.2.2/32	—
R2	GigabitEthernet0/0	10.0.12.2/30	R1 Gi0/0
R2	GigabitEthernet0/1	10.0.23.1/30	R3 Gi0/1
R3	Loopback0	3.3.3.3/32	—
R3	GigabitEthernet0/0	10.0.13.2/30	R1 Gi0/1
R3	GigabitEthernet0/1	10.0.23.2/30	R2 Gi0/1

R1 Configuration

! Base interface configuration
interface Loopback0
 ip address 1.1.1.1 255.255.255.255

interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 no shutdown

interface GigabitEthernet0/1
 ip address 10.0.13.1 255.255.255.252
 no shutdown

! OSPF configuration
router ospf 1
 router-id 1.1.1.1
 auto-cost reference-bandwidth 10000
 ! Per-interface method:
 ! (configured on each interface below)

interface Loopback0
 ip ospf 1 area 0

interface GigabitEthernet0/0
 ip ospf 1 area 0

interface GigabitEthernet0/1
 ip ospf 1 area 0

R2 Configuration

interface Loopback0
 ip address 2.2.2.2 255.255.255.255

interface GigabitEthernet0/0
 ip address 10.0.12.2 255.255.255.252
 no shutdown

interface GigabitEthernet0/1
 ip address 10.0.23.1 255.255.255.252
 no shutdown

router ospf 1
 router-id 2.2.2.2
 auto-cost reference-bandwidth 10000

interface Loopback0
 ip ospf 1 area 0

interface GigabitEthernet0/0
 ip ospf 1 area 0

interface GigabitEthernet0/1
 ip ospf 1 area 0

R3 Configuration

interface Loopback0
 ip address 3.3.3.3 255.255.255.255

interface GigabitEthernet0/0
 ip address 10.0.13.2 255.255.255.252
 no shutdown

interface GigabitEthernet0/1
 ip address 10.0.23.2 255.255.255.252
 no shutdown

router ospf 1
 router-id 3.3.3.3
 auto-cost reference-bandwidth 10000

interface Loopback0
 ip ospf 1 area 0

interface GigabitEthernet0/0
 ip ospf 1 area 0

interface GigabitEthernet0/1
 ip ospf 1 area 0

Verification: show ip ospf neighbor

With auto-cost reference-bandwidth 10000, GigabitEthernet interfaces have cost 10. Point-to-point /30 links between exactly two routers: in this topology, each /30 connects exactly two routers. R1’s Gi0/0 connects only to R2 — it is effectively a point-to-point link, but since it is Ethernet the network type defaults to BROADCAST and a DR/BDR election will occur. With only two routers on each /30 segment, one will be DR and the other BDR.

On the 10.0.12.0/30 segment: R1 (RID 1.1.1.1) and R2 (RID 2.2.2.2), both priority 1 — R2 wins DR (higher RID), R1 is BDR. On the 10.0.13.0/30 segment: R1 (RID 1.1.1.1) and R3 (RID 3.3.3.3) — R3 wins DR, R1 is BDR. On the 10.0.23.0/30 segment: R2 (RID 2.2.2.2) and R3 (RID 3.3.3.3) — R3 wins DR, R2 is BDR.

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:37    10.0.12.2       GigabitEthernet0/0
3.3.3.3           1   FULL/DR         00:00:34    10.0.13.2       GigabitEthernet0/1

R1 sees R2 as DR on Gi0/0 (R2’s RID 2.2.2.2 > R1’s 1.1.1.1). R1 sees R3 as DR on Gi0/1 (R3’s RID 3.3.3.3 > R1’s 1.1.1.1). Both neighbors are in FULL state.

R2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:39    10.0.12.1       GigabitEthernet0/0
3.3.3.3           1   FULL/DR         00:00:35    10.0.23.2       GigabitEthernet0/1

R2 sees R1 as BDR on Gi0/0 (from R2’s perspective, R2 is DR). R2 sees R3 as DR on Gi0/1.

R3# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:36    10.0.13.1       GigabitEthernet0/0
2.2.2.2           1   FULL/BDR        00:00:33    10.0.23.1       GigabitEthernet0/1

R3 is DR on both its segments (highest RID). It sees R1 as BDR on Gi0/0 and R2 as BDR on Gi0/1.

Verification: show ip route ospf

R1# show ip route ospf
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/11] via 10.0.12.2, 00:22:15, GigabitEthernet0/0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/11] via 10.0.13.2, 00:22:15, GigabitEthernet0/1
      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O        10.0.23.0/30 [110/20] via 10.0.12.2, 00:22:15, GigabitEthernet0/0
                      [110/20] via 10.0.13.2, 00:22:15, GigabitEthernet0/1

Cost analysis with reference-bandwidth 10000 (GigabitEthernet cost = 10):

R1 to 2.2.2.2/32: exit Gi0/0 (cost 10) + R2’s loopback stub link (cost 1 per R2’s Type 1 LSA) = 11 ✓
R1 to 3.3.3.3/32: exit Gi0/1 (cost 10) + R3’s loopback stub (cost 1) = 11 ✓
R1 to 10.0.23.0/30: two paths both cost 20
- Path via R2: exit Gi0/0 (10) + R2’s Gi0/1 to 10.0.23.0/30 (10) = 20 ✓
- Path via R3: exit Gi0/1 (10) + R3’s Gi0/0 leads to 10.0.13.0/30 (already there) — actually exit Gi0/1 (10) + R3’s Gi0/1 which is on 10.0.23.0/30 (cost 10) = 20 ✓
- Both paths are equal cost — ECMP, both installed

Connectivity Verification

R1# ping 2.2.2.2 source Loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

R1# ping 3.3.3.3 source Loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

R1# ping 3.3.3.3 source 2.2.2.2
% Note: sending from 2.2.2.2 requires pinging from R2...

R2# ping 3.3.3.3 source Loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

Always ping from a loopback to a loopback (source Loopback0) to test full end-to-end reachability. Pinging without a source address uses the outgoing interface IP, which is always reachable via the direct connected route and does not test OSPF routing.

Part 12: OSPF Troubleshooting

The neighbor state machine is your primary diagnostic tool. The state you see in show ip ospf neighbor — or the absence of a neighbor entirely — points directly to the category of problem.

Neighbor Not Present at All

If a router is completely absent from show ip ospf neighbor:

Is OSPF enabled on both interfaces? Check show ip ospf interface brief on both routers to confirm both interfaces are participating in OSPF.
Is the interface up? OSPF only sends Hellos on interfaces that are up/up. Check show interfaces <int>.
Is one interface passive? A passive-interface will not send Hellos. An absent neighbor on an interface where you expect one is a common symptom of accidental passive-interface configuration.
Is there Layer 2/3 connectivity? If the two routers can’t ping each other, OSPF won’t work either. Verify IP addressing and the physical connection.
Access list blocking multicast? An inbound ACL blocking 224.0.0.5 will drop all Hello packets. Check show ip interface <int> for applied ACLs.

Neighbor Stuck in Init

Only the problematic router can see the other’s Hellos, but the other cannot see ours. This is almost always a unidirectional Layer 2 issue — cable problem, duplex mismatch, or access list blocking traffic in one direction. Both routers will typically show the other as Init from their respective perspectives if the connectivity issue is intermittent.

Neighbor Stuck in 2-Way (Unexpected)

Expected 2-Way: DROther-to-DROther on a multi-access segment. This is normal.

Unexpected 2-Way: Two routers that should be forming a full adjacency but are not. This usually means they agreed to 2-Way but the criteria for forming a full adjacency were not met. Check that the OSPF network type is the same on both sides — mismatched network types (one side broadcast, one side point-to-point) can cause this.

Timer Mismatch

Symptoms: neighbor stays in Init, or constantly oscillates. Debug output shows:

OSPF: hello with invalid timers on interface GigabitEthernet0/0
  hello interval received 5 configured 10
  dead interval received 20 configured 40

Fix: make Hello and Dead intervals match on both sides.

Area ID Mismatch

A Hello received with a different Area ID is silently dropped. No neighbor entry is created. The symptom is identical to the interface not being configured for OSPF at all. Verify with show ip ospf interface brief on both sides and confirm the area IDs match.

Subnet Mask Mismatch

If R1 has 10.0.12.1/30 and R2 has 10.0.12.2/29 (same IP range, different mask), OSPF will log an error and refuse to form the neighbor relationship:

%OSPF-4-NET_ERROR: Mismatched subnet on GigabitEthernet0/0 from 10.0.12.2, 
  network 10.0.12.0 mask 255.255.255.248

Fix: correct the IP addressing so both routers are on the same subnet with the same mask.

MTU Mismatch (Stuck in Exchange or Loading)

The MTU mismatch is subtle. OSPF checks that the MTU value in DBD packets matches the local interface MTU. If there is a mismatch (common when one interface has a custom MTU configured), the DBD exchange will fail and the neighbor will be stuck in EXSTART or EXCHANGE.

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   EXSTART/DR      00:00:38    10.0.12.2       GigabitEthernet0/0

Diagnosis: show interfaces GigabitEthernet0/0 on both sides — check the MTU field. Fix the mismatch, or use ip ospf mtu-ignore on the interface to suppress the check (not recommended in production, but useful in labs where you can’t change MTU):

interface GigabitEthernet0/0
 ip ospf mtu-ignore

Duplicate Router ID

When two routers have the same Router ID, OSPF will log warnings and behave unpredictably. Routes may flap as LSAs with the same originator ID overwrite each other. The topology seen from any router will be incorrect.

%OSPF-4-DUP_RTRID_NBR: Detected duplicate router-id 1.1.1.1 from 10.0.12.2 on interface GigabitEthernet0/0

Fix: ensure all router IDs are unique. Check with show ip ospf on each router to see the Router ID. Explicitly configure router IDs with router-id under the OSPF process.

Authentication Mismatch

With OSPF authentication enabled, Hellos from routers with incorrect or no authentication are dropped. The symptom is identical to no Hello being received — neighbor completely absent from the table. Check authentication configuration on both sides and ensure key IDs and passwords match.

Passive Interface Blocking Adjacency

Accidentally configuring passive-interface default and forgetting to add no passive-interface on the router-facing interfaces is a very common exam scenario and real-world mistake. The symptom is complete absence of the neighbor from show ip ospf neighbor. Verify with:

R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  ...
  No Hellos (Passive interface)

The “No Hellos (Passive interface)” line immediately identifies the problem.

Troubleshooting Flowchart

Neighbor missing from show ip ospf neighbor?
  |
  +---> Is OSPF enabled on the interface? (show ip ospf interface brief)
  |       NO --> Add 'ip ospf 1 area 0' to the interface
  |
  +---> Is the interface up/up? (show interfaces)
  |       NO --> Fix Layer 1/2 issue
  |
  +---> Is the interface passive? (show ip ospf interface -- "No Hellos")
  |       YES --> Remove passive-interface or add 'no passive-interface'
  |
  +---> Can you ping the neighbor's IP? 
          NO --> Fix IP addressing / Layer 3 connectivity

Neighbor present but in Init?
  --> Layer 2 unidirectional issue, or ACL blocking inbound Hellos

Neighbor present but in 2-Way (unexpected)?
  --> Network type mismatch between the two sides

Neighbor present but in EXSTART/EXCHANGE?
  --> MTU mismatch -- check 'show interfaces' MTU field on both sides

Neighbor present but in LOADING?
  --> MTU mismatch or corrupted LSA -- clear ip ospf process

Timer mismatch messages in log?
  --> Align Hello/Dead intervals on both interfaces

Area ID mismatch in log?
  --> Correct area configuration on one or both interfaces

Duplicate router ID in log?
  --> Assign unique router IDs with 'router-id' command

Part 13: OSPF Authentication

Why Authentication Matters

Without authentication, any router that is physically connected to your network and running OSPF can inject arbitrary LSAs. A rogue router could advertise more-specific routes to pull traffic toward itself (a man-in-the-middle attack), advertise unreachable destinations to black-hole traffic (a denial of service attack), or corrupt the LSDB with incorrect topology information causing routing loops. Authentication ensures that only authorized routers can participate in OSPF.

For the CCNA exam, understand that authentication is configured per-interface and that both sides must use the same authentication type, key ID, and key (password).

Plain Text Authentication (Not Recommended)

Simple plain-text authentication sends the password in clear text in OSPF packets. It provides only a basic sanity check against misconfiguration — any packet capture will reveal the password. Do not use plain text in production.

interface GigabitEthernet0/0
 ip ospf authentication
 ip ospf authentication-key MyPassword

MD5 Authentication

MD5 authentication computes a cryptographic hash of the OSPF packet contents using the shared key and includes the hash in the packet. The receiving router recomputes the hash with its own key and compares. If the hashes do not match, the packet is dropped. The key itself is never transmitted.

Each key has a key ID (1-255). The key ID must match between neighbors. Multiple keys can be configured on an interface simultaneously, allowing key rotation without disrupting adjacencies (configure the new key on all routers first, then remove the old key).

Configuration — both routers must match:

! R1
interface GigabitEthernet0/0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 MySharedSecret

! R2
interface GigabitEthernet0/0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 MySharedSecret

The key ID (1 in this example) must be identical on both routers. The password string (MySharedSecret) must be identical. If either differs, the neighbor will not form.

Verification:

R1# show ip ospf interface GigabitEthernet0/0
...
  Message digest authentication enabled
    Youngest key id is 1

Authentication mismatch symptoms:

%OSPF-4-BAD_AUTH: Bad authentication

This log message appears when a Hello packet arrives but authentication verification fails. The neighbor will not appear in show ip ospf neighbor.

Process-Level Authentication

You can enable authentication for all interfaces in an area from the OSPF process, rather than configuring it per-interface:

router ospf 1
 area 0 authentication message-digest

This still requires the key to be configured on each interface (ip ospf message-digest-key), but it enables MD5 authentication for all interfaces in Area 0 without needing ip ospf authentication message-digest on each one individually.

SHA Authentication (OSPFv3 / Modern IOS)

MD5 is considered cryptographically weak by modern standards. OSPFv3 (used with IPv6) uses IPsec for authentication, supporting SHA-1 and SHA-256. Some modern IOS versions support SHA-based OSPF authentication via the key chain mechanism:

key chain OSPF-KEYS
 key 1
  key-string MySharedSecret
  cryptographic-algorithm hmac-sha-256

interface GigabitEthernet0/0
 ip ospf authentication key-chain OSPF-KEYS

This provides stronger security than MD5 while maintaining the same operational model. For CCNA, MD5 is the expected authentication mechanism. Understanding SHA variants demonstrates awareness of current best practices.

Quick Reference: OSPF Defaults and Key Values

Parameter	Default Value	Configuration Command
Process ID	—	`router ospf <1-65535>`
Router ID selection	Highest loopback, then highest interface	`router-id <x.x.x.x>`
Reference bandwidth	100 Mbps	`auto-cost reference-bandwidth <Mbps>`
Hello interval (broadcast)	10 seconds	`ip ospf hello-interval <seconds>`
Dead interval (broadcast)	40 seconds	`ip ospf dead-interval <seconds>`
Hello interval (NBMA)	30 seconds	`ip ospf hello-interval <seconds>`
Dead interval (NBMA)	120 seconds	`ip ospf dead-interval <seconds>`
OSPF interface priority	1	`ip ospf priority <0-255>`
Administrative distance	110	`distance ospf external <val> inter-area <val> intra-area <val>`
Maximum ECMP paths	4 (platform dependent)	`maximum-paths <1-32>` under `router ospf`
AllSPFRouters multicast	224.0.0.5	—
AllDRRouters multicast	224.0.0.6	—
IP protocol number	89	—
Network type (GigE)	Broadcast	`ip ospf network <type>`
Network type (Serial PPP)	Point-to-point	`ip ospf network point-to-point`
Authentication	None	`ip ospf authentication [message-digest]`

Quick Reference: Troubleshooting by Symptom

Symptom	Most Likely Cause	Verification Command
Neighbor absent	Not OSPF-enabled, passive, L2 down	`show ip ospf interface brief`
Neighbor in Init	Unidirectional Hello — they see us, we don’t see them	`debug ip ospf events`
Neighbor in 2-Way (unexpected)	Network type mismatch	`show ip ospf interface <int>`
Neighbor in EXSTART/EXCHANGE	MTU mismatch	`show interfaces <int>`
Neighbor in LOADING	MTU mismatch or LSA corruption	`show interfaces`, `clear ip ospf process`
Neighbor flaps constantly	Hello/Dead timer mismatch or L2 instability	`show ip ospf interface`, check timers
No OSPF routes in table	OSPF not redistributing, wrong area, all passive	`show ip ospf`, `show ip route`
Wrong path selected	Reference bandwidth mismatch, incorrect cost	`show ip ospf interface`, `show ip route ospf`
Neighbor never becomes DR	Non-preemptive election, priority 0	`show ip ospf interface`, `clear ip ospf process`
Authentication failure	Key ID or password mismatch	`show ip ospf interface`, check logs

Putting It Together: The OSPF Mental Model

Walk through what happens when you bring up this three-router topology from scratch, in order:

Interfaces come up. Each router detects its OSPF-enabled interfaces and begins sending Hello packets to 224.0.0.5 every 10 seconds.
R1 receives a Hello from R2 on Gi0/0. R1’s RID is not in R2’s Neighbor List. R1 records R2 as a neighbor in Init state.
R1 sends a Hello that includes R2’s RID in the Neighbor List. R2 receives this Hello, sees its own RID listed, and moves to 2-Way state. Simultaneously, R2’s Hello listing R1’s RID causes R1 to also move to 2-Way.
At 2-Way, the Wait Timer runs. After it expires, DR/BDR election occurs. On the 10.0.12.0/30 segment, R2 (RID 2.2.2.2) wins DR, R1 (RID 1.1.1.1) becomes BDR. (If there were more routers, DROthers would stay at 2-Way here.)
Since this is a two-router segment, both routers will form a full adjacency. They proceed to Exstart: both send empty DBD packets with their RIDs. R2 (higher RID) becomes Master, R1 becomes Slave.
Exchange: R2 (Master) sends numbered DBD packets describing its LSDB. R1 acknowledges each and sends its own DBDs. After exchange, both know what LSAs they have and what they are missing.
Loading: R1 sends LSR for R2’s Type 1 LSA and any Type 2 LSAs it is missing. R2 responds with LSU containing those LSAs. R1 sends LSAck. The process runs in both directions.
Full: Both routers have synchronized LSDBs. SPF runs. Routes are installed. The adjacency is maintained with Hello keepalives.
This same process repeats for R1-R3 on 10.0.13.0/30 and R2-R3 on 10.0.23.0/30.
Once all three adjacencies are Full, every router has six entries in the LSDB: three Type 1 Router LSAs (one per router) and three Type 2 Network LSAs (one per segment, each generated by the DR on that segment). SPF produces a complete routing table with paths to all loopbacks and all transit segments.

That sequence — from interface up to Full adjacency to populated routing table — is the OSPF process in its entirety. Every verification command, every troubleshooting scenario, and every exam question about OSPF maps back to some part of that sequence.

Mastering OSPF at the CCNA level is not about memorizing the seven states as a list. It is about understanding the state machine as a logical progression from “no communication” to “synchronized topology databases.” Once you have that model in your head, the states are obvious, the troubleshooting commands make sense, and the configurations follow naturally. Build this topology in a lab — GNS3, Packet Tracer, or physical hardware — and run through the verification commands until the output is as readable to you as plain English. That is the level of fluency that makes both the exam and production troubleshooting straightforward.