Dual-Hub ADVPN — Build Guide

Architecture & addressing

Sanitized for publication: interface names, hostnames and public IPs are generic. Public IPs use the IANA documentation ranges 198.51.100.0/24 and 203.0.113.0/24 (RFC 5737); overlay ranges and internal RFC 1918 LANs are illustrative. Keys shown as <PSK>.

Four overlays in total — a dual-homed spoke joins all four. HUB1's two overlays sit on separate physical interfaces, so it needs no network-id; HUB2 runs both overlays on one interface, so it uses network-id 5/6 to keep them apart.

Overlay	Hub / transport	Overlay subnet	Hub tunnel IP	network-id
OVL-A	HUB1 · `wan1`	`172.16.3.0/24`	`172.16.3.254`	—
OVL-B	HUB1 · `wan2`	`172.16.4.0/24`	`172.16.4.254`	—
OVL-C	HUB2 · `wan1`	`172.16.5.0/24`	`172.16.5.254`	`5`
OVL-D	HUB2 · `wan1`	`172.16.6.0/24`	`172.16.6.254`	`6`

Underlay transports:

Device	Interface	IP	Role
HUB1	`wan1`	`198.51.100.2/28` (gw `.1`)	WAN 1 / OVL-A / TO-HUB2-1
HUB1	`wan2`	`198.51.100.18/28` (gw `.17`)	WAN 2 / OVL-B / TO-HUB2-2
HUB2	`wan1`	`10.255.0.4/26` — public `203.0.113.10` via cloud NAT	single WAN
HUB2	`lan1`	`10.255.0.68/26` (gw `.65`)	LAN toward HUB2 networks

Inter-hub static tunnels:

Tunnel	HUB1 end	HUB2 end	Overlay	BGP
1	`TO-HUB2-1` · wan1 · `172.18.3.254` · gw→`203.0.113.10`	`TO-HUB1-1` · wan1 · `172.18.3.253` · gw→`198.51.100.2`	`172.18.3.0/24`	`.253` ⟷ `.254`
2	`TO-HUB2-2` · wan2 · `172.18.4.254` · gw→`203.0.113.10`	`TO-HUB1-2` · wan1 · `172.18.4.253` · gw→`198.51.100.18`	`172.18.4.0/24`	`.253` ⟷ `.254`

Part 1

HUB1 — on-prem, dual-WAN

One overlay anchored to each WAN link, so a single ISP failure drops only one overlay. Route reflector for its own spokes; BFD for fast failure detection.

1.1

WAN underlay

What it does

Two independent uplinks that the overlays ride on.

Why it's needed

ADVPN tunnels are sourced from these; two links make it a dual-WAN hub so one ISP failure takes down only one overlay.

config system interface

config system interface
    edit "wan1"
        set alias "WAN1"
        set ip 198.51.100.2 255.255.255.240
        set allowaccess speed-test
        set role wan
    next
    edit "wan2"
        set alias "WAN2"
        set ip 198.51.100.18 255.255.255.240
        set allowaccess speed-test
        set role wan
    next
end

1.2

ADVPN hub tunnels — Phase 1 (one per WAN)

The key ADVPN settings

auto-discovery-sender enable — makes it a hub; sends shortcut messages so spokes build direct tunnels.
type dynamic + net-device disable — one dial-up interface serves all spokes.
add-route disable — routing is left entirely to BGP.

config vpn ipsec phase1-interface

config vpn ipsec phase1-interface
    edit "OVL-A"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set proposal aes256-sha512
        set add-route disable
        set dpd on-idle
        set dhgrp 30 14
        set auto-discovery-sender enable
        set dpd-retryinterval 5
        set psksecret <PSK>
    next
    edit "OVL-B"
        set type dynamic
        set interface "wan2"
        set ike-version 2
        set peertype any
        set net-device disable
        set proposal aes256-sha512
        set add-route disable
        set dpd on-idle
        set dhgrp 30 14
        set auto-discovery-sender enable
        set dpd-retryinterval 5
        set psksecret <PSK>
    next
