Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

OSPF neighbors stuck in ExStart - case 1 - interface type mismatch

OSPF neighbors stuck in ExStart - case 1 - interface type mismatch


So we know that on a broadcast segment, two neighborship between two OSPF routers will allways be FULL given that all conditions are met. When there are more than two neighbors, the Designated Router and Backup Designated Router form a FULL adjacency with all routers on the segment and the DROthers will remain in 2-way state with each other. This is to avoid LSA flood storms on network segment with multiple OSPF speakers.


One of possible reasons why a neighbor would see FULL state neighborship with two other OSPF speakers on the broadcast segment and remain stuck in ExStart state with all the others is the interface type mismatch.


Let's see below:


What we see is that R3 has full ospf neighborship with RID 5.5.5.5 and 6.6.6.6. This is not a coincidence, these are routers with highest router ID and they are designated and backup designated routers.

RFC 2328 tells us that specific network types do not require election of designated and backup designated routers:






R3's interface is set to point-to-multipoint type. This means that, on ethernet segments, it will accept both unicast and multicast OSPF messages from all routers in the segment, but it will only send unicast. This explains why neighbourship with designated and backup designated routers is "FULL". The neighbourship with DROther routers is stuck in ExStart because the P2MP node tries to elevate the neighbourship state from 2-way to Exstart/Exchange/Loading/FUll, but DROther routers refuse to do this because they already have FULL neighborship with the DR and the BDR.

This is seen in a traffic capture taken on R3's interface:


R3 tries to send OSPF Database Description messages in unicast form to DRother routers, but they do not reply, so the neighborship remains stuck in ExStart.

Question #2: If R3 has FULL neighborship with designated routers, in theory, R3 routes should be seen by all other routes, but that is not correct.




Here is R6's view of R3's router LSA:


R3 reports individual "PointToPoint" segments with R5 and R6 while R6 sees the segment as "Transit" and this causes R6 to ignore all IDs provided by R3 in it's type 1 LSA, and it will not install routes 3.3.3.3/32 and 33.33.33.33/32 presented by R3: