close

keyboard_arrow_left

Table of Contents Expand all

Introduction
Get Started
play_arrow Apstra GUI
- Log in to Apstra GUI
- Reset Apstra GUI Admin Password
play_arrow Blueprints and Dashboard
- Create Datacenter Blueprint
- Blueprint Summaries and Dashboard
- Delete Datacenter Blueprint
play_arrow Analytics (Blueprints)
- Analytics Introduction
- play_arrow Dashboards
- play_arrow Anomalies
  - Anomalies (Analytics)
- play_arrow Widgets
- play_arrow Probes
- play_arrow Predefined Reports (Tech Preview)
- play_arrow Root Causes
  - Root Causes
play_arrow Staged (Datacenter Blueprints)
- Blueprint-Wide Search
- play_arrow Physical
- play_arrow Virtual
  - play_arrow Virtual Networks
  - play_arrow Routing Zones
  - Static Routes (Virtual)
  - Protocol Sessions (Virtual)
  - play_arrow Virtual Infrastructure
  - play_arrow Statistics
- play_arrow Policies
  - play_arrow Endpoints
  - Security Policies
  - Interface Policies
  - Routing Policies
  - Routing Zone (VRF) Constraints
  - play_arrow Routing Zone Policy (4.2.0)
    - Optimize Routing Zone Resource Usage (4.2.0)
- play_arrow Data Center Interconnect (DCI)
- play_arrow Catalog
  - play_arrow Logical Devices
    - Export Logical Device
  - play_arrow Interface Maps
    - Import Interface Map
    - Delete Interface Map (Blueprint)
  - play_arrow Property Sets
  - play_arrow Configlets
  - play_arrow AAA Servers
    - AAA Servers (Datacenter Blueprint)
  - play_arrow Tags
- play_arrow Tasks
  - Tasks (Datacenter) Staged
- play_arrow Connectivity Templates
- play_arrow Fabric Settings (4.2.1)
  - play_arrow Fabric Policy (4.2.1)
    - Update Fabric MTU (4.2.1)
    - Optimize Routing Zone Resource Usage (4.2.1)
  - play_arrow Severity Preferences (4.2.1)
    - Update Severity Preferences
- play_arrow Fabric Settings (4.2.0)
  - play_arrow Fabric Policy (4.2.0)
    - Enable IPv6 Applications
    - Update Fabric MTU (4.2.0)
  - play_arrow Virtual Network Policy (4.2.0)
    - Virtual Network Policy Introduction
    - Update Virtual Network Policy
  - play_arrow Anti-Affinity Policy (4.2.0)
    - Anti-Affinity Policy
  - play_arrow Validation Policy (4.2.0)
    - Update Validation Policy (Severity Preference)
- BGP Route Tagging
play_arrow Staged (Freeform Blueprints)
- Freeform Introduction
- play_arrow Blueprints
- play_arrow Physical
- play_arrow Resource Management
  - Resource Management Introduction (Freeform)
  - play_arrow Blueprint Resources
  - play_arrow Allocation Groups
    - Create Allocation Group (Freeform)
  - play_arrow Local Pools
    - Create Local Pool (Freeform)
    - Create Local Pool Generator (Freeform)
- play_arrow Catalog
  - play_arrow Config Templates
  - play_arrow Device Profiles
    - Import Device Profile (Freeform)
    - Delete Device Profile (Freeform Blueprint)
  - play_arrow Property Sets
  - play_arrow Tags
- play_arrow Tasks
  - Tasks - Staged (Freeform)
play_arrow Uncommitted (Blueprints)
- Uncommitted Introduction
- Commit / Revert Changes to Blueprint
play_arrow Active (Datacenter Blueprints)
- Active (Datacenter Blueprint)
- play_arrow Topology (Active)
- Nodes (Active)
- Links (Active)
- Racks (Active)
- Pods (Active)
- Query
- Anomalies (Service)
play_arrow Time Voyager (Blueprints)
- Time Voyager Introduction
- Roll Back Blueprint Revision
- Keep Blueprint Revision
- Change Number of Saved Blueprint Revisions
- Update Blueprint Revision Description
- Delete Blueprint Revision
play_arrow Devices
- Device Configuration Lifecycle
- play_arrow Managed Devices
- play_arrow System Agents
- play_arrow Pristine Config
  - Edit Pristine Config
  - Update Pristine Config from Device
