Juniper Apstra software product version 6.1.0 is available to licensed, registered Juniper customers from the Juniper Apstra software download site.Documentation for Juniper Apstra 6.1.0 is available from the Juniper Apstra documentation site.
You can now use the Device Profiles Juniper_ptx10004_4x36dd_mdp and Juniper_ptx10008_8x36dd_mdp as a Tech Preview. These profiles have been updated to correctly support the 4x and 8x Juniper_ptx10k-lc1301-36dd-lc line cards.
Apstra now supports Juniper QFX5241-64OD and QFX5241-64QD models, which are also available as qualified platforms in the AI template Designer.
New Device Profile for Juniper QFX5241-32OD has been added. This model is also available in the AI template calculator as Juniper supported.
New Device Profiles are now available for the Arista 7280CR3A-48D6, 7280DR3A-54, and the 7804R3 chassis with the 7800R3-36D line card.
You can now deploy the Juniper PTX10002-36QDD switch in Apstra
Device Profiles now feature validations which describe and ensure compliance with inter-port configuration limitations associated with various hardware platforms. For example, a platform might require running pairs of ports at a common speed. The validations will warn you if the staged configuration requires setting members of a pair to different speeds. You can view the validations when reviewing the Device Profile details, and can configure the validations when creating or editing a device profile.
New Device Profile for Accton AS9817-64D, a Tomahawk5 based switch with 64x800G interfaces.
You now can use SONiC version 4.4.2.
Qualification of Cisco NX-OS 10.4(4)
With this new feature you will be logged out of your Apstra instance within 30 mins (default time) of the instance being idle.You can also change the default timeout value (5 min minimum).You will see a timer of 60 seconds before the instance is logged out.
This new feature allows you to leverage the AI Assistant within your Apstra instance to learn more about the status of your network and understand and analyze what anomalies are currently in your network. You can bring your own LLM and integrate it to your Apstra instance. You can access the chatbot within the Apstra UI.
This new UI enhancement for Anomalies provides a comprehensive and intuitive platform to identify, analyze, and resolve anomalies within your system. With the Current Anomalies view, you can quickly detect potential issues, leverage filtering and sorting capabilities, and gain insights through meaningful visualizations. On the Historical Anomalies page, you can view all historical data related to an anomaly in an interactive time-series view.The anomaly details page for each anomaly offers all relevant information, including type, affected elements and devices.
With this new feature, you can now perform in-place updates for security patches
You can now configure static MAC addresses for Integrated Routing and Bridging (IRB) interfaces in Apstra. This feature works similarly to configuring other network parameters such as Maximum Transmission Unit (MTU) settings. The solution includes a global default virtual MAC address setting that applies automatically to all IRB interfaces across your fabric. When you need specific MAC addresses for particular virtual networks, you can override the global setting on a per-virtual network basis. Your configured MAC addresses remain preserved during system updates and maintenance operations, ensuring network stability.
You can now leverage the AOS SDKs on PyPI through a more accessible and user-friendly experience. This provides version information and facilitates dependency management, including dependencies for the Apstra Ansible module.
Users can now upgrade Apstra ZTP either in-place or via VM-to-VM migration, allowing users to maintain ZTP configurations across new versions.
You can now reboot managed devices from the UI/API in the Devices - Managed Devices menu.
A new menu item has been added at the bottom of the left navigation bar to launch DC Assurance (dc.ai.juniper.net) in a new browser tab.
Apstra now supports managing devices operating in FIPS mode, ensuring enhanced security compliance for regulated environments. This update enables seamless integration of FIPS-compliant devices into your Apstra-managed network fabric.
You now can control in a granular the IP addressing for your underlay and choose between IPv4 you IPv6, allowing you to deploy EVPN fabrics over IPv6 underlays.
You can specify these settings on Day1 and update them on Day2 by editing the Routing Zone. Keep in mind that some Day2 changes may be disruptive and lead to traffic interruptions on the switches.
Audit logs in the Event Log under Platform now show events for device config deviation accepted (when the user accepts changes) and device config change (when the user applies the full config) with a diff on the configuration changes for each case.
You now can organize systems in "Upgrade Groups" enabling you to perform batch NOS upgrades across multiple systems simultaneously. By eliminating the tedious process of upgrading individual devices one by one, and executing bulk upgrades instead, you can significantly streamline your NOS upgrade process even for infrastructure at scale.Additionally, "Upgrade Groups" include an impact assessment feature that provides valuable insights into potential risks before the upgrade is executed.
You can now see a prominent UI indication after a Commit-Check operation that shows, for each device in the table, whether it will receive an incremental configuration as part of the next blueprint commit.
When enabling drain mode, users will now see a warning if all devices in a given fabric tier have been selected.This includes cases such as :All spines in a 3-stage fabricAll super spines or all spines in a pod (5-stage fabric)Both leaf switches in a leaf-pairThe warning allows users to review and deselect individual switches before committing, helping to prevent outages at that tier.
You can now directly upload the Network Operating System (NOS) image to the target device using the Copy Image action. This streamlines your NOS upgrade workflow by uploading the NOS images ahead of time, prior to the scheduled maintenance window. This capability is available for both individual devices and for groups of devices through the Upgrade Groups construct.
A new tab in the ZTP UI, called "Services," has been added to view the status of various ZTP components.
You can now easily add generic systems to a blueprint that have been discovered based upon automatically discovered LLDP data
With this new feature, Apstra actively monitors critical switch resources required for a reliable EVPN data center network and alerts you when thresholds are approaching. This capability is supported for both Juniper devices and third-party vendors.
This new probe allows you to gauge Control Plane Policing statistics.
This probe validates the VXLAN flood list entries on every leaf in the network. It collects appropriate telemetry data, compares it to the set of flood list forwarding entries expected to be present and alerts if expected entries are missing on any device.
This probe validates Control Plane Policing (COPP) output on all managed switches in the fabric. This is supported for Cisco NXOS, SONiC, Arista EOS, and Juniper devices. The anomaly threshold is based on any non-zero values seen and it collects the system response of DDOS outputs.
You can now install Apstra's compute agent on AMD-based GPU servers equipped with either Broadcom Thor2 NIC or Pensando's Pollara NIC providing access to comprehensive telemetry and analytics capabilities.The AMD deployments offer identical monitoring scope to their NVIDIA counterparts in version 6.0.0, including the following telemetry services: "hostname", "LLDP", "resource utilization", "interface", and "Interface counters", "GPU hardware Counters" used in ROCvE analytics.
You can now use definitions of custom telemetry collectors shipped as "Built-in" collectors which are predefined and immutable, shipped by default with the product. These collectors are ready to use and cannot be modified or deleted. However, you may clone a Built-in collector and customize the copy to meet your specific requirements.
You now can obtain an analytics report that provides comprehensive insights on MAC addresses and EVPN Route-Type 2. This report includes:
Active MAC address distribution per RZ and VN at start and end time.
Virtual Network growth over time for top 25 Virtual Networks.
Virtual networks size comparison by Routing Zone at start and end time.
Active MAC address distribution across devices (Top 3 VN's).
Missing MAC count observation.
Active and Missing MAC Address Counts.
You can now see the details of the GPUs vendor details for the GPU hosts in Managed device details.
This release supports upgrade paths from previous Apstra 5.1.X and 6.0.X releases.
Users must use VM-to-VM upgrades from Apstra 5.1.X and 6.0.X releases.Refer to the Apstra Installation and Upgrade Guide for more information on upgrade procedures.
A new page under Platform → Product Usage will show various statistics on features consumed/enabled and the associated license level based on usage.
You now can see the failed tasks with clear notifications that remain visible until you acknowledge them. This improvement ensures you stay informed about all task failures, regardless of when they happened or who initiated the task.
The API endpoints for anomalies now include the 'anomalous_node_id' field to provide a mapping between IBA anomalies and graph node IDs. This is applicable for the following API Endpoints: GET /api/anomalies to list all anomalies and GET /api/blueprints/{blueprint_id}/anomalies to list all anomalies for a given blueprint.All anomaly raising processors have been augmented with the new processor property named "Anomaly Anomalous Node ID" to be used in conjunction with Static Context keys to select a specific graph node.
You can now use IPv6 only to manage devices from the Apstra server. You can configure the network devices to have only IPv6 addresses, as well as the Apstra server, and Apstra will manage the devices directly using IPv6.
You now can use the Show Tech feature to collect comprehensive information from Compute agents running on NVIDIA or AMD GPU servers, including:
- GPU Information nvidia-smi -L - Lists all GPUs in the system along with their names, UUIDs, and GPU indices nvidia-smi topo -m - Lists NIC to GPU topology mappings, showing the connectivity between network interfaces and GPUs amd-smi static -B --json - Gather AMD GPU/accelerator diagnostics - Mellanox Hardware Information sudo mst status -v - Uses Mellanox Software Tools (MST) to display detailed information about Mellanox devices detected in the system sudo mlxconfig -d <device> query - Queries configuration parameters for detected Mellanox devices (dynamically discovers devices from MST output) - System Hardware Information sudo dmidecode -t system - Displays basic system hardware information including manufacturer, product name, version, and serial number as part of the system facts gathering process rdma link show --json - For RDMA interface mapping ethtool -i {interface} - Collect driver and version info for all interfaces
All the new diagnostic files are generated under the system_info folder
You can now deploy and manage the Apstra VM on RedHat OpenShift Virtualization
Apstra now compares your product usage to your applied licenses and provides warnings when a mismatch is detected, helping you stay compliant and optimize your investment. You can navigate to the Product Usage dashboard under Platform for detailed usage and entitlement reports, as well as guidance on resolving any discrepancies.
You can now configure the Apstra server with an IPv6 address and access the Apstra UI and Apstra Console via SSH through an IPv6 address.
You can now deploy and manage the Apstra VM on Nutanix 7.3 as the hypervisor
You can now create and execute lists of show commands across multiple devices using a new Apstra CLI command. This feature streamlines device troubleshooting and data collection by allowing you to define command sets once and run them against specific devices or device roles such as leaf, spine, or access switches within your data centre. The command outputs results both to your screen and saves them automatically to a compressed tar.gz file for later analysis.
This enhancement reduces the time needed for routine device queries and provides a consistent method for collecting diagnostic information across your network infrastructure. The compressed output format makes it simple to share diagnostic data with support teams or archive operational snapshots, whilst the role-based targeting eliminates the need to specify individual device identifiers for common troubleshooting scenarios.
The following updates have been made for switch operating systems qualified for the Apstra 6.1.0 release.
Juniper Networks:Junos Evolved for AIDC:23.4x100-D2023.4x100-D40
Junos (All roles):22.2R322.4R323.4R2-S5
Junos Evolved for IP-Forwarder role (Spines in EVPN or any role in an IP-Fabric):22.2R3-EVO22.4R3-EVO23.4R2-S5-EVO
Junos Evolved for EVPN leaf roles:22.2R3-EVO22.4R3-EVO23.4R2-S5-EVO
Junos Interconnect Gateway Leaf:22.4R3 (minimum)23.4R2-S5
Junos Evolved Interconnect Gateway Leaf:22.4R3-EVO (minimum)23.4R2-S5-EVO
Cisco Systems:10.2(6)10.3(4a)10.4(4)
Arista Networks:4.28.7.1M4.30.3M4.33.4M
Dell EMC & Edgecore:Enterprise SONiC 4.2.3Enterprise SONiC Edge Standard 4.2.3Enterprise SONiC 4.4.2Enterprise SONiC Edge Standard 4.4.2
The clone function in Rack Type Designer was improved. Now a single node gets copied below its parent, while multiple nodes get copied one step to the right from the selected group. All copied nodes are automatically selected after being created so they can be moved to the correct location.
You can now use Time-Voyager to store more revisions. Instead of limiting by revision count, it limits by time and disk space. The system uses diff-encoding like Git, which means revisions share disk space by removing duplicate parts. This allows storing hundreds or thousands of revision changes while using less disk space.
Within a Blueprint, Configlet Scopes written as `name in ["spine1"]` are now displayed as `id in ["id-of-spine1"]`. This change is cosmetic only: Under the covers, name-based scopes were always expressed by ID.
You can now write truly name-based Configlet Scopes using this notation: `label in ["spine1", "spine2"]`, or by using the constructor in the web UI.
You now can control with greater flexibility the application of configlets to your Cisco, Arista and SONiC blueprints through new capabilities including Differential Rendering which provides access to both previous and incoming device model for more granular/conditional rendering.The new feature also provides lifecycle awareness, enabling better identification of when a configlet appears for the first time and allowing more precise control over when the negation part is applied.
The EVO platforms now support sFlow on the management interface via the mgmt_junos VRF, with a minimum NOS version of 23.4X100-D31.6-EVO and 23.4R2-S3.11-EVO. You can now use the latest built-in configlet to leverage sending sFlow via the management interface on the mgmt_junos VRF.
You now can use a new modular architecture with Custom Telemetry which has evolved from a fixed functionality to being fully customizable. This new architecture lets you define advanced data processing in the form a data processing piepeline which is a collection of nodes, each performing a single function on a set of telemetry data, linked together to form a data flow. This follows the Function composition paradigm.
New capabilities have been introduced such as the "Join" and "Group" functionalities for improved data manipulation. This allows for example to define telemetry collectors leveraging more than one command.
You now can create and test pipeline queries without upfront choosing or creating the target service. i.e no need to define the Schema upfront like in previous releases. This allows you to focus on creating the desired query first and then create the service that will match the query output.
You now can use the Interface Queue Stats probe to collect and analyze critical interface metrics on the Spine-to-Leaf portion, representing an expansion compared to the previous monitoring scope, which was limited to the Generic-facing interfaces only. This includes both Uplink interfaces on the on Leaf devices and downlink interfaces on the Spines devices.
You now can benefit from more granular reporting in the predefined Queue Stats Monitoring dashboard, now structured to display for every metric, first the values on the Leaf-To-Spine interfaces portion, following by the ones in the Leaf-To-Generic interfaces portion.
The probe remains supported on QFX platforms only, which share the same internal architecture for traffic management, enabling consistency in the data collection and reporting. As such, PTX platforms, even if supported as qualified models in AI Cluster Reference-Design are excluded from the scope of this probe.
You now can set differentiated thresholds for anomaly raising in the Device System Health probe on a per System type basis Switch, Server.You now can Enable/Disable the anomaly raising for the Device System Health probe on a per System type basis Switch, Server.
You now can use the predefined and auto-enabled Device Traffic probe that has been enhanced to support multiple use-cases that were previously handled by six separate IBA probes which had to be manually instantiated. The list of these six probes for which the logic has been added to the Device Traffic probe are the following (Note that these IBA probes remain in the product as of 6.1.0 release. Their deprecation (removal) will be planned in the following release: Minecraft):
Hot/Cold Interface Counters (Fabric Interfaces)
Hot/Cold Interface Counters (Spine to Superspine Interfaces)
Hot/Cold Interface Counters (Specific Interfaces)
ECMP Imbalance (Fabric Interfaces)
ECMP Imbalance (Spine to Superspine Interfaces)
Packet Discard percentage
The incorporation of the analytics from those 7 probes into the new "Device Traffic" probe is designed with a focus on the core essentials, providing you with valuable insights. The result is a simplification by eliminating excessive options so you don't suffer from "choice paralysis" syndrome.
You now have the ability to stream any type of IBA data including dynamic stages. This means that all forms of IBA data can be accessed and transmitted in real-time through streaming capabilities.
Users can now install the compute Device agent for GPU servers using Out-Of-Band installation methods eliminating the requirement to maintain GPU server credentials within Apstra.
Junos and Junos EVO switches now use load-update instead of load-override for configuration management. Load-update modifies only the specific settings that need to change, rather than replacing your entire configuration. The system compares your current configuration with new data and updates only the differences between them. This approach provides better support for advanced features like MACsec and AAA, which require precise configuration updates rather than complete replacements.
The Product Usage reports now track the number of GPUs deployed and managed in an AIDC cluster.
You now have a DEPRECATED status for API endpoints that comes before REMOVED. Deprecated endpoints include a Deprecation HTTP Header Field and appear strikethrough in the API Explorer before being physically removed from the code. The changlog displays the changes in a stacked way ordering different release changes by importance, with the most recent information on top: REMOVED, DEPRECATED, CHANGED, NEW.
You now can access the API changelog in the documentation so you can review it for any changes before you install the new version.
Displaying for every release the total count of change by type acting as hyperlinks to update the page with that filter. With this users can select a specific release and request to view only NEW changes or any other single change type.
Upon installing a new system agent, Apstra now verifies that the device's Netconf server is operational. This same validation process is also executed when initiating a Check Job request.
When attempting to delete a Virtual Network that are used in Connectivity Templates configured with Multiple VLAN primitives, the system now implements a two-stage verification workflow. Because removing this network could cascade and affect additional Virtual Networks, potentially triggering their removal as well, you must first review the deletion's consequences through a "View the impact" option before proceeding with the final confirmation. This ensures you are fully informed of the impact and can update or adapt the Connectivity Template design as needed.
IP Enrichment APIAn API will be introduced to enable programmatic management of IP enrichment data, providing an automation alternative to manually editing ipaddrs.yml.
ipaddrs.yml
API Development:Â Build a gRPC/REST API for creating, updating, listing, and deleting enrichment entries.
Authentication:Â Use the already-existing "basic authentication" mechanism enabled by EF_API_BASIC_AUTH_ENABLE and related configuration settings.
Support Bundles: Ensure encrypted files are automatically decrypted when generating support bundles
Tech Previews give you the ability to test functionality and provide feedback during the development process of innovations that are not final production features. The goal of a Tech Preview is for the feature to gain wider exposure and potential full support in a future release. Customers are encouraged to provide feedback and functionality suggestions for a Technology Preview feature before it becomes fully supported.
Tech Previews may not be functionally complete, may have functional alterations in future releases, or may get dropped under changing markets or unexpected conditions, at Juniper’s sole discretion. Juniper recommends that you use Tech Preview features in non-production environments only.
Juniper considers feedback to add and improve future iterations of the general availability of the innovations. Your feedback does not assert any intellectual property claim, and Juniper may implement your feedback without violating your or any other party's rights.
These features are "as is" and voluntary use. Support Services will attempt to resolve any issues that customers experience when using these features and create bug reports on behalf of support cases. However, Juniper may not provide comprehensive support services to Tech Preview features. Certain features may have reduced or modified security, accessibility, availability, and reliability standards relative to General Availability software. Tech Preview is not supported under existing service agreements, SLAs, or support service.
For additional details, please contact Juniper Support or your local account team.
You can now create an AI based rail-aligned blueprint with EVPN overlay control plane. This is a Tech-Preview feature to start prototyping the GPUaaS use-cases.
You now can use the offbox unit mode when creating offbox agents, enabling you to associate multiple managed devices with a single Docker container instead of the traditional 1:1 Device to Offbox Agent mapping. In this new mode, delivered as Tech-Preview in 6.1.0, one offbox unit docker container will host the agents for multiple devices (by default 16). This offers significant resources optimization (such as the memory footprint), hence significantly enhancing the Offbox Worker Node Scaling.Â
Attempting to pull the configlet preview for specific blueprint device ("On Device Configlet Preview"), by clicking on the device label under the general configlet preview page might fail with a slightly misleading error, if the device is unassigned. Certainly trying to get a preview for a device which is not assigned is bound to cause an error, as a real preview for a device that doesn't exist isn't possible. However, the error emitted is slightly confusing.
The error message will be improved to convey the actual problem accurately in Apstra 5.1.0.
In the AI Cluster Template workflow, selecting "Manually Selected" under Device Models incorrectly shows "4 selected" even when no models are chosen. The count should reflect actual selections or indicate default behavior clearly.
The fix to resolve the counting error in the device profile tables selection setting is targeted for version 6.1.0.
AOS server details stored in the local aos.conf file currently take precedence over any AOS server information entered through the ZTP UI.
When using the ZTP UI to post or update AOS server details, the updates will be stored in the database - this is going to be the primary source of truth for AOS server information. If the database is unavailable or the details are not yet posted, the AOS configuration file located at /containers_data/status/app/aos.conf is used as a fallback to retrieve the AOS server details. These AOS server details are essential for ZTP to forward devices ZTP status and ZTP services status to AOS, and to trigger system-agent jobs if directed by the user via the ztp configuration file(ztp.json).
When instantiating predefined probes such as "VMs Without Fabric Configured VLANs" Apstra UI may fail to display the probe with a type error, making the probe unusable.
The issue is resolved in Apstra 6.1.0, where predefined probes may not be usable from a typeerror in the UI
In Apstra 6.0, the Main Topology View (Blueprint > Staged > Physical > Topology) displays ESI/MLAG pairs with leaf2 positioned on the left and leaf1 on the right, which is the reverse of the layout seen in prior versions. In previous versions, the UI consistently rendered ESI/MLAG pairs with leaf1 on the left and leaf2 on the right, aligning with user expectations. The change in Apstra 6.0 is purely cosmetic and does not affect system behavior or configuration.
The issue is resolved in Apstra 6.1.0, where the ESI/MLAG leaf switches are displayed in the correct left-to-right order, consistent with previous versions.
The timestamp field of AosMessage in the streaming has used uint64 format for both millisecond and microsecond timestamp information. The current timestamp uin64 field will be changed in release 6.1.0 to the google.protobuf.Timestamp format, which is incompatible with the previous version, in order to provide consistent, accurate timestamp information. The streaming receiver side must be modified to accommodate this incompatible modification.
The timestamp field of AosMessage is changed from uint64 to google.protobuf.Timestamp format
An event involving BGP flaps from BGP peers configured on IRB/Loopback interfaces for Juniper EVO device has been reported during the commit with incremental changes (deleting an IRB/Loopback interface in the same VRF). The BGP flaps happen when the device's configuration is committed in override mode, which was Apstra's default setting prior to 6.1.0. However, using load update mode did not reveal the issue.
6.1.0 uses default mode as a load update for commit operations for both on-box and off-box agents.
Starting with Apstra-6.1.0 release, blueprints with disabled IPv6 application support and IPv6 addressing on fabric links are no longer supported.
Starting with Apstra-6.1.0 release, subinterfaces and static routes with IPv6 addressing over IPv4 underlay are no longer supported for default Routing Zone. Additionally, IPv6 link-local subinterfaces in a blueprint without IPv6 application support are no longer allowed for any Routing Zone. These configurations are not valid logically considering the underlay capabilities for each case.
In the case of IPv6 subinterfaces and static routes with IPv4 underlay (spine_leaf_links == ipv4), the only solution is to delete the problematic entities. For the IPv6 link-local subinterfaces there are two options, either enable IPv6 support for the blueprint or delete the problematic subinterfaces. Usually subinterfaces and static routes are created by Connectivity Templates, so to delete them the corresponding Connectivity Template should be unassigned.
User feedback was added in Apstra 6.0.0 to enable users to share their Apstra experiences. After the release of Apstra 6.0.0, the link to the feedback form was changed. It results in an error message about a missing form.
The link to the feedback form is updated with permanent link information, which allows feedback form to be referenced correctly.
If the rendered device configuration for the VLAN description contains newline characters populated from the virtual network's description field, the commit operation fails because JUNOS and JUNOS-EVO devices do not support multi-line string for the VLAN description.
Starting with Apstra-6.1.0 release, connectivity templates (CTs) with the same primitive policy having multiple batch or pipeline parent policies are no longer supported. This configuration causes ambiguity in CT application and can lead to unexpected behavior.
Delete the problematic connectivity templates from the UI and recreate them. The UI will automatically create the correct structure with proper parent-child relationships.If the /obj-policy-import API is used directly, ensure that primitive policy IDs are not reused across different "batch" or "pipeline" subpolicies. Each policy (primitive policy, pipeline, batch) should have a unique parent policy.
While viewing/editing CT (Connectivity Template)s across blueprints, it's possible that the CT may incorrectly display empty field values.
In version 4.2.0, Apstra introduces the capability for users to forcibly delete a Virtual Network, even if it has active endpoints. Apstra will initially display the interfaces to which the Virtual Network (VN) is currently allocated and prompt the user to confirm the deletion. It's important to note a limitation in the current design: if a user deletes a VN assigned in a CT where Multiple VLANs are present, all active endpoints will be unassigned.
RFE-3417 (addressed in 6.1.0) provides more contextual information to prevent unexpected consequences before action is taken.
RFE-3417
DeviceTelemetryAgent.{pid}.log files in /var/log/aos/ in the offbox agents become large and can fill up the disk
ECN marked packet information is not currently visible in the dashboard widget, although it is correctly displayed in the staged view in the probe.
Execute CLI commands in the Juniper device supported only show and request chassis beacon commands in the Apstra < 6.1.0 environment. Additional commands (ping and traceroute) are introduced in Execute CLI commands in the Apstra >= 6.1.0 environment for easier troubleshooting environments.
Because the JUNOS device might not send the full snapshot of interface-related data per reporting interval (default interval = 120 seconds) after initial synchronization, Device Telemetry Health detects continuous anomalies for gRPC Periodic Response Timeout in the interface telemetry service in a high-scale environment. The problem still exists even if the reporting interval is extended.
In 6.1.0, the interface telemetry, which uses gRPC periodic collection, will be enhanced to accommodate the gRPC updates from the device without triggering hold timeout, as long as the device sends the data per reporting interval. gRPC can be enabled back safely by setting grpc_enabled = 1 in the apstra configuration file (/user/root/etc/aos/aos.conf) and restarting AOS services (sudo service aos restart).
[telemetry_global_config] # Python multithreading enable/disable knob for telemetry collection multithreading_config = 1 # Execution timeout for extensible telemetry collectors command_timeout = 120 # Knob to enable/disable gRPC based service collectors grpc_enabled = 1
Because the MAC telemetry service uses the gRPCOnChange mode, the device only sends updates after initial synchronization. When the JUNOS device subscribes to the PATH (/network-instances/network-instance/mac-table/entries/entry) for MAC telemetry service, Apstra's gRPC client (Apstra) receives the first full data from two processes (l2ald, l2aldTM). During the initial synchronization, these processes use their own sequence number range (duplicate range), which makes the gRPC client think that the gRPC packets may be dropped internally. Granular sequence number handling will be introduced in 6.1.0 to address the existing sequence overrun issue.
The more granular sequence handling is implemented in gRPC sequence handling logic. gRPC can be enabled back safely by setting grpc_enabled = 1 in the apstra configuration file (/user/root/etc/aos/aos.conf) and restarting AOS services (sudo service aos restart).
The default collection period for IBA interface flapping is only 60 seconds and the flapping threshold is 5 times. But, the default collection period for interface service is 2 minutes, the interface will receive updates every 2 minutes only.
So, the default anomaly window is too small to capture 5 interface flaps. For 5 flaps it should be at least 10 minutes.
The threshold was changed from 5 to 2 and increasing duration from 1 minute to 6 minutes. With this change the probe is capable of tracking at least 3 interface statuses meaning 2 flaps/transitions, i.e. state -> state -> state where the value of the state doesn't matter. If so, an anomaly is raised.
Using the system parameters (go to the staging tab of the freeform blueprint, choose the target switch, enter the edit mode for the S/N field, then click the Reset value button) will not allow the Apstra UI to unassign a serial number for a system. The failure of "deploy_mode" will result in the message "Value is required." because the Apstra backend expects the deploy_mode value to be one of the values ("deploy", "ready", "drain", or "undeploy"), but the Apstra UI sends the deploy_mode value as null when the serial number is unassigned.
Apstra UI validation changed to allow un-assign the S/N when the system is part of a freeform blueprint
Customers attempting an in-place upgrade to AOS 6.1.0 may experience a failure during the upgrade pre-check stage if the system is running an unsupported or incompatible version of the docker-ce package.
When performing a ZTP upgrade to version 6.1.0, ensure that the required docker-ce package (version 5:27.5.1-1~ubuntu.22.04~jammy) is installed to maintain compatibility.
Installation failure of the out-of-band system agent for GPU servers () is observed under the below activities1. Install the "telemetry only" system agent on device1 using the Managed Devices in the UI. Select "Install" option for "Job run after creation" field2. Uninstall the agent via the Managed Devices in the UI. Also delete the device once the agent uninstallation is complete.3. Install the OOB agent on the device using device agent images (aos_device_agent-XXX.run)4. Using the UI create an onbox agent and select "telemetry only" and "None" option for "Job after creation".
A fix was merged to easier allow oob device agent install (following the below workaround) until this issue can be fully resolvedDelete system Agent and then install the OOB agent by running the command : bash aos_device_agent.run – --metadb tbt://{controller_ip}:29731 --interface eth0 --install-type outOfBand
interface 25g speed configuration was not properly rendered over ports 4-27 when 25g transformation is used in the Juniper ACX7024 device profile
interface speed 25g now rendered as part of 25g transformation for Juniper ACX7024 devices
If a user adds an invalid character like a "space" to elements (e.g. link labels) in an Apstra Blueprint, it will cause errors when the user attempts to add a pod to a Blueprint.
Junos RFC5549 BGP peer sessions were rendering the same route-map twice on import/export statements. This only applies to 'ipv6-only' bgp peers.
Configurations were rendering:
neighbor a05:fab:192:168:50::254 { description "facing_leaf1-generic"; local-address a05:fab:192:168:50::1; peer-as 65510; family inet { unicast { extended-nexthop; } } family inet6 { unicast; } import ( RoutesFromExt-default-Default_immutable && RoutesFromExt-default-Default_immutable ); export ( RoutesToExt-default-Default_immutable && RoutesToExt-default-Default_immutable ); }
This has been addressed in 6.1.0, where the import and export statements will contain that route-map entry only once.
This may result in a service disruption on upgrade for those BGP peers as Junos generically may reset the peer when it detects any import/export policy reference change.
This will also apply to ipv6-only, non-EVPN blueprints for route-maps such as "LEAF_TO_SPINE_FABRIC_OUT" between all superspine/spine/leaves.
The configuration will automatically be corrected upon upgrade to Apstra 6.1.0.
For Junos off-box agents, when load_mode is configured as update (available from Apstra 5.x), reverting interfaces from 25G back to 10G can fail during deployment. During the rollback phase of the update operation, Junos generates a warning because the 25G speed configuration affects the entire port group (eg., ports 0–3). This warning is returned through the rollback RPC call. In affected releases, the rollback operation does not ignore warnings (ignore_warning=True is not used). As a result, PyEZ treats the warning as a fatal RpcError, causing the deployment to abort and the agent to continuously retry the deployment. Example error from DeploymentProxyAgent logs:
RpcError(severity: warning, bad_element: speed 25g, message: mgd: 25g config will be applied to ports 0 to 3)
This behavior can cause the device to remain stuck in Service Config in_progress state until manual recovery or workaround steps are applied.
This issue is resolved in Apstra 6.1.0, the agent handles Junos rollback warnings gracefully by ignoring non-fatal warnings during rollback operations, preventing deployment failures and retry loops.
The Router MAC (also known as Master Bridge MAC or bridge MAC) on a SONiC device is a unique MAC address assigned to the switch and used as the source MAC address for packets originating from the switch itself, such as those generated by the virtual router or bridge interfaces. The current Mac Monitor probe does not report Router MAC on the originating switch (for example, if leaf1 has MasterBridgeMac as 52:54:00:4e:c6:60, this MAC will show up as a missing MAC on leaf1 for all VNs).This is a bug related to analytics only; it does not have any network operational impact.
The NOS upgrade procedure must parse the pristine configuration in order to determine which ports must be disabled when the Skip Shutting Down Interface During Upgrade option is not checked in the Advanced Settings of Managed Device. The NOS upgrade would fail if the configuration line in the pristine configuration extended into multiple lines because parsing the command line misses the end-of-command-line character (.
For deployment, the system agent attempts to map the agent's ID (UUID) to the system serial number using two step resolutions: system agent ID to management IP address mapping configured when the agent is created, and management IP address to system serial number mapping during device fact collection. When a system agent is configured as a FQDN rather than an IP address for the management IP address, the resolution from the agent's ID to the system serial is incorrect, causing deployment to stall until it is resolved.
When the Optical Transceivers Probe is turned on, the optical_xcvr telemetry service is enabled for all systems with on-box agents (including GPU servers) or off-box agents. Because the optical_xcvr telemetry service is not designed to run on GPU servers, it fails to collect optical transceiver information and returns an error message.
The graph query of the Optical Xcvr Stats process in the Optical Transceivers Probe is refined to cover only switch nodes.
Every leaf (device that is a part of the VN network) device has its EVPN Type2 expectations validated by Mac Monitor Probe. By using EVPN type 2 advertisement ingestion, it indicates as missing the MAC addresses that should be on the devices but aren't.
Mac Monitor Probe
It is observed in a SONiC environment that a device does not ingest the type 2 advertisements to the corresponding VLAN forwarding (MAC) table if it is not connected to a host for the given VN. In the event that the device is a part of the MLAG pair, the type 2 advertisements are ingested into the Mac Table even if it is not host-attached.
As of right now, the MacMonitor probe ignores any device from the previously mentioned type 2 validation that has no host attached. As a result, SONiC devices that are part of the MLAG but lack VN endpoints (hosts attached) are excluded from the type 2 missing MAC check. As a result, on such devices, the probe might not find any missing MACs.
However, in MLAG scenarios, no traffic is expected for the specified VLAN on the rack if a leaf device has no connected hosts, i.e., VN endpoints, so this issue has no functional impact.
An exception will be added for SONiC MLAG racks when no VN endpoints are attached in order to fix the problem. When the exception is enabled, this modification will guarantee precise verification of missing MACs against the total number of MACs discovered for the EVPN-VN. 5.1.0 is the intended release date.
When a port group in the vCenter is configured with a private vlan mode, the VLAN specification contains the pvlanid property instead of the vlanid property. However, the vlanid property is always expected from the port group's vlan specification by the Device Telemetry Agent's collector if it is not trunk mode. Anomalies could be reported if the collector's execution fails due to a reference to the vlanid property, which is nonexistent.
Sutatined Optical Threshold anomalies are frequently observed over disconnected (not connected) interfaces in the JUNOS device. The main reason for the problem is that the JUNOS device sometimes reports the received average power as a very low value or - Inf value when the interface is disconnected, and Apstra does not correctly parse the - Inf value. When a very low power value falls below the warning level, Apstra creates an anomaly for the low receive power port. But when the same interface reports a - Inf value that is later incorrectly parsed, Apstra eliminates the interface from the list of interfaces with an optical transceiver, thereby resolving the raised anomaly falsely. This is the reason anomalies are frequently raised and cleared over the same interface. No workaround is available for this issue
Since the UI misses polling of the node detail information to the Apstra backend, the Virtual Network Endpoints view of Generic System Node (Staged > Physical > Topology > Virtual Networks Endpoints) shows empty information.
Apstra creates a relationship between the PNIC and the Link Discovery Policy (which determines which discovery protocol is used) configured in the VDS when a PNIC is assigned to a VDS (Virtual Distributed Switch). One PNIC may inadvertently become linked to two relationships without clearing out the previous relationship when a user moves a PNIC directly from one VDS to another VDS. An error message below appears when the PNIC becomes unassigned from VDS because there is more than one relationship between the PNIC and Link Discovery Policy that is invalid.
virtual_infra failed to collect data, plugin raised exception: {'item_iter': <aos.sdk.graph.graph.RelationshipIterator object at 0x7f60c03f9570>, 'items': [df57a2f0-969c-4dee-9831-a53526bd7d5a-[:policy]->4c8c4c31-df9a-4188-933f-6b5d67703a1f, df57a2f0-969c-4dee-9831-a53526bd7d5a-[:policy]->1787d662-4a41-4b8b-9b77-acac5508e771]}
When multiple vNICs from a single VM are assigned to the same vNET (port group or VDS) in the Virtual Infra, the VMs Without Fabric Configured VLANs probe raises anomalies in the Analytics->Anomalies because the graph query in the VMs backed by Fabric VLANs processor treats those vNICs as identical.
When a user attempts to open the racks or pods tab in the Staged->Physical section, rack schema validation logic will be executed for every rack in the blueprint. In order to avoid incompatibilities with the underlying database, non-ASCII characters cannot be included in the link group label, which might be explicitly supplied when adding a generic system to leaf or access nodes.
Anomalies are raised due to mismatch in the operational status of interfaces due to interface status showing "unknown" on Juniper EX4400-48T devices running Junos 22.4R3.
Issue not observed in higher versions of Junos. Recommend NOS upgrade to Apstra-qualified higher JUNOS version (>= 23.4R2-S4).
When Apstra Edge container is configured with Apstra Flow together in the Apstra Controller VM, Apstra Edge shows 50% CPU utilization, which may affect the performance of the Apstra Controller and other containers. The issue is observed when the Apstra Edge container 0.5.0 image is used. In the latest version, 0.16.5, the issue is not shown anymore.
Upgrade Apstra Cloud Services Edge image from 0.5.0 to the latest image, 0.16.5 in the Apstra 5.1.0 release.
When the Apstra commit was executed, the JUNOS device with the off-box agent reported BFD underlay flaps between the committed device and the other devices. Apstra currently uses the load override option as the default action for device commits, which may result in high CPU utilization, preventing time-sensitive daemons from acquiring CPU time slices and triggering unexpected events such as BFD timeouts or writing EEPROM errors. Starting with 6.1.0, Apstra intends to use load update as the default commit action for JUNOS and EVO devices.
In 6.1.0, Apstra uses load update as default for commit action instead of load override for JUNOS/EVO on-box and off-box agents
Apstra 6.1.0 enables users to change VTEP addressing on Junos/Junos EVO devices between IPv4 and IPv6.This typically results in a PFE restart with new forwarding option configurations on some platforms as well as restarting all of the EVPN sessions in the blueprint as they transition from ipv4 & ipv6.
Users must take caution and plan maintenance windows when moving VTEP addressing to and from IPv6 as a day2 operation.
In Junos Evolved, the customer is able to remove the device FIPS mode by simply changing the configuration and, importantly, without having to zeroize the device. This is not a bug.
Customers should be aware of this and should not modify their pristine configuration in a way that removes the FIPS configuration.
Due to an outstanding bug in all available versions of Junos EVO, when two virtual networks are hosted on the same set of ESI leafs, one with DHCP enabled and one with DHCP disabled, the virtual network with DHCP disabled will also have DHCP requests forwarded.
NX-OS when configured for First Hop redundancy uses the Virtual Mac address assigned for BGP sessions. This causes BGP session tcp sessions to not come up as they may end up on the incorrect switch.
The Apstra offbox agent may fail to connect to and manage Juniper ACX7100-48L devices running Junos EVO 22.x releases. On affected devices with BIOS ROM firmware version 16.02 or later, the data interfaces are not properly initialized under older Junos EVO images, causing the show chassis mac-addresses command to return empty output. The offbox agent requires chassis MAC address information during device onboarding; when this information is unavailable, the agent aborts with an error and continuously restarts, preventing device management.This issue affects only ACX7100-48L devices that have been updated to a newer BIOS firmware version. Devices with BIOS ROM firmware version 13.01 are not affected.
Upgrade affected ACX7100-48L devices to Junos EVO 23.4R2-S7.3 or later. This version resolves the BIOS firmware compatibility issue and restores proper interface initialization and chassis MAC address reporting on devices with newer BIOS firmware.
For power supplies, Apstra primarily uses the output of the show chassis environment pem or show chassis environment psm command. On the QFX10002-36Q, both PEMs are reported, however, only one includes the XML tag that designates the component class as Power. The power supply information is further augmented using the show chassis environment command. Since the tag is missing for one PEM, Apstra does not recognize it as a valid power supply component. This is a known issue in Junos. Below is an example of the XML output from the show chassis environment without the class tag:
<environment-item> <name>FPC 0 Power Supply 1</name> <status>Present</status> </environment-item>
Due to inconsistent Junos behavior, the Power Supply State Check processor of Apstra does not evaluate the affected PEM, and no anomaly is raised. No workaround is available for this issue. This issue is expected to be addressed in newer Junos versions from 24.4R2, and the corrected behavior is expected to be present in supported versions for Apstra 6.1.0 and later.
Recommend using Apstra Qualified Junos NOS version >= 24.4R2
When copying NOS images to SONiC devices, the images are placed in a temporary directory. If the device reboots before the image is installed, the copied image will be deleted.
When deploying EVPN with IPv6 VTEP addressing in blueprints containing Juniper PTX or virtual Junos EVO (vEVO) devices (such as PTX10001-36MR), Junos EVO ignores the IPv6 VTEP source interface configuration (vtep-source-interface lo0.0 inet6) due to lack of platform CLI support. As a result, the device remains on IPv4 VTEPs, which can cause traffic inconsistencies and unexpected behavior in IPv6 underlay/overlay fabrics.
Apstra now introduces a validation check that flags unsupported IPv6 VTEP configurations on Junos PTX and vEVO platforms during design validation and staging. This prevents applying unsupported IPv6 VTEP configurations to affected devices.
2026-09-18: Added AOS-63682,AOS-63699
2026-09-15: Added AOS-57283,AOS-58620,AOS-61298
2026-09-08: Added AOS-63479
2026-09-04: Added AOS-56164
2026-08-17: Added AOS-63170
2026-08-11: Added AOS-57034,AOS-57566,AOS-59537,AOS-60746,AOS-62971
2026-08-10: Added AOS-60017,AOS-60889,AOS-61353,AOS-62222
2026-07-23: Added AOS-62738
2026-06-29: Added AOS-62117
2026-06-15: Added AOS-61764
2026-06-08: Added AOS-61624
2026-05-26: Updated AOS-59416, AOS-60637
2026-05-15: Updated AOS-54864
2026-05-14: Added AOS-61108
2026-05-06: Added AOS-57295
2026-04-21: Added AOS-52788, AOS-60637
2026-04-14: Added AOS-60612
2026-04-13: Updated AOS-60011,Added AOS-59984
2026-04-09: Added AOS-54864,AOS-60011
2026-04-03: Added AOS-55780
2026-03-23: Added AOS-60167,AOS-60183,AOS-60193
2026-03-18: Removed AOS-51029,Updated AOS-59821,Added AOS-59842,AOS-60093,AOS-60114
2026-03-16: Added AOS-60061
2026-03-05: Added AOS-59821,AOS-59931
2026-03-03: Added AOS-59726,AOS-59869,AOS-59895
2026-02-22: Added AOS-59758,AOS-59777
2026-02-18: Removed AOS-58460, Added AOS-58991,AOS-59596
2026-02-11: Added AOS-59269,AOS-59579,AOS-59663
2026-02-03: Added AOS-59198,A0S-59416
2026-01-28: Updated AOS-56175,AOS-56282
2026-01-27: Added AOS-59296
2026-01-20: Initial Publishing.