Description

In Juniper Apstra, Configlets are a powerful tool that allows the user to customise device configurations. You can add, remove, or modify existing (Apstra Reference Design) configuration.

However, with this flexibility comes risk. This article describes these risks and how best to mitigate them.

For a detailed description on how to use embedded jinja and property sets in a configlet, please refer to the Configlets flexibility and customization using Property Sets and Jinja templating KB.

Solution

To ensure no unexpected surprises, please be aware of the following:

1. Validation

As the config is added manually, there is no way for Apstra to be able to validate its content for correctness. This means that using the correct syntax as well as verifying the outcome is as expected is the responsibility of the user. It is strongly recommended to test in a lab prior to deployment in production.

2. Changing a configlet

Configlets are created in the Global Catalog, and then imported into a Blueprint. To change an existing configlet you need to delete it from the Blueprint, modify it in the global catalog and re-import it into the Blueprint. This can be done in one single operation (commit).

3. Upgrading Apstra

When upgrading Apstra this can result in changes to the Reference Design, meaning device configurations can change. This is thoroughly tested by Engineering. However, when changes are made to the Reference Design using Configlets these changes are not (and can not) be validated when the Reference Design changes as part of the upgrade.

WARNING: configlets that modify the Reference Design potentially can result in a service-impacting outage when upgrading. It is the responsibility of the end user to do a detailed review to ascertain the configlets are valid in the new version. Also see Upgrading Juniper Apstra Best Practices.

Example: a configlet that references a policy which name changes as part of the upgrade. Post-upgrade the policy name referenced in the configlet no longer exists, rendering the configuration invalid.

4. Users and Credentials

When using configlets to add users, modify credentials or add AAA configurations: please be aware the device agent relies on successful authentication for managing the device. If for example a TACACS+ server cannot be reached this will break device management.

In general this is an area that can cause a lot of difficulties. Careful design and testing is recommended.

5. OS upgrade

When upgrading a device OS via Apstra, a revert to the Pristine Config is made. This means any configlet is removed. If there are configlets that modify login details of the user that is used by the Agent, these must be temporary removed prior to the OS upgrade.

Note: OS upgrades of Apstra managed devices can NOT be done by hand, unless the device is undeployed first. See the technical documentation for details.

6. Firewalls

Configlets that create [Routing Engine] firewalls / protection must be temporary removed prior to both Device OS upgrades and Apstra upgrades.

 

Modification History

14 december 2023: Initial version
21 December 2023: Update to add link to Jinja & Property Set specific KB