- play_arrow Telemetry
  - Device Telemetry Services
  - All Telemetry Services
  - play_arrow Telemetry Service Registry
    - Service Registry
  - Telemetry Streaming
  - Route Anomalies for a Host - Example
  - Juniper Telemetry Commands
  - Cisco Telemetry Commands
  - Arista Telemetry Commands
  - Linux Server Telemetry Command
  - Debugging Telemetry
  - Extensible Telemetry Guide
- play_arrow Apstra ZTP
- play_arrow Device Profiles
play_arrow Design
- play_arrow Logical Devices
- play_arrow Interface Maps
- play_arrow Rack Types
- play_arrow Templates
- play_arrow Config Templates
  - Config Templates (Freeform Design)
- play_arrow Configlets (Datacenter)
- play_arrow Property Sets (Datacenter)
- play_arrow TCP/UDP Ports
- play_arrow Tags
play_arrow Resources
- Resources Introduction
- ASNs
- VNIs
- Integers
- IPv4 Addresses
- IPv6 Addresses
play_arrow Analytics
- play_arrow Apstra Flow
  - Apstra Flow Introduction
  - System Requirements
  - play_arrow Dashboards
    - Apstra Flow Dashboards
  - play_arrow Supported Flow Records
  - play_arrow Flow Enrichment
  - play_arrow Monitor Flow Data
    - Metrics
  - play_arrow Configuration Reference
  - play_arrow API
    - API Endpoints Options
  - play_arrow Additional Documentation
  - play_arrow Knowledge Base
play_arrow External Systems (RBAC Providers)
- play_arrow Providers
- play_arrow Provider Role Mapping
play_arrow Platform
- play_arrow User / Role Management
  - User / Role Management Introduction
  - play_arrow Users
  - play_arrow Roles
- play_arrow Security
- Syslog Configuration (Platform)
- Receivers (Platform)
- Global Statistics (Platform)
- Event Log (Audit Log)
- play_arrow Apstra VM Clusters
- play_arrow Developers
- play_arrow Technical Support
- Check Apstra Versions and Patent Numbers
Favorites & User
play_arrow Apstra Server Management
- Apstra Server Introduction
- Monitor Apstra Server via CLI
- Restart Apstra Server
- Reset Apstra Server VM Password
- Reinstall Apstra Server
- Apstra Database Overview
- Back up Apstra Database
- Restore Apstra Database
- Reset Apstra Database
- Migrate Apstra Database
- Replace SSL Certificate on Apstra Server with Signed One
- Replace SSL Certificate on Apstra Server with Self-Signed One
- Change Apstra Server Hostname
Apstra CLI Utility
play_arrow Guides
- 5-Stage Clos Architecture
- Juniper EVPN Support
- Intent-Based Analytics with apstra-cli Utility
- AOSOM-Streaming Guide
play_arrow References
- play_arrow Feature Matrix
  - Apstra 4.2.1 Feature Matrix
  - Apstra 4.2.0 Feature Matrix
- play_arrow Devices
- play_arrow Analytics
- Configlet Examples (Design)
- play_arrow Apstra CLI Commands
  - Apstra CLI Commands
- Apstra EVPN Support Addendum
- Apstra Server Configuration File
- Graph
- Juniper Apstra Technology Preview

list Table of Contents

English

Upgrade Device NOS

Release: Juniper Apstra 4.2

date_range 07-Feb-24

arrow_backward

arrow_forward

Upgrade the network operating systems (NOS) of your Apstra-managed network devices from within the Apstra environment.

We highly recommend that you become familiar with this procedure before upgrading a device NOS.

NOS Upgrade Overview

You can upgrade a device NOS within the Apstra environment with a few steps. If you've defined your own device profiles, you may need to update them. Then you'll register the new OS image that you obtained from the vendor, and click a button to start the upgrade. Apstra takes care of upgrade tasks and other requirements and ensures that pristine config is updated.

Note: Though we don't recommend it, you can upgrade a device NOS outside of the Apstra environment. This requires that you perform manual steps as follows: unassign and undeploy the device from the blueprint, commit the changes, uninstall the agent, upgrade the device NOS outside of the Apstra environment, install the agent, assign and deploy the device in the blueprint, then finally commit the changes.

For information about supported upgrade paths, see NOS Upgrade Paths in the References section.

