Understanding template structure

Intuitively, our Jinja Templates can be thought of as a small open-source product. There is a "configuration file" on the frontend and the actual "code" on the backend. The "code" can be seen (and even modified) by anyone, but typically this is neither required nor encouraged. The "code" supports multiple features that are all implemented according to our best practices. These features are controlled by the "configuration file" and by the per-device variables.

The "configuration file" is called a Project Template. It is written in a human-readable declarative (also considered implementation-agnostic) language.

You will find several examples of the Project Templates among the downloaded files. For example, see under bgp-on-loopback/projects directory (filenames starting with Project).

Once you describe your project in the Project Template and set per-device variables, the rest of the Jinja Templates (the "code") will be used by FortiManager to generate the necessary design foundation.

In this document, we will walk you through the most important aspects and show you how to use the Project Templates. For additional information and for the full reference of supported features, please see the README file and the Wiki page in the GitHub repository.

We recommend using an external plain text editor to view and edit the Project Template (and other Jinja files). Any plain text editor can be used. Many editors conveniently provide syntax highlighting. Here are some popular editors to consider: Visual Studio Code (available on macOS, Windows, and Linux) Notepad++ (available on Windows)

Following is the general structure of our Project Template:

{# Set some global values #}
{# ... #}

{# Define the regions #}
{% set regions = {
    {# ... #}
  }
%}

{# Define device profiles #}
{% set profiles = {
    {# ... #}
  }
%}

{# Define Hubs #}
{% set hubs = {
    {# ... #}
  }
%}

Apart from some global values, we define three important structures here:

• The regions dictionary defines the regions, listing the Hubs that serve each one of them.
• The hubs dictionary defines all those Hubs, and especially all the overlays that they create.
• The profiles dictionary defines device profiles, which is mainly their local topology, that is:
  • What interfaces are connected to the LAN side and what are connected to the WAN side
  • Where DHCP is available and where it is not available
  • Which overlays are terminated on each WAN interface
  • And so on

All the other Jinja templates (the "code") import the Project Template and use it as a dataset.

Following is a brief description of the remaining templates:

• Edge-Underlay and Hub-Underlay configure underlay interfaces based on the device profile. The profile will be assigned using a per-device meta field (variable) named profile.
• Edge-Overlay and Hub-Overlay configure IPsec overlay tunnels. The Edge will build the tunnels through each of its WAN interfaces and to each of the Hubs serving its region. We will use two per-device meta fields here: region and profile.
• Edge-Routing and Hub-Routing configure BGP peering. It covers BGP sessions to each of the Hubs serving the region. We use mostly the region variable here.
• Hub-MultiRegion and Hub-IntraRegion configure Hub-to-Hub connectivity both within and between regions. It covers Hub-to-Hub overlays and routing. It is kept separate for better clarity.