Routing and SD-WAN in Large FortiGate Environments
Large FortiGate deployments become difficult when routing and SD-WAN are treated as separate features. Routing tells a device which destinations are reachable and through which next hops. SD-WAN evaluates the available members and steers traffic according to application, policy, performance, and health. At small scale, configuration can hide that distinction. At enterprise scale, misunderstanding it produces unstable paths, asymmetric traffic, and troubleshooting that jumps between routing tables and SD-WAN rules without a model.
This subject was planned around FCSS_EFW_AD-7.6, an exam Fortinet retired on July 15, 2026. The replacement advanced networking path now includes NSE 7 Secure Networking 7.6 Architect. That transition reinforces the broader point: advanced FortiGate work increasingly combines routing, IPsec overlays, SD-WAN, centralized management, and architecture rather than treating them as isolated administrator tasks.
A scalable design separates three questions. First, can every site learn a valid path to the destination? Second, which available path should carry a given application right now? Third, how does the network converge when a link, hub, route, or SLA condition changes? Keeping those questions distinct makes large deployments easier to reason about.
Reachability and path selection are different control problems
Dynamic routing protocols build reachability. They advertise prefixes, learn alternatives, and select routes according to protocol rules. SD-WAN then works with the interfaces and routes that are available and can use health measurements and policy to choose among viable paths. If routing removes a destination, an SD-WAN rule cannot steer traffic to it. If routing exposes several equal paths, SD-WAN can make application-aware choices among them.
Problems occur when teams use route manipulation to solve every traffic-steering requirement. Excessive local preference, metrics, policy routes, and route maps can make the routing table encode application policy that belongs at the SD-WAN layer. Conversely, expecting SD-WAN to repair missing or incorrect routing creates black holes.
In Fortinet’s enterprise SD-WAN architecture, BGP is commonly used to exchange routes across overlays so that the fabric knows all possible remote destinations. The design goal is often to preserve multiple usable paths and allow SD-WAN policy to decide which one should carry a session.
BGP scales the overlay when the policy remains understandable
BGP is attractive in large deployments because it can support many sites, route reflection, summarization, policy, and multiple address families. It is also easy to make unnecessarily complex. Every exception added to route policy should have a clear reason because distributed routing behavior becomes difficult to visualize when communities, filters, local preference, MED, and redistribution are all changing decisions.
Hub-and-spoke topologies commonly use hubs as route reflectors so spokes do not need a full mesh of BGP peering. That reduces session count, but the design still needs to consider redundant hubs, regional boundaries, route propagation, and what happens when a hub is unreachable. Summarization can reduce scale, but aggressive summarization can hide more specific failure information.
The right routing policy should make failure behavior predictable. Engineers should be able to state which routes disappear when a tunnel fails, which alternatives remain, and how quickly the network converges without needing to inspect every device.
ADVPN changes topology dynamically, so routing intent must remain stable
Auto-Discovery VPN can reduce the inefficiency of forcing all spoke-to-spoke traffic through a hub by allowing shortcuts to form when needed. That is valuable for latency and hub capacity, but it introduces dynamic paths that operators must understand. A topology can be physically hub-and-spoke while traffic becomes more direct after shortcut establishment.
The control plane still needs a consistent method to advertise reachability. Large deployments should define how spokes learn remote networks, how shortcuts are triggered, how redundant hubs behave, and which traffic should remain hub-routed for inspection or policy reasons.
PrepAway’s earlier coverage of Fortinet SD-WAN provides useful historical context for these concepts. Product versions and exam names change, but overlay routing, path quality, and failure behavior remain core design problems.
Segmentation has to exist in the routing architecture too
Enterprise WANs often carry multiple security or business segments across the same transport. Separating them only with firewall policy at individual sites is not always sufficient. VRFs, route distinguishers, route targets, VDOMs, and separate overlay constructs can preserve routing isolation so that one segment does not automatically learn another segment’s prefixes.
Segmentation also affects scale. Repeating routes across many VRFs or business units can multiply control-plane state. Overlapping address space can require distinct routing contexts. Shared services such as DNS, identity, management, or internet egress create intentional crossing points that need explicit route leaking and security policy.
A good design documents those crossing points. If every segment can leak routes to every other segment through ad hoc exceptions, the architecture gradually becomes a flat network with more configuration.
Performance SLAs should measure what applications actually need
SD-WAN health checks are useful because a link can remain technically up while becoming unsuitable for an application. Packet loss, latency, jitter, and reachability can influence path selection. The challenge is choosing probes and thresholds that represent user experience rather than creating constant switching in response to minor fluctuations.
Voice and interactive applications may be sensitive to jitter and loss. Bulk transfer may tolerate latency but need capacity. SaaS access may depend on internet path quality rather than a private overlay. One global SLA threshold is therefore rarely appropriate for all traffic.
Designers should also consider probe destinations. Measuring only the next hop proves little about an application several networks away. Probes should be stable, meaningful, and resilient enough that a failure of the probe target does not cause the entire WAN to make the wrong decision.
Route advertisement becomes an organizational problem at scale
Large environments need a policy for which prefixes may be advertised, by whom, and with what attributes. Without that discipline, a local team can accidentally inject an overly broad route and affect many sites. Prefix lists, route maps, communities, and centralized templates become governance mechanisms as much as routing features.
Address planning matters. Summarizable site prefixes make route tables smaller and troubleshooting easier. Random or overlapping allocations force more specific advertisements and exception logic. Mergers and cloud networks frequently break old addressing assumptions, so the architecture needs a deliberate way to absorb nonconforming ranges.
Centralized administration can reduce inconsistency. PrepAway’s FortiManager administration is relevant here because templates and controlled deployment become more valuable as the number of sites and routing objects grows.
Failure design should include convergence, not just redundancy
Two circuits are not resilient if traffic takes too long to move from the failed path to the surviving path. Convergence includes link detection, tunnel state, BGP timers, route withdrawal, SLA evaluation, session behavior, and application retry. Each layer can add delay.
Fast failure detection is useful, but overly aggressive timers can create instability when a transient loss causes routes and sessions to flap. The objective is not the smallest possible timer. It is a detection and recovery profile that matches the reliability of the transport and the tolerance of the application.
Testing should include complete and partial failures: carrier loss, packet loss without link-down, hub failure, routing-process restart, IPsec failure, asymmetric reachability, and degraded internet service. These scenarios reveal whether the design has true alternatives or only duplicate configuration.
Centralized policy should not erase local operational realities
Templates make large deployments consistent, but sites are rarely identical. Different carriers, bandwidth, application patterns, local internet breakout, compliance requirements, and maintenance windows may require controlled variation. The architecture should distinguish global standards from site-specific parameters.
Reusable objects and policy packages are more sustainable than copying complete configurations and editing them manually. The goal is to centralize intent while leaving room for documented exceptions. Exceptions should be visible and periodically reviewed so they do not become the permanent architecture by accident.
The current Fortinet certifications span operational and advanced roles, reflecting how enterprise networking now requires both platform-specific configuration knowledge and broader architecture discipline.
Troubleshooting should move from route to SD-WAN to session
When traffic fails, begin by confirming the destination route and the expected next hops. Then inspect the SD-WAN rule that matches the session, the health of eligible members, and the selected path. After that, verify firewall policy, NAT, VPN state, and the session table. This order follows the forwarding decision instead of guessing which feature is responsible.
Packet captures and debug flow can confirm where traffic actually travels, but they should be used after the expected path is defined. Otherwise, a large deployment can produce enormous amounts of diagnostic output without answering the central question.
Practitioners preparing for advanced network-security work may also benefit from PrepAway’s network security engineering overview. The role increasingly depends on combining routing, security policy, automation, and troubleshooting into one coherent mental model.