Fortinet NSE7_ESN_AR-7.6: FortiGate OSPF Troubleshooting
OSPF troubleshooting should follow the protocol from interface eligibility to adjacency, link-state database, shortest-path calculation, and route installation. When engineers skip directly to route filters or static routes, they can mask the actual defect and make the topology harder to reason about later.
On network security platforms, FortiGate can run OSPF alongside BGP, IPsec, SD-WAN, firewall policy, and segmentation. The routing process may be healthy while the packet still fails elsewhere, so each layer needs separate evidence.
The fastest investigations ask whether the neighbor exists, whether the expected LSA exists, whether SPF selects a path, and whether that path reaches the FortiGate routing table.
Confirm interface and area participation
OSPF only forms neighbors on interfaces that participate in the protocol and agree on the relevant area and network behavior. Verify interface address, mask, area, passive-interface state, and whether the configuration includes the intended link.
In routed VPN or overlay environments, confirm which logical interface should carry the adjacency. Accidentally enabling OSPF on an underlay while expecting it on an overlay creates confusing partial reachability.
OSPF fundamentals are easiest to apply when each interface has a clear role in the topology.
Read neighbor state as a diagnostic
A missing neighbor means discovery or basic compatibility failed. A neighbor stuck in intermediate states points toward different causes such as MTU mismatch, database exchange problems, network type, authentication, or unstable transport.
Compare hello and dead timers, area type, authentication, interface MTU, and network type on both peers. OSPF is symmetric enough that a one-sided check is rarely sufficient.
Neighbor problems should be mapped to the exact adjacency state instead of treated as one generic failure.
Verify the link-state database
Once adjacency is Full, inspect whether the expected router, network, summary, or external information appears in the link-state database. The LSDB shows what the router knows about topology before route preference and installation are considered.
If the LSA is missing, trace origination and flooding. If the LSA exists, move forward to SPF and route selection rather than repeatedly resetting the neighbor.
OSPF scale depends on controlling area boundaries and LSA scope so every router does not carry unnecessary topology.
Distinguish intra-area, inter-area, and external routes
OSPF path type affects preference and troubleshooting. A route originated inside the area, summarized by an ABR, or redistributed as an external route follows different control-plane rules.
Unexpected route type often reveals a design issue: redistribution may be happening at the wrong boundary, summary configuration may hide detail, or a route may be leaving and re-entering the OSPF domain.
Route redistribution should be inspected whenever an external route behaves differently from native OSPF prefixes.
Check cost and equal-cost behavior
OSPF chooses paths using cost. Interface cost or reference-bandwidth assumptions can make an apparently faster path look worse to the protocol. Confirm the accumulated metric rather than judging by interface speed alone.
Equal-cost paths can create multiple next hops. That may be intentional, but stateful firewalls and asymmetric network designs need careful return-path validation.
Routing diagnostics should include both protocol metric and the actual forwarding path observed by traffic.
Inspect summarization and filtering boundaries
OSPF filtering is not a universal per-neighbor policy mechanism like BGP. Understand whether a configuration affects route installation, LSA advertisement at an ABR or ASBR, or redistribution into another protocol.
Overaggressive summarization can hide a failed component route, while missing summarization can create unnecessary churn. The topology should document where aggregation is expected and which devices own it.
Network documentation becomes valuable during incidents because operators can compare the live LSDB with the intended area design.
Correlate adjacency flaps with the underlay
Repeated neighbor resets often indicate link, tunnel, or device instability rather than an OSPF algorithm problem. Correlate adjacency events with interface errors, IPsec events, HA changes, and SD-WAN health checks.
If OSPF runs over an overlay, verify that the overlay remains established long enough for the adjacency and database to converge. A short transport interruption can trigger larger control-plane churn in a dense topology.
FortiGate IPsec is relevant when the adjacency rides inside an encrypted tunnel.
Prove forwarding after the route is installed
A correct OSPF route can still lead to failed traffic because firewall policy, NAT, session state, return routing, or SD-WAN steering rejects or diverts the packet. Once the route table is correct, stop changing OSPF and inspect the flow.
Packet captures, flow diagnostics, and session-table evidence show whether traffic entered the FortiGate, matched the expected policy, chose the intended egress, and received a reply.
FortiGate sessions help close the gap between control-plane success and application success.
Build the troubleshooting sequence into operations
A runbook should move in one direction: interface, neighbor, LSDB, SPF, routing table, forwarding. This prevents teams from repeating disruptive resets and makes handoffs between network and security operators more precise.
Record the known-good neighbor count, expected area membership, critical routes, and normal convergence behavior. Baselines make subtle changes easier to spot during a live event.
Fortinet certifications support product familiarity, but stable OSPF operations come from topology discipline and evidence-based troubleshooting.
Check DR and BDR expectations
Broadcast and NBMA network types elect designated and backup designated routers, while point-to-point links do not use the same adjacency pattern. Misunderstanding the network type can make a healthy topology look incomplete because not every router becomes fully adjacent with every other router on a multiaccess segment.
Confirm interface priority, router IDs, and the expected DR/BDR roles before forcing elections. Changing priority can trigger topology churn and should be planned rather than used as an exploratory troubleshooting step.
Verify router ID stability
OSPF identifies routers with a router ID that should remain stable across reboots and interface changes. Unexpected router-ID changes can alter LSAs, neighbor relationships, and troubleshooting references even when IP connectivity remains available.
Explicitly configure router IDs in production where deterministic identity matters, and avoid reusing the same router ID on two devices. Duplicate IDs can create confusing database behavior that is difficult to diagnose from a single node.
Inspect default-route origination
Many OSPF domains depend on a small number of devices to inject a default route. If internet or upstream reachability disappears while internal routes remain healthy, verify whether the expected default is still being originated and whether any condition controlling origination has changed.
The default should not remain blindly advertised when the upstream path is unusable unless another mechanism guarantees safe forwarding. Tie origination policy to the design intent and test failure behavior.
Control external-route feedback
When OSPF exchanges routes with BGP, static routes, or another OSPF process, tags and filters can help identify the original source. Without that control, the same prefix can leave one domain and re-enter with a different metric or route type.
Redistribution incidents often look like mysterious preference changes. Track route origin and use explicit boundary devices so the protocol relationship can be understood from a small number of configurations.
Measure convergence instead of assuming it
After a link or neighbor failure, record how long it takes for adjacency loss, LSA propagation, SPF calculation, route replacement, and application recovery. The user-visible outage can be much longer than the configured hello or dead timer suggests.
Use those measurements to decide whether timer tuning, BFD, topology simplification, or a different failure-detection mechanism is justified. Faster timers increase control-plane sensitivity and should not be changed without evidence.
In segmented environments, verify the VDOM, VRF, interface, and area context before comparing route output. A correct OSPF database in one routing domain does not help traffic that is actually forwarded in another. Naming conventions for areas, interfaces, and VRFs make these mistakes easier to spot under incident pressure.
If OSPF is carried over tunnels or SD-WAN overlays, include MTU and fragmentation behavior in tests. A control packet may succeed while larger application traffic fails, or database exchange may stall when peers disagree about MTU. Path MTU evidence can therefore connect adjacency symptoms to the transport layer.
After resolution, capture the root cause in topology documentation and monitoring. Repeated neighbor loss, excessive LSA churn, or frequent SPF runs should become measurable signals so the team detects degradation before users report reachability loss.
OSPF authentication should be treated as both a security control and a troubleshooting dependency. A key mismatch, rollover timing problem, or inconsistent authentication mode prevents adjacency even when every IP and area setting is correct. Document key rotation procedures and validate both sides during maintenance so a security change does not create an unexpected routing outage.
For critical areas, monitor neighbor count, adjacency changes, LSA churn, SPF frequency, and the presence of a small set of expected routes. These signals reveal control-plane instability before every application path breaks. Alert thresholds should reflect normal maintenance and topology size so ordinary convergence does not create constant noise.
During planned changes, take a before-and-after snapshot of neighbors, LSDB summaries, route counts, and critical next hops. This makes it possible to prove that the intended topology changed without accidentally losing unrelated reachability. A rollback decision is much faster when the team can compare concrete control-plane state instead of relying on memory.