Inter-Region ADVPN Shortcuts with a Default-Only Overlay
Global freight forwarder runs 40 offices on FortiGate 80F spokes and two FortiGate 200F hubs in Frankfurt and Singapore. The overlay is ADVPN with iBGP; both hubs are route reflectors in the same private AS. European offices peer with Frankfurt and APAC offices with Singapore. Each spoke advertises its /24 LAN; the hubs advertise only a default route into the overlay. Intra-region shortcuts form, but a traceroute from a Frankfurt spoke to a Singapore spoke goes through Frankfurt hub and then Singapore hub, never direct. diagnose vpn ike gateway list on the Frankfurt spoke shows only the two hub tunnels. Hub firewall policies permit spoke-to-spoke traffic. The business wants direct inter-region shortcuts for file transfers without losing the default route that keeps internet traffic at the hubs.
1. Why do intra-region shortcuts work but inter-region shortcuts not?
Read the worked answer
ADVPN shortcuts need the spoke to have a specific route to the remote LAN and a known remote public address. If the hubs advertise only a default, the Frankfurt spoke sends all non-local traffic, including Singapore /24s, to the default next-hop, the Frankfurt hub. There is no specific route to trigger a shortcut. Intra-region shortcuts may work because the hub advertises the regional summary or specific routes, or because the shortcut is triggered within the same hub discovery domain. Check get router info bgp network on the spoke: if the Singapore prefix is learned only as a default, no shortcut. Also check whether the hub rewrites next-hop to itself; if so, the spoke cannot identify the remote peer. The fix is to advertise specific prefixes or controlled summaries for the other region while keeping the default for internet.
2. What BGP and ADVPN changes do you make, and how do you avoid a routing loop?
Read the worked answer
Allow the hubs to reflect inter-region prefixes to the spokes, or add a second BGP session between hubs and advertise a regional summary. Preserve next-hop for spoke routes so the receiving spoke can trigger the shortcut; do not set next-hop-self on those routes, or use a route map to preserve it. Keep the default only from the hubs and filter it from spokes. Add route maps so a spoke never advertises a hub-learned prefix back to the hub, and set maximum-prefix. On the ADVPN side, ensure both hubs are senders and spokes are receivers, and that the shortcut search mode covers the learned prefixes. Test with get router info bgp network, diagnose vpn ike gateway list, and a traceroute; the first packet may still go via the hub while the shortcut is built.
3. How do you test this without losing the internet default route, and what is the rollback?
Read the worked answer
Test on one European and one APAC spoke. Confirm the default is still learned only from the regional hub, then confirm the remote region prefix is learned with the remote spoke next-hop. Generate a file transfer and watch diagnose vpn ike gateway list for a new shortcut and diagnose sys sdwan service for member selection. A traceroute should switch from hub-hub to direct after the shortcut establishes. If the default is lost or the spokes start preferring each other for internet, roll back the route map on the hubs, not the spoke BGP sessions. Keep the FortiManager revision before the change and reinstall the previous policy package if the pilot fails. Do not advertise a global default from both hubs into both regions without a clear primary and backup policy.