NSE7 Part 12: ADVPN: On-Demand Shortcuts and BGP on Loopback

Every IPsec design in Part 11 assumed tunnels were explicitly provisioned: a spoke has a tunnel to hub A, maybe hub B, and that’s the full set of paths it can use. Auto-Discovery VPN (ADVPN) removes that assumption for spoke-to-spoke traffic specifically: a spoke that needs to talk to another spoke doesn’t have to backhaul through the hub for the life of that conversation, it can build a direct tunnel, a shortcut, to the other spoke on demand, use it, and let it expire when it’s no longer needed.

ADVPN Operation and Requirements

In a standard hub-and-spoke IPsec design, spoke-to-spoke traffic (branch A talking to branch B) has no choice but to route through the hub twice, once in on the A-to-hub tunnel, once back out on the hub-to-B tunnel, doubling the hub’s traffic load and adding the hub’s own latency and potential congestion to every spoke-to-spoke conversation regardless of how physically close A and B might actually be to each other. ADVPN’s premise is that this is wasteful whenever A-to-B traffic is frequent or latency-sensitive enough to justify a direct path.

The mechanism requires three things to be in place: the hub configured as an ADVPN hub (set auto-discovery-sender enable on the hub’s phase1-interface), the spokes configured to both advertise their own reachability and accept shortcut suggestions from the hub (set auto-discovery-receiver enable), and a dynamic routing protocol, in practice BGP for every design this domain actually tests, running across the tunnel overlay so that routing can adapt automatically once a shortcut forms, since a shortcut that forms but has no routing pointing traffic at it accomplishes nothing.

ADVPN in a Hub-and-Spoke Network

The starting topology is ordinary hub-and-spoke IPsec, the same shape Part 11 covers, with every spoke tunneled to the hub and no spoke-to-spoke tunnels provisioned at all. ADVPN doesn’t replace this topology, it augments it: the hub-spoke tunnels remain the baseline path every spoke always has, and shortcuts are additive, opportunistic paths that form only when spoke-to-spoke traffic actually appears and persist only while that traffic continues.

ADVPN Shortcut Negotiation

The sequence, from first packet to established shortcut:

1. Spoke A sends traffic destined for a network behind Spoke B. Since no direct tunnel to B exists yet, this traffic initially routes through the hub, exactly as it would in a design with no ADVPN at all.
2. The hub, seeing this A-to-B traffic transit it, and knowing (via its ADVPN sender role) both A’s and B’s public tunnel endpoints, sends a shortcut-offer notification to both A and B, essentially introducing them and providing each spoke the other’s actual reachable IKE endpoint.
3. Spoke A and Spoke B negotiate a new IKE/IPsec SA directly with each other, using the endpoint information the hub provided, forming a genuine point-to-point tunnel that bypasses the hub entirely.
4. BGP, running across the newly-formed shortcut tunnel interface, advertises reachability across it, and once BGP converges on the shortcut as the better (typically shorter AS-path, or explicitly preferred via local preference) path, subsequent A-to-B traffic uses the shortcut directly rather than the original hub-relayed path.

The critical design point: the hub only ever facilitates shortcut formation, it never remains in the data path of an established shortcut. Once step 4 completes, hub load for that specific A-to-B conversation drops to essentially nothing, which is the entire performance case for building ADVPN in the first place.

ADVPN on FortiManager

Building ADVPN by hand across dozens of spokes, correctly configuring both auto-discovery-sender/receiver flags, matching IKE/IPsec proposals across every spoke, and matching BGP configuration for shortcut-aware routing on each one, is exactly the kind of replicated, error-prone configuration Part 6’s templating tools exist to eliminate. Fortinet auto-discovery VPN using FortiGate or FortiManager as a blueprint phrase draws this distinction deliberately: the protocol mechanics are identical either way, standalone-FortiGate-built ADVPN and FortiManager-templated ADVPN produce the same on-the-wire behavior, but only the FortiManager path scales to an enterprise spoke count without becoming an operational liability.

ADVPN Using the FortiManager VPN Manager, and IPsec Templates

The VPN Manager module and the IPsec templates from Part 6 both apply to ADVPN specifically: an IPsec template’s hub-and-spoke topology option, combined with auto-discovery-sender/receiver settings expressed once at the template level rather than per-spoke, is what actually makes a fifty-spoke ADVPN design a template-and-metadata-variable exercise rather than fifty hand-built spoke configurations repeating the same ADVPN-enabling flags with only endpoint addressing differing.

SD-WAN Support for ADVPN

ADVPN shortcut tunnel interfaces, once formed, are ordinary SD-WAN zone members like any other tunnel interface from Part 10’s perspective, participating in the same rule matching, SLA health checks, and steering logic as a statically-provisioned tunnel. The practical consequence: an SD-WAN rule doesn’t need special ADVPN-aware configuration to benefit from a shortcut once it forms, BGP’s own preference for the shorter path, combined with SD-WAN’s normal member health evaluation, is sufficient for traffic to naturally prefer the shortcut the moment it’s viable.

Designing a Network with SD-WAN and ADVPN

Shortcut Timeout, Delay for Shortcut Failback, and Dependent Shortcuts

Three lifecycle parameters govern how long-lived a shortcut actually is, and getting them wrong produces either wasted tunnel churn or unnecessarily persistent tunnels carrying no real traffic:

