OSPF NSSA External LSA Type 7 to Type 5 Translator Loop
Dual FortiGate Area Border Routers (ABRs) connecting an OSPF Not-So-Stubby Area (NSSA) to Area 0 enter an infinite Type-7 to Type-5 LSA translation race condition, causing rapid routing table churn, packet drops, and 100% CPU utilization in routerd.
Technical Root Cause Analysis
In standard OSPF NSSA deployments (RFC 3101), autonomous system external routes are injected into the NSSA as Type-7 LSAs. When multiple Area Border Routers link the NSSA back to the Area 0 backbone, a deterministic election chooses the ABR with the highest Router ID to translate Type-7 LSAs into Type-5 external LSAs, setting the P-bit (Propagate bit) to 0.
In affected FortiOS releases, when external routes are redistributed into the NSSA with non-zero Forwarding Addresses (FA), both ABRs receive each other's regenerated Type-5 LSAs across Area 0. The internal OSPF state machine inside routerd interprets the received Type-5 as a signal that the peer has relinquished translation duties. Both firewalls simultaneously flip their election states, flush active Type-5 LSAs, re-originate new Type-5 LSAs with incremented sequence numbers, and flood the backbone. This continuous loop leads to flapping routing table entries and route cache invalidation.
Affected Firmware & Blast Radius Matrix
| FortiOS Branch | Vulnerable Builds | Confirmed Clean Build | Status & Workaround |
|---|---|---|---|
| FortiOS 7.2 | 7.2.4 – 7.2.6 | 7.2.7+ | Set static nssa-translator-role always / never |
| FortiOS 7.0 | 7.0.10 – 7.0.15 | 7.0.16+ | Manually pin translation role on primary ABR |
| FortiOS 7.4 | 7.4.0 – 7.4.1 | 7.4.2+ | Clean state machine logic implemented in 7.4.2 |
Platform Impact: Affects FortiGate 100F, 200F, and 400F clusters deployed as redundant enterprise ABRs interconnecting multi-area OSPF topologies with NSSA redistribution.
Step 01: Free Verification CLI (Safe Read-Only)
Execute these commands to detect whether your OSPF database is experiencing Type-7 to Type-5 translator election thrashing:
Diagnostic Commands
# 1. Query the OSPF NSSA external LSA database for rapid sequence churn
get router info ospf database nssa-external
# 2. Inspect active OSPF routing table entries and route age
get router info routing-table ospf
# 3. Check OSPF general status, router ID, and translator election role
get router info ospf status
# 4. Filter real-time OSPF LSA generation and translation events
diagnose ip router ospf level info
diagnose ip router ospf show lsa-timerRemediation & Workaround Steps (Teaser Preview)
Follow the complete step-by-step remediation guide in the interactive Ferrite platform:
Frequently Asked Questions
Under RFC 3101, when multiple Area Border Routers connect an NSSA to the backbone, only the router with the highest Router ID should translate Type-7 LSAs into Type-5 LSAs. Due to an election sync defect in FortiOS routerd, when both ABRs receive external routes redistributed with forwarding addresses, both nodes attempt simultaneous translation, oscillating the translator bit and causing continuous LSA churn.
Under 'config router ospf -> config area', manually set 'set nssa-translator-role always' on the primary ABR, and 'set nssa-translator-role never' on the backup ABR. This overrides dynamic election and eliminates race conditions immediately.
The dynamic RFC 3101 translator state machine is resolved in FortiOS 7.2.7, 7.4.2, and all later maintenance releases.