CCNA OSPF Questions — Page 3 of 3

151

MCQhard

After configuring the area 0 range 10.0.0.0 255.255.0.0 command on an OSPF ABR, a technician finds that a host at 10.0.5.100 in Area 1 cannot reach hosts in Area 0. The ABR’s OSPF database shows only the summary 10.0.0.0/16 in Area 0, and no individual /24 routes. What is the most likely cause?

A.The ABR is filtering the specific /24 routes using a distribute-list under the OSPF process.

B.The routers in Area 1 are no longer advertising their /24 routes to the ABR because the ABR is in a different area.

C.The area range command causes the ABR to advertise only the summary LSA and suppress the more-specific Type-3 LSAs for the range.

D.The ABR has automatically created a discard route to null0 for the summary, which is dropping all traffic destined to the summarized networks.

AnswerC

By default, the area range command summarizes the specified prefix range and suppresses the individual component routes from being advertised into the target area. Only the summary LSA appears in Area 0, which matches the observed behavior.

Why this answer

The `area 0 range 10.0.0.0 255.255.0.0` command on an OSPF ABR creates a single Type-3 summary LSA (10.0.0.0/16) for Area 0 and suppresses the advertisement of more-specific Type-3 LSAs (e.g., /24 routes) that fall within that range. This is the intended behavior of the `range` command: it summarizes routes at the ABR and prevents the individual component routes from being advertised into the backbone area. Since the host at 10.0.5.100 in Area 1 relies on those specific /24 routes to reach destinations in Area 0, the suppression breaks connectivity.

Exam trap

Cisco often tests the misconception that the `area range` command only summarizes routes without suppressing the more-specific LSAs, leading candidates to incorrectly attribute the connectivity loss to filtering or routing issues rather than the intended suppression behavior.

Why the other options are wrong

A distribute-list requires explicit configuration; its absence makes this an unsubstantiated guess.

Area border routers receive all LSAs from non-backbone areas; the area boundary does not stop LSA propagation to the ABR itself.

The null0 route is a loop-prevention mechanism, not an absolute traffic blocker; more-specific entries in the routing table take precedence.

Practice this question →

152

MCQhard

A technician is troubleshooting an OSPF network. On a broadcast segment, R1 is the DR and R2 is the BDR. R1's interface GigabitEthernet0/0 is shut down for maintenance. The technician expects that R2 will assume the DR role, but instead a new DR election occurs and another router is elected DR. What is the most likely cause?

A.The OSPF hello and dead intervals on R2 do not match those of other routers on the segment.

B.R2 has an OSPF priority of 255.

C.The OSPF network type on the segment was changed to point-to-point.

D.R2 has an OSPF priority of 0.

AnswerD

On a broadcast OSPF network, a priority of 0 makes a router ineligible for DR or BDR election. Even though R2 was the BDR, its priority of 0 prevents it from taking over as DR when R1 fails. Consequently, a new DR election is triggered among the remaining eligible routers, and a router other than R2 becomes the new DR.

Why this answer

When the DR (R1) goes down, a new DR election occurs. R2 is the BDR, but if its OSPF priority is 0, it is ineligible to become the DR. Therefore, a new election takes place among the remaining routers with non-zero priorities, and another router wins the DR role.

Exam trap

Cisco often tests the misconception that the BDR automatically becomes DR when the DR fails, but the BDR only takes over if it has a non-zero priority; otherwise, a new election is triggered.

Why the other options are wrong

Neighbor adjacency failure due to timer mismatch would have prevented R2 from becoming BDR at all.

High priority increases the chance of being elected DR, not decrease it.

Point-to-point networks do not have DR/BDR elections, so R2 could not have been BDR.

Practice this question →

153

Drag & Dropmedium

Drag and drop the following commands into the correct order to configure OSPFv3 for IPv6 on a Cisco IOS-XE router.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for configuring OSPFv3 on a Cisco IOS-XE router is: first enable IPv6 routing globally with `ipv6 unicast-routing` (A), then create the OSPFv3 process with `router ospfv3 1` (B), then enter interface configuration mode for the desired interface with `interface GigabitEthernet0/0` (C), and finally enable OSPFv3 on that interface using `ipv6 ospf 1 area 0` (D). This order ensures IPv6 is enabled before configuring OSPFv3, the OSPFv3 process exists before it is assigned to an interface, and the interface is selected before applying the OSPFv3 configuration.

Exam trap

Do not confuse the order with OSPFv2. For OSPFv3, you must first enable IPv6 routing globally; otherwise, the router will reject OSPFv3 configuration commands.

