Refer to the exhibit. Router1 and Router2 have shared routes in the OSPF database, but the routes are missing from their routing tables. Checking the prefix-list configuration on both routers, the…

Question

Exhibit

Options

• AConfigure the two routers with different process IDs
• BConfigure the two routers with different hello and dead timer values
• CSwitch the DR and BDR roles between the two routers
• DConfigure interface Senal1/0 on Router1 as a point-to-point interface

• A
  5% (2)
• B
  29% (11)
• C
  11% (4)
• D
  55% (21)

Explanation

Option D fixes the problem because a network type mismatch on Serial1/0 is the classic cause of routes appearing in the OSPF database but not the routing table - if one router's serial interface is set to a DR/BDR-requiring type (like non-broadcast/NBMA) while the other expects point-to-point, full adjacency is never achieved, leaving routes stuck in the database. Configuring Serial1/0 as ip ospf network point-to-point eliminates DR/BDR election entirely and forces a direct Full adjacency, which allows routes to be installed.

Why the others are wrong:

• A - OSPF process IDs are locally significant and never need to match between routers; mismatched IDs have no effect on adjacency or route installation.
• B - Hello/dead timers must match for adjacency formation; making them different would break the existing neighbor relationship, worsening the problem.
• C - DR/BDR role-swapping is irrelevant here; on a proper point-to-point serial link there is no DR/BDR election at all, and swapping roles does nothing to resolve a network type mismatch.

Memory tip: "Routes in the DB but not the table = suspect a network type mismatch." Serial links should almost always be point-to-point - if you see DR/BDR behavior on a serial interface, that's your red flag.

No community discussion yet for this question.