In OSPF networks with totally Not-So-Stubby Areas (NSSA), routers may fail to install external routes in their routing tables when an adjacency remains stuck in the ExStart state. This occurs specifically:
Between core routers (Core1 and Core2) connected via a shared subnet
With SRX devices as OSPF neighbors
When Core2 shows full adjacency with SRX, but ExStart with Core1
The ExStart state halts database synchronization, preventing SPF calculation and route installation for external (Type 7/Type 5) routes, even though they exist in the OSPF database.
OSPF Neighbor Stuck in ExStart:
show ospf neighbor instance FSA
Address Interface State ID Pri Dead 10.113.252.2 irb.998 ExStart 10.23.254.204 128 34
External Routes Missing from Routing Table:
Routes appear in the database, but not in the routing table
show ospf database external extensive # Routes present here show route protocol ospf # Missing external routes
We informed the customer that inorder to get the external routers in their routing tables, the adjacency should be full between the core 1 and core 2 devices.
Totally, NSSA is intended for stub areas in multi-area OSPF designs where we need to filter Type-5 LSAs but still allow redistribution of external routes. In a single-area OSPF network, using Totally NSSA is unnecessary and may cause route visibility issues or unwanted complexity. It's best to use a standard area in such a case."