Understanding template structure

All the "mutable" parts of the template set is concentrated in the Project file, which we will refer to as a Project template. This is where you tailor the templates set to your particular project(s). The rest of the files are not expected to change between projects. They simply use the structures defined in the Project template, in order to produce the Best Practice configuration.

Here 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, 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
  • Which overlays are terminated on each WAN interface
  • And so on

All the other Jinja templates 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 by way of 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 meta field here.
• Hub-MultiRegion configures inter-regional connectivity. It covers Hub-to-Hub overlays and routing. It is kept separate for better clarity.

There are additional templates under the pre-run subfolder. Those are the Pre-Run CLI Templates for different devices. They are used for one-time modifications that must be applied to the freshly added model device for a successful provisioning. For example, they can be used to delete a certain factory-default policy that would interfere with the execution of other provisioning templates. Or they can be used to fix some "imperfections" of your environment without breaking the main workflow.

Pre-Run CLI Templates run exactly once on the model device, before any other provisioning templates.