Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configlets Introduction

Configlets are configuration templates that augment Apstra’s reference design with non-native device configuration. They consist of one or more generators. Each generator specifies a NOS type (config style), when to render the configuration, and CLI commands (and file name as applicable). The section that you select when creating the configlet determines when the configuration is rendered.

When you want to use a configlet, you import it from the global catalog into a blueprint catalog and assign it to one or more roles and/or deployed devices. You can edit the roles and/or devices in a blueprint configlet, but if you want to change the configlet itself, you must export it to the global catalog, modify it, and re-import it into the blueprint.

You can use the same configlets across the entire enterprise, but we recommend creating and applying regionally-specific property sets instead.

Note:

Improperly configured configlets may not raise warnings or restrictions. Testing and validating configlets for correctness is the responsibility of the end user. We recommend that you test configlets on a separate dedicated service to ensure that the configlet performs exactly as intended.

Passwords and other secret keys are not encrypted in configlets.

Configlet Applications

Some applications for configlets include the following:

  • Syslog
  • SNMP access policy
  • TACACS / RADIUS
  • Management ACLs
  • Control plane policing
  • NTP
  • Username / password

When Not to Use Configlets

CAUTION:

Using configlets to add non-native configuration is not always appropriate or possible. Configlets are powerful, but if used improperly they pose risks to deployment stability and reference design feature interactions. Testing and validating configlets for correctness is the responsibility of the end user.

Don't use configlets to replace reference design configuration, such as for routing or connectivity. If you change interface configuration, the Apstra-intended interface configuration could be overwritten. For example, if a configlet creates a network span port, you must apply the configlet to an Unused port, or it might inadvertently overwrite one that is already in use.

On Cisco NX-OS and Arista EOS devices, do not use configlets to configure multi-line banners (such as banner motd) because of a problematic extra non-ASCII character that cannot be entered. Instead, configure multi-line banners with Cisco POAP (Power-on Auto Provisioning) or ZTP (Arista Zero Touch Provisioning) before installing the device agent. The banner configuration becomes part of the device's pristine configuration and persists throughout the Apstra configuration. Another option is to manually configure multi-line banners on the device. This method causes a configuration deviation anomaly that you can clear by accepting the new configuration as the golden config. For more information, see Configuration Deviation.

Configlet Parameters

Configlets include the following details. The selected config style (NOS type) and section determine whether template text, negation template text and filename are required:

Table 1: Configlet Parameters
Name Description
Configlet Name A unique name to identify the configlet, 64 characters or fewer
Config Style (NOS Type) Junos, NX-OS, EOS, SONiC
  • Section: System (NX-OS, EOS, SONiC)
  • Section: Top-Level: Hierarchical (previously called System) (Junos)
  • Runs commands as root user. Improper changes could break the functionality of the reference design and take down a network.
  • When a device is unassigned from a node, the negation template text removes configuration. For example, if the template text is username example privilege 15 secret 0 MyPassword, the negation template text might be 
    no username example
  • Can use in conjunction with File configlets to restart processes or perform administrative tasks after File configlets render.
  • System configlets can nest other configuration.
  • For NX-OS and EOS, the appropriate configure terminal context is applied. It doesn’t need to be part of the configlet.
Section: Top-Level: Set / Delete (Junos) Author configlets using Juniper "Set" style rather than structured JSON
  • Section: Interface (NX-OS, EOS)
  • Section: Interface-Level: Hierarchical (Junos)
  • For physical devices only.
  • You specify the interface when you import the configlet into a blueprint (scope).
Section: Interface-Level: Set (Junos) Author configlets using Juniper "Set" command rather than structured JSON. Text is validated to begin with 'set'.
Section: Interface-Level: Delete (Junos) Author configlets using Juniper "Delete" command rather than structured JSON. Text is validated to begin with 'delete'.
Section: File (SONiC)
  • The entire contents of the file must be present within the configlet because the entire file is overwritten; there is no versioning or storing of the original file contents, soyou can’t restore it to its original content. Improper use can take down a network. Do not use on config files of critical processes (such as /etc/frr/frr.conf or /etc/network/interfaces/).
  • Contents are written, as root user, to the /etc directory file (because of Apstra’s Docker container host mount). To write to a file outside of /etc (/usr for example) build the File configlet, then use a System configlet to move the file afterwards.
Section: System Top (NX-OS, EOS) Ensures that you can overwrite a setting to implement programmed intent. When the reference design is applied, any needed features that were “turned off” in this configlet are reenabled.
Section: FRR (SONiC)
  • Configlet configuration is appended to the end of the Apstra-generated /etc/frr/frr.conf file and becomes part of FRR intent. Configuration is incrementally included in frr-reload.
  • Template text is not validated. Errors are likely to cause deployment errors, unintended configuration and device impact.
Template Text CLI commands to add configuration to devices. Issued directly to devices without validation.
Negation Template Text CLI commands to disable configlet functionality (when a device is unassigned). Issued directly to devices without validation.
Filename For File configlets

Configuration Rendering Order

Configuration rendering order is as follows:

  1. System Top: negation template text (NX-OS, EOS)
  2. System Top: template text (NX-OS, EOS)
  3. Apstra reference design
  4. Interface: negation template text (Junos, NX-OS, EOS)
  5. System: negation template text (Junos, NX-OS, EOS, SONiC)
  6. File (SONiC)
  7. System: template text (Junos, NX-OS, EOS, SONiC)
  8. Interface: template text (Junos, NX-OS, EOS)

To control the order of operations within a section, create configlets with numeric names. For example, 01_syslog renders before 02_ntp. Configlets are then ordered based on the condition of the configlet (for example the spine or leaf role), and then by the Node ID of the configlet.

View Configlets (Design)

From the left navigation menu, navigate to Design > Configlets to go to configlets in the design (global) catalog. You can create, clone, import, export, edit and delete configlets.

Related Documentation