Overlapping Branch Subnets Break ADVPN Shortcuts

ADVPN shortcuts are built from routing information. The hub looks at its route for the destination prefix, identifies the tunnel next hop that owns it, and offers the spoke a shortcut to that peer. The whole mechanism is destination-based, so it can only work when a prefix maps to exactly one peer.

With 10.0.50.0/24 advertised by two spokes, the hubs hold two BGP paths for one prefix and install exactly one best path, selected by the usual attributes: weight, local preference, AS-path length, origin, MED, then eBGP or iBGP preference and finally router ID. Nothing in that comparison knows which branch the packet was really meant for. The result is deterministic but wrong for half the traffic: packets destined for the new branch's server farm are forwarded down the tunnel belonging to the branch that won best-path, and are dropped there because that branch has no such host, or because the packet arrives on an interface that does not own the destination.

The shortcut does not form for the same reason plus one more. With only one best path, the hub can only advertise one shortcut target. Additionally, each spoke has 10.0.50.0/24 as a connected route, and a connected route beats any learned overlay route, so a spoke would reject or ignore a shortcut for a prefix it believes it owns. There is no SD-WAN rule, health-check setting, or BGP timer that resolves this; the ambiguity is in the addressing, not the protocol tuning.

Three options are worth evaluating.

• Source NAT at the new branch. Translate 10.0.50.0/24 to a unique range such as 10.251.50.0/24 before it enters the overlay, so the hubs see a prefix that maps to one peer and BGP becomes unambiguous. This is fast and needs no hub VDOM work. It breaks if the legacy servers must be reached inbound by address, because return traffic needs destination NAT somewhere that knows which 10.0.50.0/24 is meant, and the hub cannot know that. It also breaks any application that embeds addresses in payloads.
• Isolate the new branch in a dedicated VDOM on both hubs. Each VDOM runs its own routing table and BGP process, so the overlapping prefix appears once per VDOM and best-path is unambiguous. Inter-VDOM links and firewall policies connect it to shared services. The trade-off is operational: more objects to manage, and ADVPN shortcuts generally do not form across VDOM boundaries, so this branch stays hub-and-spoke for three months. For 85 branches, creating a VDOM per overlapping site does not scale indefinitely.
• Re-address now. Cleanest, blocked by the hard-coded application, and therefore the target state rather than the interim.

Recommendation: use VDOM isolation on the hubs for this branch, because it preserves inbound reachability to the server farm, which source NAT cannot do without fragile double-NAT. Scope it tightly, document it as temporary, and pair it with a project to fix the application and retire the VDOM. Accept hub-and-spoke latency for this branch and say so explicitly in the risk register.

The process gap is that nobody compared the proposed branch prefix against the existing routing domain before the tunnel was built.

Add these gates to onboarding:

• IPAM check against all existing branch, data-centre and cloud prefixes, with an explicit approval step when a duplicate is found. The output should be a signed-off address plan, not a verbal agreement.
• Overlay advertisement check: what exactly will this branch advertise into BGP, and does any hub already hold a route for it? Confirm with a route lookup on both hubs before cutover, not after.
• ADVPN role check: hubs configured as auto-discovery senders, spokes as receivers, and a documented statement of which prefixes are eligible for shortcuts.
• A lab or staging test of spoke-to-spoke reachability and inbound access to any server farm, with results attached to the change record.

After the change, verify in this order: get router info bgp network 10.0.50.0 on both hubs to confirm the prefix now resolves to one peer per routing table; diagnose vpn ike gateway list and diagnose vpn tunnel list to confirm both tunnels are up and the correct selectors are installed; a traceroute from the new branch to the nearby branch to confirm the expected path, hub-and-spoke in this case; and application-level tests from the branch to the legacy server farm and in the reverse direction. Use FortiManager install preview and a saved revision so rollback is a single reinstall. Record the residual risks, especially the absence of shortcuts for this branch, in the change closure.