You have just completed an OSPF implementation. While executing your verification plan, you determine that R1 is not able to establish full OSPF adjacency with R2. The show ip ospf neighbor command output on R1 shows that R2 is stuck in the INIT state.
What could be the cause of this problem?
Select the best response.
A.
DR and BDR election errors between R1 and R2.
B.
The R2 router has not received the OSPF hello packets from the R1 router.
C.
Mismatched interface maximum transmission unit (MTU) configuration between the R1 and R2.
D.
Mismatched OSPF hello interval configuration between the R1 and R2.
E.
Corrupted LSAs exchanges between the R1 and R2.
I think , C is true.
We have output on router R1. Not in R2.
B – wrong
If router R2 has not received the OSPF hello packets from the R1 router.
Then output on router R2 (not on R1 !) shows that neighbor R1 is DOWN (not INIT)
Down sate – No Hellos have been received from this neighbor for more than the dead interval.
D. – wrong
If we have mismatch OSPF hello interval between the R1 and R2.
Neighbor goes to Down sate – No Hellos have been received from this neighbor for more than the dead interval.
And after dead interval expired the neighbor is removed from neighbor database
But for C
The mismatched MTU does not prevent routers from becoming neighbors, but it does prevent them from successfully exchanging topology data.
When the mismatch occurs, a pair of routers tries to become neighbors, and they list each
other in the output of show ip ospf neighbors. However, the neighbor state moves from EXSTART (which means the database exchange process is starting), but it fails as implied by the highlighted
. Then, the state changes to DOWN, and later one router tries again, moving to INIT (initializing) state. So, the neighbor is listed in the output of show
ip ospf neighbors command, but never succeeds at exchanging the topology data.
Cisco.com
Take a look at this sample output of the show ip ospf neighbor command:
router2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
170.170.5.1 1 INIT/- 00:00:34 170.170.1.1 Serial0
router-2#
In this example output, the init state indicates that router-2 sees hello packets from the neighbor, but two-way communication has not been established. A Cisco router includes the Router IDs of all neighbors in the init (or a higher) state in the neighbor field of its hello packets. For two-way communication to be established with a neighbor, a router also must see its own Router ID in the neighbor field of the neighbor’s hello packets. In other words, a router with a neighbor in the init state has received hello packets from the neighbor but has not seen its own Router ID in the neighbor’s hellos. In this case, if the router does not receive four consecutive hellos, it tears down the session and the OSPF adjacency goes down.
Possible Causes and Solutions for a Neighbor Stuck in the Init State
The most likely reason that a local router is not listed in a neighbor’s hello packets is that the neighbor has not received hello packets from the local router. Possible reasons for this are:
Use the ping and traceroute commands to verify that links between routers are operational. If a ping between routers is not successful, the link is not functioning properly and you need to be troubleshoot it. Refer to troubleshooting pages related to Layer 2 technology you are using, such as ISDN, Ethernet, ATM, etc.
If there are any access lists defined on the neighbor’s interface, the destination IP of 224.0.0.5 must be permitted in the input access list.
OSPF hello packets have a destination address of 224.0.0.5 (the all ospf routers multicast address).
There might be a second layer or configuration problem affecting multicast packets from reaching the neighboring router. You can test this with the ping command on the multicast address 224.0.0.5 and confirm that responses are received from the neighboring router(s). In non-broadcast media such as Frame Relay, X.25, and ISDN, mapping is required between layer 2 and the IP address. In case of static mapping (for example, the interface level frame-relay map ip 1.1.1.1 100 broadcast or dialer map ip 1.1.1.1 broadcast name router1 55346 commands), you must configure the keyword broadcast to avoid encapsulation failure every time OSPF tries to send the multicast hello packet. The debug ip packet detail command used with the access list shows if there are any encapsulation failures.
Authentication is not enabled on both sides. The router on which authentication is not enabled still processes hello packets from the neighbor and sees the neighbor in the init state. In order to correct this problem, enable authentication on both sides.
If you are running Cisco IOS® Software Release 11.1.9 or earlier, check the output of the show ip ospf interface command for discrepancies, such as:
Neighbor Count is 0, Adjacent neighbor count is 1
If the OSPF adjacent neighbor count is higher than the neighbor count, the neighbor list might be corrupted