Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

ztp.json Keys

The Apstra ZTP configuration file (ztp.json) includes all configuration for the Apstra ZTP script (ztp.py). Never modify ztp.py directly. You can use several methods for configuring ztp.json. First, familiarize yourself with the keys in the file, as described below, then configure the file, as needed for your devices (as described in later pages).

Key Categories

Contents of the ztp.json file are organized from more general sections to more specific sections as follows:

  • defaults - Configured values in the defaults section are used for all devices unless more specific sections use the same keys. The more specific section values take precedence. Here's an example of what you might put in the defaults section:

  • platform-specific - Configured values in each of the vendor platform sections (junos, junos-evo, eos, nxos, sonic, linux) are used for all devices from that vendor unless the same keys in more specific sections are defined. Here's an example for devices using SONiC OS:

  • model-specific - Configured values in a specific model number section are used for all devices of that model, unless, of course, the same keys are used in a serial number section. Then the value in the serial number section would be used. Here's an example for a specific Juniper device:

  • serial number-specific - Configured values under a specific serial number (system ID) are used for that one device. For example:

Keys List

See descriptions and examples below for all keys in the ztp.json file. All keys are included in each category, whether or not they apply specifically to that category. For example, you may notice the junos section includes the key nxos-version. This is to allow all keys to be included in the defaults category. You can ignore or remove keys that don't apply to your devices.

nxos-versions

The nxos-versions parameter includes valid OS versions for Cisco NX-OS devices.

Example: "nxos-versions": [ "10.2(5)", "9.3(11)" ]

nxos-image(-location)

In the Configurator is called nxos-image-location and in the code editor and CLI it's called nxos-image.

If the version running on the device doesn't match a version in nxos-versions, then the Cisco NX-OS image location specified in the nxos-image field is uploaded.

By default, the image is loaded via TFTP. You can also load the image via HTTP by specifying the HTTP/HTTPS server URL with the IP address. You can also upload NX-OS images to Devices / OS images on the Apstra server.

TFTP Example (default): "nxos-image": [ "nxos.10.2.5.bin" ]

HTTP Server Example: "nxos-image": "http://192.168.59.4/nxos.10.2.5.bin"

Devices / OS Images Example: "nxos-image": "https://192.168.59.3/dos_images/nxos.10.2.5.bin"

eos-versions

The eos-versions parameter includes valid OS versions for Arista EOS devices.

Example: "eos-versions": [ "4.27.6M" ]

eos-image(-location)

In the Configurator is called eos-image-location and in the code editor and CLI it's called eos-image.

If the version running on the device doesn't match a version in eos-versions, then the Arista EOS SWI image location specified in the eos-image field is uploaded.

By default, the image is loaded via TFTP. You can also load the image via HTTP by specifying the HTTP/HTTPS server URL with the IP address. You can also upload NX-OS images to Devices / OS images on the Apstra server.

TFTP Example (default): "eos-image": [ "EOS-4.24.5M.swi" ]

HTTP Server Example: "eos-image": "http://192.168.59.3/dos_images/EOS-4.21.51F.swi"

Devices / OS Images Example: "nxos-image": "https://192.168.59.3/dos_images/nxos.10.2.5.bin"

To use any HTTP server for image transfer, enter a valid HTTP or HTTPS URL with IP address. For example: "eos-image": "http://192.168.59.3/dos_images/EOS-4.27.6M.swi"

This example uses HTTP from the Apstra ZTP server (192.168.59.4) to transfer the Arista EOS image from the Apstra ZTP /container_data/tftp/ directory.

You can also upload Arista EOS images to the Apstra controller Devices / OS Images. For example:

"nxos-image": "https://192.168.59.3/dos_images/EOS-4.27.6M.swi"

junos-versions

The junos-versions parameter includes valid OS versions for Juniper Junos OS devices.

Example: "junos-versions": [ "22.4R2" ]

junos-image(-location)

In the Configurator is called junos-image-location and in the code editor and CLI it's called junos-image.

If the running Junos OS version doesn't match a version in the junos-versions list, then the image in the junos-image field is uploaded.

By default, the image is loaded from the ZTP server's /container_data/tftp/ directory via TFTP. To use any HTTP server for transferring the image, enter a valid HTTP URL with IP address. For example:

"junos-image": "http://192.168.59.4/jinstall-host-qfx-5-18.4R3-S4.2-signed.tgz"

To use any HTTP server for image transfer, enter a valid HTTP or HTTPS URL with IP address. For example:

This example uses HTTP from the Apstra ZTP server (192.168.59.4) to transfer the Juniper Junos image from the Apstra ZTP /container_data/tftp/ directory.

You can also upload Juniper Junos images to the Apstra controller Devices / OS Images. For example:

junos-evo-versions

The junos-evo-versions parameter includes valid OS versions for Juniper Junos OS Evolved devices.

Example: "junos-versions": [ "22.4R2-EVO" ]

junos-evo-image(-location)

sonic-versions

The sonic-versions parameter includes valid OS versions for Enterprise SONiC devices.

Example: "sonic-versions": [ "SONiC-OS-4.0.5-Enterprise_Advanced" ]