Apstra software ships with built-in device profiles that support specific OS versions. When you upgrade the Apstra server, device profiles with the OS versions that are supported in the new Apstra version are also updated. You can then upgrade the NOS to one of the newly supported versions.

For example, Apstra version 4.0.0 supports Arista EOS versions as shown in the OS version selector (4.(18|20|21|22|23|24)) in the device profile. That is, it supports versions 4.18, 4.20, 4.21, 4.22, 4.23, and 4.24. Whereas, Apstra version 4.0.2 supports EOS versions 4.18, 4.20, 4.21, 4.22, 4.23, 4.24, and 4.25 (4.(18|20|21|22|23|24|25)). 4.25 is a newly supported version. If you upgrade the Apstra server to version 4.0.2, you can upgrade Arista devices to EOS version 4.25.

However, device profiles that you've created (cloned) yourself, are not managed in the Apstra environment, so when you upgrade the Apstra server those device profiles aren't automatically updated with newly supported versions. You'll need to follow a few extra steps to add them as described in the next section.

Before beginning the process, make sure of the following:

Make sure that you understand the device configuration lifecycle and that you're comfortable with managing deploy modes.
Make sure that Apstra software is managing the device you're upgrading. Navigate to Devices > Managed Devices and confirm that your device is in the table and that it is acknowledged (with a green check mark).
Before upgrading NOS, delete any device AAA/TACACS+ configlets from the blueprint. After the upgrade is complete, you can reapply them.
Make sure that the Admin state of the device is set to normal. Navigate to Devices > Managed Devices, click on the Management IP of the device to confirm the admin state. (Do NOT set the Admin state to MAINT/DECOMM or the device could enter an unrecoverable state.)
Make sure that the Apstra version specified is the same on both the Apstra server and the device. If they are different, you can't upgrade the device. If you attempt to upgrade with different versions, you will not receive a warning; the task status remains in the IN PROGRESS state indefinitely.

Update User-defined Device Profiles

Make sure that your devices are in the appropriate states for upgrading as described in the overview above.

If you've created (cloned) your own device profiles, you'll need to manually specify OS versions in the device profile and the blueprint that uses that device profile. (If your devices use built-in device profiles, then proceed to the next section to register the new OS image.)

From the left navigation menu in the Apstra GUI, navigate to Devices > Device Profiles, select your device and update the OS version in the Selector section.
From the left navigation menu, navigate to Platform > Developers > Graph Explorer and find the ID for the device profile. You can find it with the query variables { device_profile_nodes { id label } }
In this example, the "id" for the label "Clone DCS-7160-48YC6_abc" is "35a376ad-6ba1-42ec-bfe9-7810c56003d3".

Use apstra-cli to update the device profile.

You can use your blueprint ID and the node ID from the previous step, then set the proper model ID ("DCS-7160-48YC6" for example), and execute.

apstra-cli command format:

content_copy zoom_out_map
blueprint set-node-property --blueprint <your blueprint ID> --node_type
device_profile --node <node ID from Step2> --property selector
--value-fn '{"os_version":"4\.(18|20|21|22|23)\..*","model":"<your model>"
,"os": "EOS","manufacturer": "Arista"}'

Example:

content_copy zoom_out_map
apstra-cli> blueprint set-node-property --blueprint
a74906ab-1c7a-42ee-bbea-7a0be2572bc2 --node_type device_profile
--node 35a376ad-6ba1-42ec-bfe9-7810c56003d3 --property selector
--value-fn '{"os_version":"4\.(18|20|21|22|23)\..*","model":"DCS-7160-48YC6",
"os": "EOS","manufacturer": "Arista"}'

From the Apstra GUI, navigate to your blueprint, click Uncommitted and commit the changes.
Proceed to the next section to upgrade the OS in the same manner as for devices using predefined device profiles.

Register / Upload OS Image

Obtain the OS image from the device vendor.

CAUTION:
Make sure to select a compatible device operating system image for the device that you're upgrading. If you use an incompatible image and the upgrade fails, the deployment lock is not released automatically, even if you recover the device. To release the deployment lock and activate the device again, remove the device assignment from the blueprint, decommission and normalize the device (from Devices > Managed Devices), then reassign the device to the blueprint. For assistance, contact Juniper Support.
From the left navigation menu, navigate to Devices > System Agents > OS Images and click Register OS Image (top-right). You can see how much space is left for uploading new NOS images, and if the partition has under 5GB of free space a warning appears when you register.)
Select the platform from the drop-down list (EOS, NXOS, SONIC, JUNOS) and enter a description.
Either upload the image directly to the Apstra server or provide a URL download link pointing to an image file on an accessible HTTP server (described in sections below).

