OSPF Deep Dive Part 8: FortiOS Implementation and Gotchas

BRANCH-FGT is the FortiGate in this series’ lab, sitting in Area 0 and originating Area 1 as NSSA. FortiOS gets OSPF conceptually right in the same places Cisco does, same LSA types, same area hierarchy, same SPF behavior, but its defaults and its configuration surface differ in ways that matter operationally, some of them in FortiOS’s favor and at least one distinctly not.

One OSPF instance per VDOM

FortiOS scopes a single OSPF process to a VDOM. There’s no numbered multi-process concept like Cisco’s router ospf <id>; if a genuinely separate OSPF domain needs to coexist on the same physical box, that’s a VDOM boundary, not a second process inside the same one. Multi-VRF support inside a single VDOM (up to 32 VRF IDs) lets one OSPF instance carry multiple independent routing tables, which covers a lot of the same ground Cisco’s VRF-lite plus multiple processes would, but it’s still one OSPF configuration block per VDOM, referencing the VRF ID per interface rather than a second top-level process.

This matters for BRANCH-FGT specifically because it means Area 0 and Area 1’s NSSA configuration from Parts 2 and 4 both live inside the same config router ospf block, distinguished by area ID under config area, not by separate processes the way an entirely unrelated Cisco OSPF domain on the same box would be.

No passive-interface-default, and that’s a real gap to plan around

Part 7 covered Cisco’s recommended pattern: passive-interface default, then explicitly un-passive the interfaces that should form adjacencies. FortiOS has no equivalent blanket-passive command. Configuring an OSPF network range on a FortiGate (config router ospf / config network / matching a prefix to an area, functionally identical to Cisco’s classic network statement) enables active OSPF, hello packets sent and accepted, on every interface whose address falls inside that range, the moment the range is configured. There’s no “default off” posture to build from.

The practical consequence: a network range configured broadly enough to cover more than the intended interfaces, the same mistake flagged in Part 7 for Cisco’s classic network-statement style, has no passive-interface default safety net to fall back on when someone gets the range wrong on a FortiGate. Getting a range slightly too broad on a Cisco box wrapped in passive-interface default still only forms adjacencies on interfaces explicitly un-passived. The same mistake on FortiOS forms adjacencies on every interface the range happens to touch, immediately. The operational mitigation is discipline, not a config knob: scope network ranges as tightly as the actual intended interfaces, or use the interface-level config interface block under an area to add specific interfaces by name instead of relying on a range match at all. BRANCH-FGT in this lab is configured the interface-explicit way for exactly this reason.

config router ospf
    set router-id 10.0.0.2
    config area
        edit 0.0.0.0
            config interface
                edit "wan1"
                    set interface "wan1"
                next
            end
        next
        edit 0.0.0.1
            set type nssa
            config interface
                edit "port3"
                    set interface "port3"
                next
            end
        next
    end
    config redistribute "static"
        set status enable
        set metric-type 1
    end
end

Router-id selection genuinely differs from Cisco

Part 7 covered Cisco’s router-id selection order: manually configured value first, then highest loopback IP, then highest active physical interface IP, prioritizing loopbacks specifically. FortiOS’s fallback, if set router-id isn’t configured, simply picks the highest IP address across all interfaces with no special weighting for loopback-style interfaces at all. A FortiGate with a numerically high WAN interface address and a lower loopback address will select the WAN address as its router-id under auto-selection, precisely the scenario Cisco’s algorithm is designed to avoid. This is one more reason set router-id belongs in every FortiOS OSPF configuration explicitly, not left to the platform default, which is true of Cisco too but for a milder version of the same underlying risk.

OSPF and SD-WAN policy routes don’t automatically agree

This site’s Fortinet SD-WAN and packet-flow series have already covered how FortiOS evaluates policy routes ahead of the standard routing table for matching traffic. OSPF-learned routes populate the standard routing table the same way any other dynamic protocol’s routes do, but a policy route that matches the same traffic will still win, silently, regardless of what OSPF has calculated as the best path. An OSPF adjacency reporting Full, with correct routes in the routing table, is not proof that traffic is actually taking the OSPF-preferred path on a FortiGate running SD-WAN policy routes over the same interfaces. This isn’t a bug or a FortiOS-specific gotcha in the sense the passive-interface gap above is; it’s the expected policy-route-before-routing-table evaluation order covered in that earlier series, but it’s worth restating here because troubleshooting an OSPF “problem” that’s actually a policy-route match is a real category of wasted effort, and the LSDB will look completely healthy the entire time.

Reference-bandwidth and cost

FortiOS uses the same 100 Mbps default reference bandwidth and the same set auto-cost-ref-bandwidth command family as the concept Part 3 and Part 7 covered, with the identical cross-vendor requirement: every router in the domain, FortiGate or otherwise, needs to agree on this value, and FortiOS has no protocol-level check for a mismatch any more than Cisco does.

Part 9 covers Junos, where OSPF configuration structure, redistribution, and even the default route-preference relative to BGP all diverge further from both Cisco and FortiOS than either of them diverge from each other.