Aviatrix Controller and Gateway Software Release Notes

8.1.0 Release Notes

Release Date: 11 August 2025

Corrected Issues in Aviatrix Release 8.1.0

Issue

Description

AVX-60731

Fixed an issue where BGP gateways could crash when receiving route updates containing AS-SET information in the AS-PATH attribute. The system now rejects AS-SET and AS_CONFED_SET using default configuration, improving BGP stability and aligning with industry standards.

AVX-63175

Fixed an issue where Edge Gateway version numbers in the Controller UI were incorrectly updated after the gateway came back online. The version display now reflects the actual running image.

AVX-63334

Fixed an issue where Edge Gateways on Equinix Network Edge or certain VMware environments failed to resize the root disk during initial setup. Disk resize logic has been corrected.

AVX-63608

Fixed an issue where gateway resize operations could fail with a KeyError: 'src' during validation. This occurred when resizing gateways, including attempts to resize to the same instance size for recovery. The fix improves peer data handling to ensure resize operations complete successfully.

AVX-63616

Fixed an issue where new CIDRs added to an OCI VCN through the OCI console were not reflected in the Controller. Previously, the Controller only read CIDRs during initial spoke-transit attachment, causing failures in gateway creation for new CIDRs. The fix enables the Controller to dynamically query and sync updated VCN CIDRs from OCI.

AVX-63816

Resolved an issue where the Public Internet SmartGroup incorrectly retained the 100.64.0.0/10 range after upgrading to 8.0.0. The range is now removed per updated default definitions.

AVX-63883

Resolved an issue where creating or modifying DCF rules failed in the CoPilot UI or Terraform due to a missing policy list. The system now generates and updates the list correctly.

AVX-64015

Fixed an issue where Jumbo Frame support could not be enabled on existing BGPoLAN connections for AWS HPE gateways. MTU configuration updates are now applied without requiring recreation.

AVX-64196

Resolved an issue where IPSec diagnostics in the Controller UI did not display logs for non-Equinix Edge Gateways. Log retrieval now works for all Edge Gateway types.

AVX-64213

Fixed an issue where certain Edge Gateway images (g3-202504251522, g3-202504251525) incorrectly sized the root disk after ZTP, limiting available storage. Disk sizing has been corrected in these images.

AVX-64483

Resolved an issue where creating a Secondary or HA Transit/Spoke Edge Gateway on a Dell appliance failed due to incorrect hardware detection. Appliance compatibility has been updated.

AVX-64767

Fixed a performance regression and packet drop issue with Site-to-Cloud mapped NAT at scale. Packet forwarding performance has been restored to expected levels.

AVX-64774

Fixed an issue where backup restoration failed on GCP controllers when restoring from earlier versions (such as 7.2.5090) to 8.0.0 and later. The issue was caused by a Google Cloud Storage API error during the upload phase. The fix includes a library update and improved error handling to ensure successful restoration.

AVX-65050

Fixed an issue where DCF policies failed to apply to Azure gateways due to Cloud Asset Inventory (CAI) not resolving Azure subnets correctly. This was caused by missing Azure VNET GUID metadata during upgrades, resulting in Smart Group resolution failures and incorrect policy rule enforcement. The fix improves Azure metadata handling and ensures consistent DCF policy application.

AVX-65213

Fixed an issue where system diagnostics could fail with an AttributeError during Controller operations. The error occurred when collecting CloudXD process data that unexpectedly returned None. The fix adds proper null checks to ensure the diagnostic collection completes successfully.

AVX-65252

Resolved an issue where creating a WebGroup containing both Domain and URL entries caused configuration pushes to fail. Validation now accepts mixed entry types.

AVX-65386

Fixed an issue preventing upgrades to Controller version 8.0.0 when duplicate DCF policy names existed. The upgrade process now detects and resolves name conflicts automatically.

AVX-65565

