Based on the exhibit, why is the router not installing routes in the OSPF database into the routing
The neighbor is stuck in the ExStart state
The routes are going to a different table than inet.0
There is an interface type mismatch
There is an MTU mismatch
8 Comments on “why is the router not installing routes in the OSPF database into the routing table?”
It is C… If it had been D, there would not have been OSPF database at all.
It is D, the neighbor is stuck in 220.127.116.11 is stuck in Extsart state. This seen to be a MTU issue on the neighbor configuration.
The routes are learned from the others neighbors.
It is D, the neighbor 18.104.22.168 is stuck in Extart state. This seen to be a MTU issue on the neighbor configuration.
It is C. Extart state affects the routes only comes fromm 22.214.171.124
In broadcast media it requires a DR and BDR. P2MP mode is just establish the adjacency but not exchange the routes. inet.0 have a route to 126.96.36.199 means all OSPF Routers address is used to send Hello packets to all OSPF routers on a network segment.
Sinany is correct
Correct answer is =D
After two OSPF neighboring routers establish bi-directional communication and complete DR/BDR election (on multi-access networks), the routers transition to the
exstart state. In this state, the neighboring routers establish a master/slave relationship and determine the initial database descriptor (DBD) sequence number to use while exchanging DBD packets.
Once the master/slave relationship has been negotiated (the router with the highest Router-ID becomes the master), the neighboring routers transition into the exchange state. In this state, the routers exchange DBD packets, which describe their entire link-state database. The routers also send link-state request packets, which request more recent link-state advertisements (LSA) from neighbors.
Although OSPF neighbors transition through the exstart/exchange states during the normal OSPF adjacency-building process, it is not normal for OSPF neighbors to be stuck in this state
Should be C as our router has interface ge-0/0/8.0 in an ospf pt-to-pt configuration with ip address 188.8.131.52. It is trying to establish and maintain ospf adjacencies with 184.108.40.206, 220.127.116.11 and 18.104.22.168 who are all reachable over its local ge-0/0/8.0
This arrangement will not be sustainable as a broadcast interface type (gigabit ethernet) has been forced into a pt-to-pt ospf arrangement. If we clear ospf adjacencies on our router, there will atleast be one neigbor in exstart state at any moment.
This has nothing to do with MTU…poor design and hence the issue.