This repository contains generic, ready-to-use Jinja templates that generate our best-practice SD-WAN/ADVPN configuration. These templates are easily tunable for your projects. We call them the Jinja Orchestrator, because of the layer of abstraction that they provide - as will be briefly explained below.

The best way of thinking about these templates is as if they were a small open-source product. There is a code (which you can read but normally should not need to modify) and a configuration file (which contains parameters in a human-readable language, so that by configuring them the user can fine-tune what the "code" will eventually generate).

In our case, the "configuration file" is called a Project Template. It is by itself written in Jinja, but it includes only the necessary definitions. For example, it does not contain a single CLI command. All the CLI is generated by the "code".

Generally, there are two ways of using the Jinja Orchestrator:

• It can be used as part of the FortiManager-based SD-WAN deployment, thanks to the Jinja engine built into the FortiManager 7.0.1+. The Jinja Orchestrator is used to generate the foundation of your SD-WAN project, supplemented by other templates available in the FortiManager. Our Deployment Guide for MSSPs (Release 7.4) contains more information about using the Jinja Orchestrator in this way.

• It can also be used for an offline rendering (without the FortiManager), thanks to a simple renderer written in Python. It will generate a set of plain-text files with FOS configuration for each device, which you can simply copy-paste to your FortiGate devices (or use the Configuration Scripts feature). This method is handy to build a quick and simple lab or to quickly validate the changes made to your Project Template. Please check the README file in the repository for more details about the offline renderer.

In both cases, the user describes the project in the Project Template, provides the necessary variables and lets the Jinja Orchestrator generate the CLI configuration. We recommend studying this chapter in our official "Deployment Guide for MSSPs" for more details about the template structure.

We recommend starting from one of the provided Project Template examples.
Refer also to the dedicated page on this topic.

The Project Template includes multiple variables, some of them having simple values (such as strings, integers or booleans) and others being complex structures (dictionaries and lists). Many of these variables are optional, having default values when they are not explicitly set in the Project Template.

In this documentation, we will describe the variables in their respective topics. Usually they will be listed in a table prior to the text discussing their use in depth. The table will contain several additional columns that demand clarification:

• Configuration Scope. This simply indicates where the variable is defined in the Project Template. For example, project means that it is a global parameter, while profiles.interfaces means that it is defined per interface inside a device profile.

• Default Value. Since most of the project variables are optional, we will always specify their default values. If there is no default value, we will distinguish between two cases:

  • If the "Default" column states -, it means that the variable is optional, but the default value is simply not required logically. It may be, for example, that the variable is required only when another variable is set, otherwise it is not used. You should consult the detailed textual description to find this out.
  • If the "Default" column states -(!), it means that the variable is required, so the user must provide a value (otherwise the rendering will fail).

• Stateful Variables. This is a new concept introduced in Jinja Orchestrator 7.4, which means a variable whose value can be safely changed with the expectation that the Jinja Orchestrator will correctly update the configuration, not only setting the new state, but also unsetting the old one. Normally, this is not always guaranteed. For example, we cannot guarantee removing the old overlay tunnels when a Spoke changes its profile. This is caused by limited visibility that the Jinja Orchestrator has: during the device rendering, it does not have any visibility into the previous state of that device. Therefore, its ability to reconfigure devices (as opposed to configuring them from scratch) is limited.

  However, if the variable is stateful, it means that we guarantee to not only set the respective configuration, but also to unset its opposite. For example, when the user enables PSK authentication for the IPSEC overlays, we automatically disable the certificate-based authentication, unsetting the relevant lines of the configuration.

  NOTE: The "stateful" concept is introduced only starting from Jinja Orchestrator version 7.4.

Jinja Orchestrator version: 7.4

Variable	Scope	Description	Values	Default	stateful
lo_summary	project	Aggregate loopback summary	e.g. '10.0.0.0/14'	-(!)	yes

In addition to the above mandatory variables, a valid Project Template must contain:

• At least one region in the regions section
• At least one device profile in the profiles
• At least one Hub in the hubs section

The Project Template defines per-project variables. In addition, for every FortiGate device the user will define per-device variables.

• In FortiManager-based deployment, the per-device variables are defined as Metadata Variables.
• In offline deployment, the per-device variables are defined in the inventory file.

Generally, when rendering a device, the following three types of variables must be set:

1. The variables region and profile, correctly classifying the device in the project (linking to the respective entries in the Project Template)

2. The external variables implicitly used by the provided templates

3. The external variables explicitly used in your own Project Template

The following table summarizes the required per-device variables, except for the last category (which, of course, depends on your own Project Template):

Parameter	Values	Description	Example
region	<str>	One of the regions defined in Project template	'West'
profile	<str>	One of the profiles defined in Project template	'Silver'
hostname	<str>	Device hostname	'site1-1'
loopback	<ip>	Device main loopback IP (overlay)	'10.200.1.1'

Here is the summary of the rendering process for each FortiGate device:

• Underlay. Loop through all the interfaces defined in the device profile and configure their parameters.

  • Interfaces without names are automatically skipped (handy when the names are set by external variables)
  • For available options, refer to Underlay Customization page.

• Overlay. For each WAN interface (with role: 'wan') in the device profile of a Spoke, configure IPSEC tunnels towards each Hub serving the device region, to the overlay specified by the ol_type parameter.

  • The respective overlay must be described in the hubs structure.
  • For available options, refer to Overlay Customization page.
  • For more advanced Spoke-to-Hub IPSEC topologies, refer to the Advanced Hub Connectivity Options page.

• Routing. Configure BGP peering for the overlay network, in accordance with the selected routing design.

  • For available options, refer to Overlay Customization page.