end

1.3

Phase 2

What it does

The IPsec SA for each overlay.

Why it's needed

No subnet selectors (default 0.0.0.0/0) so routing, not the SA, decides what crosses — required for ADVPN.

config vpn ipsec phase2-interface

config vpn ipsec phase2-interface
    edit "OVL-A-p2"
        set phase1name "OVL-A"
        set proposal aes256-sha512
        set pfs disable
    next
    edit "OVL-B-p2"
        set phase1name "OVL-B"
        set proposal aes256-sha512
        set pfs disable
    next
end

1.4

Overlay interface IPs + BFD

What it does

Hub overlay IP per tunnel, with BFD enabled.

Why it's needed

Hub IP is a /32 while remote-ip carries the /24, so the whole overlay is reachable and BGP can peer any spoke. BFD gives sub-second failure detection.

config system interface

config system interface
    edit "OVL-A"
        set ip 172.16.3.254 255.255.255.255
        set remote-ip 172.16.3.253 255.255.255.0
        set allowaccess ping snmp speed-test
        set bfd enable
        set type tunnel
        set interface "wan1"
    next
    edit "OVL-B"
        set ip 172.16.4.254 255.255.255.255
        set remote-ip 172.16.4.253 255.255.255.0
        set allowaccess ping snmp speed-test
        set bfd enable
        set type tunnel
        set interface "wan2"
    next
end

1.5

BGP — route reflector, dynamic peering, additional-path

Why it's needed — the ADVPN-critical parts

neighbor-range — auto-peers dynamic spokes into the right per-overlay group.
route-reflector-client — lets the hub relay one spoke's routes to the others in a single AS.
additional-path send + adv-additional-path 255 — advertises the same destination over both overlays for redundancy and shortcuts.

config router bgp

config router bgp
    set as 65505
    set keepalive-timer 5
    set holdtime-timer 15
    set ibgp-multipath enable
    set additional-path enable
    set additional-path-select 255
    # (see Part 7 — consider: set recursive-next-hop enable, to match HUB2)

    config neighbor-group
        edit "OVL-A"
            set advertisement-interval 1
            set link-down-failover enable
            set soft-reconfiguration enable
            set remote-as 65505
            set route-map-out "OVL-A"
            set additional-path send
            set adv-additional-path 255
            set route-reflector-client enable
        next
        edit "OVL-B"
            set advertisement-interval 1
            set link-down-failover enable
            set soft-reconfiguration enable
            set remote-as 65505
            set route-map-out "OVL-B"
            set additional-path send
            set adv-additional-path 255
            set route-reflector-client enable
        next
    end

    config neighbor-range
        edit 3
            set prefix 172.16.3.0 255.255.255.0
            set neighbor-group "OVL-A"
        next
        edit 4
            set prefix 172.16.4.0 255.255.255.0
            set neighbor-group "OVL-B"
        next
    end

    config network
        edit 1
            set prefix 10.200.1.0 255.255.255.0
        next
        # ... all HUB1 local / enterprise LAN prefixes ...
    end
end

1.6

Inter-overlay loop prevention

What it does

Denies re-advertising any route whose next-hop is on the other overlay.

Why it's needed

Both overlays share one AS on one hub; without this, OVL-A routes would be reflected out OVL-B and a dual-homed spoke could loop.

config router prefix-list / route-map

config router prefix-list
    edit "OVL-A"
        config rule
            edit 1
                set prefix 172.16.3.0 255.255.255.0
                set le 32
            next
        end
    next
    edit "OVL-B"
        config rule
            edit 1
                set prefix 172.16.4.0 255.255.255.0
                set le 32
            next
        end
    next
end

