A network engineer enters the following commands on R1, but R1 does not form an OSPF adjacency with R2 on interface GigabitEthernet0/0.
What is the most likely cause of the failure?
R1# interface GigabitEthernet0/0 ip address 10.1.12.1 255.255.255.0 ip ospf hello-interval 10 ip ospf dead-interval 40 ! router ospf 10 network 10.1.12.0 0.0.0.255 area 0 R2# interface GigabitEthernet0/0 ip address 10.1.12.2 255.255.255.0 ip ospf hello-interval 5 ip ospf dead-interval 20 ! router ospf 10 network 10.1.12.0 0.0.0.255 area 0
A network engineer enters the following commands on R1, but R1 does not form an OSPF adjacency with R2 on interface GigabitEthernet0/0.
What is the most likely cause of the failure?
Answer choices
Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
The routers are in different OSPF areas.
This would be a valid reason if one router were in area 0 and the other were in another area. In the exhibit, both routers place the same subnet into area 0, so the area setting is not the issue. The failure occurs at the interface parameter level instead.
The OSPF timers on the interface do not match.
This is correct because the interfaces are configured with different hello and dead intervals. OSPF neighbors expect those timers to align, and if they do not, the routers reject the neighbor relationship. The addressing and area assignment are fine, but the timer mismatch blocks adjacency formation.
The subnet mask prevents multicast OSPF packets from being exchanged.
The subnet mask shown is a normal /24 LAN mask and does not stop OSPF multicast traffic. OSPF commonly uses multicast on broadcast segments without any problem in that mask size. The real incompatibility is the timer mismatch, not the mask.
The OSPF process IDs do not match on the two routers.
This sounds believable because many learners assume OSPF process IDs must match between neighbors. In reality, the process ID is locally significant and is not exchanged as a neighbor-forming parameter. Two routers can still become neighbors with different local process numbers if the real link parameters match.
Common exam trap
A common exam trap is believing that OSPF process IDs must match between routers to form an adjacency. Many learners mistakenly think the process ID is a neighbor parameter, but it is actually locally significant and irrelevant to neighbor formation. Another trap is assuming that subnet mask differences or area mismatches are the cause when the real issue is timer mismatch. In this question, the hello and dead intervals differ between routers, causing adjacency failure. Misunderstanding these timer requirements leads to incorrect troubleshooting and exam answers.
Technical deep dive
Open Shortest Path First (OSPF) is a link-state routing protocol that requires routers to form neighbor adjacencies before exchanging routing information. For two routers to become OSPF neighbors, several interface parameters must match exactly, including the hello interval and dead interval timers. The hello interval defines how often a router sends hello packets to discover and maintain neighbor relationships, while the dead interval specifies the time a router waits without receiving a hello before declaring the neighbor down. OSPF adjacency formation follows strict rules: routers must be in the same subnet, configured with the same area ID, use compatible authentication settings, and have matching network types and timers on the interfaces involved. The hello and dead timers are critical because mismatched timers cause routers to perceive each other as incompatible, preventing adjacency formation. The OSPF process ID is locally significant and does not affect neighbor relationships. A common exam trap is assuming that OSPF process IDs must match between neighbors or that subnet masks alone can block adjacency. In practice, mismatched hello and dead intervals are a frequent cause of adjacency failure. Cisco routers will not form OSPF adjacencies if these timers differ, as the routers cannot synchronize their neighbor state machines. Understanding this behavior is essential for troubleshooting OSPF neighbor issues and ensuring stable routing in Cisco networks.
Related practice questions
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Practise IPv4 subnetting, CIDR, masks, host ranges and subnet selection.
Practise OSPF neighbours, router IDs, metrics, areas and routing-table interpretation.
Practise VLANs, access ports, trunks, allowed VLANs and switching scenarios.
Practise spanning tree, root bridge election, port roles and STP troubleshooting.
Practise LACP, PAgP, port-channel behaviour and bundle requirements.
Practise standard and extended ACLs, permit/deny logic and traffic filtering.
Practise static NAT, dynamic NAT, PAT and inside/outside address translation.
Practise DHCP scopes, relay, leases and troubleshooting.
Practise routing-table output, longest-prefix match, AD and route selection.
Practise trunk verification and VLAN forwarding across switches.
Practise WLAN security, authentication and wireless architecture concepts.
Practise IPv6 addressing, routes, neighbour discovery and common IPv6 exam traps.
Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.
Question 1
Question 2
Question 3
Question 4
Question 5
Question 6
FAQ
OSPF routers must have matching hello and dead interval timers on interfaces to successfully form neighbor adjacencies.
The correct answer is: The OSPF timers on the interface do not match. — In plain terms, the routers are speaking OSPF at different speeds, so they do not trust each other enough to become neighbors. OSPF requires several interface parameters to match before an adjacency can form, and the hello and dead timers are two of the important ones. On R1, the hello timer is 10 seconds and the dead timer is 40 seconds. On R2, the hello timer is 5 seconds and the dead timer is 20 seconds. Because those values are different, each router sees the other as incompatible. From a technical point of view, OSPF neighbors on the same link must agree on area, authentication, stub settings, network type in many cases, and the hello/dead intervals. The process ID is locally significant, so it does not need to match between routers. The addresses are in the same subnet and both interfaces are placed into area 0. That leaves the timer mismatch as the real cause of the failed adjacency.
Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.
Sign in to join the discussion.