Practice this question →

154

MCQhard

R1 and R2 are directly connected via Ethernet on interface G0/0. Both interfaces are in the same subnet and configured for OSPF area 0. After enabling OSPF, R1's G0/0 is stuck in the INIT state in the OSPF neighbor table. What is the most likely cause?

A.MTU mismatch

B.Hello and dead timer mismatch

C.Missing router ID on both routers

D.A duplicate static route to 10.1.12.0/30

AnswerB

OSPF adjacency requires that Hello and Dead intervals match exactly between neighbors on the same link. The Dead interval is typically four times the Hello interval, but if one side is configured with different timers (e.g., 10/40 vs 30/120), the routers will discard each other's Hello packets and never reach the 2-Way state. This is the classic cause of a neighbor relationship that remains completely down, with no OSPF neighbor entry at all.

Why this answer

Being stuck in the INIT state means R1 has received Hello packets from R2 but has not transitioned to the 2-WAY state. This most often occurs when critical OSPF parameters like the hello and dead timers do not match. An MTU mismatch, while problematic, would cause the adjacency to fail during database exchange (Exstart/Exchange), not during initial neighbor formation.

Missing router IDs are not a real issue because routers auto-generate them, and a duplicate static route to the connected subnet would not affect OSPF neighbor discovery.

Exam trap

A common exam trap is selecting MTU mismatch or missing router IDs as the cause of OSPF adjacency failure. While MTU mismatches can cause adjacency issues during database exchange, they do not prevent the initial neighbor relationship from forming. Missing router IDs do not block adjacency because routers automatically generate IDs if none are configured.

Another trap is confusing static routes with neighbor discovery; static routes do not influence OSPF adjacency. The key is to focus on timer mismatches, as hello and dead intervals must be identical for routers to recognize each other as neighbors and establish adjacency.

Why the other options are wrong

MTU mismatch can cause OSPF adjacency problems during the database exchange phase, but it does not typically prevent the initial neighbor relationship from forming. Since the question states adjacency cannot form, MTU mismatch is unlikely the primary cause.

Missing router IDs do not prevent OSPF adjacency because routers automatically generate a router ID if none is configured. Therefore, this option is not a valid cause for adjacency failure.

A duplicate static route to 10.1.12.0/30 does not affect OSPF neighbor formation, as static routes are unrelated to OSPF adjacency processes. This option is irrelevant to the adjacency issue.

Practice this question →

155

MCQhard

A network engineer is troubleshooting OSPFv3 adjacency between two directly connected Cisco routers, R1 and R2, both running IOS-XE. The engineer configures OSPFv3 on both routers but notices that the adjacency does not form. The engineer runs 'show ospfv3 neighbor' on R1 and sees no neighbors. What is the most likely cause of this issue?

A.The OSPFv3 process ID must match on both routers.

B.The interface GigabitEthernet0/0 is missing the 'ospfv3 1 ipv6 area 0' command.

C.The link-local addresses are not in the same subnet.

D.The router ID 1.1.1.1 is duplicated on R2.

AnswerB

With OSPFv3, enabling the OSPF process globally is not enough; each participating interface must be explicitly activated with the 'ospfv3 1 ipv6 area 0' interface-level configuration. This command assigns the interface to the OSPFv3 process 1 for address family IPv6 and places it into area 0. Without this command, the router will not send or listen for OSPFv3 Hello messages on GigabitEthernet0/0, so no neighbor adjacency can ever form. That is exactly why R2's neighbor entry is missing from the 'show ospfv3 neighbor' output.

Why this answer

OSPFv3 requires explicit interface-level configuration to enable the protocol on a specific interface. The correct command is 'ospfv3 1 ipv6 area 0' (or 'ipv6 ospf 1 area 0' for the traditional OSPFv3 configuration). Without this command, the interface does not participate in OSPFv3, so no Hello packets are sent or received, preventing adjacency formation.

Exam trap

Cisco often tests the distinction between OSPFv2 (where enabling the protocol under the routing process automatically activates it on all interfaces with 'network' statements) and OSPFv3 (which requires explicit per-interface activation), leading candidates to overlook the mandatory interface-level command.

Why the other options are wrong

This is a common misconception; OSPFv3 uses the router ID for neighbor identification, not the process ID.

Link-local addresses are automatically configured and do not affect OSPFv3 adjacency as long as they are unique.

In this scenario, no neighbors are seen, indicating a more fundamental issue like OSPFv3 not being enabled on the interface.

Practice this question →