config router route-map
    edit "OVL-A"
        config rule
            edit 3
                set action deny
                set match-ip-nexthop "OVL-B"
            next
            edit 4
            next
        end
    next
    edit "OVL-B"
        config rule
            edit 3
                set action deny
                set match-ip-nexthop "OVL-A"
            next
            edit 4
            next
        end
    next
end

1.7

Overlay-affinity policy routes + BFD neighbors

What it does

Pins traffic ingressing an overlay to egress the same overlay; static BFD neighbors per spoke IP.

Why it's needed

Keeps each overlay's flows symmetric (avoids RPF issues), and BFD triggers immediate BGP withdrawal on spoke failure.

config router policy / bfd

config router policy
    edit 1
        set input-device "OVL-A"
        set output-device "OVL-A"
    next
    edit 2
        set input-device "OVL-B"
        set output-device "OVL-B"
    next
end

config router bfd
    config neighbor
        edit 172.16.3.2
            set interface "OVL-A"
        next
        # ... 172.16.3.x spokes on OVL-A ...
        edit 172.16.4.2
            set interface "OVL-B"
        next
        # ... 172.16.4.x spokes on OVL-B ...
    end
end

1.8

Blackhole supernets + default route

What it does

Distance-250 blackholes for the overlay space; default route out the WAN zones.

Why it's needed

Traffic to a down overlay is dropped, never sent to the Internet. The WAN-zone default is Internet egress only — not part of ADVPN.

config router static

config router static
    edit 9
        set dst 172.16.0.0 255.255.248.0
        set distance 250
        set blackhole enable
    next
    edit 10
        set dst 172.18.0.0 255.255.248.0
        set distance 250
        set blackhole enable
    next
    edit 4
        set distance 1
        set sdwan-zone "wan-zone1" "wan-zone2" "wan-zone3"
    next   # Internet egress only (not part of ADVPN)
end

Part 2

HUB2 — cloud VM, single WAN

Same ADVPN philosophy as HUB1, but both overlays share one interface — so they're separated by network-id. Route reflector for its own spokes.

2.1

WAN / LAN interfaces

What it does

wan1 is the cloud external NIC (private IP; public 203.0.113.10 mapped by cloud NAT); lan1 faces internal networks.

Why it's needed

Both overlays and both inter-hub tunnels are sourced from the single wan1.

config system interface

config system interface
    edit "wan1"
        set alias "WAN"
        set description "external"
        set ip 10.255.0.4 255.255.255.192
        set allowaccess speed-test
        set monitor-bandwidth enable
    next
    edit "lan1"
        set alias "LAN"
        set description "internal"
        set ip 10.255.0.68 255.255.255.192
        set allowaccess ping https ssh speed-test
    next
end

2.2

ADVPN hub tunnels — both on `wan1`, split by network-id

What's different from HUB1

network-overlay enable + network-id 5/6 — distinguishes the two overlays that share one interface.
mode-cfg enable / assign-ip disable — one dynamic interface serving many spokes.
Everything else (auto-discovery-sender, net-device disable, add-route disable) matches HUB1.

config vpn ipsec phase1-interface

config vpn ipsec phase1-interface
    edit "OVL-C"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal aes256-sha512
        set add-route disable
        set dpd on-idle
        set dhgrp 30 14
        set auto-discovery-sender enable
        set network-overlay enable
        set network-id 5
        set assign-ip disable
        set dpd-retryinterval 5
        set psksecret <PSK>
    next
    edit "OVL-D"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal aes256-sha512
        set add-route disable
        set dpd on-idle
        set dhgrp 30 14
        set auto-discovery-sender enable
        set network-overlay enable
        set network-id 6
        set assign-ip disable
        set dpd-retryinterval 5
        set psksecret <PSK>
    next
end

2.3

Phase 2

config vpn ipsec phase2-interface

config vpn ipsec phase2-interface
    edit "OVL-C"
        set phase1name "OVL-C"
        set proposal aes256-sha512
        set pfs disable
    next
    edit "OVL-D"
        set phase1name "OVL-D"
        set proposal aes256-sha512
        set pfs disable
    next
end

2.4

Overlay interface IPs

What it does

Same /32 + /24 remote-ip pattern as HUB1.

Note

No BFD here — HUB2 uses a link-monitor to HUB1's overlay IPs instead (see Part 7).

config system interface

config system interface
    edit "OVL-C"
        set ip 172.16.5.254 255.255.255.255
        set remote-ip 172.16.5.253 255.255.255.0
        set allowaccess ping speed-test
        set type tunnel
        set interface "wan1"
    next
    edit "OVL-D"
        set ip 172.16.6.254 255.255.255.255
        set remote-ip 172.16.6.253 255.255.255.0
        set allowaccess ping speed-test
        set type tunnel
        set interface "wan1"
    next
end

2.5

BGP — route reflector for HUB2 spokes

What it does

Same AS, RR clients, additional-path as HUB1.

What's added

recursive-next-hop enable, and each neighbor-group is bound to its interface.

config router bgp

config router bgp
    set as 65505
    set keepalive-timer 5
    set holdtime-timer 15
    set ibgp-multipath enable
    set additional-path enable
    set recursive-next-hop enable
    set additional-path-select 255

    config neighbor-group
        edit "OVL-C"
            set advertisement-interval 1
            set link-down-failover enable
            set soft-reconfiguration enable
            set interface "OVL-C"
            set remote-as 65505
            set route-map-out "OVL-C"
            set additional-path send
            set adv-additional-path 255
            set route-reflector-client enable
        next
        edit "OVL-D"
            set advertisement-interval 1
            set link-down-failover enable
            set soft-reconfiguration enable
            set interface "OVL-D"
            set remote-as 65505
            set route-map-out "OVL-D"
            set additional-path send
            set adv-additional-path 255
            set route-reflector-client enable
        next
    end

    config neighbor-range
        edit 3
            set prefix 172.16.5.0 255.255.255.0
            set neighbor-group "OVL-C"
        next
        edit 4
            set prefix 172.16.6.0 255.255.255.0
            set neighbor-group "OVL-D"
        next
    end

    config network
        edit 1
            set prefix 10.255.0.0 255.255.255.0
        next
        edit 2
            set prefix 10.216.0.0 255.255.248.0
        next
        # ... other HUB2 internal prefixes ...
        edit 11
            set prefix 172.16.5.0 255.255.255.0
        next
        edit 12
            set prefix 172.16.6.0 255.255.255.0
        next
    end
end

2.6

Inter-overlay loop prevention

Review item

The OVL-D rule below uses match-ip-address where every other equivalent rule uses match-ip-nexthop. For consistent next-hop loop prevention it should be match-ip-nexthop — corrected block in Part 7.

config router prefix-list / route-map

config router prefix-list
    edit "OVL-C"
        config rule
            edit 1
                set prefix 172.16.5.0 255.255.255.0
                set le 32
            next
        end
    next
    edit "OVL-D"
        config rule
            edit 1
                set prefix 172.16.6.0 255.255.255.0
                set le 32
            next
        end
    next
end

config router route-map
    edit "OVL-C"
        config rule
            edit 3
                set action deny
                set match-ip-nexthop "OVL-D"
            next
            edit 4
            next
        end
    next
    edit "OVL-D"
        config rule
            edit 3
                set action deny
                set match-ip-address "OVL-C"     # <-- see review note
            next
            edit 4
            next
        end
    next
end

2.7

Overlay-affinity policy routes

config router policy

config router policy
    edit 1
        set input-device "OVL-C"
        set output-device "OVL-C"
    next
    edit 2
        set input-device "OVL-D"
        set output-device "OVL-D"
    next
end

2.8

Static routes — internal reach, blackholes, default

What it does

Points advertised prefixes at the internal next-hop via lan1; default toward the cloud fabric; blackholes the overlay supernets.

Why it's needed

Overlay traffic is dropped when no specific route is up, and the BGP-advertised prefixes have a real forwarding path.

config router static

config router static
    edit 1
        set gateway 10.255.0.1
        set device "wan1"
    next
    edit 2
        set dst 10.255.0.0 255.255.255.0
        set gateway 10.255.0.65
        set device "lan1"
    next
    edit 3
        set dst 10.216.0.0 255.255.248.0
        set gateway 10.255.0.65
        set device "lan1"
    next
    # ... additional internal prefixes via 10.255.0.65 / lan1 ...
    edit 18
        set dst 172.16.0.0 255.255.255.0
        set distance 250
        set blackhole enable
    next
    edit 19
        set dst 172.16.0.0 255.255.248.0
        set distance 250
        set blackhole enable
    next
    edit 20
        set dst 172.18.0.0 255.255.248.0
        set distance 250
        set blackhole enable
    next
end

Part 3

Inter-hub static site-to-site

Two static (non-ADVPN) tunnels, one anchored to each HUB1 WAN, both landing on HUB2's single wan1. iBGP runs over each, and each hub advertises only its own prefixes — which is what stops the hubs from leaking into each other.

3.1

HUB1 end — `TO-HUB2-1/2`

phase1 / phase2 / interface

config vpn ipsec phase1-interface
    edit "TO-HUB2-1"
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device enable
        set proposal aes256-sha512
        set dhgrp 30 14
        set remote-gw 203.0.113.10          # HUB2 public IP
        set psksecret <PSK>                  # must match HUB2 "TO-HUB1-1"
    next
    edit "TO-HUB2-2"
        set interface "wan2"
        set ike-version 2
        set peertype any
        set net-device enable
        set proposal aes256-sha512
        set dhgrp 30 14
        set remote-gw 203.0.113.10
        set psksecret <PSK>                  # must match HUB2 "TO-HUB1-2"
    next
end

config system interface
    edit "TO-HUB2-1"
        set ip 172.18.3.254 255.255.255.255
        set remote-ip 172.18.3.253 255.255.255.0
        set type tunnel
        set interface "wan1"
    next
    edit "TO-HUB2-2"
        set ip 172.18.4.254 255.255.255.255
        set remote-ip 172.18.4.253 255.255.255.0
        set type tunnel
        set interface "wan2"
    next
end

HUB1 advertises ONLY its own prefixes to HUB2

config router prefix-list
    edit "ROUTES-TO-HUB2"
        config rule
            edit 1
                set prefix 10.200.1.0 255.255.255.0
                set le 32
            next
            # ... only HUB1 local nets ...
        end
    next
end
config router route-map
    edit "ROUTES-TO-HUB2"
        config rule
            edit 1
                set match-ip-address "ROUTES-TO-HUB2"
            next
        end
    next
end
config router bgp
    config neighbor
        edit "172.18.3.253"
            set interface "TO-HUB2-1"
            set remote-as 65505
            set update-source "TO-HUB2-1"
            set soft-reconfiguration enable
            set route-map-out "ROUTES-TO-HUB2"
        next
        edit "172.18.4.253"
            set interface "TO-HUB2-2"
            set remote-as 65505
            set update-source "TO-HUB2-2"
            set soft-reconfiguration enable
            set route-map-out "ROUTES-TO-HUB2"
        next
    end
end

3.2

HUB2 end — `TO-HUB1-1/2` (both on wan1)

Mirror of HUB1

Fixed remote-gw back to each HUB1 WAN IP; tunnel IPs are the .253 side; BGP peers HUB1's .254.

Note

ROUTES-TO-HUB1 has a 0.0.0.0/0 permit, but no default is originated — so none is actually sent today.

phase1 / interface

config vpn ipsec phase1-interface
    edit "TO-HUB1-1"
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device enable
        set proposal aes256-sha512
        set dhgrp 30 14
        set remote-gw 198.51.100.2          # HUB1 wan1
        set psksecret <PSK>                  # must match HUB1 "TO-HUB2-1"
    next
    edit "TO-HUB1-2"
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device enable
        set proposal aes256-sha512
        set dhgrp 30 14
        set remote-gw 198.51.100.18         # HUB1 wan2
        set psksecret <PSK>                  # must match HUB1 "TO-HUB2-2"
    next
end

config system interface
    edit "TO-HUB1-1"
        set ip 172.18.3.253 255.255.255.255
        set remote-ip 172.18.3.254 255.255.255.0
        set type tunnel
        set interface "wan1"
    next
    edit "TO-HUB1-2"
        set ip 172.18.4.253 255.255.255.255
        set remote-ip 172.18.4.254 255.255.255.0
        set type tunnel
        set interface "wan1"
    next
end

HUB2 advertises ONLY its own prefixes to HUB1

config router route-map
    edit "ROUTES-TO-HUB1"
        config rule
            edit 1
                set match-ip-address "ROUTES-TO-HUB1"
            next
        end
    next
end
config router bgp
    config neighbor
        edit "172.18.3.254"
            set interface "TO-HUB1-1"
            set remote-as 65505
            set update-source "TO-HUB1-1"
            set soft-reconfiguration enable
            set route-map-out "ROUTES-TO-HUB1"
        next
        edit "172.18.4.254"
            set interface "TO-HUB1-2"
            set remote-as 65505
            set update-source "TO-HUB1-2"
            set soft-reconfiguration enable
            set route-map-out "ROUTES-TO-HUB1"
        next
    end
end

Part 4

Firewall policy — routing traffic between the tunnels

ADVPN only works if the firewall permits traffic to arrive on one tunnel and leave on another. That covers spoke-to-spoke shortcuts, spoke-to-LAN, and the hub-to-hub transit that lets a spoke on one hub reach a spoke on the other.

4.1

Zones & policies (applies to both hubs)

Reality check

In the source configs this is satisfied by a single wide-open catch-all on each hub — any → any, all/all, accept. It works, but it's permissive; the zone-based set below is the recommended tightening.

as-is on both hubs today

config firewall policy
    edit 1
        set name "Default"
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
end

Recommended — zones

Group the tunnels so one policy set covers both hubs. intrazone allow on OVERLAYS is what enables same-hub spoke-to-spoke without a per-pair rule.

Keep NAT off

No policy sets nat enable and no central-SNAT should match tunnel traffic — otherwise overlay/LAN subnets stop being reachable by their real addresses.

config system zone

config system zone
    edit "OVERLAYS"
        set intrazone allow                       # spoke-to-spoke on the same hub
        set interface "OVL-A" "OVL-B"             # HUB2: "OVL-C" "OVL-D"
    next
    edit "INTERHUB"
        set interface "TO-HUB2-1" "TO-HUB2-2"     # HUB2: "TO-HUB1-1" "TO-HUB1-2"
    next
end

config firewall policy · replace "LAN" with your local zone

config firewall policy
    edit 10
        set name "spokes-to-lan"
        set srcintf "OVERLAYS"
        set dstintf "LAN"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
    edit 11
        set name "lan-to-spokes"
        set srcintf "LAN"
        set dstintf "OVERLAYS"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
    edit 12
        set name "spokes-to-otherhub"
        set srcintf "OVERLAYS"
        set dstintf "INTERHUB"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
    edit 13
        set name "otherhub-to-spokes"
        set srcintf "INTERHUB"
        set dstintf "OVERLAYS"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
    edit 14
        set name "lan-to-otherhub"
        set srcintf "LAN"
        set dstintf "INTERHUB"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
    edit 15
        set name "otherhub-to-lan"
        set srcintf "INTERHUB"
        set dstintf "LAN"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set schedule "always"
    next
end

Cross-hub path

A HUB1 spoke reaching a HUB2 spoke transits both hubs: OVERLAYS → INTERHUB on HUB1, INTERHUB → OVERLAYS on HUB2 (reverse for return). Tighten srcaddr/dstaddr to your real supernets once it verifies.

How the two hubs work together

One AS, iBGP everywhere. The hubs peer over the two static tunnels; every spoke is an RR client of its hub overlay. Additional-path lets each hub reflect all next-hops, so spokes can build shortcuts over the best path.
Four overlays, four spoke addresses. A dual-homed spoke registers to all four tunnels and gets an address in 172.16.3–6.x; neighbor-ranges auto-peer them with no per-spoke config.
Loop prevention, two layers. Within a hub, per-overlay next-hop deny route-maps; between hubs, the ROUTES-TO-* filters so each hub sends only its own prefixes.
Blackhole supernets on both hubs drop overlay traffic when no specific route is up, so it never escapes to the Internet.

Bring-up order

Both hubs: WAN/LAN interfaces (1.1, 2.1).
Both hubs: ADVPN Phase 1/2 — HUB1 one per WAN; HUB2 both on wan1 with network-id 5/6 (1.2–1.3, 2.2–2.3).
Both hubs: overlay IPs (/32 + /24 remote-ip); BFD on HUB1 (1.4, 2.4).
Both hubs: BGP — same AS, RR clients, neighbor-range, additional-path (1.5, 2.5).
Both hubs: inter-overlay loop-prevention route-maps (1.6, 2.6).
Both hubs: overlay-affinity policy routes; HUB1 BFD neighbors (1.7, 2.7).
Both hubs: blackhole supernets + statics (1.8, 2.8).
Inter-hub: the four static tunnels + ROUTES-TO-* filters (3.1, 3.2) — verify each PSK matches its far end.
Both hubs: firewall policy permitting overlay traffic without NAT (Part 4).

Differences between the hubs

network-id only on HUB2. HUB2 needs it (shared interface); HUB1 doesn't. Cleaner to give every overlay a unique id across both hubs (e.g. A=1, B=2, C=5, D=6).
recursive-next-hop. On in HUB2, not HUB1 — consider enabling on HUB1 for parity.
Loop-prevention match type. HUB2's OVL-D uses match-ip-address; change to match-ip-nexthop "OVL-C" to match the others.
Failure detection. HUB1 uses BFD; HUB2 uses a link-monitor to HUB1's overlay IPs. Enable BFD on HUB2 for uniformly fast convergence.

Out of scope on both devices (present but not part of this dual-hub ADVPN): SD-WAN Internet egress, dial-up remote-access VPN, and a customer site-to-site tunnel.

Architecture & addressing

HUB1 — on-prem, dual-WAN

WAN underlay

ADVPN hub tunnels — Phase 1 (one per WAN)

Phase 2

Overlay interface IPs + BFD

BGP — route reflector, dynamic peering, additional-path

Inter-overlay loop prevention

Overlay-affinity policy routes + BFD neighbors

Blackhole supernets + default route

HUB2 — cloud VM, single WAN

WAN / LAN interfaces

ADVPN hub tunnels — both on wan1, split by network-id

Phase 2

Overlay interface IPs

BGP — route reflector for HUB2 spokes

Inter-overlay loop prevention

Overlay-affinity policy routes

Static routes — internal reach, blackholes, default

Inter-hub static site-to-site

HUB1 end — TO-HUB2-1/2

HUB2 end — TO-HUB1-1/2 (both on wan1)

Firewall policy — routing traffic between the tunnels

Zones & policies (applies to both hubs)

How the two hubs work together

Bring-up order

Differences between the hubs

ADVPN hub tunnels — both on `wan1`, split by network-id

HUB1 end — `TO-HUB2-1/2`

HUB2 end — `TO-HUB1-1/2` (both on wan1)