Jinja Orchestrator versions: 7.2+

Multiple System Zones are created by default, in order to simplify generic Firewall Policy creation. This zone creation is optional, and for each zone there is a default name that can be changed.

Jinja Orchestrator versions: 7.4+

* - stateful only in force_cleanup mode (deleting the CRL config entry)

CRL validation can be configured (supported only on Hubs), using either SCEP or HTTP. For example:

{% set hub_crl_check = true %}
{% set crl_scep_url = 'http://10.1.0.20/app/cert/scep/' %}

Jinja Orchestrator versions: 7.2+

FOS supports 4-byte Autonomous System Numbers (ASNs), but it doesn't support using them in BGP communities (rfc5668).

For this reason, a new global optional parameter short_community_as is introduced. Its effect is the following:

• For regions with as < 65536 (2-byte ASN), this parameter is ignored. The actual ASN of the region is used in the generated BGP communities.
• For regions with as >= 65536 (4-byte ASN), this parameter is used in the generated BGP communities.

For example, one of the communities we generate is "SLA_OK", and its value is defined as:

edit "SLA_OK"
   config rule
      edit 1
         set set-community "{{ community_as }}:99"
      next
   end
next

• For a region with a 2-byte ASN = 65001, the SLA_OK community will simply have a value of "65001:99".
• For a region with a 4-byte ASN > 65536, the SLA_OK community will use the new parameter. Its default value is "65000", so that the SLA_OK community will, by default, have a value of "65000:99" for such regions.

Jinja Orchestrator versions: 7.4+

By default, it is assumed that the SD-WAN is configured in the "root" VDOM. If this is not the case, you can specify the VDOM name, using vdom parameter.

This optional parameter can be set either globally (for the entire project):

{% set vdom = "CustX" %}

...or per profile (this overrides the global value):

{% set profiles = {
    'MultiVdomBranch': {
      'options': {
        'vdom': "CustX"
      },
      'interfaces': [
        # ...
      ]
    }
  }
%}

Note that we DO NOT support multiple SD-WAN VDOMs on the same device. For example, we generate several special interfaces with fixed names (such as "Lo", "Lo-HC"...), and this would cause conflicts if you tried to do it in multiple VDOMs. That is why there must be only one SD-WAN VDOM on the device. It's just that it doesn't have to be the "root" VDOM.

Jinja Orchestrator versions: 7.4+

During offline rendering (without the FortiManager), the Jinja Orchestrator also renders the firewall policies and the SD-WAN configuration. Several optional parameters are available to control this behavior, as summarized in the table above.

These parameters are currently ignored, when using the Jinja Orchestrator for the FortiManager-based deployment.

Jinja Orchestrator versions: 7.4+

With the introduction of the "stateful variable" concept, the Jinja Orchestrator attempts to reconfigure devices, bringing them to the new state. This means not only adding the configuration, but also trying to cleanup the configuration which is no longer needed or even unwanted.

However, this is not always safe, due to the limited visibility of the Jinja rendering engine.

The variables listed here help limiting the degree of automatic cleaning that the Jinja Orchestrator can "afford". The default values should be good for standard deployments.

All the listed variables can be configured globally (on the project level) and overriden per profile, using the options structure. For example:

{% set strict_peering = true %}

{% set profiles = {
    'MyBranch': {
      'options': {
         'strict_peering': false,
      }
      'interfaces': [
         # ...
      ]
    }     
  }
%}

The force_cleanup option is different from the rest, because it attempts to explicitly delete table entries that could be previously created by the Jinja Orchestrator (such as specific static routes etc.). This is safe, as long as you do not reuse names and indexes listed on this page. However, in FortiManager-based deployment, this can result in install failures, when the entries in question are not found in the device configuration. That is why we have to keep this mode disabled by default. It is intended for an "ad-hoc" use: enable it when the cleanup is required, install the configuration and then disable it.

When upgrading the Jinja Orchestrator to version 7.4+ from an earlier version, it is recommended to enable force_cleanup during the first configuration install. This will help to cleanup deprecated entries and those entries that followed older numbering conventions (such as BGP networks). After the first install, the force_cleanup option can be disabled.

Following is a detailed specification of the elements purged by each of the above options:

On Spokes:

• Purge and reconfigure all BGP neighbors
• Purge and reconfigure all BGP neighbor-groups and neighbor-ranges
• Purge and reconfigure all BGP networks

On Hubs:

• Purge and reconfigure all BGP neighbor-groups and neighbor-ranges
• Purge and reconfigure all BGP aggregate-addresses

To purge and reconfigure all BGP networks on the Hubs, it is required to enable both strict_peering and force_cleanup

On Hubs:

• Purge and reconfigure all policy routes

On Spokes and Hubs:

• Purge and reconfigure all firewall policies (only in offline rendering mode)

On Spokes:

• Cleanup unused inter-VRF links based on the region's VRF list (can be used for offline rendering)

On Hubs:

• Purge and reconfigure all BGP networks (requires also strict_peering)
• Delete unused static route entry 101 (reserved for the LAN summary blackhole)
• Delete unused static route entry 103 (reserved for the regional loopback summary)
• Cleanup unused inter-VRF links based on the region's VRF list (can be used for offline rendering)
• Delete unused "TheCA" CRL entry