Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

header-navigation
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

Config Templates (Freeform Blueprint)

Release: Juniper Apstra 4.2
{}
Change Release
date_range 07-Feb-24

We recommend that you familiarize yourself with the Jinja Template Designer before working with config templates.

Several predefined config templates are included with the Apstra product. To get familiar with the syntax and how config Jinja is used in config templates. check out the sections below.

A Simple Config Template

Let's take a look at the config template junos_protocols.jinja, which ships with Apstra software.

content_copy zoom_out_map
protocols {
    lldp {
        port-id-subtype interface-name;
        port-description-type interface-description;
        neighbour-port-info-display port-id;
        interface all;
    }
}

This straightforward template doesn't include any variables or other conditions. It's nested inside the config template junos_configuration.jinja, one of the other predefined config templates. You could create your own config template and nest this basic one in it as well.

Config Template With Variable

Let's look at junos_system.jinja, another predefined config template.

content_copy zoom_out_map
{% if hostname %}
system {
    host-name {{hostname}};
}
{% endif %}

This template includes an if-then statement and the variable hostname. When configuration is rendered, if the system device context includes a value for hostname, then the rendered configuration includes that value.

Config Template and Property Sets

An example of using property sets is with NTP servers. Configuration for NTP might be consistent across all devices in the enterprise except for time sources or strata per geography. You can build a config template with a variable, named ntp for example, in place of the actual IP address. The configuration will be generated with the value of the ntp property in a property set. You'd import the same config template into all blueprints, but for blueprints running in the east region you'd import the "EAST" property set, and for blueprint running in the west region you'd import the "WEST" property set. Property sets are global, that is they are blueprint-wide.

The config template could look like this.

content_copy zoom_out_map
{% if property_sets.get('ntp') %} 
system {
    ntp {
        server {{property_sets['ntp']['ntp_server']}};
    }
}
{% endif %}

The example below shows the syntax for the property set ntp that contains the IP address.

content_copy zoom_out_map
ntp_server = '1.2.3.4'
footer-navigation