sonic-image(-location)

In the Configurator is called sonic-image-location and in the code editor and CLI it's called sonic-image.

This is the filename of the SONiC ONIE BIN image to load if the running version does not match a version in the sonic-versions list.

To use any HTTP server for image transfer, enter a valid HTTP or HTTPS URL with IP address. For example:

This example uses HTTP from the Apstra ZTP server (192.168.59.4) to transfer the SONiC image from the Apstra ZTP /container_data/tftp/ directory.

You can also upload SONiC images to the Apstra controller Devices / OS Images. For example:

device-root-password

The ZTP process sets the device root password to this value. For Arista EOS and Cisco NX-OS devices, the device-root-password is used to set the password for the system admin password.

Example: "device-root-password": "root-admin-password"

device-user

Username for the device system agent. Also, if necessary, the ZTP process creates a user on the device with this username and and the device-user-password.

Example:

device-user-password

Password for the device system agent. Also, if necessary, the ZTP process creates a user on the device with the device-user and this password.

Example:

custom-config

This is the filename of the custom configuration shell script in the TFTP directory or a URL pointing to the file on a HTTP server. This shell script runs during the ZTP process allowing you to add custom configuration to the device. See Platform Specific Information for more information.

Example: "custom-config": "junos_custom.sh"

dual-routing-engine (check box)

system-agent-params

System agent parameters are used to create new users and device system agents on each device. (For all available system-agent-params options, see the REST API documentation for /api/system-agents.)

The individual system agent parameters are described below.

agent_type (system-agent-params)

Agent type is either onbox or offbox

Example: "agent_type": "onbox"

platform (system-agent-params)

This field is used only for offbox agents only. Set it to the device platform ("eos", "nxos", "junos"). Lowercase only

Example: "platform": "junos"

job_on_create (system-agent-params)

To have the onbox agent installed on the device, set job_on_create to install

Example: "job_on_create": "install"

operation_mode (system-agent-params)

profile (system-agent-params)

The device agent profile as defined in Apstra to use during agent creation. The value must be the ID of the agent profile, not the agent profile name.

Example: “profile”: “8d68d1ec-c168-4ef3-8ffd-09389c17a3e4”

Requirements for Juniper on Apstra version 4.2.0: If you need to provide “profile” parameters, you must use UUID instead of the profile name/label.

The parameters force_package_install, install_requirements, and enable_monitor are always visible in the ZTP server. These will cause agent creation failure during the ZTP process. You must remove these parameters from system-agent-params for Juniper agent creation to work. However, due to a bug, when you remove these parameters from the ztp.json file via the Apstra GUI, they aren't actually removed. The configurator adds them back in. To prevent this from happening, use the CLI instead of the Apstra ZTP GUI, and log in via an SSH connection to the ZTP server. Then restart the tftp container.

packages (system-agent-params)

Set to configure the additional SDK or extended telemetry packages to upload to the system agent.

Example:

force_package_install (system-agent-params)

For Juniper devices used in Apstra 4.2.0, you must remove this parameter via CLI. If you use the Apstra ZTP GUI, the parameter will be added back in.

install_requirements (system-agent-params)

Always set to false. Not currently needed for any supported Network Operating System.

Example: "install_requirements": false

For Juniper devices used in Apstra 4.2.0, you must remove this parameter via CLI. If you use the Apstra ZTP GUI, the parameter will be added back in.

enable_monitor (system-agent-params)

For Juniper devices used in Apstra 4.2.0, you must remove this parameter via CLI. If you use the Apstra ZTP GUI, the parameter will be added back in.

open_options (is this still relevant?)

Example:

Offbox agents only. Set to enable HTTPS between offbox agent to device API interface. If open_options isn't defined, the connection defaults to HTTP.

Examples

See the sections below for some examples of ztp.json values.

Defaults

An example of values you might want to include as defaults include the following:

All devices would use these values unless values for more specific categories are configured, then those would take precedence. More specific categories include platform-specific, such as "junos", "junos-evo", "eos", "nxos", and "sonic"; model-specific, such as "QFX10002-60C"; and serial number-specific, such as "TH0TFD6TCET0015G0015".

Cisco Onbox Agent on Apstra ZTP 4.2.0 Example

Cisco Offbox Agent with HTTP on Apstra ZTP 4.2.0 Example

This configuration enables secure offbox agent HTTPS (port 443) between the offbox agent on the server and the device API.

Note:

open_options" can't be configured from the Apstra ZTP UI configurator. You must use the GUI code editor or edit the ztp.json file from the CLI.

Arista Onbox Agent on Apstra ZTP 4.2.0 Example

Junos Offbox Agent on Apstra ZTP 4.2.0 Example

Junos Evolved Onbox Agent on Apstra ZTP 4.2.0 Example

You can use the following additional fields for dual RE platforms, such as PTX10004.

Juniper OS Evolved

Enterprise SONiC Onbox Agent on Apstra ZTP 4.2.0 Example

Note:

If you use another device-user besides admin (aosadmin for example) Apstra ZTP creates this new user, but it doesn't change the password for the default SONiC admin user (password set to YourPaSsWoRd by default).

Model-specific Example