Description
This article describes how the redesigned ADVPN 2.0 overcomes the limitations and complexities encountered in ADVPN 1.0, offering a more efficient and streamlined solution.
Scope
FortiGate v7.4 +.
Solution
First, consider the previous version of ADVPN to understand the benefits of this new design. In the topology below, the Hub and Spoke use two internet links, ISP1 and ISP2. Both the Hub and Spoke have standard ADVPN and SD-WAN configurations applied.
Each spoke establishes two VPN tunnels to the Hub, and BGP peers using the tunnel IPs. Hub reflects the networks advertised by the spokes and on-demand tunnel is established between the spokes when there is traffic between the LAN networks.
If Spoke2's ISP1 experiences high latency, Spoke1 does not detect the issue and tries to establish a shortcut tunnel to Spoke 2's ISP1 link.
To mitigate this, the following configurations were implemented:
- Branch Overlay Preference
- The receiving branch advertises its preferred overlay for communication.
- The sending branch honors this preference whenever possible.
- Conditional Overlay Preference Advertisement
- The receiving branch advertises its preferred overlay only if the corresponding underlay meets SLA requirements.
- If the SLA is not met, it advertises a secondary overlay as a fallback.
- Sending Branch Override Decision
- The sending branch honors the remote branch’s overlay preference if the local overlay also meets SLA criteria.
- If the local overlay fails to meet the SLA, the sending branch chooses an alternative overlay.
BGP is extensively used to support this design, relying on complex mechanisms such as advertising communities and tags.
With the ADVPN 2.0 design, spokes can now share information about the health of the links. Based on this data, a spoke can select the optimal path and establish the shortcut tunnel to another spoke, considering local link health.
The initial setup is straightforward, with each spoke sending SLA probes to the Hub's loopback interface.During the shortcut tunnel negotiation, the shortcut reply includes this health information.
The originating spoke uses this data to decide which link to use for setting up the shortcut tunnel. In the below output, Spoke1 can see that in the shortcut reply, the health information embedded by Spoke2. The SD-WAN process will use this information and inform IKE which interface to use for shortcut tunnel.
After the shortcut tunnel is in place, an ICMP probe (auto health check) is exchanged between the spokes.
This method provides more accurate health measurements compared to the previous approach, which relied on SLA probes to the Hub’s loopback. Based on the updated health information, the originating spoke can trigger a new shortcut tunnel if it detects a better path to another spoke.
With the introduction of the dynamic BGP feature in FortiOS 7.4, spokes can establish BGP over shortcut tunnels. This eliminates the need for route reflection and add-path configuration on the Hub, which were previously required in ADVPN 1.0.
With this new design, ADVPN 2.0 enables spokes to discover each other’s health status and select the optimal path for shortcuts. Periodic health updates allow spokes to identify the best path for triggering new shortcuts. Additionally, SD-WAN now has visibility into other spokes’ health and topology, simplifying configurations by removing the need for complex BGP setups.