Fixed an issue where Distributed Cloud Firewall (DCF) eBPF programs were not fully cleaned up from gateway interfaces when DCF features were disabled. The cleanup logic has been improved to ensure all interfaces are properly cleared, preventing residual eBPF programs from remaining after disabling Site-to-Cloud DCF or other DCF features.

AVX-65698

Fixed a memory leak in the DCF Traffic Server (TS_MAIN process) that could cause gateway reboots during high-volume threat IP traffic processing. The issue occurred when multiple DCF rules with ThreatIQ external groups were triggered by continuous probing to inactive threat IPs. Memory usage now stabilizes under sustained load.

AVX-67128

Fixed an issue where user-uploaded SSL certificates were not automatically restored during Controller migration to version 8.0.0. This caused FQDN-based secure access to the Controller UI to fail post-migration. The fix ensures that existing certificates are now retained and restored during the migration process.

Known Issues in Aviatrix Release 8.1.0

Issue

Description

AVX-58696

TCP MSS clamping is not supported on Standalone Gateways in Release 7.1 and later.

AVX-59298

In Aviatrix Controller 8.0 versions, when deploying Edge Spoke or Edge Transit Gateways in Megaport Virtual Edge (MVE), less than 5 VNICs can result in the gateway failing to initialize. This issue occurs because the cloud-init expects 5 interfaces.

Workaround:

To ensure the successful deployment of Edge Spoke or Edge Transit Gateways in MVE, configure the MVE with 5 VNICs.

AVX-59376

When using Controller High Availability (HA) with Controllers version 8.0 and later, the standby Controller will fail to launch correctly. This is because the HA mechanism relies on a fixed software version specified in the Auto Scaling Group (ASG) launch template, but with Controllers version 8.0 and later now require the version to be passed dynamically through cloud-init during instance creation.

This issue occurs only in environments that use:

  • Controller HA for with Controllers version 8.0 and later

  • AWS Auto Scaling Group (ASG) launch templates

  • The default CloudFormation HA deployment method

Workaround: Use the new CloudFormation template to enable AWS Controller High Availability. This template supports dynamic version injection and restores compatibility with Controllers version 8.0 and later in supported regions. For versions 7.x and earlier, use the existing CloudFormation script (without the v3 suffix).

Note: This solution is not available in AWS regions that do not support Lambda Function URLs.

AVX-61355

Azure Standard_B1ms SNAT-enabled Egress Spoke Gateways may experience significant throughput drops under high connection loads. This limitation is caused by the Azure Standard_B1ms instance type, which has limited compute and network resources.

Affected Scenario:

  • SNAT-enabled Egress Spoke Gateways using Azure Standard_B1ms under high connection loads.

Workaround:

Upsize the Spoke Gateway to a larger Azure instance type for workloads that require more than 10K concurrent connections or consistent network throughput.

AVX-62011

Auto migration will not work from 7.2 to 8.0 when proxy is enabled. You must use a manual backup and restore process to perform the upgrade. Follow the steps below to back up and restore during the upgrade:

  1. If your Controller software version is 7.2.5012 or older, upgrade both the Controller and Gateways to the latest 7.2 build.

  2. Delete the proxy configuration from Controller UI > Settings > Advanced > Proxy.

  3. Back up the Controller from Controller UI > Settings > Maintenance > Backup & Restore > Backup.

  4. Shut down the old Controller.

  5. Launch the new 8.0 Controller and transfer the EIP.

  6. Once the 8.0 Controller is up, restore the Controller using the backup config from Controller UI > Settings > Maintenance > Backup & Restore > Restore.

  7. Add back the proxy configuration from Controller UI > Settings > Advanced > Proxy.

  8. Software upgrade the Gateways from version 7.2 to 8.0.

AVX-62022

When more than sixteen External Connections are configured on a single gateway with Distributed Cloud Firewall (DCF) enabled for route-based Site-to-Cloud (S2C), the Controller may experience high CPU utilization during policy processing and configuration updates. This can affect overall system responsiveness and increase the risk of configuration delays or failures.

