Edge SD-WAN Templates
We are going to configure all the WAN-facing interfaces, which includes both underlay and overlay, to be part of our SD-WAN bundle. This way, all the traffic steering will be controlled by the SD-WAN rules. And since our design foundation is generic, we do not need to reconfigure the other elements (for example, IPsec and BGP), when changing the SD-WAN rules.
We outline the general configuration steps recommended for every Edge SD-WAN Template. All the screenshots demonstrate a generic template called Edge-SDWAN from our example project, and it is prepared for all the Edge sites (Spokes) despite their different topologies.
Detailed descriptions of the available SD-WAN functionality is outside the scope of this document. Please refer to the public documentation or contact your Fortinet representatives for more details. |
To configure the Edge SD-WAN Template interactively:
-
Go to Device Manager > Provisioning Templates. Under the SD-WAN tab, create a new template:
-
Inside this template, in the SD-WAN Zones section, click Create New > SD-WAN Zone to create two SD-WAN Zones named underlay and overlay:
-
Still in the SD-WAN Zones section, click Create New > SD-WAN Member to create SD-WAN Members and add them to the Zones:
-
All the underlay interfaces should be added to the underlay zone.
-
All the overlay interfaces (tunnels) should be added to the overlay zone. For a description of the overlay tunnel names, see the Naming Conventions section.
-
Make sure that the Priority value for the overlay members is worse (higher) than the value for the underlay members. For example, set the overlay Priority to 10 and leave the underlay Priority unchanged (0).
We are going to use SD-WAN as a default route, and this priority will be set for each individual member. As a result, underlay members will be automatically preferred for Internet traffic that does not have any explicit SD-WAN rule. This also includes the traffic originated by the FortiGate device itself, such as, FortiGuard connectivity.
-
Make sure that the Source value for the overlay members is set to
$(loopback)
. This refers to the per-device variable that will contain the device loopback address, and in our the "BGP on Loopback" design we will use it as a source IP for the health probes.
-
-
Optionally, in the list of the SD-WAN Members, use the Installation Target column to limit the scope of devices to which a particular SD-WAN Member should be provisioned. This allows you to reuse the same SD-WAN Template for different types of sites.
-
In our example project, there is a major difference between the sites belonging to the West region and the sites belonging to the East region: the former are served by two Hubs, while the latter are served by only one Hub. For this reason, all the H2 overlay members must be provisioned only on the sites belonging to the West region.
-
Similarly, there is a major difference between the Silver sites and the Gold sites: the former have only two WAN links (connected to ISP1 and MPLS only), while the latter have a third WAN link (connected to ISP2). For this reason, all the ISP2 overlay members must be provisioned only on the Gold sites.
-
We can meet the above requirements by setting the installation target of the ISP2 overlay members, as well as “port2”, to the “Edge-West-Gold” group and additionally setting the installation target of the H2 overlay members to the “Edge-West” device group:
SD-WAN Member
Installation Target
port2
Edge-West-Gold
H1_ISP2
Edge-West-Gold
H2_ISP1
Edge-West
H2_ISP2
Edge-West-Gold
H2_MPLS
Edge-West
-
-
Create the necessary Performance SLAs:
-
For the corporate (internal) traffic, create Performance SLA that pings the Hub loopback. This loopback is created by the Jinja Orchestrator, and its IP address, by default, is set to 10.200.99.1. Specify to run the probes only on the overlay members, and enable the embedding of the measured health into the probes (for the correct Hub-to-Edge SD-WAN support).
-
For the Internet traffic, create Performance SLAs that uses any desired probe destination. A typical choice to probe generic Internet connectivity would be a DNS probe towards 8.8.8.8. Additionally, application-specific Performance SLAs can be created, depending on the desired steering strategy.
Specify to run the probes through all the members, which should be used for the Internet access. The choice depends on whether it is required to provide Direct Internet Access (DIA), Remote Internet Access (RIA), or a hybrid of the two.
For example, on the below screenshot we are planning to use a hybrid Internet access model. However, keep in mind that here we do not define any traffic steering rules yet. We are merely defining on which SD-WAN Members to run the respective health probes. The traffic steering will be determined by the SD-WAN Rules.
If you want to see SLA graphs on the FortiAnalyzer widgets and reports, remember to set the values of
sla-fail-log-period
andsla-pass-log-period
under Advanced Options of the respective Performance SLAs. For example, use the values of 10 seconds:
-
-
Activate ADVPN 2.0 as follows:
-
Edit the SD-WAN Zone overlay, activate ADVPN 2.0 by enabling the
advpn-select
option, and select the corporate Performance SLA created earlier: -
Edit the SD-WAN Members, defining the right Transport Groups (use the
transport-group
parameter in the Advanced Options). In our example project, we will assign the MPLS overlay members to the Transport Group 2:Why don’t we define any Transport Group for the ISP1/ISP2 overlay members? We could do it, but it is not mandatory: the default value (0) is as good as any custom value. It is only important to assign the ISP1/ISP2 and the MPLS overlay members to different groups.
-
-
Finally, create the necessary SD-WAN Rules which will determine the actual traffic steering behavior:
-
For the corporate (internal) traffic, for optimal ADVPN operation, we recommend enabling the Advanced Option of
tie-break fib-best-match
. This per-rule option instructs the SD-WAN to rely on the best route to the destination (rather than on any valid route, as it is done by default). In conjunction with ADVPN, this setting provides an optimal behavior in certain failure scenarios: -
For the Internet traffic, a wide variety of options exist, depending on the desired steering strategy. For example, the following screenshot demonstrates an SD-WAN Rule for the business-critical SaaS applications (such as, Salesforce and GoToMeeting in our example), implementing a hybrid Internet access model combined with application-based traffic steering:
-
The applications in question will be identified by their Layer7 payloads, using our extensive Application database.
-
The applications will prefer Direct Internet Access using port1, as long as it meets the configured SLA target (the latency of up to 250 ms).
-
If the SLA target is not met, the traffic will switchover to the Remote Internet Access through one of the Hubs by using one of the MPLS overlays of H1_MPLS or H2_MPLS.
-
-
Another popular option for the Internet traffic would be simply to load-balance the SaaS applications (Salesforce and GoToMeeting in our example) between the available underlay members (DIA), still with respect to the SLA target (that is, skipping a member if it does not meet the target). This is shown on the following screenshot:
-
Different SD-WAN Rules can be created for different types of traffic by selecting the optimal traffic steering strategy and SLA targets for different applications.
-
-
Optionally, the installation target can be set for the SD-WAN Rules, to limit the scope of devices to which a particular SD-WAN Rule should be provisioned.
-
For example, we have proposed two different ways to handle the Internet traffic: a hybrid DIA/RIA option (a rule called “SaaS-Hybrid”) and a DIA-only option with load-balancing (a rule called “SaaS-DIA”). The second option seems preferable only on the sites having multiple DIA connections, such as the Gold sites. All the Silver sites will prefer the hybrid option instead.
-
To accomplish this, we will set the installation target for the “SaaS-DIA” rule to “Edge-West-Gold” and we will set the installation target for the “SaaS-Hybrid” rule to “Edge-West-Silver” and “Edge-East-Silver”:
-
Now our generic Edge-SDWAN Template is ready.
It is certainly not mandatory to configure a single SD-WAN Template for all types of sites. The described functionality is optional. It allows reducing the number of templates, which is often beneficial. However, it is also possible to create separate SD-WAN Templates for different types of sites, especially when the desired steering strategy deviates significantly. |