Design A - BGP peering on the tunnel interfaces.
Each overlay carries its own BGP session. With N overlays per spoke, each spoke holds N independent iBGP sessions to the hub. Source and destination of TCP/179 are the overlay tunnel IPs. No loopback, no exchange-ip-addr4, and no cross-interface firewall policy for BGP are required — TCP/179 originates and terminates on the same tunnel interface.
Hub neighbor-groups (one per overlay):
config router bgp
set as 65000
set router-id 10.0.10.1
config neighbor-group
edit "Spokes-A"
set interface "ADVPN-A"
set remote-as 65000
set route-reflector-client enable
next
edit "Spokes-B"
set interface "ADVPN-B"
set remote-as 65000
set route-reflector-client enable
next
end
config neighbor-range
edit 0
set prefix 169.254.10.0 255.255.255.0
set neighbor-group "Spokes-A"
next
edit 0
set prefix 169.254.20.0 255.255.255.0
set neighbor-group "Spokes-B"
next
end
end
Spoke neighbors (one per overlay):
config router bgp
set as 65000
set router-id 169.254.10.2
config neighbor
edit "169.254.10.1"
set interface "ADVPN-A"
set remote-as 65000
next
edit "169.254.20.1"
set interface "ADVPN-B"
set remote-as 65000
next
end
end
Design B — BGP peering on loopback interfaces.
A dedicated /32 loopback per site hosts the BGP router-id and terminates the BGP session. The loopback is reachable through any of the available overlays via IKE-injected /32 routes ( set exchange-ip-adr4 <own loopback> in each phase1). With N overlays per spoke, the spoke still holds one iBGP session to the hub.
Hub neighbor-group:
config router bgp
set as 65000
set router-id 172.16.255.1
config neighbor-group
edit "Spokes"
set next-hop-self disable
set interface "BGP-LO"
set remote-as 65000
set update-source "BGP-LO"
set route-reflector-client enable
next
end
config neighbor-range
edit 0
set prefix 172.16.255.0 255.255.255.0
set neighbor-group "Spokes"
next
end
end
Spoke neighbor:
config router bgp
set as 65000
set router-id 172.16.255.2
config neighbor
edit "172.16.255.1"
set interface "BGP-LO"
set remote-as 65000
set update-source "BGP-LO"
next
end
end
Required components for Design B:
A loopback interface (BGP-LO) on every site. 'set exchange-ip-adr4 <own loopback>'Â in every phase1, so IKE injects the peer loopback as a /32 route over each tunnel. Firewall policies for BGP-LO <> ADVPN in both directions on every device. 'set next-hop-sel disable' on the hub neighbor-group, so spokes see the originating spoke's loopback as the next-hop (mandatory for ADVPN dependent shortcuts to fire).
A complete reference build for Design B is in the seed article (see Related Articles).
Comparison summary:
Criterion | Loopback (Design B) | Tunnel Interface (Design A) |
|---|
BGP sessions per spoke | 1 | N (one per overlay) | BGP sessions on hub (N spokes, M overlays) | N | N × M | Behavior on overlay loss | Session stays up via surviving overlay; no prefix flap | Session of the failed overlay drops; prefixes flap; hold-timer drives reconvergence | Convergence on overlay failure | Driven by SD-WAN healthcheck (sub-second feasible) | Driven by BGP keepalive/hold-timer unless BFD is added | ECMP across overlays | Native — same prefix learned once, recursive resolution to multiple /32 next-hops | Requires set ibgp-multipath enable and matching attributes from each overlay | ADVPN shortcut compatibility | Native with next-hop-self disable — spokes see remote spoke loopback as next-hop | Functional but more fragile; next-hop is an overlay IP, relies on recursive resolution | Route-map / policy application | Once per peer, applies to all underlying paths | Duplicated per overlay; risk of asymmetric policy | get router info bgp summary clarity | One line per peer | One line per peer per overlay | IP plan overhead | Requires a dedicated /32 block (typical: 172.16.255.0/24) | None — reuses overlay IPs | Firewall policy for BGP | Cross-interface policy required (BGP <> ADVPN) | Not required — same interface for source and destination | Initial configuration effort | Higher (loopback, exchange-ip-addr4, firewall policy, next-hop-self disable) | Lower (one neighbor per overlay, no extra interfaces) | Multi-hop BFD | Native between loopbacks | Single-hop BFD per overlay (multiplied) | Behavior under overlay maintenance / draining | Control-plane untouched; only data-plane redistributes | Half the prefixes withdrawn until reconvergence |
Verification:
The evidence below is from a reference lab (FortiOS 7.4.11, 1× HUB + 2× SPOKES, two underlays per site) running Design B.
One BGP session per spoke regardless of the number of overlays:
HUB # get router info bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.255.2 4 65000 1007 1013 6 0 0 03:39:35 2
172.16.255.3 4 65000 1005 1007 6 0 0 03:39:35 2
Two spokes, two overlays each, but only two BGP sessions on the hub. Under Design A the same topology would show four lines (one per overlay per spoke).
HUB # get router info bgp neighbors 172.16.255.2
BGP neighbor is 172.16.255.2, remote AS 65000, local AS 65000, internal link
BGP state = Established, up for 03:39:38
Update source is BGP-LO
Local host: 172.16.255.1, Local port: 179
Foreign host: 172.16.255.2, Foreign port: 9403
Nexthop interface: BGP-LO
Local host and Foreign host are the loopback IPs — proof that the session terminates on the loopbacks, not on the tunnel interfaces.
Loopback /32 learned via both overlays - native ECMP:
HUB # get router info routing-table all | grep 172.16.255
S 172.16.255.2/32 [15/0] via ADVPN-A tunnel 172.16.255.2
[15/0] via ADVPN-B tunnel 10.0.0.3
S 172.16.255.3/32 [15/0] via ADVPN-B tunnel 172.16.255.3
[15/0] via ADVPN-A tunnel 10.0.0.4
The remote loopback is reachable through both overlays. When one overlay drops, the BGP session continues via the other without re-establishing.
Notes: Default to loopback peering for any ADVPN with two or more overlays. The reduction in session count, the survival of the BGP session across overlay failures, and the cleaner route-policy attachment make it the conservative choice at scale. Tunnel-interface peering is acceptable for single-overlay or PoC deployments. When there is only one path, the resilience advantage of loopbacks disappears and the extra configuration overhead is not justified. Loopback peering requires 'set next-hop-self disable' on the hub neighbor-group when ADVPN dependent shortcuts are in use. Without it, spokes never see the remote spoke as next-hop and shortcuts do not form. Loopback peering requires firewall policy BGP-LO <> ADVPN in both directions. Without it, TCP/179 stays in Connect state — the local-in default does not cover cross-interface BGP. Use 'set exchange-ip-addr4 <own-loopback>' in every phase1. IKE injects the peer loopback as a /32 route per overlay, providing native ECMP with no static configuration. Both designs benefit from BFD. With tunnel-interface peering, BFD must be enabled per overlay neighbor; with loopback peering, multi-hop BFD between loopbacks covers all paths at once.
| 