Workaround:

  • Do not attach more than 16 S2C connections to a gateway where DCF is enabled.

Impact:

  • Excessive CPU usage on the Controller during DCF rule enforcement

  • Slower configuration push times or timeouts for gateways with many External Connections

  • Potential sync delays for large deployments using DCF on route-based S2C

AVX-62147

The Controller auto-migration and Gateway upgrade features do not function properly when the Aviatrix Controller has proxy settings enabled. In such environments, migration may fail, and you must follow a manual backup and restore process instead of using the standard auto-migration workflow. This limitation is due to current backend behavior that does not support migration through proxy-enabled setups.

Affected Scenario:

  • Controller and Gateway upgrades using auto-migration in environments where proxy settings are enabled on the Aviatrix Controller

Check Whether You Are Affected:

  • In Controller UI: Go to Settings > Advanced > Proxy

  • In CoPilot UI: Go to Settings > Configuration > Private Mode > Proxy Servers

If proxy configurations are present in either location, your deployment is affected.

Workaround:

Follow the manual backup and restore steps below to upgrade the Aviatrix Controller and Gateways:

  1. If the Controller is running version 7.2.5012 or earlier, upgrade to the latest 7.2 build first.

  2. Delete the proxy configuration in the Controller UI.

  3. Back up the Controller from Settings > Maintenance > Backup & Restore > Backup in the CoPilot UI.

  4. Shut down the old Controller.

  5. Launch a new Controller with version 8.0 and reassign the EIP.

  6. Restore the backup in the new Controller.

  7. Reconfigure the proxy settings.

  8. Upgrade the Gateways from version 7.2 to 8.0.

    A maintenance window is recommended for this manual upgrade, as it involves Controller downtime and multiple steps.

AVX-62230

When upgrading Aviatrix Gateways from version 7.2.x to 8.0.0 with TLS decryption enabled in Distributed Cloud Firewall (DCF), the Gateway automatically regenerates its TLS decryption certificate authority (CA). Because each Gateway maintains its own unique CA for security, the regenerated CA no longer matches the CA previously trusted by clients.

As a result, you may experience the following issues after the upgrade:

  • Failed TLS connections for decrypted traffic

  • Certificate trust errors in browsers or applications

  • Traffic disruption for services that rely on TLS inspection

Affected Scenario:

  • Gateways with TLS decryption enabled in DCF being upgraded from 7.2.x to 8.0.0

Workaround: If you have imported your own proxy CA and key, you can re-import the same certificate and key after the Gateway upgrade to maintain trust continuity.

If you rely on the Aviatrix-generated CA:

After the Gateway upgrade, export the newly generated CA certificate and add it to the trust bundles on client systems to restore trust and resume decrypted connections.

AVX-62299

When upgrading from Controller version 7.1 to 7.2 or 8.0, Spoke Gateways with routing through a Public Subnet Filtering (PSF) Gateway may fail to upgrade and become unreachable if the PSF Gateway has not been upgraded first. This issue affects AWS environments where Spoke Gateway route tables are configured to point to a PSF Gateway.

To avoid this issue, follow the correct upgrade sequence:

  1. Upgrade the PSF Gateway first.

  2. Wait for the PSF Gateway upgrade to complete successfully.

  3. Then upgrade the dependent Spoke Gateways.

AVX-62506

During a gateway software upgrade, traffic matching DCF WebGroup rules may be briefly dropped during the upgrade. This impacts both Layer 7 (HTTP/HTTPS) and Layer 4 traffic and occurs across all supported cloud providers (AWS, Azure, and GCP). The disruption typically lasts a few seconds but may vary depending on gateway load and policy complexity.

Workaround:

None

Recommendations:

  • Schedule gateway upgrades during maintenance windows or low-traffic periods.

  • Use HA deployments and upgrade gateways one at a time in HA pairs.

  • Monitor logs for “Failed to load policy” messages to confirm when policies are reloaded.

