Externals Missing, Overload Left On, and a Stub in the Way
R-EDGE is a Nokia SR OS ASBR in area 0. It must inject 300 static routes and two connected /24s into OSPF; the statics point to a partner network reachable through a firewall on a separate VLAN. An engineer created a policy named ospf-export with a single entry that matches from protocol static and has action accept, then attached it with configure router ospf export ospf-export. show router route-table protocol static on R-EDGE lists all 300 routes as active, but show router ospf database external is empty and a neighbor in area 0 sees no OSPF externals from R-EDGE. Meanwhile a neighbor in area 3, which was made a stub last year, cannot see the partner prefixes at all, and its traffic to the partner network is taking a much longer path than expected. A maintenance script also left an overload flag set on R-EDGE three weeks ago after a software upgrade.
1. Why are no type 5 LSAs being originated, and how do you prove it?
Read the worked answer
Redistribution on SR OS is policy-driven, and a matching from clause with an accept action is not sufficient. The export policy entry must also match the destination protocol with to protocol ospf; without it the entry does not apply to OSPF export and no type 5 is originated. The failure is silent - routes stay in the route table, no LSA appears, and nothing is logged. Check in order: show router policy for the entry content, confirming from protocol static, to protocol ospf, and action accept; show router ospf status to confirm the export policy is attached to the instance you think it is; and show router route-table protocol static to confirm the 300 routes are active and genuinely static. Three common traps are worth stating: the routes are BGP-learned, so from protocol static never matches; the policy is applied in a different router instance or VRF; or a later entry with a reject action shadows the match. After the fix, show router ospf database external on R-EDGE should list 300-plus type 5 LSAs with R-EDGE's router ID as advertising router.
2. Does the stuck overload flag explain any of the reported symptoms? What does overload actually do?
Read the worked answer
An overloaded router has not stopped redistributing. SR OS sets the metric of the router's transit links in its router LSA to the maximum value, 0xFFFF, so other routers still see the ASBR and its type 5 LSAs but prefer any alternate path for transit traffic across it; its own connected and stub networks remain usable for traffic destined to them. So type 5s appearing while traffic detours around R-EDGE is the expected overload signature, not a contradiction, and it fully explains why area 3's traffic takes a longer path even once the externals exist. Confirm with show router ospf status for the overload flag and inspect the router LSA in show router ospf database, where transit link metrics read 65535. Typical causes are a maintenance flag a script failed to clear, or overload-on-boot still counting down: SR OS can set overload for a configurable period after startup so traffic does not blackhole through a router whose other protocols have not converged. Clear the flag explicitly since the maintenance is long finished, and check the boot-timeout value.
3. The area 3 neighbor still cannot see the partner prefixes even after redistribution works. Explain and give the design options.
Read the worked answer
Area 3 rejects type 5 by definition, so the 300 externals will never appear there regardless of the export policy; that is correct behaviour, not a fault. The decision is requirement-driven. If area 3 only needs to reach those destinations, its ABR's default route is enough: traffic goes to the ABR, which holds the type 5s, and follows the optimal path from there - the partner prefixes simply do not appear as specific routes inside the area. If area 3 needs per-prefix visibility, for policy or for a second exit, then area 3 must become a normal area or an NSSA; note that an NSSA only helps if area 3 itself needs to originate externals, because it still blocks type 5 from the backbone and still requires its own default. Also check whether area 3 has a single exit: with only a default from one ABR, that ABR's failure takes the area offline even though the LSDB contained other paths. Before converting area 3 to normal, verify LSDB and SPF capacity on its smallest router.