NSE7 Part 8: OSPF for Enterprise Routing

The OSPF Deep Dive series covers the protocol itself in full: neighbor states, LSA types, the SPF algorithm, virtual links, OSPFv3, and authentication, twelve parts total including a dedicated FortiOS implementation part covering basic FortiOS OSPF configuration syntax and gotchas. This post does not repeat any of that. It stays narrowly on what the NSE 7 blueprint’s “Implement OSPF to route enterprise traffic” task actually names: route filtering and redistribution mechanisms, OSPF over IPsec specifically, and ECMP behavior with OSPF-learned routes.

Access Lists, Prefix Lists, and Route Maps on FortiOS

FortiOS separates route filtering into three composable objects, and the exam expects you to know which one is the right tool for a given filtering requirement, not just that all three exist.

Access lists (config router access-list) match on prefix and, optionally, an exact or ge/le prefix-length range, with a simple permit/deny action. They’re the blunt instrument, useful for a straightforward “permit only these specific networks” filter with no further logic attached.

config router access-list
    edit "branch-summary-only"
        config rule
            edit 1
                set prefix 10.30.0.0 255.255.0.0
                set ge 24
                set le 24
            next
        end
    next
end

Prefix lists (config router prefix-list) are functionally similar to access lists but are the object type BGP route maps and several other FortiOS routing contexts expect specifically, so in practice the choice between the two is often dictated by which downstream construct is doing the matching rather than a meaningful functional difference for OSPF alone.

Route maps (config router route-map) are where actual conditional logic lives: match criteria (referencing an access list or prefix list, plus metric, tag, or interface matches) paired with set actions (metric, metric-type, tag). A route map is what a redistribution statement actually references to control not just which routes get redistributed but what values they carry once redistributed.

config router route-map
    edit "static-to-ospf"
        config rule
            edit 1
                set match-ip-address "branch-summary-only"
                set set-metric-type "type-1"
                set set-metric 20
            next
        end
    next
end

Protocol Redistribution

Redistribution into OSPF (config router ospf → config redistribute) injects routes learned from another source (static routes, connected interfaces, BGP, or another OSPF process in a multi-VDOM design) as external LSAs (Type 5, or Type 7 within an NSSA, per the LSA hierarchy the Deep Dive series covers in depth). The FortiOS-specific detail worth holding onto for the exam: redistribution is configured per protocol type under config router ospf, each with its own optional route-map reference, meaning a design can redistribute static routes with one metric-type/metric via one route map while redistributing BGP routes with entirely different values via a separate route map, all within the same OSPF process.

config router ospf
    config redistribute "static"
        set status enable
        set metric-type "1"
        set routemap "static-to-ospf"
    end
end

The exam-relevant failure mode: forgetting that a route map referenced by a redistribution statement, but containing a match clause that never actually matches (wrong access list, wrong prefix range), results in zero routes redistributed, not an error, since the redistribution statement is enabled and syntactically valid, it’s just filtering everything out by an unintended empty match. This is a genuinely common real-world debugging scenario and a natural fit for a scenario question: “redistribution is enabled and no errors are logged, but no external routes appear in the OSPF database, what’s wrong” is pointing at the route map’s match logic, not the redistribution statement itself.

OSPF over IPsec

Running OSPF across an IPsec tunnel is mechanically no different from running it across any other point-to-point or broadcast-capable interface, once the tunnel interface itself is correctly enrolled as an OSPF interface (config router ospf → config ospf-interface, referencing the IPsec tunnel interface name, with network-type point-to-point being the typical choice for a single hub-spoke tunnel rather than the default broadcast type, which assumes a shared-medium DR/BDR election that a point-to-point tunnel doesn’t actually have).

config router ospf
    config ospf-interface
        edit "to-branch12"
            set interface "vpn-branch12"
            set network-type point-to-point
            set hello-interval 10
            set dead-interval 40
        next
    end
end

The design consideration the blueprint is actually testing here is less about OSPF’s own mechanics and more about why you’d choose OSPF over an IPsec overlay at all, given that Part 12 covers BGP as ADVPN’s own preferred routing protocol. OSPF over IPsec fits smaller, largely static hub-and-spoke topologies where the operational simplicity of a link-state protocol’s automatic topology discovery outweighs BGP’s superior scaling and policy control, and where the topology doesn’t involve ADVPN’s dynamic shortcut tunnels forming and tearing down at runtime, since OSPF’s neighbor adjacency model handles that kind of dynamic topology change far less gracefully than BGP does. A large, ADVPN-heavy multiregion SD-WAN design is BGP territory almost without exception; a modest, largely-static hub-and-spoke IPsec design without ADVPN shortcuts is where OSPF over IPsec remains a genuinely reasonable choice.

OSPF ECMP

FortiOS installs multiple equal-cost OSPF routes to the routing table when more than one path to a destination shares the identical OSPF cost, and by default load-balances traffic across them (config system settings → v4-ecmp-mode, with source-ip-based, weight-based, or usage-based as the selection options, source-ip-based being the default and the one that keeps a given session’s traffic on a single consistent path rather than spraying individual packets across multiple paths, which would break stateful inspection for that session).

The exam-relevant nuance: OSPF ECMP requires the paths to be genuinely equal-cost as OSPF calculates cost (interface bandwidth-derived reference cost, not a judgment call), so two paths that look intuitively similar but differ even slightly in configured or auto-derived interface cost will not ECMP, one will simply be preferred and the other held in reserve as a backup, not load-shared. A design expecting ECMP load-sharing across two links needs to confirm their OSPF costs are actually identical, not just similar, and get router info ospf ecmp or checking show router ospf interface cost values directly is the diagnostic step that confirms it rather than assuming similarly-provisioned links have matched.

Use Cases: Where This Domain’s Weight Actually Comes From

The blueprint groups OSPF, BGP, SD-WAN rules, and SD-WAN routing into a single 25-35% “Rules and routing” domain rather than weighting OSPF separately, and the practical reading of that is: OSPF alone is not where most of this domain’s marks live. OSPF questions on this exam are more likely to show up as one leg of a larger scenario, redistribution between OSPF and BGP at a hub that’s also running SD-WAN rules over the resulting routes, for instance, than as a standalone “configure OSPF” question in isolation. Keeping this section’s redistribution and route-map mechanics genuinely fluent matters less for OSPF-specific questions and more for correctly reading the routing table state in a multi-protocol scenario question in Part 10 and Part 13.

Part 9 covers the equivalent ground for BGP, which the blueprint weights far more heavily on its own, and which does most of the actual work in the ADVPN and multiregion designs Parts 11 and 12 build toward.