AVX-62542

In environments where Distributed Cloud Firewall (DCF) and customized SNAT are used together, DCF rules may fail to match traffic correctly when the same SmartGroups are specified in both the source and destination fields. This is because the system does not account for the translated source address during rule evaluation.

As a result, traffic may be unintentionally blocked by the DefaultDenyAll rule, and policies may not apply as expected—particularly in cross-cloud or cross-region scenarios.

Affected Configurations:

  • Customized SNAT (not Single IP SNAT) configured on gateways

  • DCF rules with overlapping SmartGroups in source and destination

  • Environments involving SNAT-translated traffic

Workaround:

In earlier versions, avoid using 0.0.0.0/0 as the destination in SNAT rules. Instead, specify only the required destination CIDRs.

AVX-62636

Distributed Cloud Firewall (DCF) is not officially supported on Edge gateways. Although DCF rules may appear to be deployed to Edge gateways, they are not fully validated and may not function correctly, especially in environments using NAT for overlapping IP address spaces.

DCF rules pushed to Edge gateways may not account for NAT translations, leading to incorrect rule behavior and potential traffic filtering issues.

Affected Deployments:

  • Edge gateways with DCF rules applied

  • Environments using NAT to manage overlapping IP address spaces

  • Traffic flows between cloud resources and Edge sites with DCF enforcement

Workaround:

  • Avoid applying DCF rules to Edge gateways in environments with NAT or overlapping IP ranges.

  • Explicitly exclude Edge from DCF deployment by using the following Provider Deployment API:

POST /v2.5/api/microseg/deploy-policy
{
  "providers": ["AWS", "AZURE", "GCP"]  // Include all desired cloud providers EXCEPT "EDGE"
}

AVX-62712

When recreating a policy-based Site-to-Cloud (S2C) VPN connection after deleting a previous one with the same remote CIDR, the system may incorrectly report a CIDR overlap error, even though the original connection has been removed. This occurs because the system does not fully clean up the remote CIDR information, causing it to believe the CIDR is still in use.

Affected Scenario:

  • Recreating a policy-based Site-to-Cloud VPN connection using the same remote CIDR after deletion, in either of the following cases:

    • The deleted connection was a route-based S2C connection on a gateway that still has other S2C connections.

    • The deleted connection was a policy-based S2C connection.

Workaround:

Contact Aviatrix Support to manually clear the cached CIDR information.

AVX-62719

The Distributed Cloud Firewall (DCF) policy writer writes approximately 40KB of data per gateway during each configuration snapshot, regardless of whether there are policy changes. In large deployments, this results in frequent and unnecessary write operations to the controller database.

Affected Scenario: - DCF enabled across many gateways - Frequent configuration snapshots (triggered automatically or during updates)

Impact: Increased system load and database write activity, which may affect controller performance and stability in large-scale environments.

Workaround:

There is no direct workaround at this time. Users operating at scale should monitor controller resource usage closely. Aviatrix is actively working to reduce unnecessary write operations in a future update. If performance issues are observed, contact Aviatrix Support for evaluation and potential tuning options.

AVX-63224

In Controller release 8.0, gateway software upgrades take longer to complete compared to earlier versions. On average, the upgrade rate drops from approximately 14 gateways per minute in version 7.2 to approximately 11 gateways per minute in 8.0, which is an increase of about 20% in execution time.

Affected Scenarios:

  • Upgrading from version 7.2.x to 8.0.x

  • Upgrading between 8.0.x versions

Impact:

Only the upgrade duration is affected. Gateway functionality remains unaffected after a successful upgrade.

Recommendations:

  • Allocate approximately 20% more time for gateway upgrades.

  • For large environments (for example, 1,000+ gateways), plan for 90–120 minutes of upgrade time.

  • Schedule upgrades during maintenance windows to accommodate the longer duration.