Method One: Upload Image
Method Two: Provide Image URL
Add Checksum (Optional)

Method One: Upload Image

Select Upload Image, then either click Choose File and navigate to the image on your computer, or drag and drop the image from your computer into the dialog window and click Open.
Add a checksum (optional) (described in section below).
Click Upload to upload and register the image with the Apstra software. The image and image size appear in the table view.
If the (optional) checksum is not verified, the upgrade process stops, before the device reboots.

Method Two: Provide Image URL

If another HTTP server is accessible to the devices being upgraded via their network management port, you can register the OS Image instead of uploading it. Only HTTP URLs are supported. (HTTPS, FTP, SFTP, SCP and others are not supported.)

Select Provide Image URL.
Enter the URL that points to the image on the other server.
Add a checksum (optional) (described in the section below).
Click Register to register the image with the Apstra software. The image and image size appear in the table view.
If the (optional) checksum is not verified, the upgrade process stops, before the device reboots.

Add Checksum (Optional)

The platform determines the type of checksum that's used:

Juniper Junos - MD5 (32 characters) or SHA256 (64 characters)
Enterprise SONiC - MD5 (32 characters)
Cisco NX-OS - SHA512 (128 characters)
Arista EOS - SHA512 (128 characters)

If the device vendor provides a checksum file, we recommend that you download the file and copy it to the Checksum field. If a checksum file is not available, you can generate a checksum with the Linux md5sum or shasum commands, as applicable, or with equivalent programs.

content_copy zoom_out_map
$ shasum -a 512 EOS-4.20.11M.swi
dbfd28d3597777a6ee5946b52277205fc714e11ab992574b7ef1156ffcd6e379979979f8c009f665fc21212e4d38d1794a412d79bab149f859aa72be417c0975  EOS-4.20.11M.swi
$

Upgrade OS Image

Make sure that your devices are in the appropriate states for upgrading as described in the overview above, and that if you're device profiles are user-defined that you've updated them accordingly.

From the left navigation menu, navigate to Devices > Managed Devices, and select the check box(es) for the device(s) to upgrade. (If you have many devices, use the query function to filter selections.) All selected devices must be of the same type, and they must be upgraded to the same image and version. To search for specific devices (such as for all EOS devices) enter a query.
Click the Upgrade OS Image button (above table in Agent section). The dialog lists the available OS images that match the selected devices.
Select the appropriate image and click Upgrade OS Image. You can monitor the upgrade status from the Active Jobs section at the bottom of the page.
After the image is uploaded, if a checksum is provided with the OS image, the image checksum is verified. If the MD5/SHA512 checksum is incorrect, or if any other failures occur (such as for insufficient disk space, incorrect remote URL, or when the device NOS version is not changed post upgrade), the job state changes to FAIL and the device does not reboot.

Note:
If an issue arises with the OS image (such as interrupted download or invalid URL) during a NOS upgrade, you are informed before any device configuration is changed. You can then resolve the issue and restart the upgrade process.
If the job fails, click the agent to view errors. You can also click the Show Log button to view the detailed Ansible job. If an upgrade fails, you must manually resolve the issue causing the failure. For example, with a checksum error, you must either correct the invalid checksum or register a new OS image with a correct checksum, then repeat the upgrade process.
If the checksum is correct and no other failures occur, the job state changes to SUCCESS and the device reboots.
When the device has rebooted with the new image and has reestablished its agent connection with the controller, the upgrade is complete. The Managed Devices page displays the new OS version.

arrow_backward PREVIOUS Set Device Admin State

NEXT arrow_forward Delete Device

Juniper Apstra 4.2.2 / 4.2.1 / 4.2.0 User Guide

ON THIS PAGE

Upgrade Device NOS

NOS Upgrade Overview

Update User-defined Device Profiles

Register / Upload OS Image

Method One: Upload Image

Method Two: Provide Image URL

Add Checksum (Optional)

Upgrade OS Image

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry