NSE7 Part 9: BGP for Enterprise Routing

The BGP Deep Dive series covers the protocol itself across twelve parts: the session, the attribute catalog, best-path selection, route reflection, communities, policy, traffic engineering, and convergence and scale. None of that gets re-derived here. This post stays on the FortiOS-specific mechanics the blueprint names directly: access lists and route maps as applied to BGP, ECMP with BGP routes, loopback sourcing, the neighbor-group command, and the specific convergence-optimization toolkit FortiOS exposes.

Access Lists, Prefix Lists, and Route Maps for BGP

The same three object types from Part 8 apply to BGP, with one FortiOS-specific wrinkle worth noting: BGP route maps are where most of BGP’s actual policy expression happens on FortiOS, since set-community, set-local-preference, set-metric (MED), set-aspath (prepend), and set-weight are all route-map set actions, not standalone configuration objects. A FortiOS BGP policy design lives almost entirely in route maps applied at config router bgp → config neighbor → route-map-in / route-map-out, which is the same shape the BGP Deep Dive’s policy part describes in vendor-neutral terms, applied here specifically to FortiOS syntax.

config router route-map
    edit "prefer-mpls-outbound"
        config rule
            edit 1
                set match-ip-address "branch-prefixes"
                set set-local-preference 200
            next
        end
    next
end

config router bgp
    config neighbor
        edit "10.0.0.2"
            set route-map-in "prefer-mpls-outbound"
        next
    end
end

Redistribution into BGP follows the identical pattern from Part 8: config redistribute under config router bgp, each protocol source optionally bound to its own route map controlling which routes cross and what attributes they carry once redistributed.

ECMP with BGP Routes

BGP ECMP requires routes to be equal-cost by BGP’s own best-path criteria, not just present in the table, meaning every attribute the best-path algorithm evaluates ahead of the router-ID tiebreak (weight, local preference, AS-path length, origin, MED, where comparable) needs to actually tie for multiple paths to be installed together. set multipath-relax enable under config router bgp is the FortiOS-specific setting that relaxes the AS-path-length-equality requirement specifically, allowing ECMP across paths with different AS-path lengths as long as everything else ties, which matters directly in multi-provider or multiregion designs where the “best” path by strict default BGP rules would otherwise starve a perfectly usable second path of any traffic at all.

config router bgp
    set multipath-relax enable
end

Same v4-ecmp-mode setting from Part 8 governs how traffic actually distributes once multiple BGP paths are installed as equal-cost.

Loopback Interfaces as BGP Sources

Sourcing BGP sessions from loopback interfaces rather than physical/tunnel interface addresses is standard practice the moment a design has any redundancy at all: a loopback doesn’t go down when a single physical link does, so a BGP session sourced from a loopback survives a link failure as long as an alternate path to that loopback still exists, rather than the session itself dropping the instant the interface it was sourced from goes down.

config system interface
    edit "loopback0"
        set type loopback
        set ip 10.255.0.1 255.255.255.255
    next
end

config router bgp
    config neighbor
        edit "10.255.0.2"
            set update-source "loopback0"
            set ebgp-enforce-multihop enable
        next
    end
end

ebgp-enforce-multihop (the FortiOS equivalent of the more commonly-known ebgp-multihop concept) is required whenever loopback-sourced peers aren’t directly connected at Layer 3, since eBGP’s default TTL behavior assumes single-hop adjacency and a loopback-to-loopback session is, by construction, at least two hops away from the peer’s perspective. Forgetting this on an eBGP loopback-sourced session is a specific, common configuration mistake: the session simply never establishes, and the fix is this one setting, not a routing problem.

SD-WAN Resilience Part 2 builds a full working example of this exact pattern in a dual-DC hub design, worth reading alongside this section for the topology-level reasoning rather than just the syntax.

The neighbor-group Command

Configuring per-neighbor settings individually doesn’t scale past a handful of peers, and a hub with dozens of ADVPN spokes sharing near-identical BGP configuration (same route maps, same timers, same AS in an iBGP design) is exactly the scenario neighbor-group exists for. A neighbor group defines the shared configuration once; individual peers are then added as neighbor-range members (matched by a prefix covering the expected peer address range) or explicitly listed against the group, inheriting every setting the group defines without repeating it per neighbor.

config router bgp
    config neighbor-group
        edit "spoke-group"
            set remote-as 65001
            set route-map-in "spoke-routes-in"
            set update-source "loopback0"
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.20.0.0 255.255.0.0
            set neighbor-group "spoke-group"
        next
    end
end

This is the routing-layer equivalent of the metadata-variable templating covered in Part 6: one definition, replicated automatically across every peer that matches, rather than hand-repeated configuration that drifts the moment someone updates one peer’s route map and forgets the other forty-nine.

Optimizing BGP for Rapid Convergence

The blueprint names four specific convergence tools, and treats them as a toolkit to be selected from deliberately based on what’s actually slow in a given design, not a checklist to enable uniformly.

BGP convergence as a general topic is the baseline the other three tools optimize: how quickly BGP detects a failure and reconverges on an alternate path, bounded fundamentally by how quickly the failure is detected (which is where BFD comes in) and how quickly the resulting withdrawal/update propagates (where route reflector design and graceful-restart both matter, in different directions).

Route reflectors: covered in full in the BGP Deep Dive, and directly relevant to convergence speed in a large iBGP mesh: without reflection, an N-router full iBGP mesh means every router directly peers with every other, and a route change has to propagate across all of those sessions individually. A route-reflector design concentrates propagation through the reflector, which can be faster to converge in some topologies and slower in others depending on reflector placement and cluster design, which is exactly why this is framed as an optimization decision requiring topology-specific judgment rather than a universal speedup.

The BFD parameter: BGP’s own hold-timer-based failure detection is typically tuned in seconds; BFD detects link failure in milliseconds and, when bound to a BGP neighbor (set bfd enable under the neighbor or neighbor-group), triggers immediate BGP reconvergence on failure detection rather than waiting for the BGP hold timer to expire naturally. This is the single highest-leverage convergence optimization available for directly-connected or single-hop peers, and the blueprint’s emphasis on it reflects how much of real-world BGP “slowness” is actually failure-detection latency rather than anything about BGP’s own reconvergence logic once it knows a path is gone.

config router bgp
    config neighbor
        edit "10.0.0.2"
            set bfd enable
        next
    end
end

The graceful-restart command solves the opposite problem from the other three: not detecting failure faster, but avoiding unnecessary reconvergence entirely when a BGP speaker’s control plane restarts (a software upgrade, a process crash) while its forwarding plane keeps working uninterrupted. A graceful-restart-capable router signals its restart to peers, which hold onto the previously-learned routes for a grace period rather than immediately withdrawing them and triggering network-wide reconvergence for what turns out to be a brief, forwarding-plane-unaffected control-plane blip.

config router bgp
    set graceful-restart enable
    set graceful-restart-time 120
end

The design tension between BFD and graceful-restart is worth holding onto explicitly, since a scenario question can plausibly test it: BFD is tuned to detect failure fast and react immediately; graceful-restart is tuned to not react immediately to what might just be a brief restart. A design running aggressive BFD timers against a peer that also does scheduled graceful-restart maintenance needs those two behaviors to not fight each other, since a fast BFD failure detection during a peer’s planned graceful restart could trigger exactly the disruptive reconvergence graceful-restart was configured to prevent.

What Part 10 Builds On Top of This

Everything in this post and Part 8 establishes the routing table SD-WAN then makes forwarding decisions against. Part 10 is where OSPF and BGP routes, redistribution, and ECMP all feed into the SD-WAN rule lookup process specifically, the part of this domain where a correct-looking routing table can still produce traffic taking the wrong SD-WAN path if the rule logic on top of it doesn’t match what the underlying routing actually supports.