AVX-63846

In the CoPilot UI, Groups > SmartGroups and Groups > ExternalGroups with multiple filters may not appear as originally configured after being saved. This issue occurs when creating groups with multiple sets of any resource type. While policy enforcement is correct, the UI may display missing or merged filter sets, leading to ambiguity and confusion during review or editing.

Affected Scenario:

  • Creating or editing SmartGroups or ExternalGroups with multiple filters applied

Workaround:

There is no workaround at this time. If possible, avoid using multiple filter sets in a single group until the issue is resolved.

AVX-64136

In OCI environments, new CIDRs added to a VCN via the OCI console may not be reflected in the Controller after the initial spoke-transit attachment. As a result, users cannot create gateways in the newly added CIDRs, and the CIDR will not appear in the subnet selection dropdown.

Workaround:

  • Add both the original and newly added CIDRs to the Customized Spoke Advertised VPC CIDRs field in the Controller.

Impact:

  • Controller fails to recognize new OCI CIDRs

  • Gateway creation fails in new CIDR ranges

  • Manual intervention required to refresh CIDR information

AVX-64339

AWS t3.small and t3.medium instances used for Egress Spoke Gateways have limited connection tracking capacity, which can affect performance in high-connection environments.

Workaround:

  • Use larger instance types such as c5.xlarge or c6in.large for applications requiring high concurrent connections

  • Avoid or remove IDS-enabled DCF rules if high connection capacity is needed

  • Monitor conntrack usage using platform tools or gateway diagnostics

Impact:

  • t3.medium supports around 25,000 concurrent connections

  • IDS-enabled DCF rules can reduce this to about 2,000

  • When limits are exceeded, traffic may drop and SSH access to the gateway may fail

Resolution:

This is a documented platform limitation. No product fix is required. Refer to Aviatrix Best Practices for gateway sizing guidance.

AVX-64794

When Distributed Cloud Firewall (DCF) is enabled, policy-based Site-to-Cloud (S2C) traffic may be misclassified due to how the traffic flows through the gateway. This can lead to unintended blocking or incorrect policy enforcement.

Workaround:

  • Consider using route-based S2C VPNs, where plaintext traffic traverses a dedicated tunnel interface and is classified correctly by DCF

  • Temporarily disable DCF on gateways handling policy-based S2C connections if misclassification impacts production traffic

Impact:

  • Policy-based S2C traffic may be incorrectly evaluated against VPC or internet DCF rules

  • Unexpected traffic drops or policy mismatches

  • Inconsistent DCF behavior between policy-based and route-based S2C configurations

AVX-64868

In some scenarios involving rapid VRRP state transitions, the keepalived VRRP state may not be reported accurately to the Controller. This can result in temporary discrepancies between the actual VRRP status and what is displayed in the Controller UI, leading to confusion and difficulties during troubleshooting.

Workaround:

  • Use diagnostic logs to verify actual VRRP state

Impact:

  • Controller UI may show incorrect VRRP status such as both peers reporting Primary or Initializing

  • No impact on actual VRRP traffic handling or failover behavior.

AVX-66190

When using Threat Intelligence (ThreatIQ) external groups in Distributed Cloud Firewall (DCF), gateways may log field threat_severity not found errors if unsupported selectors (such as threat_severity) are used.

These configurations are currently accepted by the Controller without validation, but the unsupported selectors are ignored during policy enforcement, and repeated error messages are logged.

Workaround:

  • Remove unsupported selectors (e.g., threat_severity) from threat group configurations

  • Use only supported fields when defining ThreatIQ external groups

  • Monitor DCF gateway logs for error messages to identify invalid selectors

Impact:

  • DCF policies continue to function as expected, but administrators may be unaware that some threat selectors are not being applied.

  • The repeated log entries may also affect log analysis and monitoring.**

Resolution:

Future enhancements will add validation during configuration and UI notifications when unsupported selectors are used.

