Exam Objective 3.3: Configure single area OSPFv2 for IPv4 and OSPFv3 for IPv6.
3.3.a Neighbor adjacencies (excluding authentication)
3.3.b Point-to-point
3.3.c Broadcast (DR/BDR selection)
3.3.d Router ID
OSPF is the dynamic routing protocol most heavily tested on the CCNA, and single-area OSPF is the foundation everything else builds on. This objective covers how OSPF routers actually find each other and form adjacencies, how that process differs depending on the network type (point-to-point versus broadcast), the special DR/BDR election that only happens on broadcast segments, and how a router identifies itself to the rest of the OSPF domain via its Router ID. Both the IPv4 version (OSPFv2) and the IPv6 version (OSPFv3) are in scope.
OSPF (Open Shortest Path First) is a link-state, classless, interior gateway routing protocol that builds a complete map (a link-state database) of the network topology within its area, then independently calculates the shortest path to every destination using the Dijkstra Shortest Path First (SPF) algorithm. Unlike distance-vector protocols that only know what their neighbors tell them, every OSPF router within an area has an identical view of that area's entire topology.
Key OSPF characteristics:
Administrative distance: 110 (OSPFv2 for IPv4); OSPFv3 for IPv6 also uses AD 110
Metric: cost, calculated from cumulative interface bandwidth along the path (lower cost = better path)
Uses multicast for neighbor discovery and updates: 224.0.0.5 (All OSPF Routers) and 224.0.0.6 (All DR/BDR Routers) for OSPFv2; the IPv6 equivalents FF02::5 and FF02::6 for OSPFv3
Single-area OSPF (the exam's focus) means the entire OSPF domain is configured as one area, typically Area 0 (the backbone area) — multi-area design and inter-area route summarization are out of scope for this objective
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
router ospf [process-id] — enables OSPF and assigns a locally significant process ID (this number only matters on the local router and does not need to match between neighboring routers, unlike area numbers which absolutely must match).
network [address] [wildcard-mask] area [area-id] — identifies which locally connected interfaces should participate in OSPF, based on matching the interface's IP address against the network statement's address and wildcard mask. Any interface whose IP address falls within the specified range is enabled for OSPF and placed into the specified area.
Wildcard masks — the inverse of a subnet mask: OSPF network statements use wildcard masks rather than standard subnet masks. A wildcard mask is calculated by subtracting each octet of the subnet mask from 255. For example, a /24 network (255.255.255.0) becomes wildcard mask 0.0.0.255; a /30 network (255.255.255.252) becomes wildcard mask 0.0.0.3.
Alternative interface-level configuration:
interface GigabitEthernet0/1
ip ospf 1 area 0
This applies OSPF directly to a specific interface instead of using a network statement, specifying the process ID and area right on the interface — increasingly the more explicit and commonly recommended method on modern IOS, since it avoids any ambiguity about exactly which interfaces are included.
ipv6 unicast-routing
ipv6 router ospf 1
router-id 1.1.1.1
interface GigabitEthernet0/1
ipv6 ospf 1 area 0
Key difference from OSPFv2: OSPFv3 does not use network statements at all — OSPF is enabled directly and exclusively at the interface level with the ipv6 ospf [process-id] area [area-id] command. This is a deliberate and frequently tested distinction: OSPFv2 can use either network statements or interface-level configuration, but OSPFv3 only supports the interface-level method.
ipv6 unicast-routing must be enabled globally first (as covered in objective 3.2) before OSPFv3 will function at all.
Exam Alert: Memorize that OSPFv3 has no network command — OSPF for IPv6 is always enabled directly on each participating interface. This is one of the most reliably tested OSPFv2-vs-OSPFv3 configuration differences.
The Router ID (RID) is a 32-bit number, formatted like an IPv4 address, that uniquely identifies each router within the OSPF domain. It is used in the link-state database and in DR/BDR election (covered below), and every router in the same OSPF process must have a unique Router ID.
Router ID selection order (highest priority first):
Manually configured Router ID — using the router-id [id] command directly under the OSPF process; this always takes precedence over any automatic selection method and is the recommended best practice for predictability
Highest IP address among configured loopback interfaces — if no Router ID is manually set, OSPF prefers loopback interfaces specifically over physical interfaces, since loopbacks are always up (never physically down) and therefore provide a more stable Router ID
Highest IP address among active physical interfaces — used only if no loopback interfaces exist and no Router ID was manually configured
Manual Router ID configuration (OSPFv2):
router ospf 1
router-id 1.1.1.1
Manual Router ID configuration (OSPFv3):
ipv6 router ospf 1
router-id 1.1.1.1
Why manual Router ID matters for IPv6 specifically: Since OSPFv3 runs over IPv6, and IPv6 interfaces are not required to have an IPv4 address at all, a router running OSPFv3 with no IPv4 addresses configured anywhere has no automatic source for a properly formatted Router ID — manually configuring router-id becomes effectively mandatory in an IPv6-only environment, rather than just a best practice.
Changing the Router ID after OSPF is already running: Simply typing a new router-id command does not immediately take effect on an already-running OSPF process — the change is only picked up after the OSPF process is restarted, using clear ip ospf process (OSPFv2) or by reloading/manually restarting the process for OSPFv3.
Exam Alert: Know the three-tier selection order (manual > highest loopback IP > highest physical interface IP), and remember that a Router ID change requires clearing/restarting the OSPF process to actually take effect — this is a commonly tested "gotcha," since configuring a new router-id and immediately checking show ip ospf will often still show the old value.
Before two OSPF routers can exchange routing information, they must first discover each other and progress through a defined sequence of neighbor states, ultimately reaching a full adjacency.
How neighbors are discovered: OSPF routers send Hello packets out every OSPF-enabled interface via multicast (224.0.0.5 for OSPFv2), advertising their own Router ID and key parameters. A neighboring router receiving a compatible Hello packet begins the adjacency-formation process.
Neighbor state progression (simplified):
Down — no Hello packets received yet from this potential neighbor
Init — a Hello packet has been received, but it doesn't yet list this router's own Router ID, meaning bidirectional communication hasn't been confirmed
2-Way — the neighbor's Hello packet now lists this router's own Router ID, confirming bidirectional communication; on a broadcast network, DR/BDR election occurs at this stage
ExStart / Exchange — routers begin exchanging database description (DBD) packets, describing the contents of their respective link-state databases
Loading — routers request any link-state advertisements (LSAs) they're missing from their neighbor's database
Full — the routers have fully synchronized link-state databases and are considered fully adjacent
Conditions that must match for two OSPF routers to become neighbors at all:
Same area ID on the connecting interfaces
Same subnet (the interfaces must actually share the same IP subnet, matching mask)
Same Hello and Dead timer intervals (Hello default 10 seconds on broadcast/point-to-point networks, Dead timer default 40 seconds — four times the Hello interval)
Matching authentication configuration, if authentication is enabled (excluded from this specific exam objective, but still a real-world requirement)
No duplicate Router IDs between the two routers
Matching OSPF network type on both ends of the link (point-to-point matching point-to-point, broadcast matching broadcast — a mismatch here prevents adjacency from forming correctly)
Exam Alert: A mismatched Hello/Dead timer, a mismatched area ID, or a subnet mismatch between two directly connected interfaces are the most commonly tested reasons neighbors get "stuck" in the Init or 2-Way state and never reach Full.
A point-to-point OSPF network type is used on links that connect exactly two routers directly, most commonly serial WAN links or dedicated point-to-point Ethernet connections (such as a routed interface used specifically as a single link between two routers).
Key characteristics of point-to-point OSPF networks:
No DR/BDR election occurs at all — since there are only ever two routers on the segment, there's no need to elect a designated router to reduce adjacency overhead
Hello packets are sent every 10 seconds by default, with a Dead interval of 40 seconds
OSPF Hellos and updates are sent to the multicast address 224.0.0.5 (All OSPF Routers)
Adjacency forms directly and simply between the two routers, without the extra 2-Way/DR-election complexity seen on broadcast networks
Manually setting the network type to point-to-point:
interface Serial0/0/0
ip ospf network point-to-point
This is sometimes done deliberately even on an Ethernet link that only ever connects two routers, specifically to skip DR/BDR election and its associated overhead — a legitimate design choice covered under this exam objective.
A broadcast OSPF network type is the default on Ethernet-type interfaces, used on multi-access segments where potentially more than two OSPF routers could be present on the same subnet (a shared LAN segment, for example).
Why DR/BDR election exists: On a multi-access segment with more than two routers, forming a full adjacency between every possible pair of routers (a full mesh of adjacencies) would create unnecessary overhead — the number of adjacencies needed grows rapidly as more routers join the segment. Instead, OSPF elects one router as the Designated Router (DR) and one as the Backup Designated Router (BDR); every other router on the segment forms a full adjacency only with the DR and BDR, not with each other, dramatically reducing the total number of adjacencies and the associated link-state advertisement flooding.
DRother: Any router on the segment that is neither the DR nor the BDR is referred to as a DRother — these routers form full adjacencies only with the DR and BDR, and remain in a 2-Way (not Full) state with every other DRother on the same segment.
DR/BDR election process — priority and tiebreaker:
OSPF interface priority — a configurable value (default 1, range 0–255) set per interface; the router with the highest priority on the segment becomes DR, and the router with the second-highest becomes BDR
Setting priority to 0 explicitly excludes that router from ever becoming DR or BDR — useful for a router that should always remain a DRother
If priorities are tied (including the default of 1 for every router), the tiebreaker falls to the highest Router ID
Configuring OSPF interface priority:
interface GigabitEthernet0/1
ip ospf priority 100
A critical, frequently tested behavior — DR election is not preemptive: Once a DR is elected on a segment, it remains the DR even if a new router with a higher priority (or higher Router ID) later joins the same segment. The only way to force a new DR election is if the current DR itself goes down/is removed from the segment, or if the OSPF process on that segment is manually reset. This non-preemptive behavior is intentional, since forcing frequent DR changes would be disruptive.
Multicast addressing relevant to DR/BDR: All OSPF routers on the segment (DR, BDR, and every DRother) send Hellos to 224.0.0.5. DRothers send their actual link-state updates specifically to 224.0.0.6 (All DR/BDR Routers), which only the DR and BDR listen to; the DR then relays that information out to 224.0.0.5 so all other DRothers on the segment receive it.
Exam Alert: Three facts are especially likely to appear directly: (1) DR/BDR election only happens on broadcast (multi-access) network types, never on point-to-point; (2) the process is not preemptive — a higher-priority router joining later does not displace an already-elected DR; (3) setting priority to 0 removes a router from DR/BDR eligibility entirely, forcing it to always remain a DRother.
The neighbor adjacency process, point-to-point behavior, and DR/BDR election concepts described above apply identically to OSPFv3 running over IPv6 — the underlying mechanics of the protocol did not fundamentally change between versions. The most significant practical differences are:
OSPFv3 has no network command (interface-level ipv6 ospf [process] area [area] configuration only, as noted in section 3)
OSPFv3 uses IPv6 multicast addresses (FF02::5 and FF02::6) instead of OSPFv2's IPv4 multicast addresses
OSPFv3 Hellos and adjacencies are formed using each router's link-local IPv6 address on the connecting interface, rather than a global unicast address, since link-local addresses are always present and sufficient for direct neighbor communication on a shared link
Router ID remains a 32-bit, IPv4-address-formatted value even in OSPFv3, despite running entirely over IPv6 — this is a commonly tested, slightly counterintuitive detail, and is exactly why manually configuring router-id becomes especially important in an IPv6-only deployment with no IPv4 addressing anywhere to derive one automatically
Exam Alert: Remember that OSPFv3's Router ID format does not change to an IPv6-style address — it remains a 32-bit, dotted-decimal-formatted value exactly like OSPFv2, even though the entire routing process runs over IPv6.
OSPFv2:
show ip ospf neighbor — displays each neighbor's Router ID, priority, current state (2-Way, Full, etc.), and the interface/IP address the adjacency was formed over; the single most important command for confirming adjacency status
show ip protocols — confirms OSPF is running, along with key timers and networks being advertised
show ip ospf interface [interface] — detailed per-interface OSPF information, including network type, Hello/Dead timers, priority, and current DR/BDR for that segment
show ip route ospf — filters the routing table to show only OSPF-learned routes
OSPFv3:
show ipv6 ospf neighbor — the IPv6 equivalent, showing neighbor Router ID, state, and interface
show ipv6 ospf interface [interface] — detailed per-interface OSPFv3 information
show ipv6 route ospf — filters the IPv6 routing table to OSPF-learned routes
Exam Alert: show ip ospf neighbor (or show ipv6 ospf neighbor) is the primary command for confirming whether adjacencies have actually reached the Full state — expect to be shown sample output and asked whether a specific neighbor relationship is healthy, and if not, what state it's stuck in.
Confirm OSPF is enabled on the expected interfaces — for OSPFv2, verify via show ip protocols or show run | section ospf; for OSPFv3, confirm ipv6 ospf [process] area [area] is applied directly on each intended interface, and that ipv6 unicast-routing is enabled globally.
Check show ip ospf neighbor (or show ipv6 ospf neighbor) to confirm the expected neighbors are present and in the Full state, not stuck in Init or 2-Way.
If neighbors are missing entirely, verify Layer 1/2 connectivity first (per objective 1.1), then confirm the two interfaces share the same subnet and area ID.
If neighbors are stuck in Init or 2-Way rather than reaching Full, check for a Hello/Dead timer mismatch or an OSPF network type mismatch (point-to-point on one end, broadcast on the other) using show ip ospf interface.
On a broadcast (multi-access) segment, confirm DR/BDR election has occurred as expected using show ip ospf interface [interface], and remember that a router expected to be DR based on priority may not be, if it simply joined the segment after the election already occurred (non-preemptive behavior).
Confirm the Router ID is unique across all routers in the OSPF domain and, if a Router ID was recently changed, confirm the OSPF process was actually cleared/restarted for the change to take effect.
Once adjacencies are confirmed healthy, verify expected routes are actually present using show ip route ospf (or show ipv6 route ospf).
Q1. Which command is used to enable OSPFv3 on a specific interface for IPv6 routing?
A. network 2001:db8::/64 area 0
B. ipv6 ospf 1 area 0 (applied directly on the interface)
C. router ospf 1
D. ip ospf network point-to-point
Answer: B. Unlike OSPFv2, OSPFv3 does not support the network command at all. OSPF for IPv6 must be enabled directly at the interface level using the ipv6 ospf [process-id] area [area-id] command on each participating interface.
Q2. Two OSPF routers are directly connected but their neighbor relationship remains stuck in the Init state and never progresses to Full. Both interfaces are confirmed to be in the same area and same subnet. What should be checked next?
A. Whether the Router IDs are identical
B. Whether the Hello and Dead timers match between the two interfaces
C. Whether DR/BDR election has completed
D. Whether ipv6 unicast-routing is enabled
Answer: B. A neighbor stuck in Init typically indicates one-way (rather than bidirectional) Hello reception, and mismatched Hello/Dead timer intervals between the two connecting interfaces are a common cause of this exact symptom, since OSPF requires matching timers to form a proper adjacency. Identical Router IDs would actually prevent adjacency entirely (a conflict), and DR/BDR election is only relevant on broadcast network types, not universally applicable to this scenario.
Q3. On which OSPF network type does DR/BDR election NOT occur?
A. Broadcast
B. Point-to-point
C. Both broadcast and point-to-point always elect a DR
D. DR/BDR election occurs on every network type equally
Answer: B. DR/BDR election only occurs on broadcast (multi-access) network segments, where more than two routers could potentially share the same subnet, to reduce the total number of adjacencies needed. Point-to-point links, by definition connecting exactly two routers, have no need for DR/BDR election and skip this process entirely.
Q4. A router on a broadcast OSPF segment is elected DR. Later, a new router with a higher OSPF priority joins the same segment. What happens?
A. The new router immediately becomes the new DR
B. The existing DR remains DR, since DR election is not preemptive
C. Both routers become co-DRs
D. The segment reverts to point-to-point network type
Answer: B. OSPF DR/BDR election is not preemptive — once a DR has been elected on a segment, it remains DR even if a router with a higher priority (or higher Router ID) joins later. A new election only occurs if the current DR itself leaves the segment or the OSPF process is manually reset.
Q5. In the absence of a manually configured Router ID, which of the following does OSPF prefer when automatically selecting a Router ID?
A. The lowest IP address among all physical interfaces
B. The highest IP address among configured loopback interfaces, preferred over physical interfaces
C. A randomly generated 32-bit value
D. The IP address of the interface with the lowest OSPF priority
Answer: B. When no Router ID is manually configured, OSPF prefers the highest IP address among any configured loopback interfaces over physical interfaces, since loopback interfaces are always up and therefore provide a more stable Router ID. Only if no loopback interfaces exist does OSPF fall back to the highest IP address among active physical interfaces.
Q6. An administrator changes a router's OSPF Router ID using the router-id command while OSPF is already running, but show ip ospf still displays the old Router ID. What is the most likely explanation?
A. The router-id command is not valid syntax
B. The Router ID change requires the OSPF process to be cleared or restarted to take effect
C. Router IDs cannot be changed once OSPF has formed any adjacencies
D. The new Router ID conflicts with a neighbor's Router ID
Answer: B. Simply entering a new router-id command does not immediately apply to an already-running OSPF process. The change is only picked up after the OSPF process is cleared (using a command such as clear ip ospf process) or the router/process is otherwise restarted, which is a commonly tested detail since it can appear as though the command silently failed.