BGP on loopback: limitations
On release 7.2 of FortiOS, the following limitations exist in the new BGP on loopback design compared to the BGP per overlay design:
Suboptimal support for segregated transports
-
In topologies that include several transports that are physically segregated from each other (the most common example being Internet and MPLS), in certain failure scenarios, traffic between two Spokes might not trigger an ADVPN shortcut during switchover. (It will flow through the Hub instead.)
-
The reason for this limitation is the inability of a Spoke to learn the status of the overlays on remote Spokes. Consider, for example, a classic topology with two underlay transports: Internet and MPLS. Let's assume that the Internet overlay must be used as a Primary on all the Spokes. The following situation might occur:
-
On Spoke-1, all overlays are healthy.
-
On Spoke-2, an Internet link is currently down, and therefore the Internet overlay is down too.
-
A new session starts from Spoke-1 to Spoke-2.
-
Since the Internet overlay is healthy on the Spoke-1, it is selected by its local SD-WAN rules.
However, no ADVPN shortcut can be established, since the Internet overlay is down on the Spoke-2. -
In this situation, an optimal behavior would be for the Spoke-1 to select the backup MPLS overlay, so that an ADVPN shortcut could be successfully established. Unfortunately, the Spoke-1 doesn't have enough information to make this choice.
It must be highlighted that, despite this limitation, the traffic will not be dropped. It will nevertheless reach its destination by flowing through the Hub!
-
Suboptimal support for route-tags in SD-WAN rules
-
Route-tags provide a useful mechanism integrating BGP with SD-WAN in our solution. This mechanism is described in detail in the SD-WAN strategy and dynamic routing section of this document.
-
As noted earlier, for this mechanism to work as expected, it is required that an SD-WAN rule in question include the Member from which the route-tag is learned.
-
The following situation might occur, in which the route-tags will not work as expected:
-
Three overlay tunnels exist to a Spoke towards the same Hub: H1_T1, H1_T2 and H1_T3.
-
An SD-WAN rule is configured to load-balance certain traffic between the overlays H1_T1 and H1_T2 (based on a certain SLA target).
-
Since in "BGP on Loopback" design there is just a single BGP session between the Spoke and the Hub, this session may happen to use the overlay H1_T3. In that case, the above SD-WAN rule will not be operational.
-
-
In comparison, let us describe another situation in which the route-tags will work as expected:
-
The same three overlay tunnels: H1_T1, H1_T2 and H1_T3.
-
An SD-WAN rule is configured with Lowest Cost (SLA) strategy, preferring H1_T1, then H1_T2, and finally H1_T3. Note that all the three overlays are listed in the rule.
-
This time, whichever overlay the BGP session happens to use, it will be one of the overlays listed in the rule. Therefore, this SD-WAN rule will work as expected.
-
Features unsupported with unnumbered tunnel interfaces
-
Since no tunnel IPs are configured, this may cause problems for other features that are not directly related to the "BGP on Loopback" design.
-
One known example is Multicast. Because the industry-standard PIM protocol cannot be bound to unnumbered interfaces, no PIM adjacencies can be built over the overlays.
We recommend contacting your Fortinet Sales representatives or Fortinet Professional Services for more details, because certain workarounds exist that might be successfully applied in your project!