AVX-66324

When using Distributed Cloud Firewall (DCF) Layer 7 rules with Smart Groups that contain tagged resources, no bell notifications appear when configuration issues potentially block traffic. This affects deployments where Smart Groups match resources by tags (such as AWS instance tags) rather than static IPs or CIDRs. Although traffic is enforced correctly, administrators may not be alerted to the problematic configuration.

Affected Scenario:

  • DCF Layer 7 rules configured between Smart Groups based on resource tags (for example, Kubernetes pods and VMs)

  • Both VPCs use RFC1918 IP addresses

  • Gateways are deployed in High Availability (HA) mode

Workaround:

  • Monitor traffic flow manually

  • Use Smart Groups with static IPs or CIDRs if alerting is critical

Impact: Only affects notifications. Traffic enforcement continues to function as expected.

AVX-66630

Uploading SSL certificates from some providers (such as GoDaddy) could fail if the PEM file included a Unicode Byte Order Mark (BOM). The certificate might appear to upload successfully but would not take effect, and could cause the Controller’s application server to crash with a missing private key error.

Workaround:

  • Open the certificate file in a text editor that supports encoding and remove the BOM before uploading

  • Use certificates saved in standard UTF-8 format without BOM

Impact:

  • SSL certificate installation may silently fail

  • In some cases, the Controller application server could crash

  • Affects wildcard and other SSL certificates from providers like GoDaddy

AVX-66631

Transit gateways with large-scale tunnel deployments (1300+ tunnels) may experience extended traffic loss during image upgrades. Although the image upgrade completes successfully, traffic may remain down for several minutes afterward due to delayed tunnel reconfiguration.

Workaround:

  • Schedule maintenance windows to account for potential traffic loss beyond upgrade completion.

  • Consider staggering upgrades across transit gateways to reduce impact.

  • Monitor tunnel and route service status post-upgrade through the CoPilot UI.

Impact:

  • Traffic loss may persist after image upgrade completes

  • Route service startup is blocked until all tunnels are sequentially reconfigured

  • Configuration push may time out with Context cancelled during Phase 1 Create error

AVX-66654

In environments where a custom certificate domain is configured, users can no longer modify the domain if one or more gateways are already deployed. This safeguard was introduced to prevent misconfiguration scenarios where VPN containers may fail to start due to incorrect registry references caused by domain mismatches.

Impact:

  • Users are blocked from changing the custom domain when gateways exist

  • Prevents VPN container startup failures and DNS resolution issues

  • Ensures consistency between gateway configuration and domain registry

Workaround:

  • If a custom domain change is required, delete all existing gateways first.

  • After updating the domain, redeploy gateways to ensure correct configuration.

AVX-66737

During large-scale gateway software upgrades (typically 50+ gateways), the Controller UI may display incorrect or unclear upgrade status messages. This includes repeated messages, incomplete reporting, and misleading "undefined" entries. Despite the UI errors, the actual upgrade process continues in the background.

Workaround:

  • Use the gateway logs or CoPilot to verify actual upgrade completion status.

  • Avoid relying solely on the UI message list for large batch upgrades.

Impact:

  • "undefined" messages may appear during upgrade.

  • Some gateways may not show a successful completion message in the UI.

  • Upgrade progress may appear stalled or partially reported.

  • Browser console may show HTTP 502 errors.

AVX-66781

