Configlets (Datacenter Design)
Configlet Overview
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.
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
- When Not to Use Configlets
- Configlet Parameters
- Configuration Rendering Order
- View Configlets (Design)
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
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:
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: Top-Level: Set / Delete (Junos) | Author configlets using Juniper "Set" style rather than structured JSON |
|
|
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) |
|
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) |
|
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:
- System Top: negation template text (NX-OS, EOS)
- System Top: template text (NX-OS, EOS)
- Apstra reference design
- Interface: negation template text (NX-OS, EOS)
- System: negation template text (Junos, NX-OS, EOS, SONiC)
- File (SONiC)
- System: template text (Junos, NX-OS, EOS, SONiC)
- Interface: template text (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.