Juniper Apstra software product version 6.1.2 is available to licensed, registered Juniper customers from the Juniper Apstra software download site.
N/A
You can now use SONiC 4.5.1 with Apstra
Adding multiple AAA servers in the blueprint through Staged > Catalog > AAA Servers leads to a configuration load error in the JUNOS and EVO device during commit check or commit.
After upgrading Apstra from version 5.1.0 to 6.1.1, frequent updates to the LLDP graph result in repeated updates to the operational graph. This, in turn, triggers the DashboardManager to evaluate predefined dashboard graph query conditions for all blueprints, leading to high CPU utilization of the ScotchAgent. As a result, the customer is unable to perform any actions on the blueprint.
In Apstra 6.1.0 and later, Junos configlet containing multiline login banner text using newline escape sequences fails during commit check with a ConfigLoadError. The same configlet works as expected in Apstra 6.0 and earlier releases. In Apstra 6.1.0, a regex change was introduced in the config processing logic. As a result, the login message is incorrectly split into multiple separate lines, leaving orphaned tokens. These orphaned tokens are interpreted by Junos as unknown commands, causing the commit check to fail.
The Last Modified field of the interface telemetry service, which uses gRPC periodic mode, is inadvertently updated according to the interface telemetry service's default interval even if no data has been collected from the device. This problem is noticed when gRPC periodic mode is used for Interface telemetry service. The Last Modified field should be updated if a status change is observed, and the Last Fetched field should be updated if the device reports telemetry data.
The Last Fetched and Last Modified fields in the Interface Telemetry Service using gRPC periodic mode are correctly updated with the right information.
When upgrading Apstra to 6.1.1, liveness anomalies may be observed for offbox agents due to missing SSH host fingerprint keys. The Managed Devices page may continue to display a healthy green status and may not indicate any issue. The problem becomes visible only when navigating to the individual agent page of a specific device, where a known-hosts related error is shown. Additionally, the agent displayed Apstra version may remain at older version instead of 6.1.1 until the issue is resolved.
The workaround is to run the Update Host Key job for the affected devices so that the SSH host keys are refreshed and agent health returns to normal.
Future enhancements will focus on improving console and UI notifications to proactively alert users to update host keys following an Apstra upgrade.
User-defined import / export route-targets with ":0" are rejected with validation errors.
{ "rt_policy": { "import_RTs": { "0": "Type 0 RD X:Y must be in format 2-byte ASN:4-byte value. Provided value: \"65500:0\"" } }
Apstra release 6.1.2 has corrected the validators to permit ":0" suffixes.
Because the Jinja comment is not recognized as a valid Jinja expression during rendering, it is submitted as normal commands to the device, causing the JUNOS/EVO device to reject the invalid commands and deployment to fail.
The state_check processor outputs a state column for each series. However, users may not be able to filter series in the output stage using the per series state column when querying stage data. Users attempting to use a filter such as properties.state = 'false, true' may see no results, even if matching data is present. This is a known limitation in how filtering works on series-level data in the state_check processors output. The filtering behavior may not align with user expectations when attempting to use conditions on the state column. Engineering evaluating potential improvements to allow filtering on state column in state processor for a future release.
Decreasing the value of the "Time Window" property of the "Time in State" processor, either directly or via predefined probe parameters, may not have an immediate effect but rather after the expiration of a previously configured time window or an update of the input stage.
Disable and enable back the affected probe
Apstra's BuilderAgent may crash if the generic system's interface name (if_name), identified by LLDP from the generic system, contains trailing space after the user creates generic systems based on the gathered LLDP data. This is because the automatically generated interface's description for the generic system contains if_name information with trailing space, which causes a validation error in the BuilderAgent.
The below signature can be seen in the BuildAgent.err log file.File "/usr/lib/python3.10/dist-packages/aos/grappa/table/cpp_graph.py", line 909, in set_noderaise ValidationError(errors)lollipop.errors.ValidationError: Invalid data: {'description': 'Invalid description. Only ASCII characters with codes 32 - 126, except "?", "<", ">" ,\'"\' and are allowed. The description should not start or end with a space.'}
The if_name with trailig space (coming from LLDP) needs to be correct by REST API Post call. Please contact Juniper Apstra Support for further assistance.
Junos devices use multiple SSH host key families. Due to differences in how host key negotiation is handled between the Apstra system agent and managed devices, regenerating a single host key type may not always exhibit a Host Key Mismatch error in the check job output. In some cases, the agent may successfully connect using an alternative valid key type still present in the trust store, or it may fail with a generic error instead of a Host Key Mismatch error or BadHostKeyException. There is no security vulnerability as no unverified keys are accepted.
To ensure consistent state and agent connectivity, users should perform an Update Host Keys job in the Apstra UI whenever any single host key is regenerated.
As a workaround, users must manually trigger a key update after any regeneration:
1) Navigate to Devices > Managed Devices. 2) Select the affected device(s). 3) Execute the Update Host Keys job from the bulk actions or individual device menu.
To ensure the Apstra controller has an updated and consistent record of all device host keys, users must manually trigger a key update after any regeneration:
When multiple show-tech jobs are triggered simultaneously, the /var/log partition can reach high utilization, causing the controller to enter read-only mode. This may result in incomplete job status updates, leaving several jobs stuck in in-progress or pending states. In a corner case, this condition can also lead to repeated crashes of SystemAgentManager, preventing automatic recovery even after disk space is reclaimed. Avoid triggering bulk show-tech collection on a large number of devices. Ensure sufficient disk space is available before running show-tech.
If the issue occurs, reclaim space in /var/log and restart AOS services. In most cases, SystemAgentManager recovers automatically, clearing stuck jobs and completing or failing pending ones. If SystemAgentManager crash persist and jobs remain stuck, manual cleanup via Acons is required. It is recommended to contact Apstra Support for assistance.
When modifying the maximum disk usage setting in a blueprint, the following behavior may be observed:
1. If the maximum disk usage is set to a value lower than the current disk usage, the blueprint commit fails. 2. If the maximum disk usage is increased to a value greater than the current disk usage and committed, the commit may still fail.
In the above scenario, the blueprint commit version does not advance, and the updated maximum disk usage setting is not honored.
After increasing the maximum disk usage to a valid value, make an additional, unrelated change in the blueprint and commit again. This subsequent commit succeeds and correctly applies the updated maximum disk usage setting.
In rare situations where several dozens of BGP peerings to external generic devices have been setup on an NXOS edge leaf switch, the upgrade configuration may fail to apply within the allotted 120 seconds with a timeout. The upgrade configuration is modifying all the external BGP neighbors to always use the next-hop-self command, to properly support RFC-5549.
After the upgrade completes, perform a full configuration apply on the affected device. This ensures that the correct configuration is successfully applied. Note that this workaround is not necessary unless there is a setup that routes IPv4 packets using IPv6 next hops, per RFC-5549.
While configlet is being applied to the SONiC device, if the device agent restarts after being disconnected from the controller, the agent executes any remaining changes and collects the running configuration as golden configuration to monitor for configuration anomalies. Because the process of applying configlet changes is still running independently of the agent, it introduces changes into the running configuration even when the golden configuration is collected by the agent. The following changes from the process cause configuration anomalies in the SONiC device.
After reviewing the running configuration on the SONiC device, if all the changes from the configlet are correctly applied, the customer can safely accept changes to avoid further configuration anomalies.
When attempting to convert leaf switches from ESI to MLAG within the same blueprint, the operation fails because Apstra does not allow mixing ESI and MLAG redundancy models at the rack level. This restriction is enforced starting in Apstra 4.2.0 and is expected behavior. During the operation, users may see the following error in the UI or REST API Explorer:
"Combining MLAG and ESI leaf pairs not supported"
Currently, converting ESI racks to MLAG racks or vice versa requires replacing all racks within a single FE operation using the REST API. However, due to limitation, this conversion can cause BuilderAgent to fail when links are present between external generic system and leaf switches. In this occurs, please revert the changes and follow the steps outlined in workaround section.
To successfully convert the rack type using modify-racks API, the following workaround can be used:
1. Identify the leaf switches connected to the external generic system 2. Identify the Connectivity Templates (CTs) associated with the external generic interfaces and unassign the corresponding application points 3. Delete the links between the leaf switches and the external generic system 4. Undeploy and unassign the leaf devices from the blueprint 5. Unassign interface maps from the blueprint 6. Use the REST API /api/blueprints/{blueprint_id}/modify-racks to convert the racks from ESI to MLAG 7. Import MLAG-compatible interface maps and assign them to the switches 8. Recreate the links to the external generic system 9. Reassign the endpoints to the appropriate Connectivity Templates
For additional guidance, please contact Apstra Technical Support.
Task Error will show: "virtual_network": "IPv4 in VRF \"default\" is not supported with Routing Zone disable_ipv4=\ "True\"" with rail-id's in the payload.
Provisioning of VLANS is currently not possible when the default RZ is configured with disable_ipv4=True (IPv6 only). When changes to Apstra allowed the creation of RZ without IPv4 (IPv6 only), the API endpoint, which creates VLANs, incorrectly assumed IPv4 is always present.
The current Radius client in the Apstra Controller adheres to standard RFC 2865 functionality, inherently not FIPS-compliant because it relies on weak, non-compliant algorithms (MD5/MD4) for password hashing and authentication.
When a configlet action (import/delete) occurs in a blueprint with a large number of configlets, it can fail with a timeout, and the BlueprintDiffProducerAgent process can crash due to a heartbeat timeout. The problem occurs when the blueprint has a configlet with an incorrect Jinja expression via configlet import/delete actions. Failure of rendering configuration with incorrect Jina expressions can cause all configlets to be re-evaluated for all eligible devices, potentially resulting in much longer configlet processing.
The below steps can be applied as a workaround. If further assistance is needed, please contact the Apstra support team.
1. In order to recover from the crash of BlueprintDiffProducerAgent, please increase the heartbeat_period to 1200 secs in agent_management section of aos.conf file (<=6.1.0: /etc/aos/aos.conf, >=6.1.1: /user/root/etc/aos/aos.conf) and restart AOS service (service aos restart).
[agent_management] # Override the default heartbeat timeout for agents spawned dynamically by # AgentManager. The value must be a non-negative number. The unit is seconds. # The value 0 is used to turn off heartbeat-based agent timeouts and restarts. # The minimum non-0 value allowed is 60. If not provided, then the default # timeout value (600 seconds) is used. heartbeat_period = 1200
2. Please check each configlet in the blueprint and delete the configlet with incorrect Jinja expression from the blueprint.
When rack types are exported, modified, and then re-imported into a blueprint, generic systems in the rack may be unexpectedly renamed, resulting in some servers losing their original user-defined labels even though only rack parameters were changed.
Customers should avoid editing the rack type in the Global Catalog UI when they need to preserve generic system names.(1) Export the rack type from the blueprint to the Global Catalog.(2) use the API PUT /api/design/rack-types/{rack_type_id} to update only the link_per_spine_speed (e.g., from 25 to 100) directly in the rack type JSON without changing the generic system group_label or count structure.(3) re-import the updated rack type into the blueprint.
The Platform -> Product Usage page does not take into account the quantity field in each license. It simply counts the number of licenses. Product Usage erroneously displays insufficient license warnings even though a license with multiple quantities is applied correctly since it is seen as a single license. Apstra operation would remain unaffected even if there were product usage warnings.
Starting in Apstra 6.1.0, which introduces EVPN VXLAN over IPv6 underlay (RFE-1364), Apstra automatically applies next-hop self in the RoutesToExt routing policy for all BGP sessions toward external generic routers. This is expected behavior.
RFE-1364
In deployments using IPv6 underlay with RFC 5549, IPv4 routes may carry IPv6 next-hops. External routers using IPv4 BGP sessions cannot use these next-hops. Without next-hop rewriting, affected IPv4 prefixes may not be advertised to external routers, resulting in loss of reachability and potential service impact (for example, DHCPv4 relay failures).
Customers upgrading to 6.1.x who have external generic router peerings configured will observe next-hop self added to their RoutesToExt policy as part of the upgrade. This change ensures consistent route advertisement and requires no manual action.
No workaround is required.
On ACX7100-32C devices, configuring a port with 10GE speed (non-channelized) could result in the port failing to link up, accompanied by "Invalid Port Speed Configuration" and "Optics does not support configured speed" alarms. This occurred because the built-in ACX7100-32C device profile did not automatically generate the required "unused" configuration for the adjacent port within the same port group(for example 0 and 1 are in the same group for 10GE)
Clone the existing built-in ACX7100-32C Device Profile and update Transformation #7 (10GE non-channelized) to include an unused_port_list configuration for the adjacent interface in the same port group. If you need further assistance, please reach out HPE Apstra Support Team.
Steps:1. Clone the ACX7100-32C Device Profile to create a custom copy.2. In the cloned profile, edit port setting for Transformation #7 (10GE non-channelized port) to add unused_interface_list entries for the other port in the same port group (e.g., port 0 and port 1 share a group, port 2 and port 3 share a group, etc.).
Example) Port 0 setting
Old setting:
{"global": {"breakout": false, "fpc": 0, "pic": 0, "port": 0, "speed": ""}, "interface": {"speed": "10g"}, "validations": [{"constraint": "1x25or1x10", "port_group": "P0_P1"}, {"constraint": "no_constraint", "port_group": "P0_P1_P2_P3"}]}
New setting: add "unused_interfaces_list" key with value ["et-0/0/1"] for adjacent port.
{"global": {"breakout": false, "fpc": 0, "pic": 0, "port": 0, "speed": ""}, "interface": {"speed": "10g","unused_interfaces_list": ["et-0/0/1"]}, "validations": [{"constraint": "1x25or1x10", "port_group": "P0_P1"}, {"constraint": "no_constraint", "port_group": "P0_P1_P2_P3"}]}
3. Create new Interface Map with the updated Device Profile.
4. Assign the new cloned device profile into the managed devices and import the new IM into blueprint5. Assign the new IM into the deployed devices
Starting in Apstra 6.1.0, the root partition is read-only, and the NTP service override configuration (override.conf) is stored in a non-standard path (/var/root/usr/local/lib/systemd/system/ntp.service.d/) instead of under /etc/systemd/. Because this path is outside the standard systemd configuration directory, systemd does not automatically reload it during boot. As a result, the NTP service starts without the override configuration applied.
Add the below crontab entry for root user (using sudo crontab -e) to automatically reload the systemd configuration and restart the NTP service on each reboot:@reboot systemctl daemon-reload && systemctl restart ntp
When the offbox agent restarts, it checks the controller's version for compatibility via HTTPS internally. From 6.1.0, the offbox agent uses the controller IP address or the worker VM's IP address as the source IP address. If ACL has a rule to block those IP addresses, the offbox agent would fail in retrieving the controller's version information and then prevent the other agent's process from starting.
if ACL is enabled in the Apstra Controller, please add allowed rules for the controller's IP address and worker VM's IP address.
When the SSH host key of an offbox Junos OS device is rotated, the CHECK job correctly detects the mismatch and fails with an SSH host key verification error. Even if there is a key mismatch, the Show-Tech job status for offbox devices will appear as Success. This is because the controller is able to reach itself and talk to the offbox container, even though it cannot reach the real device. In this case, the Show-Tech job status will appear as Success, but the real device logs and commands won't be in the show-tech tarball. The recommendation is to run a CHECK job on the device first. If it fails due to an SSH host key mismatch, run Update Host Key for the affected device before attempting Show-Tech collection again.
Run the Update Host Key job for the affected devices so that the SSH host keys are refreshed and agent health returns to normal.
Once the host key is updated and the device status returns to normal, re-run the Show-Tech collection.
When the Junos EVPN Next-hop and Interface count maximums parameter in the staged->Fabric settings->Fabric-policy is enabled, Apstra introduced modifying the default hardware settings for VXLAN routing's resource (next-hop and interfaces) for QFX5110, QFX5120, EX4650, and EX4400 devices in the rendered configuration () starting with version 4.2.0. Whenever configuration changes in VXLAN routing's resource, JUNOS triggers PFE automatic restarts to reflect new changes with service impact. The typical scenarios would be when the device becomes deployed, undeployed, or the device is in NOS upgrade. To prevent unnecessary PFE restarts in those scenarios, the configuration for VXLAN routing's resource needs to be included in the pristine configuration.
If the Junos EVPN Next-hop and Interface count maximums parameter in the staged->Fabric settings->Fabric-policy is enabled, add the below configuration into the device's pristine configuration.QFX5120 and EX4650 VXLAN routing's resource
forwarding-options { vxlan-routing { next-hop 45056; interface-num 8192; overlay-ecmp; } }
QFX5110 VXLAN routing's resource
forwarding-options { vxlan-routing { next-hop 32768; interface-num 8192; overlay-ecmp; } }
EX4400 VXLAN routing's resource (add overlay-ecmp if Junos EX-Series Overlay ECMP is also enabled)
forwarding-options { vxlan-routing { next-hop 16384; interface-num 6144; overlay-ecmp; } }
Customers may encounter the following Server-side Validation Error in the Web UI when the pristine configuration contains multiple system stanzas which is not a expected behvavior:
"Cannot parse config: system already parsed."
According to ScotchInventoryAgent logs, POST requests to update the pristine configuration failed with a 422 Unprocessable Entity error, indicating a validation issue:
2025-02-17 23:31:18,730 680:INFO:aos.scotch.libs.scotch_flask:request: POST /api/systems/AN10555621/pristine-config HTTP/1.0 34074 bytes 2025-02-17 23:31:18,737 680:INFO:aos.scotch.libs.scotch_flask:response: 422 55 bytes 0.007347 seconds
Background of the issue:
1. In Apstra 4.2.x, gRPC was introduced to support Telemetry Streaming, and as a result, having two system blocks in the pristine configuration was expected in that release. 2. Starting from Apstra 5.0.0, enhancements were made to automatically merge multiple system stanzas in the pristine configuration during the NOS upgrade process. 3. If a customer chooses to remain on their current NOS version for an extended period, multiple system stanzas can exist in the pristine configuration without causing issues.
If a customer chooses to remain on their current NOS version for an extended period and needs to forcefully update the pristine configuration, they should manually merge the system stanzas within the pristine configuration using the UI and then perform a Force Update.
For further assistance, please contact Juniper Apstra Support.
PTX10002-36QDD configured with EVPN/vxlan on Junos 23.4R2-S5-EVO have ipv6 neighbors fail
Upgrade Junos OS to version 24.4R1-EVO or later, where the issue is resolved.
Note: Junos 24.4R1-EVO and later are not part of the Apstra 6.1 qualified NOS list. Use of these versions should be validated in a lab environment prior to deployment.
The device console may display cosmetic Python traceback error messages indicating an unreachable network when Sonic ZTP is provisioning a device. In the event that the device modifies the VRF of its management interface and is unable to send logging messages to the ZTP server, this may occur.
If the device completes the ZTP process, these messages in the console can safely be ignored.
When doing a full config apply, the SONiC configuration renderer in Apstra 6.2.0 is adding the BREAKOUT_PORTS table to the rendered tables. When running SONiC 4.5.1 with breakout ports configured, the show interface transceiver sonic-cli command may return a transaction error due to the absence of the BREAKOUT_PORTS table. Note: This release note applies only to the case of a full config apply operation (done by a direct config_db.json rendering). It does not apply to interface breakouts that have been configured in a day-2 incremental change (done via restconf).
Perform a full config apply from Apstra if the show interface transceiver command is exhibiting a transaction error in SONiC 4.5.1 with breakout ports configured. For further clarification, please contact the HPE Apstra support team.
When Blueprint->Stage->Catalog->Tags was selected in the Freeform Blueprint, it doesn't show any tags in the UI. The issue is caused by not linking correctly to tagged objects for AGGREATE LINK in the UI APPLIED TO column.
Please uncheck Applied to column in the View Option and refresh page or navigate the other tab and then back to tags tab. Please reach out HPE Apstra Support team for the further assistance.
Interface telemetry uses gRPC periodic mode to collect interface status data from the JUNOS and EVO devices. Apstra (the gRPC client) needs the delivery of all interface status information every round (the default period is 120 + delta seconds). False alerts for interface anomalies results from the devices occasionally sending incomplete information (just for a partial set of interfaces) inside a round, and the interface status for absent interfaces would be represented as missing status.
The current workaround to avoid false alerts for interface anomalies is to disable gRPC temporarily until the fix is incorporated (shown in the below example) or keep gRPC enabled with changing collection mode of interface telemetry into native polling via REST API call. If further assistance is needed, please reach out Juniper Apstra Support team
[ Example to disable gRPC globally ] To disable the gRPC service, change grpc_enabled = 0 in the /user/root/etc/aos/aos.conf file and then restart AOS service in the Apstra Controller (sudo systemctl restart aos).
[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 = 0
Integrated DCI feature(vxlan stitching) was introduced in Apstra 4.2.0. In versions 4.2.x and later, customers using this feature may encounter an issue where all VTEP loopback addresses from the fabric including those from non-border leaf devices are being advertised to external routers over BGP in the default routing zone.
This affects only VXLAN DCI Stitching deployments(Stitching requirement for VTEP loopbacks for only border leaf nodes vs OTT requirement for all VTEP loopbacks in the fabric). Even when customers configure routing policies to export only loopback of border leaf nodes, Apstra backend logic automatically includes all VTEP loopbacks. Due to the current design, Apstra does not differentiate between border and non-border leaf roles in this context, resulting in the unintended advertisement of all fabric loopbacks to external peers.
Engineering has confirmed this as a bug. The expected behavior is to advertise only the loopback addresses of border leaf switches to external routers in the default routing zone. There is no official workaround to modify this behavior through standard configuration. Engineering is actively working on a fix to address this issue in a future release. The only option is to use a custom configlet to override Apstra default export logic. Please reach out to Apstra Technical Support for assistance.
Validation logic for a security zone assumes the description includes valid ASCII characters. If the description includes violating characters, the upgrade from 5.1.0/6.0.0 to 6.1.X would fail with a error related with security zone.
Validation Logic for security zone's description 1. Description should not start or end with space 2. Description should include only printable ASCII characters (ranging from 33 to 126), excluding double quotation (") character, less than (<) character, and backslash (\) character.
Please remove or replace violating ASCII characters from the security zone's description before upgrading
When the virtual infra manager is removed from the Apstra controller, Apstra should have cleared any data related to the virtual infra manager. Because it's not cleared, when the same virtual infra manager is added back to Apstra later, old data is still used together with the new collected data from the virtual infra manager's collector. In some scenarios, when old, uncleaned data has an error condition, it can trigger continuous error even if newly collected data doesn't have an error condition.
If the virtual infrastructure manager requires re-onboarding (removing and then adding back) from Apstra, the user must take the actions listed below.1. Remove virtual infra manager from Apstra Controller (External Systems/Virtual Infra Managers).2. Restart the AOS service.3. Add the virtual infra manager back to to the Apstra
With current cluster design, worker nodes may fail to recover their configuration state after a temporary loss of SSH connectivity to the controller. This condition can be observed in the UI by navigating to Platform > Apstra Cluster > Nodes > Worker, where the following error may be displayed:
Configuration Error: ssh: connect to host 10.28.17.4 port 22: Connection refused
When the controller (ClusterManagerAgent) attempts to push configuration to worker nodes, it retries SSH connections up to three times. If all attempts fail, due to connection refused or no route to host, the node is marked with a FAILED Configuration State. Once this state is set, the system does not automatically retry configuration, even if SSH connectivity is later restored. Although worker nodes may resume sending keepalives and transition back to an active operational state, the configuration state remains in failed state indefinitely. Due to this the overall node state may continue to appear FAILED despite restored connectivity.
Manually trigger a configuration synchronization using one of the following methods:
1. Navigate to Platform > Developers > REST API Explorer 2. Execute REST API: POST /api/cluster/worker/sync [OR] 1. Restart AOS from the controller VM: systemctl restart aos
The NXOS rollback feature on the N9K-C93600CD-GX device has significant limitations when the devices' interfaces are broken out.Ports 1-24 in the model are organized into four-port groups: (1, 2, 3, 4), (5, 6, 7, 8), (9, 10, 11, 12), (13, 14, 15, 16), (17, 18, 19, 20), and (21, 22, 23, 24). When port 1 is broken out as 4x10G or 4x25G, port 3 is automatically broken out in the same mode, and vice versa. When any port in the quadruple is split into 2x50G, all four ports are automatically split in the same mode. Similarly, ports 26-28 are organized in pairs of two, i.e. (25, 26) and (27, 28). Both ports in the pair must operate in the same breakout mode.
In most cases where a breakout (or more than one) exists, rollback fails to generate a working rollback patch. The reason for this is that the breakouts cannot be reversed if the remaining broken-out interfaces in the same port group have not been shutdown first. For example, to negate the breakout of port 1, the broken-out interfaces of port 3 must be shutdown, and vice versa. It appears that the rollback logic shuts down the interfaces associated with the port whose breakout is being reverted (port 1 in the previous example), but fails to shut down other broken-out ports in the same port group (port 3).
The safer way for the N9K-C93600CD-GX to be used with AOS is for the customer to avoid using breakouts altogether on the device.No issue with rollback when ports 29-36 have been broken out has been observed. Breakouts on these ports can be rolled back In the case that the last interface of a port-group is the only one used and broken out, would the nxos rollback feature (and rollback to pristine) be successful. However this is highly discouragedIn any other case the only way to reverting to pristine would be to manually shudtown all broken down interfaces before reverting to pristine (or using the rollback to a pristine config)
The QFX10008 device with dual routing engines currently doesn't support FIPS Level. Even when the additional configuration (IPSEC) is configured after FIPS is enabled, FPC doesn't come up online correctly, which prevents normal operation.
When FIPS is enabled, interface and MAC telemetry services encounter gRPC connection errors for JUNOS and EVO devices running off-box agents. The issue is related to the device's inability to properly initialize the SSL certificate directory during FIPS activation, preventing JSD from locating the required certificates at startup.
Recommend NOS upgrade to the fixed version, JUNOS >= 23.4R2-S7 and EVO >= 23.4R2-S7-EVO.
Split horizon packet drops may be incorrectly reported in the transmit (TX) discard counters on interfaces of SONiC 4.5.1 devices. The elevated TX discard counts are primarily observed on leaf-facing-spine interfaces. Investigation confirmed that these are legitimate split horizon drops --no actual packet loss occurs-- but the counters were erroneously incrementing, which could trigger persistent TX discard anomalies in device traffic probes.
--
No workaround is required, as this is a cosmetic counter issue with no real traffic impact.
2026-06-29: Added AOS-62117
2026-06-18: Added AOS-59726
2026-06-15: Added AOS-58431,AOS-61764
2026-06-08: Added AOS-61624,AOS-61680
2026-05-26: Updated AOS-60637
2026-05-15: Updated AOS-54864
2026-05-14: Added AOS-61108
2026-05-06: Added AOS-57295
2026-05-05: Added AOS-59663
2026-04-21: Added AOS-52788, AOS-60637
2026-04-14: Added AOS-60612
2026-04-13: Initial Publishing