OpenVPN Okta authentication does not support the new Okta Integrator Free Plan URL format (https://integrator-xxxxxx.okta.com), which replaced the Developer Edition on July 18, 2025.

When using this new format, the Controller shows a "Not a valid Okta URL" error because it only accepts the older dev-xxxxxx.okta.com format.

Affected Scenarios:

  • New OpenVPN setups using the Integrator Free Plan

  • Existing setups may be affected as Okta retires the Developer Edition

Workaround:

Use an Okta paid plan with supported URL format.

Existing setups using the old Developer Edition will keep working until Okta deactivates them.

Resolution:

A fix to support the new format is planned for release 8.2.0 or later.

AVX-66808

In Edge deployments with multiple WAN interfaces, the StrongSwan service was incorrectly bound only to the first WAN interface after upgrade to 8.1.0. This prevented IPSec tunnels from establishing over other WAN interfaces, affecting all Edge-as-a-Transit (EaT) peering types and Edge-as-Spoke with multiple WAN interfaces.

Workaround:

  • Manually restart the StrongSwan service on the Edge gateway or reboot the Edge gateway to restore full multi-WAN functionality.

Impact:

  • IPSec tunnels remain stuck in CONNECTING state

  • EaT gateways fail to initiate IPsec sessions on non-first WAN interface

  • Phase 1 negotiation fails repeatedly, with IKE_SA_INIT retransmissions

  • Affects all Edge IPSec-based peering scenarios

AVX-66893

When using the Refresh VPC/VNet Route Tables feature in CoPilot with HA gateways configured with custom SNAT and DNAT rules, new route tables may not receive SNAT and DNAT routes for the HA gateway. Only the primary gateway SNAT and DNAT IP routes are added. This may lead to asymmetric routing or traffic loss if the primary gateway fails.

Impact:

  • New route tables do not include SNAT and DNAT routes for the HA gateway

  • Potential traffic disruption during HA failover

  • Existing route tables remain unaffected

Affected Configuration:

  • HA spoke gateways with custom SNAT or DNAT rules

  • Non-RFC1918 SNAT or DNAT IP addresses, such as 5.1.1.1 and 5.1.1.2

  • Use of Refresh VPC/VNet Route Tables in CoPilot

Workaround:'

  • After using the refresh feature, manually verify and add the missing SNAT and DNAT routes for the HA gateway to all new route tables.

AVX-67126

Dry-run validation may fail when upgrading the Controller from version 8.0.10 to 8.1.0 due to a gateway version mismatch error. This occurs when the upgrade path starts from 8.0.0, progresses to 8.0.10 successfully, but encounters a dry-run failure when proceeding to 8.1.0.

AVX-67474

In CoPilot version 4.23 or earlier, using the Administration > Upgrade > Upgrade Plan feature to perform a Gateway image upgrade does not correctly apply the new image. The upgrade process may silently fail across various upgrade paths, leaving the Gateway on the original version.

Impact:

  • Gateway remains on the original version after the upgrade attempt

  • Image upgrades from various upgrade paths are affected

  • Affects image upgrades across all Controller versions when using the Upgrade Plan feature

Workaround:

  • Perform the Gateway image upgrade using the Controller UI, or use the Cloud Fabric > Gateways > Management page in CoPilot instead of the Upgrade Plan page.

AVX-67493

When BGP communities are configured on gateways, restarting the Controller (such as restarting the cloudxd service or upgrading Controller software) may cause brief traffic disruption and elevated CPU utilization. This is due to a delay in BGP route propagation during the restart process, which can affect Site-to-Cloud (S2C) connectivity.

Impact:

  • Temporary traffic loss during Controller restart

  • Delayed BGP route propagation affecting S2C traffic

  • May cause elevated CPU utilization on the Controller after restart

Workaround:

  • If possible, temporarily disable BGP communities before performing Controller restarts.

  • Schedule restarts during a maintenance window.

  • Monitor BGP routes post-restart to verify successful propagation.

AVX-67527

When deleting a cloud account from the Controller, email notifications are not sent to configured recipients. The notification bell shows sent to as blank, and no actual email is delivered. This is a regression from version 8.0.0 where email alerts for account deletion worked correctly.

Impact:

  • Email notifications are not sent for cloud account deletions

  • Operational visibility is reduced for teams relying on email alerts

  • Audit trails may be incomplete

Workaround: No current workaround. Teams should manually monitor cloud account deletions and notify stakeholders as needed.