ADVPN Dual Hub with BGP on Loopback - Full meshed spokes

[JamesB]

Does anyone have a working cleaned config of ADVPN in a Dual Hub setup with BGP on Loopback and the spokes being full meshed to the Hubs?

I have everything setup and all tunnels are running, but when it comes to the SDWAN SLA's the Hub1 is currently only utilizing 1 overlay. Tags and Policy routing have been applied.

FortiNet doesn't have published configs on this setup (that I can find) due to the complexity however as of 7.0 (running 7.2.8) they do state in their design documents you no longer need the bgp per overlay, but I almost feel like I need to go back to not running BGP on the Loopbacks. 

Basically just seeing if anyone has BGP on loopback up and running when spokes are dual ISP'd with meshed connections to the Hubs.

Super simplified setup:

Spoke1 ISP1 -> Hub1 ISP1 net 1

Spoke1 ISP2 -> Hub1 ISP1 net 1

Spoke1 ISP1 -> Hub1 ISP2 net 2

Spoke1 ISP2 -> Hub1 ISP2 net 2

Spoke1 ISP1 -> Hub2 ISP1 net 3

Spoke1 ISP2 -> Hub2 ISP1 net 3

Hub1 net2 and Hub2 net3 are completely up and operational but hub1 net1 are full down even though debugs on the hub say it is responding to sla probes. So the only thing I can think of is there is something outside the kernel that has the overlays in like a failover type setup.

(hub2 doesn't have tunnels to its secondary ISP)

[spoojary]

There is an example in this doc: https://docs.fortinet.com/document/fortigate/7.4.2/administration-guide/256210/example-sd-wan-config...

https://docs.fortinet.com/document/fortigate/7.4.1/administration-guide/820072/advpn-with-bgp-as-the...

[JamesB]

Those are for 7.4 which has the advpn 2.0 in it, they also go back to utilizing ip addresses on the tunnels, vs sourcing from loopback, the hub also only has 1 wan. My hub with 1 wan works fine, my hub with 2 wans is what is broken. I think I may have hit a design limitation. Appreciate the doc link though, I may need to upgrade.

[JamesB · Accepted solution]

Solution was to split the Hubs into 4 total overlays instead of 2. I believe because the tunnels don't have IPs on them and everything is sourced from a loop-back the hubs were getting confused when a spoke wan1 and a spoke wan2 both arrived on hub wan1 in the same net-id.