• Shortcut timeout: a shortcut idle beyond its configured timeout is torn down automatically, freeing the resources (and the two spokes’ available tunnel capacity) it was consuming for traffic that’s no longer occurring.
• Delay for shortcut failback: if a shortcut fails (the direct path between two spokes degrades or drops), traffic falls back to the hub-relayed path immediately, but a configured delay before attempting shortcut renegotiation again prevents rapid, repeated shortcut-formation attempts against a still-degraded direct path, avoiding a flapping cycle of formation, failure, and immediate reattempt.
• Dependent shortcuts: in some multi-hub or multiregion designs, a shortcut’s viability genuinely depends on another shortcut or tunnel already being established (a shortcut routed via one hub’s ADVPN domain that only makes sense while that hub relationship is active); dependent shortcut handling ensures a shortcut that’s lost its own prerequisite gets torn down rather than persisting as a stale, effectively orphaned tunnel.

Hub-and-Spoke Topologies Using ADVPN with IBGP

The simplest working ADVPN routing design: every spoke and the hub share a single BGP AS, running iBGP between hub and each spoke. The hub, as the only device every spoke already has a direct session with, naturally acts as an iBGP route reflector (Part 9’s route reflection mechanism, applied here specifically), reflecting each spoke’s advertised routes to every other spoke so that every spoke has full reachability information for every other spoke, the prerequisite for step 4 of shortcut negotiation to actually resolve to a usable route once a shortcut forms.

Dual Hub-and-Spoke Topologies Using ADVPN with IBGP and EBGP

Extending to dual hubs, per Part 11’s dual-hub topology, typically means iBGP within each hub’s own ADVPN domain (spokes iBGP to their local hub, as above) combined with eBGP between the two hubs themselves, each hub representing a genuinely distinct AS from the other’s perspective. This combination, iBGP hub-to-spoke, eBGP hub-to-hub, is the standard shape for a dual-hub ADVPN design and is exactly the kind of topology-to-BGP-design mapping question this exam’s routing-and-IPsec-integration scenarios are built around.

Alternative Overlay and Routing Designs for ADVPN

BGP on Loopback Design

Same principle as Part 9’s general loopback-sourcing guidance, applied specifically to ADVPN: sourcing each spoke’s BGP session from a loopback rather than the tunnel interface’s own address means a shortcut renegotiating (a new tunnel interface effectively replacing the old one) doesn’t require BGP to re-establish from scratch, since the loopback-sourced session’s addressing didn’t change even though the underlying tunnel did. SD-WAN Resilience Part 6 builds this exact pattern in a working dual-active ADVPN design, worth reading as the concrete implementation of everything this section is describing in the abstract.

ADVPN Without BGP Route Reflection

An alternative to hub-as-route-reflector: a full iBGP mesh between every spoke directly, without hub reflection at all. This avoids the hub as a control-plane dependency for route propagation (though it remains a data-plane dependency for any traffic not yet shortcut), at the obvious cost of the same O(n²) full-mesh scaling problem the BGP Deep Dive covers as the entire reason route reflection exists in the first place. This design is rarely the right choice at any meaningful spoke count, and the exam’s framing of it as an “alternative” rather than a recommended pattern reflects that: it’s presented for completeness and for the specific narrow case (very small spoke counts, or a design deliberately avoiding hub dependency for control-plane resilience reasons) where it might actually be justified.

Dynamic BGP

Dynamic BGP (set neighbor-range combined with a neighbor-group, from Part 9) lets the hub accept BGP sessions from spokes it hasn’t individually pre-configured a config neighbor entry for, matching new spokes by address range instead. This is what makes ADVPN genuinely operationally scalable in combination with ZTP from Part 6: a newly-provisioned spoke, once it completes ZTP and brings up its hub tunnel, can establish BGP without the hub’s own configuration needing a matching manual update for that specific new spoke’s address.

ADVPN 1.0 Challenges, and What 2.0 Actually Changes

ADVPN 1.0 (the mechanism described through this entire post) has two structural limitations the blueprint calls out by name. First, shortcut decisions are fundamentally reactive and relatively simple: a shortcut forms because traffic happened to transit the hub, with limited intelligence about whether that traffic pattern is likely to recur or was a one-off. Second, in genuinely large or multiregion topologies, the volume of shortcut negotiation and the resulting BGP churn as shortcuts form and expire can itself become a meaningful control-plane load.

ADVPN 2.0 addresses this with intelligence distributed across the SD-WAN network rather than concentrated reactively at the hub: shortcut decisions incorporate a broader view of traffic patterns and can be triggered more deliberately rather than purely reactively, and 2.0 is described in Fortinet’s own materials as natively integrated with SD-WAN rather than layered underneath it, meaning shortcut formation and SD-WAN rule evaluation are aware of each other more directly than in the 1.0 model, where SD-WAN treated a shortcut as just another tunnel member once it happened to exist. The blueprint’s own phrasing, “ADVPN 2.0 overlay placeholders,” refers to the design-time template mechanism, an overlay template can pre-define where 2.0 shortcuts are expected to form (spoke-to-spoke, spoke-to-region, or scoped further) rather than 2.0’s intelligence operating with zero prior structure, which is the practical difference between “smarter reactive shortcuts” and genuinely designed-in shortcut behavior.

What Part 13 Ties Together

Twelve parts of individually-scoped domains end here. Part 13 builds a single multiregion, dual-hub, ADVPN-enabled, VDOM-segmented design from the ground up, the kind of topology a real scenario question describes in one dense paragraph and expects a coherent answer to, then walks the diagnostic commands that confirm each layer of it is actually working as designed.