This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware SASE 5.2.0 | 09 July 2024

  • VMware SASE™ Orchestrator Version R5204-20230831-GA

  • VMware SD-WAN™ Gateway Version R5202-20230725-GA

  • VMware SD-WAN™ Edge Version R5202-20240216-GA-137279

Check for additions and updates to these release notes.

What Is in The Release Notes

The release notes cover the following topics:

This release is recommended for all customers who require the features and functionality first made available in Release 5.2.0.

Compatibility

Release 5.2.0 Orchestrators, Gateways, and Hub Edges support all previous VMware SD-WAN Edge versions greater than or equal to Release 4.2.0.

The following SD-WAN interoperability combinations were explicitly tested:

Orchestrator

Gateway

Edge

Hub

Branch/Spoke

5.2.0

4.2.1

4.2.2

4.2.2

5.2.0

5.2.0

4.2.2

4.2.2

5.2.0

5.2.0

5.2.0

4.2.2

5.2.0

5.2.0

4.2.2

5.2.0

5.2.0

4.3.1

4.3.1

4.3.1

5.2.0

5.2.0

4.3.1

4.3.1

5.2.0

5.2.0

5.2.0

4.3.1

5.2.0

5.2.0

4.3.1

5.2.0

5.2.0

4.3.2

4.3.2

4.3.2

5.2.0

5.2.0

4.3.2

4.3.2

5.2.0

5.2.0

5.2.0

4.3.2

5.2.0

5.2.0

4.3.2

5.2.0

5.2.0

4.5.1

4.5.1

4.5.1

5.2.0

5.2.0

4.5.1

4.5.1

5.2.0

5.2.0

5.2.0

4.5.1

5.2.0

5.2.0

4.5.1

5.2.0

5.2.0

5.0.1.2

5.0.1.2

5.0.1.2

5.2.0

5.2.0

5.0.1.2

5.0.1.2

5.2.0

5.2.0

5.2.0

5.0.1.2

5.2.0

5.2.0

5.0.1.2

5.2.0

5.2.0

5.1.0

5.1.0

5.1.0

5.2.0

5.2.0

5.1.0

5.1.0

5.2.0

5.2.0

5.2.0

5.1.0

5.2.0

5.2.0

5.1.0

5.2.0

5.2.0

5.2.0

5.2.0

5.2.0
Note:

The above table is fully valid for customers using SD-WAN services only. Customers requiring access to VMware Cloud Web Security or VMware Secure Access need their Edges upgraded to Release 4.5.0 or later.

Important:

VMware SD-WAN Release 4.0.x has reached End of Support; Releases 4.2.x, 4.3.x, and 4.5.x have reached End of Support for Gateways and Orchestrators.

  • Release 4.0.x reached End of General Support (EOGS) on September 30, 2022, and End of Technical Guidance (EOTG) December 31, 2022. 

  • Release 4.2.x Orchestrators and Gateways reached End of General Support (EOGS) on December 30, 2022, and End of Technical Guidance on (EOTG) March 30, 2023.   

  • Release 4.2.x Edges reached End of General Support (EOGS) on June 30, 2023, and will reach End of Technical Guidance (EOTG) September 30, 2025.

  • Release 4.3.x Orchestrators and Gateways reached End of General Support (EOGS) on June 30, 2023, and End of Technical Guidance (EOTG) September 30, 2023.

  • Release 4.3.x Edges reached End of General Support (EOGS) on June 30, 2023, and will reach End of Technical Guidance (EOTG) September 30, 2025.

  • Release 4.5.x Orchestrators and Gateways reached End of General Support (EOGS) on September 30, 2023, and End of Technical Guidance on (EOTG) December 31, 2023.

  • For more information please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 4.x (88319).

Upgrade Paths for Orchestrator, Gateway, and Edge

The following lists the paths for customers wishing to upgrade their Orchestrator, Gateway, or Edge from an older release to Release 5.2.0.

Orchestrator

Orchestrators using Release 4.2.0 or later can be upgraded to Release 5.2.0. 

Gateway

Upgrading a Gateway using Release 4.2.0 or later to Release 5.2.0 is fully supported for all Gateway types.

Important:

When deploying a new Gateway using 5.2.0 the VMware ESXi instance must be at least version 6.7, Update 3 up to version 7.0. Using an earlier ESXi instance will result in the Gateway's Dataplane Service failing when trying to run Release 5.2.0 or later.

Important:

Prior to upgrading a Gateway to 5.2.0, the ESXi instance must be upgraded to at least version 6.7, Update 3 up to version 7.0. Using an earlier ESXi instance will result in the Gateway's Dataplane Service failing when trying to run Release 5.2.0 or later.

Edge

An Edge can be upgraded directly to Release 5.2.0 from any Release 4.x or later.

New SD-WAN Features

Customizable Quality of Experience (QoE) for Latency

Previously, latency values for high latency links (for example, satellite links or LTE links) were static. As a result, the QoE page displayed a red graph for both latency and overall quality, which meant that the SD-WAN service would exclude that link from the link selection process even though partners and customers wanted the high latency link considered.

In Release 5.2.0, users have the capability to modify the threshold values for latency for video, voice, and transactional traffic types through the Customizable QoE feature. This means that customers can include high latency links as part of the selection process and the Orchestrator applies the new values to the QoE monitoring page.

Enterprise Control for Link Down Visibility on the Monitor > Network Overview Page

Previously a customer had no control over how long the Orchestrator displayed a down WAN link on the Monitor > Network Overview page. If a WAN link was continuously down for 24 hours or more, the Orchestrator stopped displaying this WAN link and visibility was lost for as long as the link remained down. With Release 5.2.0, a customer has the option of configuring a customized time setting of up to 365 continuous days before the Orchestrator stops showing a down WAN link. A customer configures this setting with Service Settings > Edge Management > Edge Link Down Limit.

GRE/BGP Support on the LAN Interface

Edges in a Transit Virtual Private Cloud (VPC) can use Generic Routing Encapsulation (GRE)/BGP and Connect attachment to connect to an AWS Transit Gateway (TGW). The Connect attachment and Connect peer are both set up over a VPC Attachment to a TGW. GRE uses a private IP assigned on a Routed LAN (non-WAN) interface with two BGP neighbor's setup over the GRE tunnel.

Route Summarization

Route summarization (also called route aggregation or supernetting) addresses the scale limitations of SD-WAN devices by minimizing the number of routes that a router advertises to a neighbor through consolidating the selected route prefixes into a single route advertisement.

When using BGP, the customer configures this feature under Advanced Settings. When using OSPF, the customer configures route summarization on the main configuration page.

Note:

The Orchestrator, Gateways, and Edges all need to be upgraded to Release 5.2.0 or later to use the Route Summarization feature.

Self-Healing Routing

In large datacenter-based deployments involving Hubs and Clusters, there is the potential for traffic outages due to missing routes. Prior to Release 5.2.0, VMware Engineering or Support would have restore these missing routes through an action that was itself disruptive. VMware SD-WAN introduces the Self-Healing Routing feature to reduce the risk of missing route issues in datacenter deployments due to synchronization issues.

Self-Healing Routing is implemented as an audit mechanism where the Gateway compares the route counts on Spoke Edges with the Hub/Cluster Datacenter Edges and automatically triggers a resynchronization of routes when the difference between the Spokes and the Datacenter sites exceeds a default threshold. This features is implemented for all 5.2.0 deployments (Orchestrator, Gateway, and Edge using 5.2.0) automatically and no configuration is required.

SIM Automatic Switchover

While the Edge 610-LTE supports Dual SIM Single Standby (DSSS), the customer needed to manually switch from the active SIM to the standby SIM through the Orchestrator. In version 5.2.0, the customer has the option to use Automatic Switchover for an Edge 610-LTE.

When a customer configures Automatic Switchover, the Edge 610-LTE automatically detects if the primary LTE connection has failed and initiates a connection with the standby SIM. The feature includes a configurable switchover timer so a customer can specify how long the Edge should wait before failing over to the standby SIM. The Monitor > Edges > Overview > Links Status page adds a new Auto Dual-Mode SIM column which includes SIM Switchover details.

Note:

Automatic Switchover is available for Edge 610-LTE models only. This feature is not available for Edge 510-LTE models.

Trusted Platform Module (TPM)

The Trusted Platform Module (TPM) is a hardware-based security feature. It provides a secure storage area for sensitive information like encryption keys, passwords, and certificates with a physical layer of protection through a one-direction "hardware vault".

VMware includes the TPM on all variations (LTE, -N, and so forth) of SD-WAN hardware Edges (510, 520, 540, 610, 620, 640, 680, 3000, 3100, 3400, and 3800). A customer activates the feature through the Orchestrator UI by going to Configure > Edge > Overview and checking the box for Encrypt Device Secrets.

Note:

Virtual Edges do not currently have TPM support.

Wi-Fi Access Control Using MAC Filtering

A customer can use Wi-Fi Access Control as an additional layer of security for wireless networks. When activated, SD-WAN permits only known and approved MAC addresses to associate with the base station.

New SD-WAN Enhancements

Automatic Rate-Limiting on the Gateway

This enhancement improves Gateway stability and prevents a major cause of packet drops by automatically rate-limiting an Edge that is sending an exceptionally large amount of traffic through the Gateway. As part of this enhancement there are two new auto-rate limit Operator events, which are generated and reported to the VMware SASE Orchestrator. For more information on these new events, consult the Operator-Level Orchestrator Alerts and Events section of the VMware SD-WAN Operator Guide.

BGP Gateway Neighbor State

Previously, the Orchestrator did not mark the state of BGP neighborship accurately if the Edge went offline due to a power loss as it continued to use the older state. In Release 5.2.0 the Orchestrator correctly marks the BGP neighborship state as "UNAVAILABLE" in this scenario.

Enhanced Firewall Service

The new Enhanced Firewall Service is an advanced firewall function integrated with the SD-WAN Edge. VMware designed it to protect an organization’s branch networks against modern and sophisticated cyber threats, providing higher security. A customer can obtain Enhanced Firewall Service through an add-on license to VMware SD-WAN and is supported on all SD-WAN Edge models (hardware and virtual).

The initial release of Enhanced Firewall Service in Release 5.2.0 features:

  • Intrusion Detection System/Intrusion Prevention System (IDS/IPS) powered by VMware’s award-winning VMware NSX Security components and includes support for encrypted and unencrypted traffic. By combining the power of NSX Security with the VMware SD-WAN Edge platforms, customers can confidently eliminate legacy firewalls at the branch without sacrificing security and benefiting from simplified network and security operations, all while taking advantage of VMware’s investment in threat intelligence.

  • VMware Hosted Edge Firewall Logging provides a hosted log storage to collect firewall and threat logs (allow and deny rules) from Edges. In its initial release in 5.2.0, by default the Orchestrator keeps either 15 GB of logs or seven days of logs (whichever comes first) per customer tenant, after which the logs will be overwritten. This service is included with a valid VMware SD-WAN license. A future release will add the option to purchase extended log retention.

External Certificate Authority

In phase three of the External Certificate Authority implementation, Release 5.2.0 Orchestrator UI includes support for the configuration of an Intermediate CA.

Firewall Logs on the Orchestrator

Previously the only way a customer could store and view firewall logs was by forwarding them to a Syslog server. With Release 5.2.0 the customer has the option to store firewall logs on the Orchestrator where they can be be viewed, sorted, and searched on the Orchestrator UI.. For more information, see either Configure Profile Firewall, Configure Edge Firewall, and Monitor Firewall Logs.

High Availability Enhancements

Release 5.2.0 includes multiple improvements for a site deployed using a High Availability topology with a pair of Edges. These include:

  • Improved HA Stability to ensure an HA site experiences fewer unnecessary failovers or active-active "split brain" states.

  • Events

    • New Events generated for WAN, LAN, and HA Link state changes.

    • Event usefulness is enhanced with additional metadata like Serial Number and HA mode.

  • Monitoring

    • The HA Standby tab is a new dashboard for the Standby Edge to report CPU and Memory Utilization located on the Monitor > Edges page.

    • For all Monitor > Edges dashboards, there are now "Failover bars". These are vertical markers on graphs indicating where and when an HA failover occurred.

    • All Monitor > Edges graphs include a box with the HA Edge serial number so a customer knows at a glance which HA Edge was active for a particular period on a Monitoring graph.

  • New Configuration Options for High Availability

    • HA Failover Detection Time Multiplier is used to set a longer High Availability threshold. The timer represents how long a Standby Edge will wait for a heartbeat packet from the Active Edge before becoming active and can in some scenarios prevent an Active-Active "Split Brain" state from on an HA Edge under high traffic load.

    • Configurable HA Interface allows the customer to configure any Edge switched port for use as the HA Interface (the interface that connects the Active and Standby Edges for synchronization). Previously, SD-WAN limited the HA Interface to a default interface for that Edge model (in other words, LAN1 or GE1).

    • An added enhancement to the Configurable HA Interface is that the customer has the option to choose a 1G/10G SFP port as the HA Interface.

  • Packet Capture for the Standby Edge's HA Interface: an administrator now has additional HA troubleshooting tool with the option to request a packet capture of the Standby Edge's HA Interface.

High Availability Upgrade Support for Platform Firmware or Factory Image

Previously, upgrading the platform firmware or factory image for an HA site was a time consuming and disruptive task that had to be performed manually by a user. When an Operator Profile is applied to an HA site with a new Platform Firmware or Factory Image, a Release 5.2.0 Orchestrator can automatically update both the Factory image and the Platform Firmware on High Availability for SD-WAN Edges as it would previously for the HA Edge software.

IPv6 Enhancements

Release 5.2.0 includes the following IPv6 enhancements:

  • OSPFv3

    • Underlay IPv6 route learning.

    • Redistribution of OSPFv3 routes into overlay/BGP and vice-versa.

    • Support for Overlay Flow Control (OFC).

    • A full suite of OSPFv3 Remote Diagnostics.

  • DHCPv6 Relay Agent support on Edge

    • Local / Remote / Cloud DHCP server use cases

    • Acts as Multiple Relay Agents

  • Non SD-WAN IPv6 Destinations via Edge

    • Supported tunnel failover scenarios:

      • Active-Active

      • Active- Standby

      • Active–Hot Standby

    • Flow-based link selection.

    • The Orchestrator UI includes Tunnel Monitoring, Events, and Alerts.

RADIUS MAC Address Bypass (MAB) for 802.1x on VLANs

In Release 5.1.0, the RADIUS MAB for 802.1x was introduced but limited to routed interfaces only. In Release 5.2.0, customers can also use this feature for VLANs which can be assigned to an Edge's switched port.

Note:

The MAB feature has the following limitations when configured for a VLAN for use on a switched port:

  • L2 traffic will not trigger RADIUS MAB.

  • L2 traffic will not be forwarded on Linux-based switches until routed traffic is seen. Hardware switches already do not filter pure L2 traffic, and this limitation remains unchanged.

  • If no routed traffic is observed and RADIUS MAB times out (default is 30 minutes), L2 traffic will again be blocked.

  • Additional hooks to check 802.1x status for self-destined packets may cause performance degradation when 802.1x is enabled.

  • Traffic destined to self and managed entirely by Linux will no longer be filtered prior to 802.1x authentication (DHCP, DNS, ssh, and so forth).

Route Visibility Enhancements for the Gateways

These enhancements address the need for customers and partners to have greater visibility into a Gateway's routing table and include:

  • A Gateway Route Table tab on the Customer's Monitor > Routing page of their Orchestrator.

  • A BGP Gateway Neighbor State tab on the Customer's Monitor > Routing page to show BGP Advertised and Received routes per neighbor.

  • Complete information for a particular route prefix.

  • Filtering based on a route prefix.

  • The option to export the Gateway route table.

Trusted Platform Module (TPM)

The Trusted Platform Module (TPM) is a hardware-based security feature. It provides a secure storage area for sensitive information like encryption keys, passwords, and certificates with a physical layer of protection through a one-direction "hardware vault".

VMware SD-WAN includes the TPM on all variations (LTE, -N, and so forth) of SD-WAN hardware Edges (510, 520, 540, 610, 620, 640, 680, 3000, 3100, 3400, and 3800). A customer activates the feature through the Orchestrator UI by going to Configure > Edge > Overview and checking the box for Encrypt Device Secrets.

Note:

Virtual Edges do not have TPM support in this release.

Important Notes

Change in Behavior for the BGP MED Attribute for Hub Edges

Release 5.2.0 includes a change in the BGP MED Attribute as follows: previously, the BGP MED value advertised by Hub Edges started from value 9, 10, 11, and so forth. As part of a fix for Issue #111840, the BGP MED value now starts from 33, 34, 35, and so forth.

UI Build

Beginning with Release 5.2.0.4, VMware introduces the Orchestrator UI Build. A UI Build only contains fixes for UI issues, which are problems that affect how you use the Orchestrator's user interface. A UI Build does not include any fixes for management/control plane issues that impact the underlying functionality of the Orchestrator as a standard Orchestrator build would.

A UI build is added to an existing Orchestrator release and is distinguished by a unique build version listed below the Orchestrator build name. The UI Build can be located in the same way a user identifies the Orchestrator Version by clicking on the ? icon in the upper right corner of the Orchestrator UI screen. For example, if an Orchestrator running version 5.2.0.4 with build R5204-20230831-GA is updated with UI Build version R5204-20230914-GA, that would appear immediately below the Orchestrator build with the name "UI Build". If an Orchestrator has no UI Build, a user only sees an Orchestrator build.

Orchestrators are upgraded to a UI Build as follows:

  • VMware Operations Team upgrades both Hosted Shared Orchestrators and Hosted Private Orchestrators with the latest UI Build within a week of the build's release if the Orchestrator is already using the most current Orchestrator release.

  • A Partner using a Dedicated Orchestrator needs to open a ticket with Support to have the Operations Team upgrade their Orchestrator with a UI Build on the condition they are using the most current Orchestrator release.

Note:

UI Builds are not available for Customers who deploy an On Premises Orchestrator.

For additional information on the UI Build see the KB articles VMware SD-WAN Software Upgrade FAQs (67152) and VMware SD-WAN Software Release Types and Software Upgrade Strategy for Orchestrators and Gateways (89609).

LAN-Side NAT Behavioral Change

When a LAN-side NAT is configured for many-to-one translations using Port Address Translation (PAT), traffic initiated from the opposite direction can allow unexpected access to fixed addresses based on the outside mask and original IP address. This new behavior applies to Destination NAT (DNAT), Source NAT (SNAT), and Source and Destination NAT (S+D NAT) rules.

For example, a SNAT rule with an inside network of 192.168.1.0/24 and an outside address of 10.1.1.100/32 permits outside-to-inside translation to 192.168.1.100.

To address this new behavior, SD-WAN now blocks traffic when a connection is initiated in the reverse PAT direction.

To restore the original behavior, a user needs to configure two rules of the same type as the original rule (SNAT, DNAT, S+D NAT) in a particular order. For example, using the earlier SNAT scenario a user needs to configure the following:

  1. SNAT rule with an inside network of 192.168.1.100/32 and an outside address of 10.1.1.100/32

  2. SNAT rule with an inside network of 192.168.1.0/24 and an outside address of 10.1.1.100/32

If the original rule is a DNAT or S+D NAT, then the user would need two DNAT or S+D NAT rules with the same structure and order.

In Release 4.5.0 and forward, a user can determine if flows are dropped for this type of traffic in the dispcnt logs of a diagnostic bundle by searching for the counter: lan_side_nat_reverse_pat_drop.

Classic UI Deprecated on the SASE Orchestrator

In Release 5.2.0 the New UI is now complete for all configuration and monitoring tasks. As a result, the Classic UI is by default hidden and not available for use. In addition, SASE Engineering will no longer fix issues that are specific to the Classic UI.

Greenfield Direct Customers on a Hosted Orchestrator Are Automatically Assigned to Cloud Services Platform (CSP) as their IdP

Greenfield direct customers (not assigned to a Partner) who are created on a Release 5.2.0 Hosted Orchestrator are automatically configured for SSO using CSP as the IdP. As a result:

  • New administrators are created by an administrator with a Superuser role through the CSP portal.

  • In the event of a CSP outage, the customer is permitted one "break glass" administrator account with local authentication (username/password) to allow them to access their portal.

  • New direct customers will need to use token-based authentication for API access. They will not be able to use cookie-based authentication as user creation moves to CSP.

Note:

On Premise Orchestrators are not subject to CSP requirements and their customers would continue to use Orchestrator-based authentication.

Hub or Cluster Interconnect Remains Early Access

Hub or Cluster Interconnect was introduced in Release 5.1.0 with the caveat:

"Enabling Hub or Cluster Interconnect introduces a fundamental change to the VMware SD-WAN routing protocol where it allows packets to traverse more than one hop in the network. While this change has been tested in representative topologies, it is not possible to test for all routing scenarios that may be encountered when making such a change of allowing distant routes to be distributed. As a result, VMware is releasing this feature as early access and will be closely monitoring deployments where it is enabled for unexpected routing behavior."

The caveat remains in effect for this feature in Release 5.2.0.

Limitation with BGP over IPsec on Edge and Gateway, and Azure Virtual WAN Automation

The BGP over IPsec on Edge and Gateway feature is not compatible with Azure Virtual WAN Automation from Edge or Gateway. Only static routes are supported when automating connectivity from an Edge or Gateway to an Azure vWAN.

Limitation When Deactivating Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810

When a user deactivates autonegotiation to hardcode speed and duplex on ports GE1 - GE4 on a VMware SD-WAN Edge model 620, 640 or 680; on ports GE3 or GE4 on an Edge 3400, 3800, or 3810; or on an Edge 520/540 when an SFP with a copper interface is used on ports SFP1 or SFP2, the user may find that even after a reboot the link does not come up.

This is caused by each of the listed Edge models using the Intel Ethernet Controller i350, which has a limitation that when autonegotiation is not used on both sides of the link, it is not able to dynamically detect the appropriate wires to transmit and receive on (auto-MDIX). If both sides of the connection are transmitting and receiving on the same wires, the link will not be detected. If the peer side also does not support auto-MDIX without autonegotiation, and the link does not come up with a straight cable, then a crossover Ethernet cable will be needed to bring the link up.

For more information please see the KB article Limitation When Deactivating Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810 (87208).

Available Languages

The VMware SASE Orchestrator using version 5.2.0 is localized into the following languages: Czech, English, European Portuguese, French, German, Greek, Italian, Spanish, Japanese, Korean, Simplified Chinese, and Traditional Chinese.

Orchestrator API Changes

Orchestrator API Changes since 5.1.0

Changes to the VMware SASE Orchestrator Portal API ("API v1")

There are no changes in the API v1 from 5.1.0 to 5.2.0. For reference, the complete API Changelog is available for download at developer.vmware.com (see "VMware SD-WAN Orchestrator API v1").

Changes to the VMware SASE Orchestrator API v2

This release adds support for the configuration of Profile and Edge level Quality of Service (QoS) modules. APIs for returning the firewall statistics and NNI metrics are also added for this release.

Release 5.2.0 introduces the following new API operations:

  • Profile and Edge level QOS module

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

    • PUT /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

    • PATCH /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

    • POST /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

    • PUT /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

    • PATCH /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • Enterprise and Edge level enhanced Firewall stats

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/firewallIdpsStats

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/firewallIdpsStats

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/firewallIdpsStats/timeSeries

  • Enterprise level Gateway NNI metrics

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/nniStats

    • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/nniStats/timeSeries

Developer Documentation

All VMware SASE/SD-WAN API documentation resides on the Developer Documentation Portal at https://developer.vmware.com/apis.

Document Revision History

July 9th, 2024. Thirty-Second Edition.

  • Added wording for the Automatic Rate-Limiting on the Gateway enhancement to the New SD-WAN Enhancements section of the Release Notes. This enhancement is included with all 5.2.0 and later Gateway versions but was previously only documented as an Operator Event. The added wording here makes clear when this Gateway enhancement was introduced.

May 2nd, 2024. Thirty-First Edition.

  • Added a new Important Note: Change in Behavior for the BGP MED Attribute for Hub Edges, where the BGP MED value for Hub Edges no longer starts from 9, 10, 11, and so forth, but now starts from 33, 34, 34, and so forth. This change applies to all 5.2.0 Edge software and the versions following 5.2.0 (5.2.1, 5.2.2, and 5.2.3). Also added the same note to Fixed Issue #111840 as this is where the behavior change was made.

March 18th, 2024. Thirtieth Edition.

  • Reclassified issues #92482 and #106289 from Open to Fixed and moved them from the Edge/Gateway Known Issues section to the Edge/Gateway resolved section for original GA build R5200-20230530-GA. These issues should have been classified as fixed in the 1st edition of these release notes.

March 8th, 2024. Twenty-Ninth Edition.

  • Added a new Edge Hotfix build R5202-20240216-GA-137279 to the Edge/Gateway Resolved section. This is the new Edge GA build for Release 5.2.0.

  • Edge hotfix build R5202-20240216-GA-137279 includes the fix for issues #125421, #137279, and #138006, each of which is documented in this section.

    Note:

    This is an Edge-only release. The default Gateway Release 5.2.0 build remains R5202-20230725-GA.

  • Added Fixed Issue #100005 to the Edge/Gateway Resolved Issues section for original GA build R5200-20230530-GA. This issue was omitted from the first edition of the Release Notes.

  • Moved Issue #97559 from the Edge/Gateway Known Issues section to the Edge/Gateway Resolved Issues section as a Fixed Issue for original GA build R5200-20230530-GA. This action should have been done in the first edition of the Release Notes.

  • Added Fixed Issue #108583 to the Orchestrator Resolved Issues section for the original Orchestrator build, R5200-20230530-GA. This issue was omitted from the First Edition of the Release Notes.

February 21st, 2024. Twenty-Eighth Edition

Janury 30th, 2024. Twenty-Seventh Edition.

December 22nd, 2023. Twenty-Sixth Edition.

December 18th, 2023. Twenty-Fifth Edition.

  • Added Fixed Issues #93141 and #95565 to the Edge/Gateway Resolved Issues section for the original Edge/Gateway build, R5200-20230530-GA . These issues were omitted in error from the First Edition of the Release Notes.

  • Added Open Issues #118501, #122193, #129232, #129412, #129662, #129958, #131299, #133201, and #133642 to the Orchestrator Known Issues section.

  • Added Open Issue #125274 and #134374 to the Edge/Gateway Known Issues section.

December 4th, 2023. Twenty-Fourth Edition.

  • Added a new Orchestrator UI Build R5204-20231201-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the twelfth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231201-GA includes the fixes for UI issues #126695, #128921, #129662, #131224, #131631, #132047, #132384, and #133008, each of which is documented in a separate table inside of the R5204-20230831-GA section.

  • Removed Known Issue #83166 which read: "When a VMware SD-WAN Gateway is freshly deployed with a AWS c5.4xlarge instance type from the AWS Portal with IPv6 option selected, neither IPv6 or the default routes are configured and the AWS Gateway IPv6 management tunnels are not forming." This issue will not be fixed and instead user documentation will add a requirement to only use the static mode of IPv4/IPv6 address assignment on interfaces for a Gateway because VMware SD-WAN does not support DHCP on the Gateway side.

November 22nd, 2023. Twenty-Third Edition. R5204-20231201-GA

  • Added a new Orchestrator UI Build R5204-20231121-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the eleventh UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231121-GA includes the fixes for UI issues #128017, #129695, #130810, #131138, and #132524, each of which is documented in a separate table inside of the R5204-20230831-GA section.

Note:

Issue #131118 was previously listed as fixed in UI Build R5204-20231109-GA. However the issue was not completely fixed there and is only fully fixed with this build.

  • Added Fixed Issues #104513 and #106331 to the Edge/Gateway Resolved Issues section for the original Edge/Gateway build, R5200-20230530-GA . These issues were omitted in error from the First Edition of the Release Notes.

November 16th, 2023. Twenty-Second Edition.

  • Added a new Orchestrator UI Build R5204-20231115-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the tenth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231115-GA includes the fixes for UI issues #123078, #123718, #128330, #128765, and #130877 each of which is documented in a separate table inside of the R5204-20230831-GA section.

November 14th, 2023. Twenty-First Edition.

  • Added an updated Edge rollup build R5202-20231107-GA-125647 to the Edge/Gateway Resolved section. This is an update to the second Edge rollup build R5202-20230725-GA and is the new default Edge/Gateway GA build for Release 5.2.0.

  • Edge build R5202-20231107-GA-125647 includes the fix for issue #125647, which is documented in this section.

Important:

  • All previous Release 5.2.0 Edge builds are deprecated in favor of R5202-20231107-GA-125647.

  • Customers upgrading to 5.2.0 should only upgrade to R5202-20231107-GA-125647.

  • Customers already successfully using a 5.2.0.x Edge build do not need to upgrade their Edges to R5202-20231107-GA-125647.

November 10th, 2023. Twentieth Edition.

  • Added a new Orchestrator UI Build R5204-20231109-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the ninth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231109-GA includes the fixes for UI issues #123387, #123640, #127727, #129584, #130153, and #131138, each of which is documented in a separate table inside of the R5204-20230831-GA section.

November 2nd, 2023. Nineteenth Edition.

  • Added a new Orchestrator UI Build R5204-20231101-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the eighth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231101-GA includes the fixes for UI issues #123001, #127904 #128753, #129061, #129494, #129662, #129765, and #129894, each of which is documented in a separate table inside of the R5204-20230831-GA section.

October 31st, 2023. Eighteenth Edition.

  • Revised the wording for Fixed Issue #110484 in the Edge/Gateway Resolved Issues section to make it clear this ticket does not resolve the symptoms listed for the ticket, but instead the Edge software includes enhanced logging to assist Engineering in delivering an actual fix for the listed symptoms.

October 27th, 2023. Seventeenth Edition.

  • Added a new Orchestrator UI Build R5204-20231027-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the seventh UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231027-GA includes the fixes for UI issues #125964, #126602, #127904, #128279, #128357, #129413, and #129926, each of which is documented in a separate table inside of the R5204-20230831-GA section.

October 20th, 2023. Sixteenth Edition.

  • Added a new Orchestrator UI Build R5204-20231019-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the sixth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231019-GA includes the fixes for UI issues #127021, #128706, #129049, #129271, and #129560, each of which is documented in a separate table inside of the R5204-20230831-GA section.

  • Added Open Issue #125421 to the Edge/Gateway Known Issues section.

  • Added Fixed Issue #110406 to the Edge/Gateway Resolved Issues section for the original Edge/Gateway build, R5200-20230530-GA . This issue was omitted in error from the First Edition of the Release Notes.

  • Added a new note: LAN-Side NAT Behavioral Change, to the Important Notes section.

October 13th, 2023. Fifteenth Edition.

  • Added a new Orchestrator UI Build R5204-20231013-0631-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the fifth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231013-0631-GA includes the fixes for UI issues #120419, #127035, #127636, #127774, #128371, #128620, and #129253, each of which is documented in a separate table inside of the R5204-20230831-GA section.

  • Added Open Issues #125647 to the Edge/Gateway Known Issues section.

October 4th, 2023. Fourteenth Edition.

  • Added a new Orchestrator UI Build R5204-20231003-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the fourth UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20231003-GA includes the fixes for UI issues #117923, #123070, #127037, #128628, and #128667, each of which is documented in a separate table inside of the R5204-20230831-GA section.

September 28th, 2023. Thirteenth Edition.

  • Added a new Orchestrator UI Build R5204-20230927-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the third UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20230927-GA includes the fixes for UI issues #126967, #127006, #127843, #127849, #127871, and #128277, each of which is documented in a separate table inside of the R5204-20230831-GA section.

  • Added the following tickets to the Orchestrator Known Issues section: #125082, #125504, #125663, #126257, #126421, #126425, #126465, #126695, #127037, #127152, #127636, and #128070.

  • Added Fixed Issue #110484 to the Edge/Gateway Resolved Issues section for the original Edge/Gateway build, R5200-20230530-GA . This issue was omitted in error from the First Edition of the Release Notes.

September 21st, 2023. Twelfth Edition.

  • Added a new Orchestrator UI Build R5204-20230920-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the second UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20230920-GA includes the fixes for UI issues #106191, #113254, #117941, #117993, #121469, #126503, and #126257, each of which is documented in a separate table inside of the R5204-20230831-GA section.

  • Revised the Important Notes entry, UI Build to add information about how a UI Build is added to the four respective Orchestrator types: Hosted Shared, Private Shared, Dedicated, and On Premises. This entry includes a note that UI Builds are not available to customers using On Premises Orchestrators.

September 15th, 2023. Eleventh Edition.

  • Added a new Important Notes titled UI Build. A UI Build is a new kind of Orchestrator software release which contains fixes for user interface issues only and is added to an existing Orchestrator release.

  • Added a new Orchestrator UI Build R5204-20230914-GA to the Orchestrator Resolved Issues section for R5204-20230831-GA. This is the first UI Build for Orchestrator rollup build R5204-20230831-GA.

  • UI Build R5204-20230914-GA includes the fixes for UI issues #108125, #122918, #123619, #123927, #124801, #125309, #125393, #125710, #126403, and #127007, each of which is documented in a separate table inside of the R5204-20230831-GA section.

September 1st, 2023. Tenth Edition.

  • Added a new Orchestrator rollup build R5204-20230831-GA to the Orchestrator Resolved Issues section. This is the third Orchestrator rollup build and is the new default Orchestrator GA build for Release 5.2.0.

  • Orchestrator build R5204-20230831-GA includes the fixes for issues #65668, #104775, #118728, #120398, #121118, #121526, #122113, #123002, #123053, #123150, #123346, #123551, #123749, #124073, #124129, #124273, #124315, #124778, #124798, and #125456, each of which is documented in this section.

  • Added Open Issues #117037 and #121606 to the Edge/Gateway Known Issues section.

  • Removed Open Issue #62701 from Edge Gateway Known Issues as it was fixed in Release 5.1.0.

  • Document Revision History reorganized to read from newest entries to oldest for an improved user experience.

August 9th, 2023. Ninth Edition.

  • Added a new Orchestrator rollup build R5203-20230809-GA to the Orchestrator Resolved Issues section. This is the third Orchestrator rollup build and is the new default Orchestrator GA build for Release 5.2.0.

  • Orchestrator build R5203-20230809-GA includes the fixes for issues #121118, #121884, #122132, #122797, #123384, and #123609, each of which is documented in this section.

  • Added Fixed Issue #105861 to the Orchestrator Resolved Issues section for the original Orchestrator build, R5200-20230530-GA. This issue was omitted in error from the First Edition of the Release Notes.

  • Added an Available Languages section to make clear the languages into which the VMware SASE 5.2.0 Orchestrator is localized.

August 2nd, 2023. Eighth Edition.

  • Added a new Orchestrator rollup build R5202-20230729-GA to the Orchestrator Resolved Issues section. This is the second Orchestrator rollup build and is the new default Orchestrator GA build for Release 5.2.0.

  • Orchestrator build R5202-20230729-GA includes the fixes for issues #116666, #117772, #117822, #118544, #118733, #120070, #120606, #120774, #121441, #121472, #121751, #121835, #121858, #121993, #122010, #122271, #122520, #122866, and #122977, each of which is documented in this section.

  • Added Open Issue #121118 to the Orchestrator Known Issues section.

July 31st, 2023. Seventh Edition.

  • Added a new Edge/Gateway rollup build R5202-20230725-GA to the Edge/Gateway Resolved section. This is the second Edge/Gateway rollup build and is the new default Edge/Gateway GA build for Release 5.2.0.

    Edge/Gateway build R5202-20230725-GA includes the fixes for issues #106865, #117775, and #121368, each of which is documented in this section.

  • Reclassified Fixed Issue #82095 as an Open Issue and moved the ticket to the Orchestrator Known Issues section.

  • Added Open Issue #117314 and #121998 to the Edge/Gateway Known Issues section.

  • Removed Open Issue #53359 from the Edge/Gateway Known Issues section as this was resolved in a 4.3.x build.

July 12th, 2023. Sixth Edition.

  • Added Fixed Issues #86994, #90044, #98223, #101753, #105433, #110456, #106123, and #116086 to the Edge and Gateway Resolved Issues section for the original Edge build, R5200-20230530-GA. These issues were omitted in error from the First Edition of the Release Notes.

  • Added Fixed Issue #114546 to the Orchestrator Resolved Issues section for the original Orchestrator build, R5200-20230530-GA. This issue was omitted in error from the First Edition of the Release Notes.

July 5th, 2023. Fifth Edition.

  • Added Firewall Logs on the Orchestrator to the list of New SD-WAN Enhancements. This enhancement was omitted in error from the first edition of the Release Notes.

  • Added Fixed Issue #107317 to the Edge/Gateway Resolved Issues section for the original GA build.

June 26th, 2023. Fourth Edition.

  • Added a new Orchestrator rollup build R5201-20230623-GA to the Orchestrator Resolved section. This is the first Orchestrator rollup build and is the new default Orchestrator GA build for Release 5.2.0.

  • Orchestrator build R5201-20230623-GA includes the fixes for issues #112333, #113254, #115411, #115624, #116141, #116790, #117527, #117800, #117993, #118071, #118574, #118673, #119551, and #119733, each of which is documented in this section.

Important:

Those using a 5.2.0.0 build for their on premises Orchestrator are strongly recommended to upgrade their Orchestrator to 5.2.0.1.

June 22nd, 2023. Third Edition.

  • Added a new Edge/Gateway rollup build R5201-20230619-GA to the Edge/Gateway Resolved section. This is the first Edge/Gateway rollup build and is the new default Edge/Gateway GA build for Release 5.2.0.

  • Edge/Gateway build R5201-20230619-GA includes the fixes for issues #115150 and #117638, each of which is documented in this section.

Important:

Those using a 5.2.0.0 build for the Edge or Gateway are strongly recommended to upgrade their Edges and/or Gateways to 5.2.0.1.

June 7th, 2023. Second Edition.

  • Added Fixed Issues #105933 and #109963 to the Edge and Gateway Resolved Issues section for the original Edge build, R5200-20230530-GA. These issues were omitted in error from the First Edition of the Release Notes.

May 31, 2023. First Edition.

Edge and Gateway Resolved Issues

Resolved in Edge Version R5202-20240216-GA-137279

Edge build R5202-20240216-GA-137279 was released on 03-06-2024 and is a Hotfix build for Release 5.2.0.

This Edge Hotfix build addresses the below critical issues since the previous updated 2nd rollup build, R5202-20231107-GA-125647.

  • Fixed Issue 125421: A customer may observe that the WAN links on a VMware SD-WAN Edge are intermittently showing as down and then up on the Monitoring and Events page of the VMware SASE Orchestrator UI, with the potential the Edge may become unresponsive and fail to pass traffic until it is manually rebooted, or the Edge can experience a Dataplane Service failure and restart.

    This is an Edge memory leak issue that is encountered when the Edge Dataplane Service cannot open shared memory, causing stale PIs. This in turn causes open file descriptor exhaustion which will initially impact WAN links. However if this issue is sufficiently advanced and results in Edge memory exhaustion the Edge can:

    1. Become unresponsive and unreachable through the Orchestrator, which requires an on-site reboot/power cycle.

    2. Can trigger an Edge service failure with a core file generated, with the Edge restarting to recover.

  • Fixed Issue 137279: For a customer enterprise site deployed with a High Availability topology where the HA Edges are using a 5.2.0.x software version, either upgrading the HA Edge pair to any other Edge software version, or a standard fail-over of the Active Edge to the Standby Edge may result in the site going offline on the VMware SASE Orchestrator, though customer traffic would continue to pass.

    The issue is the result of the Standby Edge's certificate not being renewed and ultimately expiring. The Active Edge's certificate is properly updated so the issue only manifests upon an HA fail-over, when the promoted Standby Edge with the expired certificate causes the HA pair to go offline on the Orchestrator. This means the site cannot be reached, monitored, or managed through the Orchestrator.

    When a customer has Certificate Enabled for their enterprise, the Active HA Edge includes the Standby Edge's certificate digest as part of every heartbeat it sends to the Orchestrator. The Orchestrator uses this certificate digest to renew the Standby Edge's certificate. The cause of the issue is a defect in this certificate digest generation process which results in a certificate digest that consists of an empty string and this results in the Standby Edge's certificate never being renewed unless a manual renewal is done from the Orchestrator prior to an HA fail-over or before the Standby Edge certificate expires.

    On an HA site using Edge versions without a fix for this issue, should a customer HA site experience this issue, the only way to restore the site is to get physical access to the HA Edge pair and reboot the current Active Edge (the former Standby Edge) to trigger an HA fail-over. This can be done either through the Local UI (if so enabled) or by power cycling the Active Edge. Once back online with the Orchestrator, a manual renewal can be done to renew the certificates both HA Edges.

    Caution:

    A manual certificate renewal results in tunnel flaps since the Active Edge's certificate is also renewed.

  • Fixed Issue 138006: For a customer site deployed with a High Availability topology, the customer may observe the Standby Edge restart as a result of having high memory usage.

    If memory usage is sufficiently high, the Standby Edge defensively restarts its Dataplane Service to clear the issue. The restart can impact traffic on Enhanced HA topologies where the Standby is passing traffic. In a Standard HA topology, there is no functional impact.

    The high memory usage is the result of a memory leak which is caused by the Edge refreshing all IPsec tunnel certificates which triggers a tear down and rebuilding of all IPsec tunnels even if there is no change in the certificate and this high number of revoked certificates are not cleared from the Standby Edge's memory.

Resolved in Edge Version R5202-20231107-GA-125647

Edge build R5202-20231107-GA-125647 was released on 11-13-2023 and is an update to the 2nd Edge rollup for Release 5.2.0.

This updated Edge build addresses a critical issue since the original 2nd Edge rollup, R5202-20230725-GA.

Important:

  • All previous Release 5.2.0 Edge builds are deprecated in favor of R5202-20231107-GA-125647.

  • Customers upgrading to 5.2.0 should only upgrade to R5202-20231107-GA-125647.

  • Customers already successfully using a 5.2.0.x Edge build do not need to upgrade their Edges to R5202-20231107-GA-125647.

  • Fixed Issue 125647: For a site deployed with an Edge model 520 or 540, when an Edge is upgraded to a 5.2.0 version, client users connected to the Edge via a LAN port may experience a total loss of connectivity.

    Rebooting the Edge 520/540 does not recover the issue nor does downgrading the Edge to an older software version once it has been upgraded to a 5.2.0 version. When the Edge's console is deactivated in the Edge Security > Console Access settings on the Firewall configuration page of the Orchestrator (which is the default configuration for any Edge), the driver that manages the LAN1 through LAN8 ports of the Edge 520 or 540 does not configure itself properly, leading to those ports not being created at all.

    On an Edge without a fix for this issue, a customer can prevent this issue from occurring and/or restore connectivity on LAN ports on an affected Edge, by doing the following: navigate to Configure > Edge/Profile > Firewall > Edge Security, and under Console Access click on Enable and Save Changes.

    Note:

    Changing this configuration requires an Edge reboot which takes ~2-3 minutes to complete. If possible, perform this change in a maintenance window.

Resolved in Edge/Gateway Version R5202-20230725-GA

Edge and Gateway build R5202-20230725-GA was released on 07-31-2023 and is the 2nd Edge/Gateway rollup for Release 5.2.0.

This Edge/Gateway rollup build addresses the below critical issues since the 1st Edge/Gateway rollup, R5201-20230619-GA.

  • Fixed Issue 106865: For a customer who uses the Edge Network Intelligence service and has activated Analytics on their enterprise, they may observe that non-IP traffic (for example, RADIUS authentication) is dropped.

    When Analytics is activated, if non-IP frames are received on a SD-WAN Edge interface, the Edge may mistakenly process these as IPv4 fragments and cause a fragment record leak. Over time, this can stop all fragment processing and all such packets are dropped. For a customer using RADIUS authentication, the result can be authentication becoming broken for all Edges at the same time.

    On an enterprise not using a fixed build, the only workaround is to reboot all Edges.

  • Fixed Issue 117775: A Non SD-WAN Destination via Gateway (NSD) may intermittently get into a state where the IPsec tunnels flap (are torn down and built back up) constantly.

    The customer would observe that the tunnels are up for several seconds, and then down for several seconds, and then back up with this cycle repeating before stopping on its own. Because the issue is timing-based, the cycle could repeat over days and potentially infinitely. The issue occurs based on a race condition when an NSD tunnel with a large number of IKE Phase 2 connections is coming up, and there is traffic the Gateway is trying to forward on one of those IKE Phase 2 connections before it is fully up, causing the whole tunnel to be torn down and rebuilt, and the cycle repeats.

    On a site not using Gateways with a fix for this issue: because this is a timing-based issue workaround options are limited. One potential workaround is to configure the NSD tunnels in small batches so that they are negotiated faster and thus avoid the window in which traffic is arriving before the tunnel is ready.

  • Fixed Issue 121368: A VMware SD-WAN Gateway may experience a Dataplane Service failure, generate a core, and restart as a result.

    The issue is triggered by remote access users accessing the Internet/Cloud through the Gateway. If the Internet/Cloud endpoint responds with a large packet that requires fragmentation, the Gateway service fails while attempting to fragment the packet.

Resolved in Edge/Gateway Version R5201-20230619-GA

Edge build R5201-20230619-GA was released on 06-22-2023 and is the 1st Edge rollup for Release 5.2.0.

This Edge/Gateway rollup build addresses the below critical issues since the original GA build, R5200-20230530-GA.

Important:

Those using Edge or Gateway 5.2.0.0 build are strongly recommended to upgrade their Edges and/or Gateways to 5.2.0.1.

  • Fixed Issue 115150: When a customer deploys either a Non SD-WAN Destination (NSD) or Cloud Security Service (CSS) with a Zscaler type, and L7 Health Check is toggled on, the customer may observe that one or more tunnels are down due to a failure of the L7 Health Check.

    This issue can be encountered on either the primary or secondary tunnels. When a VMware SD-WAN Gateway is managing multiple L7 Health Checks, a NAT leak caused by the L7 Health Check probes leads to NSD/CSS tunnel failure that cannot be recovered without rebooting the Gateway.

  • Fixed Issue 117638: When a user navigates to Monitor > Edge > Links and turns on Live Mode for a VMware SD-WAN Edge using Release 5.2.0, the SASE Orchestrator does not deliver any realtime statistics.

    In addition the user observes a Waiting for Edge ... indication that eventually times out. The issue is caused on the Edge due to the way a 5.2.0 Edge build handles LTE/USB link statistics when uploading them to the Orchestrator.

Resolved in Edge/Gateway Version R5200-20230530-GA

Edge and Gateway build R5200-20230530-GA was released on 05-31-2023 and resolves the following issues since Edge and Gateway build R5102-20230310-GA.

Note:

Release 5.2.0 contains all Edge and Gateway fixes that are listed in 5.0.0 and 5.0.1 Release Notes, and all Edge and Gateway fixes in 5.1.0 Release Notes up to the above listed build.

  • Fixed Issue 48032: There is not a way to track a VMware SD-WAN Edge's disk read and write statistics for analysis in the event of a disk failure.

    There is a current method that tracks how much is written to a disk in /velocloud/log but the data lacks any granularity as it only tracks the overall data being written and not the number of writes. This ticket adds "Disk Stats" under the Remote Diagnostic "System Information" so that VMware Engineering can refer back to these statistics in the event of a disk-based Edge RMA.

  • Fixed Issue 54573: When running a route table dump, the output may show the wrong metric value for certain connected routes.

    This issue is the result of the Edge service not receiving the right notification for interface route addition from the Edge kernel.

  • Fixed Issue 57170: A customer enterprise using BGP, private links, and a Partner Gateway may experience a loss of connectivity with clients behind the Partner Gateway towards the server behind a VMware SD-WAN Edge.

    The Internet traffic uses the MPLS network instead of the NAT handoff process.

  • Fixed Issue 58244: A customer using BGP, and a Partner Gateway may observe connectivity issues for traffic using the PG.

    The issue arises from the PSBR route not being installed and this could be observed when looking at a route table dump. The cause of this is that the Gateway was removed and added again, route events were dropped with error `route queue not found for segment 1`.

  • Fixed Issue 68748: When a client device using Windows OS is connected to a VMware SD-WAN Edge, the Event report for "New Client Device Seen" is the incorrect OS version.

    The Edge is truncating the description in the dhcp_fingerprints.json file and this prevents the customer from having the correct OS for that connected client device.

  • Fixed Issue 82808: For a VMware SD-WAN Edge that is using a Cloud Security Service (CSS) and has turned on L7 Health Check, the customer may observe traffic failing using these CSS tunnels even though the VMware SASE Orchestrator continues to mark the tunnels as UP.

    Even though the L7 probe fails with a 4XX HTTP error, the VMware SD-WAN Gateway does not acknowledge the failure and does not inform the Orchestrator to mark the CSS tunnels as DOWN.

  • Fixed Issue 84235: A VMware SD-WAN Edge may experience a Dataplane Service failure and restart to recover.

    If the Edge is freeing fragmented IKEv2 packets (in PKI enabled mode) at the same time there is tunnel flap, there is a small chance where a "double free" state can happen and trigger an exception on the Edge's service which causes the failure and restart.

  • Fixed Issue 86994: On a customer enterprise where Dynamic Branch to Branch is activated, when attempting to troubleshoot a VMware SD-WAN Edge in this enterprise the dispcnt debugging command does not work.

    The dispcnt debug command does not provide all the counter values and fails with Domain (null) does not exist. This also fails when referring to the relevant logs in an Edge diagnostic bundle. This significantly hinders troubleshooting a customer network issue.

    This issue arises in enterprises where Dynamic Branch to Branch is activated due to the large quantity of tunnels that are created and torn down towards each peer. The counters to store various metrics of the peers are stored in a shared memory and over time, these shared memory segments get into a bad state due to a collision and the counters are not fetched by the dispcnt command.

    Without a fix for this issue, the user can only clear the state by performing a service restart of the affected Edge.

  • Fixed Issue 89332: If the VMware SD-WAN Edge's /velocloud directory is full or cannot be written into, the customer is unaware of this status in Events.

    The customer would only notice that the Edge was not posting additional Events and that could be days before they did. Reporting Events to the Orchestrator happens by writing a file into the /velocloud directory. If either the directory is full, or if there is an issue with the disk such that it goes into read-only mode, the customer and VMware Engineering/Support has no way of knowing this since there is no Event or logging to warn of this.

    The fix for this issue adds a new log entry written to a different folder to indicate clearly what is happening that would read similar to the following:

    • edge:b1-edge1:~# cat /var/log/log_eventgen.log

    • 2023-05-19 13:03:46,628 Unable to create event save file: [Errno 30] Read-only file system: '/velocloud/events/client/event.1684501426626.mgp7kfvg'

    • 2023-05-19 13:03:46,634 events.EventPackage failure, queing to MGD

  • Fixed Issue 90044: When a VMware SD-WAN Gateway is configured with an ICMP probe and the Gateway is restarted, the ICMP probe does not recover and remains down.

    The ICMP Probe state in debug.py --icmp reads as DOWN after a Gateway restart.

    On a Gateway without a fix for this issue, the workaround is to deactivate the ICMP probe and then reactivate it.

  • Fixed Issue 92142: When a device behind a VMware SD-WAN Edge tries to communicate with a device directly connected to the Edge via a routed interface with a VLAN or subinterface configured, the communication may fail.

    When NAT Direct is configured on a routed interface, it is expected that all traffic sent direct via that interface (on the underlay) will be NAT'd using the routed interface's IP address. However, NAT is not applied for traffic to and from other IP addresses in the same subnet as the routed interface when the routed interface is a subinterface or uses a VLAN. This defect is not experienced if the destination is one or more hops away because the Edge is not enforcing NAT Direct and traffic will work (see below Note, for implications once an Edge uses a fixed version).

    Note:

    It is possible that an older version of the SASE Orchestrator inadvertently configured NAT Direct on a main interface with either a VLAN or subinterface configured. If that interface is sending direct traffic one or hops away, the customer would never observe an issue because the NAT Direct setting was not being applied. However, when an Edge is upgraded to 5.2.0 and later with a fix for this issue, there is a resulting change in routing behavior since this specific use case was not implemented in prior releases.

    In other words, because a 5.2.0 Edge now implements NAT Direct in the expected manner for all use cases, traffic that previously worked (because NAT Direct was not being applied per the defect) may now fail because the customer never realized that NAT Direct was checked for an interface with a VLAN or subinterface configured.

    As a result, a customer upgrading their Edge to Release 5.2.0 or later should first check their Profiles and Edge interface settings to ensure NAT Direct is configured only where they explicitly require it and to deactivate this setting where it is not, especially if that interface has a VLAN or subinterface configured.

  • Fixed Issue 92927: When a VMware SD-WAN Edge interface is deactivated, the interface continues to have a link with a connected device.

    When an interface is selected to be deactivated through the Orchestrator, it is removed from the Edge's DPDK control and placed under the control of the Edge's kernel driver. However, the script which does this conversion sets the kernel admin up on the interface, so if the interface is connected, it will attempt to autonegotiate with the connected device.

  • Fixed Issue 92400: On a customer site configured with a High Availability topology and where Edge interfaces are configured with subinterfaces, the Standby Edge takes a longer time to converge after an HA failover.

    Both Gratuitous ARP and Nexthop ARP are not sent from the subinterface, and this leads to a convergence time greater than the expected sub-seconds. 

  • Fixed Issue 92481: If a WAN interface on a VMware SD-WAN Edge is deactivated on the VMware SASE Orchestrator, SNMP will still report the interface as ‘UP’.

    The key debug process for interfaces output does not include the physical port details for Edge WAN interfaces (for example, GE3 or GE4 on an Edge 6x0 or 3x00 model). As a result when SNMP polls those interfaces it always returns a result of UP regardless of how these interfaces are configured.

  • Fixed Issue 93141: On a site deployed with a High Availability topology, a customer using an L2 switch upstream of the HA Edge pair may observe in the switch logs evidence of an L2 traffic loop, though there is no actual loop.

    The issue is the result of the HA Edge sending the HA interface heartbeat with the Virtual MAC address to the Orchestrator instead of the interface's actual MAC address, which is caused by the HA Edge storing the Virtual MAC address in its MAC file. As a result, the connected L2 switch detects traffic from the same source MAC coming from two different Edge interfaces and logs it as an L2 loop. This issue is cosmetic at the log level as there is no actual L2 loop and there is no customer traffic disruption or loss of contact with the Orchestrator arising from this issue. As a result, there is no customer impact and the customer can ignore L2 loop detection events from upstream switches that arise out of the Edge's HA interface (usually GE1).

  • Fixed Issue 93965: A VMware SD-WAN Edge may experience a Dataplane Service failure, generate a core, and restart to recover.

    Checking a core reveals that the Edge service exited with a SIGXCPU signal. The Edge operating system has a Unix socket used as a queue for interface event communication between threads. The issue is caused by the socket depth being too small which leads to thread blocking and results in the SIGXCPU signal being raised.

  • Fixed Issue 95399: When the routed interface of a VMware SD-WAN Edge is physically plugged or unplugged, the user does not observe an Edge Interface Up or Interface Down event on the VMware SASE Orchestrator.

    The issue is traced to the dhclient first added to Edge Release 4.5.1 and included in every build (5.0.x, 5.1.x) forward. Dhclient was not configured to send interface up and down events to the Orchestrator.

  • Fixed Issue 95565: On a site using a High Availability topology, the VMware SD-WAN Active Edge may experience a Dataplane Service failure with a core generated and triggering a High Availability failover.

    The issue is triggered by the Active Edge's WAN links flapping one or more times (going down and then come up rapidly) while also using SNMP where there are frequent SNMP queries. There is a timing issue where the interface coming back up and the SNMP query together can trigger a deadlock which causes the Dataplane Service to fail and generate a core. While only a single WAN link flap can cause this issue, the greater the frequency of WAN link flaps, the greater the potential for this issue to occur.

    On an HA Edge pair that experiences this issue and does not have the fix, the workaround is to disable SNMP as this is a timing issue and this reduces the risk.

  • Fixed Issue 95950: When a user configures a VMware SD-WAN Edge's interface settings when there are 128 segments configured, the Edge may experience a Dataplane Service failure, generate a core, and restart.

    When the Edge is configured with 128 segments, the iptable rule application takes too much time to complete and this leads to a mutex monitor exception and the Edge service failure.

  • Fixed Issue 95850: On a customer enterprise where OSPF is used, when a user generates a diagnostic bundle for a VMware SD-WAN Edge, the OSPF routes may flap during the bundle generation resulting in disrupted customer traffic.

    As part of the diagnostic bundle generation the commands vcdbgdump -r remote-routes and vcdbgdump -r remote_routes are run. As these commands take more than 40 seconds in a customer environment, the OSPF hellos that were queued to the event dispatcher thread were not processed. Due to this, the OSPF neighborship flaps, causing a network outage.

    On an Edge without a fix for this issue a customer should either not generate a diagnostic bundle except in a maintenance window, or reach out to VMware SD-WAN Support to generate the bundle as they have internal tools to prevent the issue from occurring on a temporary basis.

  • Fixed Issue 96710: When a customer site is configured with a High Availability topology and Loss of Signal (LOS) Detection is turned on for the HA Edge interfaces, when connectivity is lost on the Active Edge interfaces and it is demoted to Standby and the interface connectivity is later restored, the Standby Edge does not detect the restored connectivity.

    When an Edge becomes Standby due to LOS being detected on an interface when it was Active, even if connectivity is restored after some time when the Edge is in standby state, SD-WAN is cannot detect connectivity restored since LOS monitoring cannot be done on the Standby edge. The interface is still considered down according to the last known LOS state.

    On an HA Edge without this fix, a forced HA failover would cause the Standby (now Active) Edge to ARP probe its interfaces for restored connectivity.

  • Fixed Issue 97559: On a customer site deployed with an Enhanced High-Availability topology, a WAN link connected to the VMware SD-WAN Edge in a Standby role may show as down on the VMware SASE Orchestrator and not pass customer traffic even though the Edge's WAN interface where the WAN link is connected is up.

    A user looking at a tcpdump or diagnostic bundle logging would observe ARP requests coming in and the Standby Edge not responding as a result of its port being blocked. In Enhanced HA, when an Edge assumes the role of Standby, the following events should occur in sequence:

    1. The Standby Edge blocks all ports.

    2. The Standby Edge then detects that it is deployed in Enhanced HA and unblocks its WAN ports to pass traffic.

    When this issue occurs, Event 1, the initial port blocking takes an unexpectedly long time to complete and the follow-up Event 2, the unblocking of all WAN ports is completed prior to the completion of Event 1. And then Event 1 completes and thus the final state is all WAN ports are blocked on the Standby Edge.

    On an HA Edge without a fix for this issue, the workaround is to force an HA failover that promotes the Standby Edge to Active brings up the HA Edge's WAN link(s).

  • Fixed Issue 97953: An Operator or Partner user does not have the option to clear the ARP cache on a VMware SD-WAN Gateway.

    On Gateway's using Release 5.2.0 or later, a user has the option to use the command debug.py --clear_arp_cache to clear its ARP cache.

  • Fixed Issue 98223: When Edge Network Intelligence Analytics is activated on a VMware SD-WAN Edge, the Edge may lose contact with the VMware SASE Orchestrator and cause the Orchestrator to mark the Edge as down on the Orchestrator UI.

    When Analytics is activated, the Edge communication with the Analytics backend sometimes gets mixed with the Edge communication with the Orchestrator. This results in a loss of communication with the Orchestrator which causes the Orchestrator to declare that the Edge is down when it is not.

  • Fixed Issue 98359: If a customer turns on Loss of Signal (LoS) detection for an Edge interface that also uses a subinterface, LOS does not detect connectivity failures on the subinterface.

    In prior releases, LoS detection support is not supported for subinterfaces and because of that connectivity loss on subinterfaces is not detected.

  • Fixed Issue 98634: When looking at Edge > Monitor > Transport for an Edge with multiple links, a user may observe a discrepancy in the link metrics between the two links.

    This issue is sourced to a WAN link's logical ID being duplicated across multiple Edges which results in inaccurate statistics for that link.

  • Fixed Issue 98694: When a customer enterprise is configured with redundant static routes, if the primary route goes down, the alternate route(s) is not advertised, and traffic is dropped.

    When an interface goes down on a VMware SD-WAN Edge, the alternate routes are not advertised to the VMware SD-WAN Gateway even though the routes via the interface are now unreachable. Routes for the prefix will not be present in the Gateway even though there are alternate routes through other interfaces for those prefixes on the Edge. The issue is because the SD-WAN service sends a route delete without checking if there is an alternate reachable static route while handling an interface down.

  • Fixed Issue 99193: For a VMware SD-WAN Edge which is configured as a Spoke Edge and actively uses IPv6, if this Edge is running Release 5.x and is downgraded to Release 4.5.x or lower, the IPv6 traffic destined for the Spoke Edge is dropped and if there are alternate IPv6 routes, traffic does not take them but continues to go towards the downgraded Spoke Edge where they are dropped, leading to packet loss.

    When a Spoke Edge downgrades from 5.x to 4.5.x or below and goes down, the Hub Edge removes the IPv6 routes with next-hop as that Spoke Edge from the Forwarding Information Base (FIB) but retains them in the Routing Information Base (RIB). Later when the downgraded Spoke Edge comes up, the Hub restores the IPv6 routes in the FIB as well causing traffic for these prefixes to go to the Spoke Edge and get dropped there. This issue persists until a stale refresh timer kicks in and flushes the v6 routes after 5 minutes.

  • Fixed Issue 99215: On VMware SD-WAN Edge models 610, 620, 640, and 680, when the user deactivates the SFP1 interface or configures it as switched, the SFP2 interface may stop receiving packets.

    On these Edge models, the SFP2 interface may stop receiving packets if SFP1 is configured as routed and the user chooses to either deactivate SFP1 or reconfigure SFP1 as switched.

  • Fixed Issue 100005: VMware SD-WAN Edge model 610 or 610-LTE returns incorrect value for ifSpeed - OID 1.3.6.1.2.1.2.2.1.5.

    When queried for interface speed, an Edge model 610 returns an incorrect value because the DPDK AF_PACKET driver has a hardcoded speed of 10G.

  • Fixed Issue 100010: For a VMware SD-WAN Edge which is deployed with private WAN links that are configured for both IPv4 and IPv6, when a user generates a diagnostic bundle or runs the Remote Diagnostic "List Paths" the Edge may experience a memory leak.

    When traffic is run through private links, SD-WAN first checks if the IPv4 address is configured and if so the value is saved to JSON and again SD-WAN checks if IPv6 address is configured. And if there is an IPv6 address, SD-WAN overwrites the previously stored value before appending it to the JSON array which leads to a memory leak. The greater the scale of traffic being processed by the Edge, the greater the leak of memory when the triggering actions are performed.

  • Fixed Issue 100172: A VMware SD-WAN Gateway may experience a Dataplane Service failure, generate a core, and restart to recover.

    The user can encounter this issue if they are using SSH to access an Edge via the Gateway and that SSH session generates a FRAG_NEEDED ICMP error message. Since the Gateway received the packet through local gwd1 interface, pkt_in->skb->vc_sk->raw is NULL and triggers the service failure and core.

  • Fixed Issue 100237: For a customer enterprise where a Partner Gateway is used and the PG advertises a secure default route to a VMware SD-WAN Gateway, a client user may experience a failure to download a file direct from the Internet.

    The full scenario includes the Edge using multiple WAN links, having "Secure Default Route Override" configured, and a Business Policy created where the Network Service parameter is set to Direct. In this scenario the flow for traffic using this Business Policy can choose a different WAN IP address each time alternatively and a download would fail.

    Without a fix for this issue, the user must configure the Business Policy to limit all traffic to one WAN link by marking it as Mandatory.

  • Fixed Issue 100359: When an OSPFv2 outbound filter is configured to drop a summary route, the Edge continues to advertise those routes.

    OSPFv2 routes are advertised even after configuring 'Ignore' under the "Route Advertisement" for OSPF under a particular interface.

  • Fixed Issue 101102: When a VMware SD-WAN Edge that is initially assigned to a Hosted Gateway is reassigned to a Partner Gateway, SSH to the Edge through the Gateway stops working.

    When reassigned to a Partner Gateway, the Edge loses the vce1 IP address and as a result ssh through the Gateway does not work.

    On an Edge without a fix for this issue, a user initiated Edge Service restart remediates the issue.

  • Fixed Issue 101144: A VMware SD-WAN Gateway may experience packet leaks when there are out of order packets.

    These leaks can be observed when running vcdbgdump -r dpdk-leak-dump and the leaks are located at pkt_path_alloc and pkt_path_ooo. The packets are stuck in the VCMP reseq ring queue and are not processed.

  • Fixed Issue 101753: A VMware SD-WAN Edge may appear offline on their VMware SASE Orchestrator even though they are up and passing traffic.

    The issue occurs because the Edge continue to source traffic to the Orchestrator from an IP address that is no longer available, so the return traffic is dropped as a result.

  • Fixed Issue 102607: A VMware SD-WAN Edge may experience a Dataplane Service failure if it is using a Non SD-WAN Destination via Gateway or Edge and BGP over NSD is also configured.

    Issue can be encountered when an NSD datacenter route and an Edge-to-Edge route use the same prefix. In this scenario, the packets destined and encrypted for the DC can reach the SD-WAN management tunnels and this can cause a memory leak or even a service failure.

  • Fixed Issue 102655: For a customer enterprise where BGP is used for routing, BGP on a non-global segment does not come up on an Edge's subinterface.

    Issue is triggered if the Edge's main interface on the global segment and a suberinterface on a non-global segment have the same IP address where a WAN overlay is also configured on the main interface. The issue of BGP not coming up is more likely encountered after an Edge reboot or service restart.

    On an Edge without a fix for this issue, remove the subinterface IP address and BGP related configuration and reconfigure with a unique IP address.

  • Fixed Issue 102693: On a site configured with a High Availability topology, when a user attempts to determine what software version and factory build the VMware SD-WAN HA Edges are using, those fields may show as empty on the VMware SASE Orchestrator.

    When HA is activated for a pair of Edges, the Edges may not send the factory software and build versions to the Orchestrator on the initial heartbeat and as a result the Orchestrator cannot display them.

  • Fixed Issue 103558: On a customer enterprise using Edge Network Intelligence, when Analytics is activated for a VMware SD-WAN Edge the ENI dashboard may display "No Management IP Assigned" for that Edge.

    When Analytics is enabled, in rare cases the Edge does not send the Management IP address to the Edge Network Intelligence back-end.

  • Fixed Issue 103700: Applications in an Application Map configured with a mustNotPerformDpi (Deep Packet Inspection (DPI) should not be done) may still get their classification via DPI where the customer has a large scale deployment.

    An application incorrectly classified can result in client users being unable to access the application or website.

    In a large scale customer enterprise with ~8K entries in the application classification fast database cache, collisions can occur while looking up an application. In the event of a collision, although an application is configured with mustNotperformDpi, it will still be classified via DPI.

    On an Enterprise without a fix for this issue, the workaround is to configure a Business Policy where the subnets for the application or domain are used to steer traffic via Direct or Internet Backhaul.

  • Fixed Issue 103708: When new rules are added in a BGP filter configuration, there may be unexpected BGP routes received and sent by the VMware SD-WAN Edge.

    When new rules are added to the BGP filters from the Orchestrator, the prefix lists are added in the Edge's routing configuration without removing the old entries. This behavior results in stale route prefix lists and unexpected filtering behavior.

  • Fixed Issue 103962: The IPv6 and IPv4 connected routes redistributed into OSPFv3 or BGPv6 have different metrics, which can result in different routing for IPv6 traffic versus IPv4.

    Currently the IPv6 connected routes corresponding to a routed interface are installed with a different metric than IPv4 connected routes on the same interface. This is because of the different metrics given by the Edge OS kernel for IPv4 and IPv6 routes. When they are redistributed into dynamic protocols like OSPF/BGP this difference in the IPv4/IPv6 metrics is propagated.

  • Fixed Issue 104046: For a customer site deployed with a High Availability topology, the VMware SASE Orchestrator may display the Standby Edge as up when it is actually down.

    The scenarios where this happens are when either the HA Interface cable is disconnected between the HA Edges, or the Standby Edge is powered down. The issue is caused by the HA Active Edge sending an Active status when the Standby Edge is down due to a check by the Active Edge's management process that refers only to whether HA is configured while ignoring the actual status of the Standby Edge.

  • Fixed Issue 104513: For an enterprise connected to a Partner Gateway using BGP and which deploys ICMP probes, if an ICMP probe goes down, client users may observe that traffic drops and does not recover.

    When an ICMP probe goes down, the Partner Gateway BGP routes reachability status becomes false and all traffic using those routes will fail. The issue is the result of the Gateway checking all PG handoff routes for ICMP probe status, including BGP routes. If an ICMP probe status is down, the PG is also marking BGP routes as down.

    On a Gateway without a fix for this issue, the only workaround is to deactivate ICMP probes. However, this has the potential to disrupt other customers using the same Partner Gateway and should only be done with that caveat.

  • Fixed Issue 105433: For a site using an Enhanced High Availability topology, the VMware SD-WAN HA Edges may go offline with the VMware SASE Orchestrator if a WAN interface on the Standby Edge flaps.

    The Standby Edge is not synchronizing the dynamic IP Address update to the Active Edge when the interface state is changed and due to this connectivity between the HA Edge site and the Orchestrator fails. This only affects management traffic and does not affect customer traffic.

  • Fixed Issue 105440: When the Data Type for DHCP Option 43 is set to "Text" and the "Value" is configured as a text string that begins with a numeral, the option is ignored, and an error is reported.

    A typical example of this issue is for the Option 43 Value is configured as an IP address. The user sees an Event with a message "messages" : "dhcp.py:527: Invalid value for option 43: <text string configured>, ignored".

  • Fixed Issue 105492: IPv6 based L2 packets not destined for a VMware SD-WAN Edge's L2 MAC address are processed unnecessarily instead of being dropped.

    The expectation is that IPv6 packets unicast to a destination MAC that does not match the Edge's interface MAC should be dropped.

  • Fixed Issue 105686: Upgrading a VMware SD-WAN Gateway on 82599 SR-IOV to Gateway build 5.0.1.2 does not bring up the SR-IOV NIC interfaces.

    The ixgbevf driver was not available on the Gateway build running kernel 4.15.0-201-generic. The Ubuntu kernel security roll-ups (starting from version 4.15.0.159) have backports from the mainline kernel and now skb_frag_off is available in the kernel header, so ixgbevf driver's own skb_frag_off definition is not needed.

    Operators should not upgrade a Gateway release 5.0.1.2 if 82599 SRIOV interfaces are used.

  • Fixed Issue 105933: A user cannot SSH to VMware SD-WAN Edge models 610/610-LTE or 520/540 via a routed interface.

    There is no drop rule for duplicate SSH packets which originate via an af-pkt driver used by the affected Edge's OS. Because of this the Edge kernel receives 2 SSH packets: one via the vce1 interface, and another direct SSH packet because of the nature of the driver. This causes the Edge kernel to reply for 2 SSH requests, confusing the SSH client and results in the SSH failure.

    For an Edge without a fix for this issue, the user can add an IP table rule to drop the SSH packets received from interfaces other than vce1.

  • Fixed Issue 106017: When deploying a VMware SD-WAN Gateway OVA on vSphere, customers may encounter a warning that VMware Tools is not installed on the VM when in fact it is.

    The full message reads: "Tools is not installed in the GuestOS. Please install the latest version of open-vm-tools or VMware Tools to enable GuestCustomization." The message is spurious as the tools are in fact installed on the Gateway image, but the version attribute is missing, which triggers the error. No configuration functionality is impacted by this false error message.

  • Fixed Issue 106123: VMware SD-WAN may misclassify packets due to the DPI (Deep Packet Inspection) Engine not being the most current build.

    When an Edge or Gateway misclassifies a packet, this can lead to numerous issues for SD-WAN customers. The fix upgrades the Edge and Gateway's DPI engine to the most current build which ensures that the SD-WAN service is classifying customer traffic at a higher level of accuracy.

  • Fixed Issue 106225: Connected and static routes related to a subinterface are purged from remote VMware SD-WAN Edges when the WAN link goes down.

    While advertising connected routes for subinterfaces, SD-WAN uses the subinterface id in place of an array index. This causes checking for an advertise flag at the wrong interface. As a result, add/del events on interface flaps are missing for remote nodes.

    On an Edge without a fix for this issue, the customer should configure Advertise on all interfaces to prevent this issue.

  • Fixed Issue 106289: A VMware SD-WAN Hub Edge may drop packets on flows to connected Spoke Edges or backhaul flows.

    The Backhaul flow flag is set during the QoS synchronization process, there is a place in the code where it sets it during flow creation. The Edge should set this flag only as a result of QoS synchronization message processing.

    Should this issue be encountered on a Hub Edge without a fix, flush the flows on the Hub Edge to temporarily remediate the issue.

  • Fixed Issue 106331: For an enterprise connected to a Partner Gateway using BGP and which deploys ICMP probes, if an ICMP probe goes down on the Partner Gateway, client users may observe that traffic drops and does not recover.

    The issue is the result of the VMware SD-WAN Edge checking not only PG static handoff routes for ICMP probe status, but also BGP routes. And if a probe status is down, the Edge marks both the static handoff route and the BGP routes as down with a resulting disruption in customer traffic.

  • Fixed Issue 106913: Hub external routes are not advertised to a Non SD-WAN Destination via Gateway via BGP on a VMware SD-WAN Gateway.

    This issue is the result of an inherited behavior from BGP on a Partner Gateway. It was intentional for Handoff BGP to avoid redistributing OSPF HUB external routes into a PG BGP to avoid a loop and NSD BGP inherited this behavior from the PG BGP.

  • Fixed Issue 107114: When a VMware SD-WAN Edge's serial console is deactivated from the Firewall settings on the VMware SASE Orchestrator, a user can continue to see routine messages on the serial console.

    SD-WAN is not suppressing the routine messages from the console even when the serial console is deactivated from the Orchestrator. The fix here ensures the Edge only prints critical messages (CRIT, ALERT, EMERG) on the serial console when it is deactivated from the Firewall settings.

  • Fixed Issue 107216: When running the Remote Diagnostic "Interface Status", the output displays an inaccurate link speed.

    When an interface is selected for autonegotiate 'off', the interface is no longer running under DPDK with a silicon driver. The new driver in use for DPDK is 'af_packet' which leverages the underlying kernel driver. The new manual speed is not set after a PCI unbind from DPDK back to the kernel. As a result the link speed when running the ethtool debug command used by Interface Status, the result is inaccurate.

  • Fixed Issue 107309: When a customer configures the L7 Health Check for a Non SD-WAN Destination via Edge on a 4.x Orchestrator and the Orchestrator is upgraded to Release 5.x, if the customer attempts to modify the L7 probe retry value, the Edge does not apply the new value.

    For example, if the L7 Health Check probe retry value is 3 (the tunnel is marked as down on 3 failed probes) and the customer changes this value to 1, the L7 Health Check continues to use the original value of 3 retries before the tunnel is marked down.

  • Fixed Issue 107317: For a customer using SNMP where the server is located in the internet, an SNMP walk may succeed for some VMware SD-WAN Edge interfaces and fail with a timeout on other interfaces.

    When the SNMP walk fails the SNMP request enters one interface but exits a different interface and these response packets never reach the SNMP server. The issue is caused by the Edge incorrectly classifying SNMP traffic such that it steers these packets to a different interface for response packets regardless of the interface used for reception and so while SNMP walks work for the interface the Edge designates for SNMP response, it fails for all the others.

  • Fixed Issue 107708: On a VMware SD-WAN Edge where the SD-WAN Overlay Rate Limit is configured, the SD-WAN Gateway may not adhere to the limit exactly when downstream traffic flows from the internet to the Edge.

    Traffic flowing from the Internet to the Edge is not rate limited by the Gateway exactly as configured. The SD-WAN Overlay Limit is exceeded by a few Mbps. This happens as the VCMP (management) overhead is not taken into account in the Gateway for calculating the rate limit.

  • Fixed Issue 107994: When privileged Secure Edge Access users are provisioned, High Availability related operations, like running the Remote Diagnostic "HA Info" from the Orchestrator, and logging into the peer HA Edge fail.

    When privileged secure Edge access users are provisioned, the root account is completely blocked. The problem with this is that HA operations rely on communicating with the peer Edge as root. This causes any HA operations performed after the fact to not work.

    On a pair of HA Edges without a fix for this issue, the customer would need to switch back to password-based authentication and delete all privileged Secure Access Edge users OR change them to basic users.

  • Fixed Issue 108374: For a customer enterprise that uses Dynamic Branch-to-Branch and has configured LAN-Side NAT Rules, a route change may cause traffic to a remote LAN to fail.

    On a route change, such as Dynamic Branch-to-Branch tunnels, LAN-Side NAT may not be properly recalculated for existing flows and this causes them to break, impacting traffic destined for a peer Edge LAN subnet.

  • Fixed Issue 108473: A VMware SD-WAN Gateway may experience a Dataplane Service failure, generate a core, and restart to recover service.

    The Gateway can get into a situation where there is a sequence number overflow, and this triggers a deletion of all SAs (IPsec security associations). When trying to delete all SAs, the Gateway process tries to find a tunnel based on a tunnel ID, but the tunnel does not exist, and this causes a Gateway service failure.

  • Fixed Issue 108610: For a customer enterprise where Firewall is turned on, when an Edge is upgraded from a 3.x Release to a 4.x Release, the Firewall blocks traffic that was not previously being blocked.

    When the Orchestrator is moved to 4.2.2 in the following sequence: 3.4.4 to 4.0.0 to 4.0.2 to 4.2.2, the Address Group configuration is not reflecting on Edges connected to that Orchestrator that are from a 3.4.4 Edge Release to 4.2.2 Edge Release This is because the Edge expects a different version of the address groups JSON file in 3.4.4 and 4.2.2, the Orchestrator which upgraded in the above sequence does not send the JSON files to the Edges in the new format until there is a configuration change. As a result, address groups configurations do not work.

  • Fixed Issue 108982: For a VMware SD-WAN Edge where ICMP Probes are configured, the customer may observe that the Edge Probes stop working with an INIT state.

    The ICMP probe timer can become corrupted which causes the probe state machine to be stuck in INIT state. The timer corruption is due to a race condition when multiple threads are trying to add/remove/expire the timer.

  • Fixed Issue 109500: When LAN side NAT uses the same inside and outside definition, the first packet of a direct flow is dropped.

    The issue is that the match information in the original NAT table is the same for the initial LAN Side NAT translation and for the direct NAT translation. This causes a conflict in the tables which drops the first packet.

  • Fixed Issue 109511: When the max tunnel count is encountered by a VMware SD-WAN Edge, the EDGE_TUNNEL_CAP_WARNING Event may not be seen on the VMware SASE Orchestrator.

    The Edge is not sending a message to the Orchestrator for a tunnel cap warning when the issue happens for the first time within a 24 hour period.

  • Fixed Issue 109963: A user cannot SSH into a VMware SD-WAN Virtual Edge.

    All Virtual Edge types (Azure, AWS, and so forth) are affected by this issue. When an SSH attempt is made, the Virtual Edge receives two SSH packets and this causes the Edge kernel to reply for two SSH requests, confusing the SSH client and results in the SSH failure.

  • Fixed Issue 110406: For a customer site deployed with a High Availability topology, if the HA Edge pair are downgraded to an earlier software version, the Active Edge may not complete the downgrade.

    When encountering this issue, only the Standby Edge successfully downgrades to the specified software version while the Active Edge never downgrades, which means the site is effectively a standalone site and no longer HA.

    On an HA site where this issue is encountered without a fix, the workaround is to deactivate HA, downgrade the previous Active Edge as a Standalone, and then reactivate HA with both Edges now on the same downgraded version.

  • Fixed Issue 110456: ICMP probe from a Partner Gateway or Cloud Gateway to a directly attached device may drop packets if the ICMP request code field is not 0.

    Depending on the vendor, some may inspect the code field for an ICMP request packet and deem it not correct if the field is not 0.

  • Fixed Issue 110473: For a customer enterprise using BGP, unexpected routes are received/sent momentarily and flows may match wrong Business Policies, when a BGP neighbor is removed.

    When a BGP neighbor is removed from the Orchestrator, the inbound/outbound route-maps associated with it are removed first and then the neighbor is removed from the Edge routing configuration. This leads to a momentary leak of routes denied by those route-maps. This in turn affects the business policy behavior if a flow is created with the leaked routes.

    On an Edge without a fix for this issue, a user can run the Remote Diagnostic "Flush Flows" to remediate the issue.

  • Fixed Issue 110484: A customer may observe an incorrect path status on the Edge > Monitor > Paths page of the Orchestrator if the path is associated with a WAN link where Path MTU discovery has been turned off.

    The customer may also observe two different path statuses for the same path when checking Monitor > Paths for the Edge endpoints for that path. This behaviour is the result of the the Path MTU discovery link configuration not functioning as expected with respect to auto-discovered WAN overlays. This configuration is typically processed in the configuration update function, as the Edge triggers the link configuration for the Orchestrator with these kinds of links. However, the PMTU configuration update is missing during the update call, leading to this issue.

    Note:

    The symptoms for this issue are not resolved for this ticket and a customer may encounter them as outlined above. A build that includes this ticket adds logging enhancements that help Engineeering deliver an actual fix.

  • Fixed Issue 110564: For a customer site deployed in a High Availability topology, the TCP session used to synchronize data between the Active and Standby Edge may go down. On an Enhanced HA deployment, this results in WAN link traffic is not forwarded on the Standby Edge.

    For either Standard HA or Enhanced HA deployments, there could be a scenario where a child process is using the port intended for TCP sessions between the Active and Standby Edge. In this scenario, the Active Edge cannot bring up the TCP server due to bind errors, and results in the Standby Edge's interface state not being exchanged. For Enhanced HA deployments, the result is that WAN link(s) cannot be used for forwarding traffic.

  • Fixed Issue 111073: A VMware SD-WAN Edge using Release 4.5.1 may report the wrong interface speed to SNMP.

    ifSpeed is a 32-bit value and if it cannot accommodate the value of the speed given by the Edge in bits per second (bps), then it is advised to refer to ifHighSpeed which gives the value in Mbps.

  • Fixed Issue 111162: In a customer enterprise which uses a Partner Gateway and deploys Edges in High Availability, an HA Edge may have suboptimal routing when a PG route through a secondary Partner Gateway is selected as the best route.

    In the HA Edge, when there are A-A or A-S transitions there is a chance that the order for a PG route from a secondary Partner Gateway is set to 4 thereby becoming the best route. Usually primary Partner Gateway routes have higher order values.

  • Fixed Issue 111314: On a customer enterprise where Dynamic Cost Calculation is activated, traffic drops may be observed.

    This issue can occur if one of the Edges advertises more specific routes to all Edges in the enterprise before going offline. One this Edge is offline, the routes remained in all the other edges FIB (forwarding information base) with Reachability = False, and this results in packet drops.

    On an Edge without a fix for this issue, a user can remediate the issue by manually initiating an Edge Service restart through the Remote Actions menu on the Orchestrator.

  • Fixed Issue 111646: A VMware SD-WAN Gateway under a high CPU load may experience a Dataplane Service failure and restart to recover.

    A user looking in the Gateway generated core would see mutex monitor exception and the message Program terminated with signal SIGXCPU, CPU time limit exceeded message. The issue is related to a Gateway process releasing a lower priority thread lock.

  • Fixed Issue 111840: For a customer enterprise using more than 8 VMware SD-WAN Edges configured as Hubs, users may observe poor traffic performance due to sub-optimal routing.

    When a Spoke Edge is configured with multiple Hub Edges, the route via the Hub is getting preferred over a Branch-to-Branch direct route leading to sub-optimal routing.

    On Edges without a fix for this issue, the customer can configure the Hub Edges first followed by the VPN Hub Edges in the Branch to Hub site list.

    Important:

    As part of the fix for this issue, the BGP MED value advertised by Hub Edges, which previously started from 9, 10, 11, and so forth, now starts from 33, 34, 35, and so forth.

  • Fixed Issue 111888: A VMware SD-WAN Gateway deployed with 4 cores and greater than 2000 tunnels connected to it may experience high CPU usage and tunnels connected to the Gateway may be unstable.

    One of the Gateway threads is utilizing too much CPU capacity in a 4 core Gateway which is hindering the Gateway's ability to maintain stable tunnels.

  • Fixed Issue 111924: A customer may observe that across all their sites Multi-Path traffic (in other words, traffic that traverses the VMware SD-WAN Gateway) is being dropped even though their VMware SD-WAN Edge's tunnels to the Gateway are up and stable.

    There is no limit on the maximum number of times a Gateway can retransmit a VCMP packet (SD-WAN's management protocol), and such retransmits can overwhelm low bandwidth links. These retransmits will also cause packet build-up on the scheduler when the Edge has a low bandwidth link since the retransmits cannot be drained fast enough. Eventually the scheduler queues become full and lead to the scheduler dropping packets from all Edges. Direct traffic that does not use the Gateway would not be affected by this issue.

    When this issue encountered on a Gateway without a fix for this issue, the only way to remediate is for an Operator user to identify the Edges which are causing the packet build-up on the scheduler using the debug.py --qos_dump_net command and block them in the affected Gateway.

  • Fixed Issue 111935: A VMware SD-WAN Edge configured as a Hub may not learn routes from a remote site.

    When two Edges are pointing at each other as Hubs, there is a possibility one of them will learn the routes of the other Edge.

    On Edges without a fix for this issue, a customer can work around this issue by breaking the mesh Hub configuration and have all the Hub Edges in one Profile with just Cloud VPN activated.

  • Fixed Issue 112016: A VMware SD-WAN Gateway may experience multiple Dataplane Service failures with generated cores after a Gateway restart is initiated.

    When examining the cores an Operator would observe that each failure is triggered by a mutex monitor issue. There is a noticeable time increase in VCMP (SD-WAN's management protocol) processing done for the thread managing it. During a Gateway start, this leads to the VCMP thread continuously running at 100% for long durations (more than 60 seconds) leading to multiple mutex monitor related Gateway service failures.

  • Fixed Issue 112017: An Operator may observe that a VMware SD-WAN Gateway deployed with 4 cores experiences high load which leads to one or more a Dataplane Service failures.

     The Gateway core logs would point to the mutex monitor triggering the service failure. There are several tickets that address the above symptom, and in this case the cause stems from VCMP (management protocol) threads maxing out a 4 core Gateway's CPU processes, which triggers the mutex monitor. This ticket adds the ability to allow an Operator user to configure a VCMP half-open connection limit of 20. This can be done either through the Gateway's command line interface (CLI) using debug.py, or by a static configuration file.

  • Fixed Issue 112019: A VMware SD-WAN Gateway may experience a Dataplane Service failure and restart to recover under high CPU load.

    As with other Gateway service failure tickets in the 5.1.0.3 rollup build, the Operator or Partner would observe a mutex monitor trigger in the core file. With this ticket, the remediation is to move the NAT debug logs outside of the NAT table lock scope to prevent one of the causes for this issue.

  • Fixed Issue 112020: A VMware SD-WAN Gateway deployed with 4 cores which is under a high CPU load may experience a Dataplane Service failure and restart as a result.

    Looking in the Gateway core file a user would observe a mutex monitor failure caused by a Gateway process not being able to run because the CPU is running at maximum capacity because of a high tunnel count.

  • Fixed Issue 112452: A customer may observe that a VMware SD-WAN Edge configures for High Availability is experiencing L2 loops on the Edge's WAN interfaces.

    When an interface is moved from switched to routed, an issue is seen with the MAC address in the origmacs file. If a virtual MAC address is stored for an interface or if there is no original MAC address for the interface stored in the file, the Edge uses the virtual MAC address to send out WAN heartbeats leading to a L2 loop being detected.

    On an HA Edge without a fix for this issue, the workaround is to have Support delete the origmacs file and then reboot first the Standby HA Edge, and then the Active HA Edge.

  • Fixed Issue 112800: Customers using a VMware SD-WAN Gateway may experience poor performance including tunnels and routes taking far longer to converge.

    When looking at the monitoring for a Gateway, a user would observe the data plane cores (dp-cores) running at 100% as a result the Gateway failing to flush stale flow dispatcher flows.

  • Fixed Issue 112882: When a VMware SD-WAN Edge is upgraded to Release 5.1.0.3, SNMP may stop working on the Edge.

    Any changes to the entries SNMP segnat table were not having corresponding "Update" API invocation. This was leading to a corresponding destination IP address/port getting stuck.

  • Fixed Issue 113153: For a customer enterprise deployed with a High Availability topology, the VMware SD-WAN Edge in the Active role may experience a Dataplane Service failure which will trigger an HA failover, when the Standby Edge is restarted or rebooted.

    When the Active Edge experiences a Dataplane Service failure will also trigger an HA failover. The issue can be encountered when the HA site is forwarding a large amount of traffic.

  • Fixed Issue 114004: A customer may observe that a VMware SD-WAN Edge experiences a memory leak if SNMP is configured on the Edge.

    The Edge memory leak is slow but if it is not addressed it will reach a critical level of memory usage that results in the Edge defensively triggering a service restart to clear the memory. This restart can disrupt customer traffic for 15-30 seconds while the Edge recovers and without a fix for this issue, the memory leak will simply start over.

  • Fixed Issue 114052: A VMware SD-WAN Gateway may experience a Dataplane Service failure, generate a core, and restart as a result.

    The issue is caused by a thread in the Gateway's IPsec process timing out and triggering a Gateway service failure.

  • Fixed Issue 114084: For a customer who has configured a Zscaler-type Cloud Security Service (CSS) with L7 Health Check for a VMware SD-WAN Edge, when updating the Zscaler Cloud Server on the VMware SASE Orchestrator, the updated details are not applied to the Edge.

    Despite the Orchestrator showing the new Zscaler Cloud Server configuration, the Edge and Gateway do not send either traffic or the L7 probes through this new server but the old Zscaler server.

  • Fixed Issue 114282: When a VMware SD-WAN Gateway deployed with 4 cores is restarted, it may take up to twenty minutes to converge ~3000 tunnels for the connected customer enterprises.

    The expectation is for a Gateway to converge ~3000 tunnels in ~5 minutes versus the twenty minutes observed in this issue. The slower rate would cause customer traffic disruption until the tunnels were fully restored. The cause of the slower convergence is traced to a configuration in the Gateway's IPsec process which manages security associations and keys that is corrected with this ticket.

  • Fixed Issue 114511: For an auto-discovered WAN link, unchecking the Path MTU Discovery option does not work, and the Edge continues to implement the feature and resize the MTU.

    The configuration is processed during an update for auto-discovered links and this specific configuration for Path MTU was not processed during the configuration update.

  • Fixed Issue 114932: Users may experience degraded traffic performance when connected to a VMware SD-WAN Gateway.

    Operator Users can observe high CPU Utilization for the Gateway even though the tunnel count is within supported limits. The high CPU utilization arises from a stale IKE SA (security association) staying for a longer time in the IKE table and results in tunnels taking a longer time to converge and this causes increased traffic drops and path instability for customer traffic traversing the Gateway.

  • Fixed Issue 115078: On a large scale customer enterprise with ~16K users and a flow creation rate of ~2K per second on Hub Edges, users can experience poor traffic quality due to high latency.

    The Gateway's Deep Packet Inspection (DPI) engine can be overloaded on Hub Edges when a high number of peer initiated flows are created. This is due to the port cache being populated with Source IP address and port # instead of the Destination IP address and port # for these peer flows.

  • Fixed Issue 115132: For a VMware SD-WAN Edge using Edge Release 5.1.0.2, if a user runs the Remote Diagnostic "NAT Table Dump", the result may be empty values.

    This issue prevents users from debugging NAT issues on Edges using the 5.1.0.2 Release. Edges using earlier releases work as expected.

  • Fixed Issue 115692: An Operator may observe escalating memory usage in a VMware SD-WAN Gateway which can lead to memory exhaustion and a defensive service restart to clear the memory.

    In this instance the Gateway is experiencing an IKE memory leak from the Gateway renewing certificates with peer sites.

    Without a fix for this issue, the Operator can only monitor memory usage on the Gateway and proactively restart the Gateway in a maintenance window that ensures the least disruption to the customer sites using the Gateway.

  • Fixed Issue 116086: For a VMware SD-WAN Edge using a 5.0.x or 5.1.x version (either the factory image pre-activation, or a post-activation), when using the Local UI, the option to configure a routed interface with a VLAN ID is not present.

    This issue prevents a user from configuring a VLAN on a routed interface prior to the activation of the Edge if the Edge using a 5.0.x or 5.1.x factory image or if the Edge is activated and using any Edge Release in the 5.0.x or 5.1.x trains. Only a 5.2.0 or later factory image or later would have the fix for this prior to activation.

  • Fixed Issue 116182: A VMware SD-WAN Gateway may experience a Dataplane Service failure and generate a core and restart as a result.

    This issue is observed on Gateways where the connected SD-WAN Edges are configured with an internet backhaul policy using either IPv6 or IPv4/IPv6 Mixed-Mode to a Non SD-WAN Destination (NSD) via Gateway. In this scenario, when the Gateway receives IPv6 packets destined for an NSD using IPv4, this triggers the Gateway service to fail.

  • Fixed Issue 116589: When a VMware SD-WAN Edge is upgraded from Release 3.x to a 4.x or newer release, there may be cases where the configured address groups are not parsed.

    In release 3.x there is no configuration to set isakmpLifeMins and ipsecLifeMins. So when an Orchestrator is running 3.x it will send an Edge Property configuration file without isakmpLifeMins and ipsecLifeMins.

    When the Orchestrator is upgrade to 4.x+ it will have the fields isakmpLifeMins and ipsecLifeMins but this configuration is not pushed to the Edge 3.x Edge. If the Edge is also upgraded from 3.x to 4.x+ the Edge will start coming up with the last known good configuration (which does not include isakmpLifeMins and ipsecLifeMins).

    When the Edge comes up it will find out that isakmpLifeMins and ipsecLifeMins, which are mandatory parameters, are not present so it will stop processing the Edge property configuration file further meaning after this specific configuration none of the other configurations in these files like address groups will not be processed. As a result, the address group configuration is not present.

  • Fixed Issue 116641: VMware SD-WAN Edge logs contain route lookup failure logs with error reason as "None".

    When traffic is failing, sometimes customer may see route lookup failure logs with error reason as "None", which provides no value in troubleshooting the issue. The fix provides an actual reason which assists the user in troubleshooting the issue.

    For example, where previously the failure log would like this:

    20:40:41.796089,856|7|6825/10072|edged_ipv4_route_lookup_vcmp_transit:6880 Route lookup failure for tuple src_ip=10.0.1.25 dst_ip=169.254.6.18 segment_id=0 lookup failed due to [None]

    In Release 4.5.2 it looks like this (bold part is change):

    04:07:35.464563,968|7|9720/1917413|edged_ipv4_route_lookup_vcmp_transit:6958 Route lookup failure for tuple src_ip=10.0.1.25 dst_ip=169.254.6.18 segment_id=0 sroute=(nil) droute=(nil) lookup failed due to [No src and dst route]

Orchestrator Resolved Issues

Resolved in Orchestrator Version R5204-20230831-GA

Orchestrator build R5204-20230831-GA was released on 09-01-2023 and is the 4th Orchestrator rollup for Release 5.2.0.

This Orchestrator rollup build addresses the below critical issues since the 3rd Orchestrator rollup, R5203-20230809-GA.

  • UI Build R5204-20231201-GA, was released on 12-04-2023 and is the 12th UI Build added to Orchestrator Release 5.2.0.4. 

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #126695

    On the SD-WAN > Settings > Alerts > Webhooks page of the UI, if a user is configuring webhooks for Alerts, when they click on the "Configure Payload Template" button the menu is not displayed.

    Fixed Issue #128921

    A partner or enterprise superuser navigating to the SD-WAN > Enterprise > Service Settings page would observe there is no option to view Edge licenses.

    Fixed Issue #131224

    On the Configure > Device > VPN Services page of the UI, when configuring a Zscaler service, the Sub-Location Name 'Other' can be edited and results in the Orchestrator marking the configuration as invalid with errors "Zscaler sublocations cannot be named as 0" and "Cannot save changes. There is one more more errors within your configuration". The 'Other' Sub-Location should never be edited and this issue occurs only if the Zscaler service is deactivated and then reactivated.

    Fixed Issue #131631

    On the Monitor > Edge > Destinations page, a user cannot filter by Applications as the option is not present on the UI.

    Fixed Issue #132047

    On the Configure > Edge > Device > Connectivity > VLAN page of the UI, when the user chooses the VLAN DHCP option 2 (Time Offset), a negative value cannot be entered despite it being an integer. The expected behavior is for the UI to allow both positive and negative integers.

    Fixed Issue #132384

    After a configuration change done to a VLAN at the profile level, all data related to DHCP or OSPF on any Edges using that profile is lost if the configuration uses an Edge override.

    Fixed Issue #133008

    On the Monitor > Network Overview page of the UI, if the Edges are sorted by link status (for example, Links down, Links stable, or Links degraded), the Auto-Refresh option does not work and all monitoring information disappears from the UI.

  • UI Build R5204-20231121-GA, was released on 11-22-2023 and is the 11th UI Build added to Orchestrator Release 5.2.0.4.

     The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #128017

    A customer may observe that when navigating to the Configure > Edge > Device page, that the page never loads because the UI mistakenly deleted the Edge configuration references from the Orchestrator database. Once these reference are removed, they cannot be restored.

    Fixed Issue #129695

    If a Partner User changes an Edge's Wi-Fi password on its WLAN interface and saves changes, an Operator user will see the old Wi-Fi password when they look at the same Edge's WLAN interface.

    Fixed Issue #130810

    A user cannot insert a BGP filter rule into a list of these rules, either above or between two or more rules. A BGP filter rule can only be added at the end of the list.

    Fixed Issue #131138

    On the Configure > Device > VPN > Cloud VPN page, the UI allows a user to save a change to the Branch to VPN Hubs option if there are no Hubs configured. This results in the UI removing all Cloud VPN configurations because the configuration file is corrupted.

    Fixed Issue #132524

    On the Configure > Edge > Device > Routing & NAT > Static Route Settings page of the UI, when a user adds a static route to an Edge where the next hop IP address of the static route is within the same subnet of the VLAN network, the UI displays Edge interfaces when the Interface settings for the Local Routes should change to N/A.

  • UI Build R5204-20231115-GA, was released on 11-16-2023 and is the 10th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #123078

    When navigating to the Monitor > Edge > Overview page, the columns are not aligned properly as there is no information populated for the Device Serial Number column, resulting in a readability issue.

    Fixed Issue #123718

    When a user edits a Business Policy rule in the Orchestrator UI, the user is unable to enter a custom VLAN ID for the Business policy as the VLAN option in the UI is a drop-down list of VLAN interfaces, instead of a text box input.

    Fixed Issue #128330

    For an enterprise using a Non SD-WAN Destination (NSD) via Gateway network service, the UI permits the user to delete a NSD via Gateway from a Profile which includes a Business Policy rule associated with the global segment. As a result, the Business Policy rule becomes invalid and any traffic matching that rule is not steered as expected.

    Fixed Issue #128765

    On the BGP Filters page, the Submit button may be inaccessible when a user changes pages. When a user edits the BGP Filters table and navigates to another page while there is an invalid configuration state on the current page, the UI controls remain grayed out and inaccessible after returning back even though the user now fills in the correct information for that row. On an Orchestrator without a fix for this issue, a user needs to stay on the page of the BGP Filters table and ensure all configurations are correct before navigating away from it, or remove the invalid row and add it again later.

    Fixed Issue #130877

    When a user adds a static route to an Edge using the Orchestrator UI, client users for that Edge may observe that traffic fails for some local routes. On the UI under Configure > Edge > Device > Routing & NAT > Static Route Settings, if the next hop IP of a static route is within the same subnet of the VLAN network, the Interface settings for the Local Routes are changed to N/A and cannot be edited. Without a configured interface, these routes become unreachable.

  • UI Build R5204-20231109-GA, was released on 11-10-2023 and is the 9th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #123387

    A user cannot add a Zscaler Non SD-WAN Destination (NSD) via Gateway with an existing IP address. The Orchestrator's validation prevents users from adding a Zscaler with a primary or secondary IP address that is already used in another NSD via Gateway.

    Note:

    This ticket was initially listed as fixed in UI Build R5204-20231013-0631-GA, however that fix was incomplete and this issue is only fully resolved in this UI Build.

    Fixed Issue #123640

    When a user configures Static routes for an Edge and clicks the Add button in the Static Routes section, a new empty row is added to the table, but the UI throws an error message "Cannot save changes" at the bottom of the screen.

    Fixed Issue #127727

    When creating a new Cloud Security Service (CSS), if a user activates the Domestic Preference check box and saves the configuration, the Orchestrator verifies the credentials and displays a message stating that "Changes saved successfully!". But post-save, when the CSS profile is opened again, the user would observe that the Domestic Preference check box is not selected.

    Fixed Issue #129584

    On the Configure > Edges > Business Policy page, when a user edits an existing Business Policy rule, the UI does not update the reconfigured value for the Destination field even after saving the changes. For example, for an existing Business Policy rule with Destination set as “IP Address”, if the user changes the value of Destination to “Any” and saves change, the changes made to the Destination field for the rule is not reflected in the UI. The user would still see the Destination field set to “IP Address” instead of “Any” in the rule.

    Fixed Issue #130153

    For Enterprise users with a Support role, the Restart Service option is not available under Monitor > Edges > Select Edge > Shortcuts > Remote Actions menu, preventing the user from doing an Edge service restart from the Shortcuts menu on the Monitor > Edges page.

  • UI Build R5204-20231101-GA, was released on 11-02-2023 and is the 8th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #123001

    After activating High Availability (HA) and saving the configuration, when a user attempts to configure VNF settings for the VMware SD-WAN Edge, the Configure Security VNF window displays fields only for Primary Virtual Machine (VM-1) and Secondary Virtual Machine (VM-2) fields are not displayed. As a result, users must manually refresh the VNF settings window to add secondary IP address to VNF configuration.

    Fixed Issue #127904

    When a user creates a static route and an ICMP probe in the same line, the Edge does not install the ICMP probe and displays a parsing error because the UI sends the Next Hop IP and Source IP value as null instead of an empty string to the Edge.

    Fixed Issue #128753

    When a customer configures a subinterface that uses DHCP for addressing and creates a user-defined WAN overlay, the user is unable to save the configuration without configuring the Source and Next-Hop IP addresses.

    Fixed Issue #129061

    For a customer with Partner Hand off activated from the Customer > Global Settings > Customer Configuration > Additional Configuration > Gateway Pool screen, the "Use for Private Tunnels" and "Advertise Local IP Address via BGP" check boxes are not clickable under the IPv6 section of Gateway Hand Off Interface. This prevents the user from deactivating the IPv6 private tunnel for Hand off interface.

    Fixed Issue #129494

    On the Customer > Global Settings > Customer Configuration > Service Configuration > SD-WAN page, when a user is editing the service configuration, the user is required to add the domain name every time, even if Single Sign-On (SSO) authentication or Edge Network Intelligence (ENI) is not configured for the customer.

    Fixed Issue #129765

    When editing a routed interface for a VMware SD-WAN Edge, the UI populates a wrong default value for dhcpServer.options. For example, when a user edits the "GE3" routed interface and saves device settings configuration data, the value of “options” field under “dhcpServer” is sent as null instead of an empty array.

    Fixed Issue #129894

    In the Operator portal, when looking at Gateway Management > Gateways > Overview > Customer Usage screen, a user may observe some Edge client tunnel details are missing. This issue can occur if the Edge name, Gateway Pool name, and Gateway type are the same.

  • UI Build R5204-20231027-GA, was released on 10-27-2023 and is the 7th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #125964

    For a customer deploying Non SD-WAN Destinations (NSD) via Gateway, when navigating to the Configure > Network Services > NSD via Gateway > Generic IKEv2 page and clicking on Save after adding custom site subnets, the NSD configuration changes are not getting saved. This issue is the result of invalid fields (IKE SA Lifetime(min) and IPsec SA Lifetime(min) in the Primary VPN Gateway section.

    Fixed Issue #126602

    A customer cannot add a Gateway Pool to their existing partner configuration Gateway Pool. The attempt to do so returns an error if the Gateway Pool in the Partner configuration has a managed pool because the existing managed pool IDs are not removed by the UI.

    Fixed Issue #127904

    When a user creates a static route and adds an ICMP probe to this route, the Edge does not install the ICMP probe and displays a parsing error. This issue is due to sending Next Hop IP and Source IP value as null instead of an empty string from the Orchestrator to the Edge.

    Fixed Issue #128279

    On the Configure > Overlay Flow Control > Routes List page, a user can see a maximum of 256 routes with no option to click to an additional page of routes. The hard 256 route limit and lack of pagination impacts customers with large enterprises which contain a number of routes well in excess of the hard 256 limit.

    Fixed Issue #128357

    On a customer Enterprise that uses OSPFv2 or OSPFv3 for routing and selects OE1 from the Default Route list, an invalid option “None” appears in the Advertise list. The valid options for Advertise are only "Always" and "Conditional".

    Fixed Issue #129413

    When a user is configuring a VLAN at the Edge level and attempts to change the default DHCP start address and saves changes, the DHCP start address is not overwritten and the Orchestrator UI populates the old address again for the VLAN.

    Fixed Issue #129926

    When a user provisions an Edge with no serial number, the Edge activation fails.

  • UI Build R5204-20231019-GA, was released on 10-20-2023 and is the 6th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #127021

    A Non SD-WAN Destination via Edge configuration does not appear on the UI when configured using an automation API because the automation script experiences a data corruption issue.

    Fixed Issue #128706

    On the Monitor > Edges > System page, when a user tries to zoom into the chart there is only black trace and no zoom happens. Chart is still responsive to the time range selector at the top of the page, so it can be used as a workaround.

    Fixed Issue #129049

    When Edge Override is off, the Edge configuration's VLAN advertise option does not use the advertise value pushed from the profile configuration. Even when the VLAN advertise option is set to false at the profile level, when the override option is off, the Edge advertise option does not use the profile advertise value.

    Fixed Issue #129271

    The System Property: vco.enterprise.authentication.passwordPolicy with parameter disallowUsernameCharacters = 3 is not behaving as expected. For example, with username [email protected] the UI will check substrings: vis, ish, ..., t.c, .co, com, all as expected. The problem is that the UI also checks: om, m. This results in the UI throwing an error for what should be a valid password. The workaround is to set disallowUsernameCharacters back to its default value (-1).

    Fixed Issue #129560

    On the Service Settings > Alerts & Notification page, the Partner and Enterprise users cannot change the Enable Enterprise Alerts setting.

  • UI Build R5204-20231013-0631-GA, was released on 10-13-2023 and is the 5th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #120419

    A user cannot set a DHCP start address for a VLAN at the Edge level without first checking Edge Override and then changing the number of addresses assigned by the profile.

    Fixed Issue #127035

    Under Configure > Edge > Device > High Availability, after creating a Cluster and saving changes, the UI page would continue to show the default value of None even though the Cluster was successfully created. This is a cosmetic issue, and a refresh of the UI page will show the correct configuration.

    Fixed Issue #127636

    On the Monitor > Edge > Sources page of the UI, a user searching a Source by FQDN does not work as expected when using the New UI which prevents a user from locating a Source using a standard method. This includes not having the option of searching by a partial string.

    Fixed Issue #127774

    Under Configure > Edge > Device > Connectivity > Loopback Interfaces, when a user configures a loopback interface for an Edge and saves changes, the configuration is not applied and does not show on the UI page. In addition, the UI does not display an error for this failure which misleads the user about the success of the configuration change.

    Fixed Issue #128371

    When a Non SD-WAN Destination via Edge or a Cloud Security Service (like Zscaler) is deactivated at the profile level, the Orchestrator should warn the user that there is a Business Policy associated with the NSD/CSS so that they can revise the Edge level business policy. Otherwise, the Non SD-WAN Destination via Edge/ Cloud Security Service field will be empty when the user navigates to the Edge level and edits the rule.

    Fixed Issue #128620

    When looking at Configure > Device > VPN Services, both Profiles and Edges are not showing connected Hubs in the Cloud VPN configuration screen for the New UI, even though Branch Edges are connecting to Hubs (which can be confirmed under Monitor > Paths).

    Fixed Issue #129253

    Under Service Settings > Alerts & Notifications > Alerts > Notifications, a user cannot deactivate SMS as a notification method as the slider button is grayed out.

  • UI Build R5204-20231003-GA, was released on 10-04-2023 and is the 4th UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #117923

    When a user provisions an Edge and enters text in the Description field, Orchestrator UI saves this to the Custom Info field and and the Description field will show as empty when looking at this newly provisioned Edge.

    Fixed Issue #123070

    For a customer enterprise with a Hub/Spoke topology, when configuring a Business Policy where Internet Backhaul is selected, a user does not have the option to select Backhaul Hubs and thus backhaul cannot work for that rule.

    Fixed Issue #127037

    When a user navigates to Monitor > Edge > Sources tab, they cannot change the hostname for a Client. A user should have the option to change the hostname for a client by clicking the Edit icon and opening the Change Hostname box. While they can enter in the text under the Change Hostname field, when they click Save Changes, the new hostname is not applied.

    Fixed Issue #128628

    On the Manage Customers page, the download CSV export does not work and the only way a customer can get this information is to use an API to download the information and convert is to a CSV format.

    Fixed Issue #128667

    The Manage Customers or Manage Partner Customers page can take up to a minute to load when there are a large number of customers on the Orchestrator, or a large number of customers under a Partner.

  • UI Build R5204-20230927-GA, was released on 09-28-2023 and is the 3rd UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #126967

    After OSPF is activated on a profile, the routing interface's OSPF Advanced settings Inbound Route Learning and Route Advertisement are not accessible and do not display any fields for entering the required details.

    Fixed Issue #127006

    When an Operator user with the Support role navigates to the SD-WAN > Network Services page and clicks on a Non SD-WAN Destination via Gateway, they have the option to click +NEW to create and configure a new NSD. An Operator in a Support role should have read-only privileges on the Network Services page and not have the ability to create a new NSD via Gateway.

    Fixed Issue #127843

    The UI does not display correctly when localized to the Italian language resulting in some navigation tabs overlapping with one another.

    Fixed Issue #127849

    The View Certificate button is grayed out and not clickable on the Edge > Configuration > Overview screen, preventing users from viewing Edge certificates. Without a UI fix, a user can view an Edge certificate by navigating to the Edge list on the Configuration tab and search for the desired Edge.

    Fixed Issue #127871

    The Network Overview page does not automatically refresh, nor does it offer the option to enable automatic refreshing. As a result, users must manually refresh the page to view the latest data.

    Fixed Issue #128277

    When a Partner or Enterprise native user (one who logs into the Orchestrator with a username and password) attempts to log in with an expired password, the UI enters a loop and displays a blank screen.

  • UI Build R5204-20230920-GA, was released on 09-21-2023 and is the 2nd UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #106191

    If an Edge interface is configured with static IP addresses at the Profile level, a user cannot make any additional Edge changes

    Fixed Issue #113254

    Partner users are not permitted to change software images for their customers because of privilege constraints.

    Fixed Issue #117941

    The VLAN Advertise checkbox always displayed as unchecked. Even after saving the changes after selecting the checkbox, the VLAN Advertise checkbox in the Angular UI reverts to being unchecked.

    Fixed Issue #117993

    When an administrator tries to reset the password for an enterprise or partner user, the request fails and an error reading user does not have privileges required to access is displayed.

    Fixed Issue #121469

    On the Global Settings > User Management page, a user always observes a lock alert banner on the User Overview page even though the user is likely unlocked and can login.

    Fixed Issue #126503

    For an enterprise using a Non SD-WAN Destination (NSD) via Gateway of any type, if a user edits and saves a change to the PSK value for an NSD, the Orchestrator UI ignores the change and reverts to the original default value.

    Fixed Issue #126257

    The top value on the Monitor > Edge > Links page is not visible to users when there are a lot of extreme high values. This is because the chart height was previously summed using lower values, which made the chart inaccurate and unable to be aligned with the scale.

  • UI Build R5204-20230914-GA, was released on 09-15-2023 and is the 1st UI Build added to Orchestrator Release 5.2.0.4.

    The following table lists all the fixes for this UI Build with descriptions of the symptoms for each issue.

    Ticket

    Symptom/Description

    Fixed Issue #108125

    On the Monitor > Edge > Application page, when a user clicks on a point on the chart to get further details and then clicks on the chart a second time, the details window does not open properly and is functionally unusable.

    Fixed Issue #122918

    For an enterprise using a Branch to Hub topology, when a user goes to the Configure > Device > VPN Services > Cloud VPN section of the UI and tries to make a change to either Branch to Hub Site or Branch to Branch VPN setting, the user is blocked stating that Hubs are in use. This issue can be encountered if other services are being used in a Business Policy and the UI mistakenly considers them when calculating backhaul usage and blocks the change.

    Fixed Issue #123619

    If an Orchestrator does not have access to the internet (for example, one that is on-premises), the Monitor > Edge > Overview page is empty, displaying no information.

    Fixed Issue #123927

    When OSPF is configured for a VLAN, a user can deactivate the Passive Interface VLAN setting for an Edge, even though Passive OSPF mode is the only supported mode.

    Fixed Issue #124801

    When an Operator user sets the System Property 'Session.options.enableEdgeLicensing' to False, a user is still required to create an Edge by first selecting an Edge License. Setting this System Property to False allows Partner-controlled Orchestrators to bypass the Edge licensing step if they do not require an Edge license for their Edge Provisioning process. However, with this defect the user must still select a license.

    Fixed Issue #125309

    When a user deactivates IPv6 at the Edge level under Configure > Device > IPv6 Settings, the OSPF option for IPv6 can still be edited, activated, and saved.

    Fixed Issue #125393

    When looking at the Configure > Device > VLAN table at the Profile level, the OSPF column is missing.

    Fixed Issue #125710

    For an enterprise using a Branch to Hub topology, if an Edge being used in a Cloud VPN is deleted from the enterprise, the user cannot later remove any Hub Edge being used in a Branch to Branch VPN and the editing of Device settings is blocked.

    Fixed Issue #126403

    The UI may fail to load the Partner Overview page due to an issue with the 5.2.0.4 software image.

    Fixed Issue #127007

    For an enterprise using a Hub/Spoke topology, when a user changes any setting on a Profile's Configure > Device page, the Hub order is changed automatically to default, impacting all Edges using this Profile.

  • Fixed Issue 65668: A customer who is subscribed to the Cloud Web Security service cannot see which VMware SD-WAN Gateways are assigned to manage Cloud Web Security traffic when looking at the Gateway Assignment page.

    The customer should see what the primary and secondary assignments are for the Gateways (also known as SASE PoPs) handling Cloud Web Security.

  • Fixed Issue 104775: When a user configures a previously active WAN link on a VMware SD-WAN Edge to be a backup, the VMware SASE Orchestrator UI does not display the status correctly on Monitor > Edges > Overview.

    The backup link status should display as "Standby" and "Idle" with a gray colored status dot, but instead the link status does not display the link type or the backup status. This is a cosmetic defect as the WAN link is performing its role as a backup.

  • Fixed Issue 118728: On a partner portal or a customer enterprise, some users may not be allowed to login to the VMware SASE Orchestrator.

    The user may see the error 'user does not have privilege [READ:PROXY] required to access [enterpriseProxy/getEnterpriseProxy]' even though the user has the correct privileges to log in. This is true of native authentication and two factor authentication. This error actually reflects an expired password even though the Orchestrator is not letting the user know that is the real reason they cannot login and the user cannot reset their password since they cannot login.

    On an Orchestrator without a fix for this issue, a partner or customer administrator with a suitable role can send the password reset email to an affected user to reset their password.

  • Fixed Issue 120398: A Partner User cannot create a new configuration profile for a customer enterprise they are managing.

     When the Partner User tries to create a configuration profile for their customer, the Orchestrator throws an error that reads 'invalid proxy enterprise context for operator profile'. This issue is encountered for any Partner role with configuration privileges.

  • Fixed Issue 121118: An Enterprise User does not have the option to generate a Diagnostic Bundle or generate and download a Packet Capture on the VMware SASE Orchestrator.

    This is true of all Enterprise User roles (including Superuser). The expectation is that an enterprise user under SD-WAN > Diagnostics should see the option to:

    1. Generate (but not download) a diagnostic bundle.

    2. Generate and download a packet capture.

    However, all they see are options for Remote Diagnostics and Remote Actions.

    If experiencing this issue on an Orchestrator build without a fix for this issue, contact SD-WAN Support for assistance and they can generate the diagnostic bundle for you.

  • Fixed Issue 121526: A user with an Enterprise Read Only role is not permitted to view the Monitor > Edges > QoE graphs on the VMware SASE Orchestrator UI.

    An attempt to view the QoE graph results in an error banner that reads 'user does not have privilege [READ:ENTERPRISE_EVENT] required to access [event/getEnterpriseEventsList]'.

  • Fixed Issue 122113: A user cannot search for the Event 'DNS_CACHE_LIMIT_REACHED' on the Events page of the VMware SASE Orchestrator UI.

    This event will post when it is triggered on the Monitor > Events page for a customer enterprise, but it is not listed as a searchable value when trying to use the search function. As a result, the user cannot see how many times this event posted over any time period.

  • Fixed Issue 123002: Upgrading a VMware SD-WAN Edge may fail because the software only partially downloads before the connection is prematurely closed.

    The issue is traced to the VMware SASE Orchestrator having an incorrect download timeout value that causes some download sessions to close before the download is complete. The fix restores the correct timeout value to ensure the download is completed.

  • Fixed Issue 123053: When a user configures a SNMP v3 name the VMware SASE Orchestrator UI rejects any name that includes a non-alphanumeric character with an error.

    Configure > Device > Telemetry > SNMP for SNMP Version 3 names and the Orchestrator rejects non-alphanumeric characters like [@\'"/,#%&*(){}_=`:?[]§;|><]. This means a name like User_23 is not accepted with error message "Characters not allowed in this field" and this limits what a user can use for an SNMP v3 name.

  • Fixed Issue 123150: For a customer enterprise site using a High Availability topology, when the customer configures a VNF and then activates VNF Insertion, the VMware SASE Orchestrator does not show that the VNF Insertion was successful and the VNF status does not show on the HA Edge.

    The issue is the result of the Orchestrator erroneously sending a VNF setting for interface insertion as "False" even if there are interfaces with VNF insertion turned on in Configure > Edge > Interface settings. Since this field is sent as "False" in the Orchestrator configuration, the HA Edge does not activate the VNF insertion on any interface.

    On an Orchestrator without a fix for this issue, the workaround is to deactivate HA for that site and turn the HA Edge into a Standalone Edge, reconfigure each VNF and then activate VNF Insertion. After the configuration succeeds, you can reactivate HA for the site.

  • Fixed Issue 123346: Existing Customer Enterprises cannot activate 'Firewall Logging to Orchestrator' feature on a VMware SASE Orchestrator version 5.2.0.

    While VMware Hosted Edge Firewall Logging was added as a feature in Release 5.2.0, customers created prior to their Orchestrator being upgraded to 5.2.0 did not see the option to turn this feature on post-upgrade.

  • Fixed Issue 123551: A user would observe that when creating or editing a password for a VMware SD-WAN Edge Wi-Fi interface, the Orchestrator UI requires a password of 10 characters, when it should be 8 characters.

    The 10 character requirement was created inadvertently in the Release 5.1.0 Orchestrator as part of a misclassification of the Wi-Fi process and is reverted back to the correct 8 characters in this build.

  • Fixed Issue 123749: An Enterprise Administrator or Enterprise Support user cannot view the 'Diagnostic Bundles' option on the Diagnostics screen of the VMware SASE Orchestrator UI when their role is customized to do so.

    By default these roles cannot see the Diagnostics > Diagnostic Bundles option on the UI, but role customization can add privileges for Diagnostic Bundles and PCAPs to either role which should add the Diagnostic Bundles screen.

  • Fixed Issue 124073: If a user configures a Non SD-WAN Destination via Gateway using redundant Gateway tunnels with AES-256 encryption, the standby redundant Gateway tunnel continues to use AES-128 encryption.

    A user would go to Configure > Network Services on the Orchestrator UI and change the encryption algorithm to AES-256 for an NSD with redundant tunnels. Based on the API response the user would observe that the redundant tunnel continues to use AES-128 and this is the result of a defect with the API which handles the tunnel encryption change.

  • Fixed Issue 124129: If the System Property that controls the availability of the Enhanced Firewall Service (EFS) is set to True, any new customer enterprise added to the VMware SASE Orchestrator has EFS activated by default.

    The System Property enterprise.capability.enableATP is set to True by default on previous 5.2.0 builds. When this property is set to True, a user would observe that when checking the Global Customer settings for a new customer enterprise that EFS is enabled by default. The expected behavior is for every new customer enterprise to have EFS not activated by default, where they would need to have this feature activated as an explicit action.

    This is corrected on the 5.2.0.4 build by having the enterprise.capability.enableATP property set to False by default.

  • Fixed Issue 124273: An Operator User may observe that their attempt to upgrade a VMware SASE Orchestrator to a 5.1.x or 5.2.x build fails.

    When encountering this issue the logs would be similar to below:

    • fatal: [vcoxxx]: FAILED! => changed=true
    • ...
    • UPGRADE - DEBUG - Starting VCO software update preinstall
    • UPGRADE - WARNING - E: Unable to locate package linux-image-unsigned-x.x.x
    • UPGRADE - WARNING - E: Couldn't find any package by glob 'linux-image-unsigned-x.x.x-xxx'
    • UPGRADE - WARNING - E: Couldn't find any package by regex 'linux-image-unsigned-x.x.x-xxx'
    • UPGRADE - WARNING - E: No packages found
    • UPGRADE - ERROR - installer failed with return code 100. See /var/log/vco_software_update.log for details
    • UPGRADE - WARNING - Verification key does not exist: xxx

  • Fixed Issue 124315: A user appears to have the option to edit a BGP Filter at the Edge level that was created at the Profile level using the Orchestrator UI.

    While a user can always override the profile settings on an Edge using Edge Override, the user should never be able to edit the actual profile settings. In this case the UI gives the user the appearance that they can edit a BGP Filter pushed down from a profile. This is a cosmetic defect and nothing the user does to the profile BGP Filter is applied to that Edge or any other Edge.

  • Fixed Issue 124778: When a customer navigates to Global Settings > Customer Configuration, they do not see the option to configure their Security Policy.

    The Security Policy section is where a customer can configure their Edge IPsec Proposal including Encryption, DH Group, and so forth. This option is present on the Classic UI but missing on the New UI, the default interface on Release 5.2.0 and later Orchestrators.

  • Fixed Issue 124798: A user cannot edit the serial number of a VMware SD-WAN Edge on the VMware SASE Orchestrator UI.

    For an Edge provisioned or RMA'd but not yet activated, the user would be on the SD-WAN > Configure > Edge > Overview screen and under Edge Status, the Serial Number of the Edge is present but is read-only text and not editable. This is an issue because some customers may not know the serial number of the Edge to be activated until it is delivered on site and they need the option to edit this field so it aligns with the delivered Edge.

  • Fixed Issue 125456: For a customer enterprise where VNF's are used, if a user attempts to modify an Edge Device configuration, the VMware SASE Orchestrator rejects the changes when trying to save them.

    The configuration change can be as minor as adding a comment to an existing static route and the Orchestrator UI does not save the change where a VNF is activated. The user may observe a "Script injection error" banner at the bottom of the UI screen.

    The workaround on an Orchestrator without a fix for this issue is to temporarily deactivate the VNF's and then save the configuration changes. Once these are successfully saved, the user can then reactivate the VNF's.

Resolved in Orchestrator Version R5203-20230809-GA

Orchestrator build R5203-20230809-GA was released on 08-09-2023 and is the 3rd Orchestrator rollup for Release 5.2.0.

This Orchestrator rollup build addresses the below critical issues since the 2nd Orchestrator rollup, R5202-20230729-GA.

  • Fixed Issue 121118: An Enterprise User does not have the option to generate a Diagnostic Bundle or generate and download a Packet Capture on the VMware SASE Orchestrator.

    This is true of all Enterprise User roles (including Superuser). The expectation is that an enterprise user under SD-WAN > Diagnostics should see the option to:

    1. Generate (but not download) a diagnostic bundle.

    2. Generate and download a packet capture.

    However, all they see are options for Remote Diagnostics and Remote Actions.

  • Fixed Issue 121884: A VMware SASE Orchestrator may continue to process and store firewall log files even though the System Property for this action is set to false.

    When the System Property storage.firewall.logs.file.enable is set to false, the expected behavior is for the Orchestrator to stop processing and storing firewall log files at a global level, and no customer enterprise should be able to get new firewall logs regardless of their own enterprise level settings. This property is used as a tool for troubleshooting Orchestrator performance issues possibly related to firewall log processing. On Orchestrator Releases 5.2.0.1 and 5.2.0.2, this setting is not obeyed.

  • Fixed Issue 122132: A customer using the Enhanced Firewall Service may not be able to download updated definitions for the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) features.

    The issue is traced to Release 5.2.0 operator profiles not including the atpMetadata module. Edges using a 5.2.0 operator profile are not able to download IDPS signature bundles for applying IDS/IPS and thus are not getting the expected level of protection from the Enhanced Firewall Service.

  • Fixed Issue 122797: A user cannot activate the setting 'Enable Branch to Branch VPN' on a profile used by a Hub Edge.

    On the screen, Configure > Profile > Device > VPN Services, the Orchestrator UI allows the user to check the box for Enable Branch to Branch VPN but when attempting to save the configuration the Orchestrator UI throws the error - "Cannot save changes. There is one or more errors within your configuration." This error does not tell the user what the actual error is. This issue occurs on the New UI only, the default UI for Release 5.2.x.

  • Fixed Issue 123384: When accessing either the SD-WAN > Configure > Edges page, or SD-WAN > Monitor > Edges page on the VMware SASE Orchestrator, if the user adds a filter to sort by either operator profile, configuration profile, or analytics, the page fails to return any results with an error.

    The user would observe a page saying Failed to Load Data, and if they pull up the browser's console would also observe an 'API Error' entry.

  • Fixed Issue 123609: A user cannot save changes to the BGP Filter List if there are greater than ten BGP Filter Rules.

     The user adds BGP filters on the SD-WAN > Configure > Profile/Edges > Device > Routing & NAT > BGP page of the Orchestrator. If the user adds enough new filter rules to the Filter List to exceed a total of ten, saving this configuration fails and the Orchestrator UI shows an error message "Cannot save changes. There is one or more errors within your configuration".

    The issue is caused by the New UI (the default UI on Release 5.2.x) using an incorrect indexation in the BGP Filter Rules table which causes it to start from the second page of the pagination (11 rules and more).

Resolved in Orchestrator Version R5202-20230729-GA

Orchestrator build R5202-20230729-GA was released on 08-02-2023 and is the 2nd Orchestrator rollup for Release 5.2.0.

This Orchestrator rollup build addresses the below critical issues since the 1st Orchestrator rollup, R5201-20230623-GA.

  • Fixed Issue 116666: A Partner with a Superuser role does not have the option to activate Enhanced Firewall Service for one of their supported customer enterprises.

    This option should be available for a Partner Superuser when navigating to Global Settings > Customer Configuration on the VMware SASE Orchestrator.

  • Fixed Issue 117772: When looking at Monitor > Network Overview screen for a VMware SASE Orchestrator for an Enterprise Customer, WAN links that have a status of Degraded or Down may not be included in the Link status screen if more than 10 WAN links are being monitored.

    This issue is exclusive to the New Orchestrator UI due to a front end issue that does not account for WAN links in a Degraded or Down status. Monitoring works as expected on the Classic UI.

  • Fixed Issue 117822: When a customer looks at Monitor > Edges > QoE, they may observe gaps in the QoE graphs that are not explained by any issues with the Edge's WAN links.

    The gaps are the result of an issue with the Orchestrator database where the internal job queue for link data is missed and the link data is not backfilled.

  • Fixed Issue 118544: A user may observe that an Operator Profile does not load and is inaccessible and thus cannot be assigned to a customer enterprise.

    There is an issue with the Orchestrator database where the Operator Profile is present, but an incorrect logical ID is added to a configuration module if a customer enterprise is deleted, and this prevents it from loading.

  • Fixed Issue 118733: When using the VMware SASE Orchestrator's New UI and a user configures either a Business Policy or Firewall Rule at the profile level which is then overridden at the Edge level, when a user looks at the Configure > Edges > List Edges screen, the icons for the overridden Edge are not correctly represented for Device, Business, and Firewall.

    The icons where Edge Override is checked should show as a solid color and are instead shown as empty when using the New UI, which is the default UI for Release 5.2.0. The Classic Orchestrator correctly displays the icons as solid when an Edge Override has been configured for a particular category.

  • Fixed Issue 120070: For a customer who deploys a Cloud Security Service (CSS) with a Zscaler type where 'Automate Cloud Service Deployment' is activated, if a user goes to Monitor > Network Services > Cloud Security Services > Deployment Status, the user sees no option to view status for that CSS.

    This monitoring screen and Deployment Status in particular are important to any customer deploying an automated Zscaler CSS.

  • Fixed Issue 120606: When attempting to create a new role on the Customer > Global Settings > User Management > New Role, they would observe an error and privileges are not loaded.

    When encountering this issue the user sees "method error" on the UI page while creating a new role, which also prevents privileges from being loaded.

  • Fixed Issue 120774: For a customer deploying Non SD-WAN Destinations via Gateway (NSD), when navigating to the Monitor > Network Services or Configure > Network Services and clicking on an NSD, the user may not see the IKE settings for an NSD tunnel.

    A user observes the following error: Cannot read Properties of undefined (reading 'clearDontFragmentBit') and nothing is displayed.

  • Fixed Issue 121441: When a customer activates VNF Insertion on a VMware SD-WAN Edge's VLAN, the Edge deletes and then redeploys the VNF, which makes it unusable for that Edge.

    After VNF insertion is activated on the VLAN, the customer would observe VNF deletion and redeployment events on the Monitor > Events page and also receive an email with the message "(VNF_VM_DELETED) / Unknown vendor VNF was deleted on the edge <Edge Name>". The issue is traced to the Orchestrator sending a new UUID (Universally Unique IDentifier) after VNF insertion is activated on a VLAN. The Edge interprets this UUID change as a trigger to delete the VNF and redeploy it, which makes it unusable for that Edge.

    This issue occurs on the New UI only, which is the default UI for the 5.2.0 Orchestrator. As a result there is no workaround when using this version in the absence of a fix.

  • Fixed Issue 121472: When Two Factor Authentication (2FA) is activated for a customer enterprise, an individual user account does not have the option to deactivate 2FA for itself.

    If 2FA is activated for a customer, there should be a checkbox option to either deactivate it or require it when clicking on any user's account details. The fix adds a toggle option for 2FA that makes it clear what the 2FA status is for that user.

  • Fixed Issue 121751: An Operator or Partner user is not permitted to reassign the VMware SD-WAN Gateway used by a Non SD-WAN Destination (NSD) via Gateway to a different Gateway when using the VMware SASE Orchestrator UI.

    When an Operator or Partner Superuser navigates to Gateways > Gateway Management, they cannot reassign the Gateway an NSD via Gateway uses to another Gateway (these are Gateways configured to have a Secure VPN Gateway role). The user can click on a different Gateway, but the Orchestrator UI will not allow the user to then click the Assign Gateway button to complete the reassignment.

  • Fixed Issue 121835: When a user tries to turn on the Advertise feature on a loopback interface, the Save popup box does not come up and the user does not have the option to save any Edge Device Settings configuration data.

    When a user tries to Edit a loopback interface in Configure > Edge > Device, the Edit dialog does not load properly. This is caused by the UI expecting OSPF parameters in a segment other than the Global segment while the OSPF configuration is only allowed on the Global segment. This issue is encountered only in enterprises on SASE Orchestrators upgraded to 5.2.0 from a previous release and only if the enterprise contains loopback interfaces on multiple segments.

    If the customer enterprise is on an Orchestrator without a fix for this issue, the only workaround is to make device settings changes using API calls.

  • Fixed Issue 121858: For a VMware SASE Orchestrator deployed in a Disaster Recovery (DR) topology, when the Orchestrator is upgraded to the 5.2.0.1 rollup build, DR synchronization may fail leading to large data gaps after an Orchestrator failover.

    As part of the Orchestrator software upgrade, the ClickHouse database management system (DBMS) is upgraded from 20.3.19.4 to 22.3.13.80. During the upgrade, the DBMS process deletes all group permissions and restricts access to the data directory to the DBMS alone. This behavior breaks the rsync based replication process and leads to the DBMS data failing to synchronize between the Active and Standby Orchestrators.

    If on an Orchestrator build 5.2.0.1, an Operator can fix the permission issue on the active Orchestrator with the command: chmod g+rx /store3/clickhouse.

  • Fixed Issue 121993: A user may not have the option to edit the VLAN properties for a VMware SD-WAN Edge on the VMware SASE Orchestrator UI.

    The issue does not affect all VLANs in use by an Edge but when the issue is encountered the user would click on a VLAN in the UI and the result is nothing happens.

    If a customer is experiencing this issue on an Orchestrator without a fix for this issue, contact SD-WAN Support for assistance.

  • Fixed Issue 122010: When an Operator goes to System Properties on a VMware SASE Orchestrator running Orchestrator build 5.2.0.1 and attempts a search, the page may not load.

    This issue is triggered if one or more System Properties has a null value (in other words the value is not defined).

  • Fixed Issue 122271: When a customer adds additional LAN-side NAT rules to a profile using the VMware SASE Orchestrator's New UI, they may observe that all traffic matching these rules fails for the Edges using that profile.

    The New UI incorrectly calculates the LAN-side NAT outside mask from the inside address prefix. When the rules are not written such that the inside and outside prefix are the same (in other words: 1:1) the behavior of the rules changes and can become nonfunctional if a user modifies any LAN Side NAT rule from the New UI. Since the New UI is the default UI for a Release 5.2.0 Orchestrator, this issue has no workaround.

  • Fixed Issue 122520: On a customer enterprise that uses OSPF for routing and also uses loopback interfaces, in some cases the loopback interface may not open at all.

    This issue is traced to the VMware SASE Orchestrator not loading OSPF on the loopback interface when OSPF is configured on one.

  • Fixed Issue 122866: When a user deletes a BGP hand-off from one Partner Gateway, the VMware SASE Orchestrator also deletes this same BGP hand-off from all other Partner Gateways in the same Gateway Pool.

    This issue occurs whether the user is an Operator or a Partner and only occurs on the New UI, which is the default UI for the Release 5.2.0 Orchestrator.

    The workaround is to isolate the Partner Gateway that needs to have the BGP hand-off deleted by temporarily removing it from the Gateway Pool. Doing this prevents other Partner Gateways from being impacted. After the BGP hand-off is deleted, the user could restore that Partner Gateway back to the original Gateway Pool.

  • Fixed Issue 122977: A user may not have the option to activate the Enhanced Firewall Services on the VMware SASE Orchestrator UI.

    This option should appear in three places:

    • Global Settings > Customer Configuration > SD-WAN Settings > Feature Access right below the Stateful Firewall option.

    • Configure > Profile > Firewall as an option once Firewall Status is set to On.

    • Configure > Edge > Firewall as an option once Firewall Status is set to On.

    In all instances it is missing.

    The issue is caused by the Orchestrator mistakenly thinking the customer enterprise is not compatible with the Enhanced Firewall Services feature, even though it is.

Resolved in Orchestrator Version R5201-20230623-GA

Orchestrator build R5201-20230623-GA was released on 06-26-2023 and is the 1st Orchestrator rollup for Release 5.2.0.

This Orchestrator rollup build addresses the below critical issues since the original GA build, R5200-20230529-GA.

Important:

Those customers using an on premises Orchestrator with the 5.2.0.0 build are strongly recommended to upgrade to 5.2.0.1.

  • Fixed Issue 112333: A VMware SASE Orchestrator handling ~4K VMware SD-WAN Edges with ~6K tunnels and continuous traffic flow may become unstable over a period of ~4 days and start to randomly log users out.

    The stress causes the Orchestrator's database to fail and trigger the error "connect ECONNREFUSED" followed by the Orchestrator's IP address. This issue has only been observed in a scale test environment and not in a field deployment.

  • Fixed Issue 113254: A Partner Administrator with a Superuser or Standard role cannot change the default operator profile for a customer under their management.

    The same Partner Administrator would observe that they could perform this action when using the Classic UI, which is not available on Release 5.2.0.

  • Fixed Issue 115411: For a VMware SASE Orchestrator using version 5.1.0 or later and deployed with a Disaster Recovery topology, the synchronization may fail due to a database issue.

    The specific process that fails is dr_utils.js and is a result of this process being deprecated on the latest version of the Orchestrator's database software found in Release 5.1.0 and later.

  • Fixed Issue 115624: A VMware SASE Orchestrator may experience high CPU utilization and instability along with observed slowness in loading Device Settings and Network Settings UI pages when the portal service is restarted.

    The issue is observed on an Orchestrator with ~2K connected Edges while also using Cloud Security Services (CSS) and could occur with this number of connected Edges or greater. The issue is caused by several Orchestrator processes related to Edge, Profile, and Network configurations being uploaded from the Edges to the Orchestrator and taking much longer to complete than expected (~60 seconds or more).

  • Fixed Issue 116141: When a user makes changes to the Device Settings on a configuration profile, the VMware SASE Orchestrator may takes up to a minute to validate the changes.

    Each change can take up to a minute to validate and apply when it should take just seconds. The issue is traced to an Orchestrator process that is not only retrieving a count of all Edge configuration records associated with that profile, but is also decoding and parsing each record ,which is both unnecessary and taxing on the Orchestrator CPU. The fix ensures the process only retrieves the record count.

  • Fixed Issue 116790: When a VMware SASE Orchestrator is upgraded to Release 5.1.x or later, Customer VMware SD-WAN Edges may be inadvertently downgraded to an older Edge version than the Edge is configured to use.

     The issue is triggered when a customer enterprise is deleted from the Orchestrator where the deleted enterprise was associated with an Operator Profile by its logical ID in the Orchestrator database. When the enterprise is deleted, the Operator Profile is also deleted. Customers who have Edge Image Management configured and multiple Operator Profiles available and who had this deleted Operator Profile assigned as their default are then assigned an Operator Profile that remains available in their Edge Image Management menu.

    As a result the customer could be assigned an Operator Profile containing a much older Edge Release, and the Edges assigned this Operator Profile can have their software changed and potentially downgraded if changed to a much lower Edge software version. This can have disruptive effects including network failure if the Edge is runs an older release that does not support features the customer is using.

  • Fixed Issue 117527: When a user is configuring BGP at the Profile level, the browser may become unresponsive if a large number of rules are configured.

    This issue is not observed when using the Classic UI, which is not available on a 5.2.0 Orchestrator.

  • Fixed Issue 117800: When a VMware SASE Orchestrator is upgraded from Release 4.x to 5.1.x or later, the Operator may observe that after the backend process restarts, the same upgradeSchema.sql file is created, even though it was successfully executed.

    This issue occurs with the post-upgrade schema update and once the post-schema script is executed, the upgradeSchema.sql file should not be generated again.

  • Fixed Issue 117993: When a Partner User managing customer enterprises which use native authentication (in other words, username/password) or an Enterprise User attempts to reset a password for an Enterprise User, the attempt fails.

    The user would observe the error: user does not have privileges required to access [enterpriseUser/sendEnterpriseUserPasswordResetEMail]. This issue is only experienced on the New UI which is the default UI for 5.2.0 and is the result of missing request parameters.

  • Fixed Issue 118071: User attempt to change the VPN settings in Configure > Profile > Device may fail with an error if there are multiple VMware SD-WAN Gateways assigned to the customer all of which have ~2K+ Edges assigned.

    The Orchestrator error reads "Error validating changes". The VMware SASE Orchestrator is failing to update the VPN settings because the API is waiting for a databased query which returns an excess of 10K rows, something that can happen with an Orchestrator operating at a large scale. The issue is caused by the Orchestrator getting all Gateways regardless of type (Primary, and Secondary) when it should only have the Edge report its Primary Gateway. This vastly increases the number of records returned and can overflow a query at scale.

  • Fixed Issue 118574: For a customer enterprise using the Enhanced Firewall Service, an alert can be sent with an "informational" severity even though the impact score is high.

    An inaccurate severity description can mislead a customer user and hinder their ability to act upon the alert. The issue is the result of signatures not being correctly classified.

  • Fixed Issue 118673: When a VMware SD-WAN Edge is switched to a different profile, it can take ~60 seconds for the process to complete, with the potential to time out entirely.

    Switching from one profile to another profile should take seconds to complete, but the Orchestrator takes much longer to complete this task due to APIs that are not properly optimized.

  • Fixed Issue 119551: For customers using the VMware Cloud Web Security service, if a user attempts to change a Cloud Web Security setting under Global Settings > Customer Configuration, the attempt fails with an error.

    After the user clicks Update, the Orchestrator throw an error that reads "Invalid Service details" and can occur, for example, when attempting to change the Cloud Web Security license type.

  • Fixed Issue 119733: The VMware SASE Orchestrator's database may experience a failure and require an Orchestrator restart to recover.

    The issue is the result of the database not being on the latest version of MySQL and Orchestrator Release 5.2.0.1 corrects that deficiency with an updated MySQL version.

Resolved in Orchestrator Version R5200-20230529-GA

Orchestrator Version R5200-20230529-GA was released on 05-31-2023 and resolves the following issues since Orchestrator Version R5104-20230426-GA.

Note:

Release 5.2.0 contains all Orchestrator fixes that are listed in either the 5.0.0 or 5.0.1 Release Notes and all Orchestrator fixes in 5.1.0 Release Notes up to the above listed build.

  • Fixed Issue 50480: The text in the drop down menus for a new Non SD-WAN Destination via Edge is incorrect.

    The dropdown for 'New Non SD-WAN Destination via Edge' says:

    • Generic IKEv1 Router(Router Based VPN)

    • Generic IKEv2 Router(Router Based VPN)

    It should say "Route Based VPN" with proper spacing.

  • Fixed Issue 78572: An Operator user can configure an Operator Profile with an invalid FQDN and no error is thrown.

    The Orchestrator should perform a validation on the FQDN value and if the FQDN is not valid, throw an error to alert the Operator. Not having this validation opens the potential for a loss of Edge connectivity to the Orchestrator when the Edge is assigned the Operator Profile.

  • Fixed Issue 78602: When a user configures Syslog on a Profile and then checks a VMware SD-WAN Edge that is using that Profile, the user may observe that the Syslog Level does not show correctly.

    The user would observe that instead of indicating a Syslog Level, the Orchestrator UI only displays "Error" even though the Syslog configuration is valid from the Profile.

  • Fixed Issue 81514: When a Non SD-WAN Destination via Gateway is configured on a 4.x Orchestrator which is then upgraded to 5.x, the New UI does not display the NSD on the Configure > Device Settings page.

    This issue is limited to NSD's configured on a 4.x Orchestrator and when using the New UI. An NSD configured on a 5.x Orchestrator does not have this issue.

  • Fixed Issue 83607: When a user creates, updates, or deletes an Object Group, the VMware SASE Orchestrator does not generate an Event for any of these actions.

    Users need to see Events when a change is made to an Object Group so that they can be verified and audited by both the user that made the change and other customer administrators.

  • Fixed Issue 88661: When configuring a Non SD-WAN Destination via Edge, the user can configure an invalid PSK value which can result in the tunnel to forming.

    The Orchestrator allows any value to be entered for PSK, whether it is one character or a 100 characters with no error thrown.

  • Fixed Issue 93930: The VMware SASE Orchestrator New UI allows invalid values for AS-Path Prepend.

    When configuring a Partner Handoff and then configuring BGP & BGP filters with AS- path prepend, the user can configure invalid values and the New UI is not validating or throwing an error.

  • Fixed Issue 94610: When a user initiates a forced HA Failover through Remote Actions > Force HA Failover, the VMware SASE Orchestrator may not generate and send an Alert for the HA failover.

    Since the HA failover is forced by the Orchestrator, both the Active and Standby Edge anticipate the failover, and this can cause both the HA_GOING_ACTIVE and HA_READY messages to be sent in the same heartbeat by the HA Edge. If the ‘HA State’ sent in the heartbeat shows as ‘Ready,’ this fools the Orchestrator into not generating an Alert for the failover because it only sees this 'Ready' message and does not see the 'Going Active' one.

  • Fixed Issue 97014: When using the VMware SASE Orchestrator's New UI and navigating to the Monitor > Network Overview for a customer enterprise, the column "Bastion State" is not available.

    "Bastion State" is also missing from the Gateway Monitor page, and in both cases is visible on the Classic UI.

  • Fixed Issue 98241: When a user turns on or off the Edge Network Intelligence service on the Customer configuration page, the VMware SASE Orchestrator throws an error even though the action was valid.

    The error reads: "Analytics Url must be set in system property (service.analytics.apiUrl) for analytics feature". The error message is spurious and the changes were in fact successfully saved.

  • Fixed Issue 99065: On the VMware SASE Orchestrator's New UI, a user cannot create a new VNF Service on the Edge Security VNF page.

    The user can create a new VNF Service via the Network Services page, but the fix here also allows the user to do this on the Edge Security VNF page.

  • Fixed Issue 99080: For a user viewing the VMware SASE Orchestrator New UI with the Apple Safari browser, on the Configure Security VNF page, the dropdown options menus have empty options.

    This is only on Safari browsers and Chromium-based browsers work as expected.

  • Fixed Issue 99353: The VMware SASE Orchestrator allows a user to configure the same Server IP Address for multiple NetFlow collector configurations.

    The Orchestrator should validate for duplicate IP addresses in NetFlow settings and reject a server IP address which already exists.

  • Fixed Issue 99891: When a Partner Administrator logs onto the VMware SASE Orchestrator and uses the New UI, when they are on the Manger Partner Customers page and select Customer > Global Settings > Customer Configuration, they will observe an error.

    The error message reads "not allowed to method" when the Partner Administrator attempts to access the customer configuration even though they have full privileges to that page.

  • Fixed Issue 100148: An Operator Superuser cannot edit an Operator role without first changing the description.

    The Operator Superuser should be able to change the functional role of an Operator role without having to change the description.

  • Fixed Issue 101129: Enterprise SSH keys section is visible for Operator Support, Partner Superuser, and Customer Superuser.

    The listed user roles do not have the privileges to view this information and it should not be visible to them.

  • Fixed Issue 103066: When a Business Policy is associated with an application in an Application Map and that application is later deleted from the Application Map, a user is unable to perform further edits to that Business Policy.

    A user should be able to edit the Business Policy even if the application associated with the policy has been deleted from the Application Map.

  • Fixed Issue 103620: On the VMware SASE Orchestrator New UI, when configuring Interface Settings > OSPF > Advanced Settings > Inbound Route Learning, the option "Exact Match" displays a "True" value even though it is actually set to "False".

    This can cause confusion and mislead a user into thinking an important OSPF setting is the opposite of what it is, potentially causing routing issues.

  • Fixed Issue 104667: On the VMware SASE Orchestrator New UI, when looking at Monitor > Edge > Link Status, if the link is marked as Unstable, the date information is wrong.

    If a user clicks on the info bubble for that link, the overview can report "Link Down: 53 years ago" even though it is up but degraded.

  • Fixed Issue 105580: For a VMware SASE Orchestrator where FIPS mode is configured, an attempt to set up Disaster Recovery (DR) for the Orchestrator may fail.

    The DR setup with FIPS configured includes an Orchestrator build with MySQL version 8.0.28 or higher and would fail during the DR COPYING_DP phase with an error SSL_CTX_new failed when trying to connect.

  • Fixed Issue 105861: When a WAN link goes down for several minutes and comes back, the Monitor > QoE graph does not reflect the actual link state.

    The QoE should show red while the link is down and then resume the color (green if good quality) when the link is restored, and this is not happening and causes confusion for users. The issue is caused by the VMware SASE Orchestrator's databased not recording the link down event correctly.

  • Fixed Issue 106295: For a Non SD-WAN Destination with an AWS type, when primary and secondary Gateways are setup with BGP configured on each, the VMware SASE Orchestrator may show the redundant secondary tunnels as down even though they are up.

    The AWS side will report both primary and secondary tunnels as up, but on the Orchestrator's Monitor > Network Services page the secondary shows down. The is strictly a cosmetic issue.

  • Fixed Issue 106554: On a VMware SASE Orchestrator New UI, when creating a new VMware SD-WAN Edge the Edge is always created with Default Edge Authentication set to "Certificate Acquire" no matter what the user configures the "Default Certificate" setting under Service Settings > Edge Management.

    If a user sets Default Certificate as either Certificate Deactivated or Certificate Required, the New UI ignores these global settings and configures the new Edge as Certificate Acquire. Issue not seen on the Classic UI.

  • Fixed Issue 107858: For customers configuring APIs for use on a VMware SASE Orchestrator, in Swagger there are JSON keys missing for inside ha and device_settings_dhcp_relay.

    Release 5.2.0 and later include the missing JSON keys: inside ha and device_settings_dhcp_relay properties.

  • Fixed Issue 108583: For a VMware SASE Orchestrator deployment where Google Maps is not configured, if a user attempts to manually enter the address for an Edge location, the Orchestrator does not allow the attempt to Save.

    Google Maps requires an API key to work on an Orchestrator and the lack of one means the Orchestrator has no means of establishing geolocation for an Edge. However, the expected workaround is for a user to manually enter an address for the Edge. With this issue the user cannot input an address manually, because the Orchestrator has a validation to check if the address is real and valid, and in the absence of the Google Maps application, this check cannot be performed and the Save button is not exposed.

  • Fixed Issue 109710: A Partner Administrator may not be able to configure a Partner Hand-Off on the VMware SASE Orchestrator.

    Partner Administrator users receive "cannot set property v6Detail of undefined" error when configuring static routes on a partner hand off when configured at the per Gateway level. Operator Users can make the change without a problem.

  • Fixed Issue 112912: On a VMware SASE Orchestrator with the New UI, a user logged in with an 'Enterprise Support' role when to 'Remote Actions' for an Edge, the 'Reboot' option is greyed out.

    An Enterprise Support user is able to remotely reboot an Edge when using the Classic UI and should be able to do this on the New UI as well.

  • Fixed Issue 113209: A user cannot delete a VMware SD-WAN Edge from the SASE Orchestrator if the Edge is in a 'Degraded' state.

    The Orchestrator throws an error message that reads "Degraded edges and connected edges cannot be deleted". While a user should not be able to delete a connected Edge, they should be able to delete a degraded Edge.

  • Fixed Issue 114224: On the VMware SASE Orchestrator when using the New UI, if an Operator removes Google Maps integration from the Orchestrator System Properties, the New UI continues to show Google Maps.

    When a user modifies the System Property service.client.googleMapsApi.enable to false to remove Google Maps integration for an On Premises customer, Google Maps integration should be removed from the New UI. Instead the change is only applied to the Classic UI.

  • Fixed Issue 114564: User cannot configure the 802.1P Setting under the optional configuration for an Edge Interface on the VMware SASE Orchestrator's New UI.

    While this setting shows up as an optional configuration on the Classic Orchestrator, this parameter is missing from the New UI, which is the default UI for Release 5.2.0.

  • Fixed Issue 114900: The "Non SD-WAN Destinations via Edge" tab is not visible for Enterprise Read Only users.

    The issue is caused by permissions being incorrectly configured for the Enterprise Read Only role.

  • Fixed Issue 115527: When a user configures a Non SD-WAN Destination via Edge with a Zscaler type, no tunnel status shows when looking at Monitor > Edges on the VMware SASE Orchestrator's New UI.

    The API used by the New UI to fetch Edge tunnel records makes a wrong assumption that the Edge software version always follows the format of "x.x.x" and thus, excludes tunnel status data from Edges whose version does not follow this format (for example, 5.1.0.3).

  • Fixed Issue 115719: A internet backhaul rule is not being retained in the Business Policy rule if any changes are made to Device Settings at the Profile level.

    The Orchestrator is mistakenly removing the backhaul rule on any change in the Device Settings section for a Profile.

  • Fixed Issue 116958: When using the VMware SASE Orchestrator's New UI, if an Operator user goes to the Operator Events page, they may observe an API error message.

    The issue is caused by the filters event cache not clearing and sharing for all Events pages. The Enterprise Events page should have forbidden values for Operator and Partner pages.

  • Fixed Issue 116976: For API users on the VMware SASE Orchestrator, getEnterpriseEdgeLInkStatus may not respond with links that have been disconnected for more than 24 hours when the API is invoked with the parameters {"detailed": true} and the caller is a Partner Administrator.

    There is a regression introduced in the 4.0.0 release that altered the API behavior to returning ONLY recent links for Partner Administrator logins. This issue does not affect Operator or Enterprise Administrator logins.

Known Issues

Open Issues in Release 5.2.0.

Edge/Gateway Known Issues

  • Issue 14655:

    Plugging or unplugging an SFP adapter may cause the device to stop responding on the Edge 540, Edge 840, and Edge 1000 and require a physical reboot.

    Workaround: The Edge must be physically rebooted. This may be done either on the Orchestrator using Remote Actions > Reboot Edge, or by power-cycling the Edge.

  • Issue 25504:

    Static route costs greater than 255 may result in unpredictable route ordering.

    Workaround: Use a route cost between 0 and 255.

  • Issue 25595:

    A restart may be required for changes to static SLA on a WAN overlay to work properly.

    Workaround: Restart Edge after adding and removing Static SLA from WAN overlay.

  • Issue 25742:

    Underlay accounted traffic is capped at a maximum of the capacity towards the VMware SD-WAN Gateway, even if that is less than the capacity of a private WAN link which is not connected to the Gateway.

  • Issue 25758:

    USB WAN links may not update properly when switched from one USB port to another until the VMware SD-WAN Edge is rebooted.

    Workaround: Reboot the Edge after moving USB WAN links from one port to another.

  • Issue 25885:

    A large configuration update on the Partner Gateway (e.g. 200 BGP-configured VRFs) may cause latency to increase for approximately 2-3 seconds for some traffic via the VMware SD-WAN Gateway.

    Workaround: No workaround available.

  • Issue 25921:

    VMware SD-WAN Hub High Availability failover takes longer than expected (up to 15 seconds) when there are three thousand branch Edges connected to the Hub.

    Workaround: No workaround available.

  • Issue 25997:

    The VMware SD-WAN Edge may require a reboot to properly pass traffic on a routed interface that has been converted to a switched port.

    Workaround: Reboot the Edge after making the configuration change.

  • Issue 26421:

    The primary Partner Gateway for any branch site must also be assigned to a VMware SD-WAN Hub cluster for tunnels to the cluster to be established.

    Workaround: No workaround available.

  • Issue 28175:

    Business Policy NAT fails when the NAT IP overlaps with the VMware SD-WAN Gateway interface IP.

    Workaround: No workaround available.

  • Issue 31210:

    VRRP: ARP is not resolved in the LAN client for the VRRP virtual IP address when the VMware SD-WAN Edge is primary with a non-global CDE segment running on the LAN interface.

    Workaround: No workaround available.

  • Issue 32731:

    Conditional default routes advertised via OSPF may not be withdrawn properly when the route is deactivated.

    Workaround: Reactivating the route, followed by deactivating it again will retract it successfully.

  • Issue 32960:

    Interface “Autonegotiation” and “Speed” status might be displayed incorrectly on the Local Web UI for activated VMware SD-WAN Edges.

    Workaround: Refer to the Orchestrator UI under Remote Diagnostics > Interface Status.

  • Issue 32981:

    Hard-coding speed and duplex on a DPDK-configured port may require a VMware SD-WAN Edge reboot for the configurations to take effect as it requires turning DPDK off.

    Workaround: There is no workaround for this issue.

  • Issue 34254:

    When a Zscaler CSS is created and the Global Segment has FQDN/PSK settings configured, these settings are copied to Non-Global Segments to form IPsec tunnels to a Zscaler CSS.

  • Issue 35778:

    When there are multiple user-defined WAN links on a single interface, only one of those WAN links can have a GRE tunnel to Zscaler.

    Workaround: Use a different interface for each WAN link that needs to build GRE tunnels to Zscaler.

  • Issue 36923:

    Cluster name may not be updated properly in the NetFlow interface description for a VMware SD-WAN Edge which is connected to that Cluster as its Hub.

  • Issue 38682:

    VMware SD-WAN Edge acting as a DHCP server on a DPDK-configured interface may not properly generate “New Client Device" events for all connected clients.

  • Issue 38767:

    When a WAN overlay that has GRE tunnels to Zscaler configured is changed from auto-detect to user-defined, stale tunnels may remain until the next restart.

    Workaround: Restart the Edge to clear the stale tunnel.

  • Issue 39374:

    Changing the order of VMware SD-WAN Partner Gateways assigned to a VMware SD-WAN Edge may not properly set Gateway 1 as the local Gateway to be used for bandwidth testing.

  • Issue 39608:

    The output of the Remote Diagnostic “Ping Test” may display invalid content briefly before showing the correct results.

    Workaround: There is not workaround for this issue.

  • Issue 39624:

    Ping through a subinterface may fail when the parent interface is configured with PPPoE.

    Workaround: There is no workaround for this issue.

  • Issue 39753:

    Toggling Dynamic Branch-to-Branch VPN to off may cause existing flows currently being sent using Dynamic Branch-to-Branch to stall.

    Workaround: Only deactivate Dynamic Branch-to-Branch VPN in a maintenance window.

  • Issue 40421:

    Traceroute is not showing the path when passing through a VMware SD-WAN Edge with an interface configured as a switched port.

  • Issue 40096:

    If an activated VMware SD-WAN Edge 840 is rebooted, there is a chance an SFP module plugged into the Edge will stop passing traffic even though the link lights and the VMware SD-WAN Orchestrator will show the port as 'UP'.

    Workaround: Unplug the SFP module and then replug it back into the port.

  • Issue 42278:

    For a specific type of peer misconfiguration, the VMware SD-WAN Gateway may continuously send IKE init messages to a Non-SD-WAN peer. This issue does not disrupt user traffic to the Gateway; however, the Gateway logs will be filled with IKE errors and this may obscure useful log entries.

  • Issue 42872:

    Activating Profile Isolation on a Hub profile where a Hub Cluster is associated does not revoke the Hub routes from the routing information base (RIB).

  • Issue 43373:

    When the same BGP route is learnt from multiple VMware SD-WAN Edges, if this route is moved from preferred to eligible exit in the Overlay Flow Control, the Edge is not removed from the advertising list and continues to be advertised.

    Workaround: Activate Distributed Cost Calculation (DCC) on the VMware SD-WAN Orchestrator.

  • Issue 44995:

    OSPF routes are not revoked from VMware SD-WAN Gateways and VMware SD-WAN Spoke Edges when the routes are withdrawn from the Hub Cluster.

  • Issue 45189:

    With source LAN side NAT is configured, the traffic from a VMware SD-WAN Spoke Edge to a Hub Edge is allowed even without the static route configuration for the NAT subnet.

  • Issue 45302:

    In a VMware SD-WAN Hub Cluster, if one Hub loses connectivity for more than 5 minutes to all of the VMware SD-WAN Gateways common between itself and its assigned Spoke Edges, the Spokes may in rare conditions be unable to retain the hub routes after 5 minutes. The issue resolves itself when the Hub regains contact with the Gateways.

  • Issue 46053:

    BGP preference does not get auto-corrected for overlay routes when its neighbor is changed to an uplink neighbor.

    Workaround: An Edge Service Restart will correct this issue.

  • Issue 46137:

    A VMware SD-WAN Edge running 3.4.x software does not initiate a tunnel with AES-GCM encryption even if the Edge is configured for GCM.

    Workaround: If a customer is using AES-256, they must explicitly deactivate GCM from the Orchestrator prior to upgrading their Edges to a 4.x Release. Once all their Edges are running a 4.x release, the customer may choose between AES-256-GCM and AES-256-CBC.

  • Issue 46216:

    On a Non SD-WAN Destinations via Gateway or Edge where the peer is an AWS instance, when the peer initiates Phase-2 re-key, the Phase-1 IKE is also deleted and forces a rekey. This means the tunnel is torn down and rebuilt, causing packet loss during the tunnel rebuild.

    Workaround: To avoid tunnel destruction, configure the Non SD-WAN Destinations via Gateway/Edge or CSS IPsec rekey timer to less than 60 minutes. This prevents AWS from initiating the re-key.

  • Issue 46391:

    For a VMware SD-WAN Edge 3800, the SFP1 and SFP2 interfaces each have issues with Multi-Rate SFPs (i.e. 1/10G) and should not be used in those ports.

    Workaround: Please use single rate SFP's per the KB article VMware SD-WAN SupportedSFP Module List (79270). Multi-Rate SFPs may be used with SFP3 and SFP4.

  • Issue 47664:

    In a Hub and Spoke configuration where Branch-to-Branch via Hub VPN is not configured, trying to U-turn Branch-to-Branch traffic using a summary route on an L3 switch/router will cause routing loops.

    Workaround: Configure Cloud VPN to activate Branch-to-Branch VPN and select “Use Hubs for VPN”.

  • Issue 47681:

    When a host on the LAN side of a VMware SD-WAN Edge uses the same IP as that Edge’s WAN interface, the connection from the LAN host to the WAN does not work.

  • Issue 48530:

    VMware SD-WAN Edge 6x0 models do not perform autonegotiation for triple speed (10/100/1000 Mbps) copper SFP's.

    Workaround: Edge 520/540 supports triple speed copper SFPs but this model has been marked for End-of-Sale by Q1 2021.

  • Issue 48597: Multihop BGP neighborship does not stay up if one of the two paths to the peer goes down.

    If there is a Multihop BGP neighborship with a peer to which there are multiple paths and one of them goes down, user will notice that the BGP neighborship goes down and does not come up using the other available path(s). This includes the Local IP-loopback neighborship case too.

    Workaround: There is no workaround for this issue.

  • Issue 50518:

    On a VMware SD-WAN Gateway where PKI is configured, if >6000 PKI tunnels attempt to connect to the Gateway, the tunnels may not all come up because inbound SAs do not get deleted.

    Note:

    Tunnels using pre-shared key (PSK) authentication do not have this issue.

  • Issue 51436: For a site using an Enhanced High-Availability topology while deploying a VMware SD-WAN Edge using an LTE modem, if the site gets into a "split-brain" state, the HA failover takes ~5-6 minutes.

    As part of the recovery from a split-brain state, the LAN ports are brought down on the Active Edge and this impacts LAN traffic during the time the ports are down and until the site can recover.

    Workaround: There is no workaround for this issue.

  • Issue 52955: DHCP decline is not sent from Edge and DHCP rebinding is not restarted after DAD failure in Stateful DHCP.

    If DHCPv6 server allocates an address which is detected as duplicate by the kernel during a DAD check then the DHCPv6 client does not send a decline. This will lead to traffic dropping as the interface address will be marked as DAD check failed and will not be used. This will not lead to any traffic looping in the network but traffic blackholing will be seen.

    Workaround: There is no workaround for this Issue.

  • Issue 53219: After a VMware SD-WAN Hub Cluster rebalances, a few Spoke Edges may not have their RPF interface/IIF set properly.

    On the affected Spoke Edges, multicast traffic will be impacted. What happens is that after a cluster rebalance, some of the Spoke Edge fail to send a PIM join.

    Workaround: This issue will persist until the affected Spoke Edge has an Edge Service restart.

  • Issue 53934: In an enterprise where a VMware SD-WAN Hub Cluster is configured, if the primary Hub has Multihop BGP neighborships on the LAN side, the customer may experience traffic drops on a Spoke Edge when there is a LAN side failure or when BGP is not configured on all segments.

    In a Hub cluster, the primary Hub has Multihop BGP neighborship with a peer device to learn routes. If the physical interface on the Hub by which BGP neighborship is established, goes down, then BGP LAN routes may not become zero despite BGP view being empty. This may cause Hub Cluster rebalancing to not happen. The issue may also be observed when BGP is not configured for all segments and when there are one or more Multihop BGP neighborships.

    Workaround: Restart the Hub which had the LAN-side failure (or BGP not activated).

  • Issue 57210: Even when a VMware SD-WAN Edge is working normally and is able to reach the internet, the LED in the Local UI's Overview page shows as "Red".

    The Edge's Local UI determines the Edge's connectivity by whether it can resolve a well known name via Google's DNS resolver (8.8.8.8). If it cannot do so for any reason, then it thinks it is offline and shows the LED as red.

    Workaround: There is no workaround for this issue, except to ensure that DNS traffic to 8.8.8.8 can reach the destination and be resolved successfully.

  • Issue 61543: If more than one 1:1 NAT rule is configured on different interfaces with the same Inside IP, the inbound traffic can be received on one interface and the outbound packets of the same flow can be routed via different interface.

    For the NAT flows from Outside to Inside, the 1:1 NAT rules will be matched against the Outside IP and the interface where the packets are received. For the outbound packets of the same flow, the VMWare SD-WAN Edge will try to match the NAT rules again comparing the Inside IP and the outbound traffic can be routed via the interface configured in the first matching rule with "Outbound Traffic" configured.

    Workaround: There is no workaround for this issue outside of ensuring no more than one 1:1 NAT rule is configured with a particular Inside IP address.

  • Issue 65560: Traffic from a customer to PE (Provider Edge) device fails.

    BGP neighborship between a Partner Gateway and Provider Edge does not get established when tag-type is selected as "none" on the handoff configuration. This is because ctag, stag values get picked from /etc/config/gatewayd instead of the handoff configuration on the Orchestrator when tag-type is "none".

    Workaround: Update the ctag, stag values to 0 each under vrf_vlan->tag_info in /etc/config/ gatewayd. Do a vc_procmon restart.

  • Issue 67879: A Cloud Security Service (CSS) tunnel is deleted after a user changes a WAN Overlay setting from auto-detect to user-defined on a WAN interface setting.

    After saving the changes, the CSS tunnels do not come back up until the customer takes down and then puts back up the tunnel. Changing the WAN configuration will bring down the CSS tunnel and parse the CSS setup again. However, in some corner cases, the nvs_config>num_gre_links is 0 and the CSS tunnel fails to come up.

    Workaround: Deactivate the CSS setup, and then reactivate it and this will bring the CSS tunnel up.

  • Issue 68057: DHCPv6 release packet is not sent from the VMware SD-WAN Edge on the changing of a WAN interface address mode from DHCP stateful to static IPv6 address and the lease remains active till reaching its valid time.

    The DHCPv6 client possesses a lease which it does not release when the configuration change is done. The lease remains valid till its lifetime expires in the DHCPv6 server and is deleted.

    Workaround: There is no way of remediating this issue as the lease would remain active till valid lifetime.

  • Issue 68851: If a VMware SD-WAN Edge and VMware SD-WAN Gateway each have the same TCP syslog server configured, the TCP connection is not established from the Edge to the syslog server.

    If the Edge and Gateway each have the same TCP server and if the syslog packets from the Edge are routed via the Gateway, the syslog server sends a TCP reset to the Edge.

    Workaround: Send the syslog packets direct from the Edge instead of routing via a Gateway or configure a different syslog server for the Edge and Gateway.

  • Issue 69284: For a site using a High-Availability topology where the Edges deploy VNF's in an HA configuration and are using Release 4.x, if these HA Edges are downgraded to a 3.4.x Release where HA VNF's are not supported, and then upgraded to 4.5.0, when the HA VNF's are reactivated, the Standby Edge VNF will not come up.

    The VNF state on the Standby Edge is communicated as down via SNMP. If the HA VNF pair is downgraded from a version supporting VNF-HA (release 4.0+) to a release which does not support it with VNF configured on the Orchestrator. This issue will be seen when the Edge is upgraded back to a version supporting VNF-HA and it is configured on the Orchestrator again.

    Workaround: VNF should first be deactivated in the case of an HA configuration if the Edge is being downgraded to a version which does not support it.

  • Issue 72358: If the IP address of a VMware SD-WAN Orchestrator DNS name changes, the VMware SD-WAN Gateway's management plane process fails to resolve it properly and the Gateway will be unable to connect to the Orchestrator.

    The Gateway's management process periodically checks the DNS resolution of the

    Orchestrator's DNS name, to see if it has changed recently so that the Gateway can connect to the right host. The DNS resolution code has an issue in it so that all of these resolution checks fail, and the Gateway will keep using the old address and thus no longer be able to connect to the Orchestrator.

    Workaround: Until this issue is resolved, an Operator User should not change the IP address of the Orchestrator. If the Orchestrator's IP address must be changed, all Gateways connecting to that Orchestrator will have to be reactivated.

  • Issue 77541: When a USB modem that supports IPv6 is unplugged and then replugged into a VMware SD-WAN Edge USB interface, an IPv6 address may not provisioned to the USB interface.

    This affects USB modems that are IP-based, versus being managed by the ModemManager application. Most Inseego modems are IP-based and this is important because Inseego is the modem manufacturer VMware SASE recommends. USB modems supporting IPv6 which use ModemManager versus being IP-based will be fine in a plug out and plug in scenario.

    Workaround: The Edge needs to be rebooted (or power-cycled) after the USB modem is replugged into the Edge's USB port. Post reboot, the Edge will retrieve the IPv6 address for the modem.

  • Issue 81852: For a VMware SD-WAN Edge that is using a Zscaler type Cloud Security Service (CSS) which uses GRE tunnels that has turned on L7 Health Check, when that Edge is upgraded to Release 5.0.0, in some instances the customer may observe L7 Health Check errors.

    This is typically seen during software upgrade or during startup time. When L7 Health check for a CSS using GRE tunnels is turned on, error messages related to socket getaddress error may be seen. The observed error is intermittently seen, and not consistent. Because of this, L7 Health Check probe messages are not sent out.

    Workaround: Without the fix, to remediate the issue, a user needs to turn off and then turn back on the L7 Health Check configuration, and this feature would then work as expected.

  • Issue 82184: On a VMware SD-WAN Edge which is running Edge Release 5.0.0, when a traceroute or traceroute6 is run to the Edge's br-network IPv4/IPv6 address, the traceroute will not properly terminate when a UDP probe used.

    Traceroute or traceroute6 to the Edge's br-network IPv4/IPv6 address will not properly when Default Mode (in other words, UDP probe) is used.

    Workaround: Use -I option in traceroute and traceroute6 to use ICMP probe and then traceroute to br-network IPv4/IPv6 address will work as expected.

  • Issue 85402: For a customer enterprise using BGP with Partner Gateways configured, a user may obseve that some BGP neighborships are down and this causes customer traffic issues.

    If a customer has maximum-prefix configured on a router which has BGP peering with the Edge and Gateway, the BGP session may be dropped by the router.

    For example, if the router has BGP configured to only receive max 'n' number of prefixes, but the Edge and Gateway have more than 'n' number of prefixes to be advertised in the absence of any filters. Now if the BGP filter configuration is changed on the Orchestrator, even if the total number of prefixes allowed in the outbound direction is less than 'n', the issue will be encountered where more than 'n' prefixes are sent to the peer before any filters are applied. This causes the router to tear down the session.

    Workaround: If BGP goes down due to this issue (Maximum Number of Prefixes Reached), flap BGP on the peer using CLI (For FRR/Cisco, "neighbor x shut" followed by "no neighbor x shut"), and the BGP will produce only the desired number of prefixes advertised to the peer.

  • Issue 98136: For customer enterprises using a Hub/Spoke topology where Dynamic Branch To Branch VPN is configured, client users behind a SD-WAN Spoke Edge may observe that some traffic has unexpected latency resulting from the traffic using a sub-optimal path.

    Spoke Edge traffic that experiences this issue uses a route that was initially a non-uplink route for a Hub Edge not included in the Profile the Spoke Edge was using. A Dynamic Branch-to-Branch VPN tunnel can be formed from the Spoke Edge to the Hub Edge because of traffic being sent towards some other unrelated prefix and in this instance the non-uplink route is installed in the Spoke Edge.

    As a result of this non-uplink route, all traffic towards this prefix starts going through the

    Hub Edge and the non-uplink route becomes uplink (community change to uplink community) but the non-uplink route installed previously is not revoked and the traffic takes the Hub Edge path as long as the Dynamic Branch-to-Branch VPN tunnel remains up.

    Workaround: Wait for the Dynamic Branch-to-Branch VPN tunnel to tear down, after which the uplink route will not be installed in the Spoke Edge when a new Dynamic Branch-to-Branch VPN tunnel is formed towards the Hub Edge.

  • Issue 109771: A VMware SD-WAN Edge may not be able to establish a tunnel with a Cisco CSR/ASE type Non SD-WAN Destination via Edge when NAT66 is applied in between.

    If between two peers a source IPv6 address NAT is involved with a Cisco CSR/ASA, then a tunnel is not established.

    Workaround: On an Edge without a fix for this issue, the only thing a user can do is upgrade the Cisco CSR/ASA to a version of Cisco software that supports NAT66 over IPsec.

  • Issue 110561: Dynamic tunnels may not come up between the same set of VMware SD-WAN Edges with bidirectional traffic when traffic stops and then restarts.

    Issue is observed in a test environment where there are 6000 dynamic tunnels with high bidirectional traffic being sent between the Edges. Even in lower scale testing at 1000 dynamic tunnels, not all the tunnels come up.

    Workaround: There is no workaround for this issue.

  • Issue 111085: When a VMware SD-WAN Edge's WAN link is configured with an IP address in the same network as the Edge's loopback IP, the Edge uses the MAC address of the WAN interface while responding to an ARP request for the Edge's loopback IP address.

    This can cause ARP spoof and results in the Management IP being deprecated and network disruptions as a result.

    Workaround: There is no workaround for this issue.

  • Issue 113877: For customers who configure BGP/GRE LAN, those using a TGW GRE will experience BGP flaps and traffic interruption on the TGW secondary tunnel in all segments when the BGP configuration for TGW GRE is modified on the Global segment.

    When customer changes a BGP configuration of TGW GRE on the global segment then the secondary tunnel in the global and other segments flap, leading to a BGP connection reset and reconvergence and traffic interruption. The BGP connection will form again, and traffic will restore.

    Workaround: There is no workaround for this issue.

  • Issue 117037: For a customer using a Hub/Spoke topology where multiple WAN links are used to send and receive traffic from the Spoke Edge to the Hub Edge, customers may observe lower than expected performance for traffic that is steered by Business Policies because the WAN links are not aggregating the WAN link's bandwidth.

    SD-WAN uses a counter for accounting the number of packets buffered in a resequencing queue. This counter is managed per peer and used to make sure only 4K packets are buffered per peer. Under some conditions, this counter can become negative. Prior to Release 4.2.x, when this counter became negative, the respective counter was immediately reset back to 0 after flushing the packets in the resequencing queue. However, starting in Release 4.3.x, this counter is updated automatically to ensure that the counter stays within expected bounds.

    The result of this change in behavior can cause cases where the counter accounting is incorrect and the resequencing queue can stay at a very high number to which SD-WAN reacts by flushing every single packet. This action not only prevents bandwidth aggregation but can reduce the effectiveness of flows that would otherwise be on a single link.

    Workaround: On Edges without a fix for this issue, the workaround is to configure business policies that steer matching traffic to a single mandatory link.

  • Issue 117314: When an ICMP flow already exists between a Source and Destination IP address pair, a Firewall rule that uses an Object Group/Service Group (type and code) to filter ICMP packets may not work.

    As part of a revision to Firewall funtionality, the changes introduced for caching ICMP type and code were reverted, and this impacted Firewall rules which used a Service Group with an ICMP type and code (for example, ICMP Redirect Type 5 and Code 0). If a flow is already present between a source and destination IP address, then ICMP traffic that should match the rules for this flow will not be honored, and only the first packets for a session will match the Firewall rules. The issue impacts either IPv4 or IPv6 ICMP flows.

    Workaround: Flushing flows to create new ICMP flows will temporarily remediate the issue.

  • Issue 117876: In a customer site using a High Availability topology, if a user activates or deactivates the Enhanced Firewall Services, a VMware SD-WAN HA Edge may experience multiple restarts.

    When Enhanced Firewall Services is activated or deactivated, only the Active Edge's Device Settings configuration is synchronized immediately with the Standby Edge, with the remainder of the configuration synchronization is only in response to a Standby Edge heartbeat. When the Active Edge is restarted to apply the latest configuration prior to receiving a heartbeat from the Standby Edge it will result in a configuration mismatch between the two HA Edges and they will undergo multiple restarts to complete the configuration synchronization.

    Workaround: The only workaround is to turn on or off Enhanced Firewall Services during a maintenance window for HA Edges.

  • Issue 121606: Customer enterprises using Partner Gateways may observe that traffic drops for some traffic including Non SD-WAN Destinations using that Gateway.

    Release 5.1.0 and later Partner Gateways support a maximum of 64 IP addresses per IPsec interface. For a Partner Gateway, handoff IPs are getting added to this IPsec interface unconditionally. If the number of handoff IP addresses exceeds the 64 limit, older IP addresses are overwritten on the IPsec process and this results in the tunnels using those overwritten IP addresses to go down.

    Workaround: If all the Partner Gateway handoff IP addresses are configured as expected there is no workaround beyond moving some of those addresses to a different PG (for example, moving an NSD via Gateway). However, if there are unnecessary PG handoff IP addresses, removing them may help if this action results in the reduction of the total handoff IP addresses to 63 or less. After a configuration change, the Gateway service needs to be restarted.

  • Issue 121998: For a customer using the Stateful Firewall in a Hub/Spoke topology, traffic that matches a firewall rule configured for Spoke-to-Hub traffic where the rule includes a source VLAN may be dropped.

    When there is an application classification, business policy table, or firewall policy table version change, SD-WAN performs a firewall lookup for flows on its next packet. Due to a timing issue, that packet could be one from the management traffic (VCMP) side. As a result, during a firewall policy lookup key creation, SD-WAN swaps the Spoke Edge VLAN with the Hub Edge VLAN and this leads to not matching the rule and dropping that traffic.

    Workaround: A customer can to change the Source from an Edge VLAN to 'Any'.

  • Issue 125274: When a customer runs an SNMP walk, the loopback interface of the VMware SD-WAN Edge is not discovered.

    The Edge loopback interface is a unique interface category that the Edge does not classify as either WAN or LAN. As a result, the loopback interface is not in the allow list of interfaces to process for the snmp-request.

    Workaround: There is no workaround for this issue. The loopback interface status would have to be individually monitored through the Orchestrator UI.

  • Issue 125421: A customer may observe that the WAN links on a VMware SD-WAN Edge are intermittently showing as down and then up on the Monitoring and Events page of the VMware SASE Orchestrator UI, with the potential the Edge may become unresponsive and fail to pass traffic until it is manually rebooted, or the Edge can experience a Dataplane Service failure and restart.

    This is an Edge memory leak issue that is encountered when the Edge Dataplane Service cannot open shared memory, causing stale PIs. This in turn causes open file descriptor exhaustion which will initially impact WAN links. However if this issue is sufficiently advanced and results in Edge memory exhaustion the Edge can:

    1. Become unresponsive and unreachable through the Orchestrator, which requires an on-site reboot/power cycle.

    2. Can trigger an Edge service failure with a core file generated, with the Edge restarting to recover.

    Workaround: If first observing this issue, schedule an Edge service restart in a maintenance window before the issue worsens.

  • Issue 131029: For a customer enterprise site that uses one or more PPPoE links, when the VMware SD-WAN Edge is either deployed or upgraded to Release 5.2.0.x, the PPPoE links may fail to come back up.

    Post-upgrade the Edge process that handles PPPoE interfaces fails because a key configuration file is missing and this results in the failure of any PPPoE links on the Edge.

    Workaround: If an Edge encounters this issue, there is no workaround beyond:

    1. Upgrading the Edge to any 5.2.2.x build. This version includes a fix for this issue and resolves the condition and prevents it from recurring. It is strongly recommended to use this method.

    2. If a customer wants to continue using a 5.2.0.x build, they can contact VMware SD-WAN Support who can correct the issue for the customer on a per Edge basis.

  • Issue 134374: Inbound firewall rules associated with a VMware SD-WAN Edge CELL interface are not applied as expected in a sequence.

    If the Edge CELL interface has either not yet been created or is not up (for example, no SIM card inserted), when the Firewall configuration is parsed, then the CELL interface value does not get populated correctly for the Firewall rule and traffic does not match the rule.

    Workaround: Delete the rule and recreate it after the CELL interface is up.

Orchestrator Known Issues

  • Issue 21342:

    When assigning Partner Gateways per-segment, the proper list of Gateway Assignments may not show under the Operator option "View" Gateways on the VMware SD-WAN Edge monitoring list.

  • Issue 24269:

    Monitor > Transport > Loss not graphing observed WAN link loss while QoE graphs do reflect this loss. 

  • Issue 25932:

    The VMware SD-WAN Orchestrator allows VMware SD-WAN Gateways to be removed from the Gateway Pool even when they are in use.

  • Issue 32335:

    The ‘End User Service Agreement’ (EUSA) page throws an error when a user is trying to accept the agreement.

    Workaround: Ensure no leading or trailing spaces are found in Enterprise Name.

  • Issue 32435:

    A VMware SD-WAN Edge override for a policy-based NAT configuration is permitted for tuples which are already configured at the profile level and vice versa.

  • Issue 32856:

    Though a business policy is configured to use the Hub cluster to backhaul internet traffic, the user can unselect the Hub cluster from a profile on a VMware SD-WAN Orchestrator that has been upgraded from Release 3.2.1 to Release 3.3.x.

  • Issue 35658:

    When a VMware SD-WAN Edge is moved from one profile to another which has a different CSS setting (e.g. IPsec in profile1 to GRE in profile2), the Edge level CSS settings will continue to use the previous CSS settings (e.g. IPsec versus GRE). 

    Workaround: At the Edge level, deactivate GRE, and then reactivate GRE to resolve the issue.

  • Issue 35667:

    When a VMware SD-WAN Edge is moved from one profile to another profile which has the same CSS setting but a different GRE CSS name (the same endpoints), some GRE tunnels will not show in monitoring.

    Workaround: At the Edge level, deactivate GRE and then reactivate GRE to resolve the issue.

  • Issue 36665:

    If the VMware SD-WAN Orchestrator cannot reach the internet, user interface pages that require accessing the Google Maps API may fail to load entirely.

  • Issue 32913:

    After activating High Availability, multicast details for the VMware SD-WAN Edge are not displayed on the Monitoring Page. A failover resolves the issue.

  • Issue 33026:

    The ‘End User Service Agreement’ (EUSA) page does not reload properly after deleting the agreement.

  • Issue 38056:

    The Edge-Licensing export.csv file not show region data.

  • Issue 38843:

    When pushing an application map, there is no Operator event, and the Edge event is of limited utility.

  • Issue 39633:

    The Super Gateway hyperlink does not work after a user assigns the Alternate Gateway as the Super Gateway.

  • Issue 39790:

    The VMware SD-WAN Orchestrator allows a user to configure a VMware SD-WAN Edge’s routed interface to have greater than the supported 32 subinterfaces, creating the risk that a user can configure 33 or more subinterfaces on an interface which would cause a Dataplane Service Failure for the Edge.

  • Issue 41691:

    User cannot change the 'Number of addresses' field although the DHCP pool is not exhausted on the Configure > Edge > Device page.

  • Issue 43276:

    User cannot change the Segment type when a VMware SD-WAN Edge or Profile has a Partner Gateway configured.

    Workaround: Temporarily remove the Partner Gateway configuration from the Profile or Edge so that the Segment can be changed between private and regular. Alternatively, the user can remove the Segment from the profile and make the change from there.

  • Issue 47713:

     If a Business Policy Rule is configured while Cloud VPN is toggled off, the NAT configuration must be reconfigured upon turning on Cloud VPN.

  • Issue 47820:

    If a VLAN is configured with DHCP toggled off at the Profile level, while also having an Edge Override for this VLAN on that Edge with DHCP activated, and there is an entry for the DNS server field set to none (no IP configured), the user will be unable to make any changed on the Configure > Edge > Device page and will get an error message of ‘invalid IP address []’ that does not explain or point to the actual problem.

  • Issue 48085: The VMware SD-WAN Orchestrator allows a user to delete a VLAN which is associated with an interface.

    When encountering this issue, the user would see an error message similar to "VLAN ID [xx] cannot be removed, in use by edge [b1-edge1 (GEx-disabled]".

  • Issue 51722: On the VMware SASE Orchestrator, the time range selector is no greater than two weeks for any statistic in the Monitor > Edge tabs.

    The time range selector does not show options greater than "Past 2 Weeks" in Monitor > Edge tabs even if the retention period for a set of statistics is much longer than 2 weeks. For example, flow and link statistics are retained for 365 days by default (which is configurable), while path statistics are retained only for 2 weeks by default (also configurable). This issue is making all monitor tabs conform to the lowest retained type of statistic versus allowing a user to select a time period that is consistent with the retention period for that statistic.

    Workaround: A user may use the "Custom" option in the time range selector to see data for more than 2 weeks.

  • Issue 60522: On the VMware SD-WAN Orchestrator UI, the user observes a large number of error messages when they try to remove a segment.

    The issue can be observed when adding a segment to a profile and the associating the segment with multiple VMware SD-WAN Edges. When the user attempts to remove the added segment from the profile, they will see a large number of error messages.

    Workaround: There is no workaround for this issue.

  • Issue 82095: User can configure invalid device settings for Edge VLANs that will result in significant connectivity issues for the Edge.

    The Orchestrator is not attempting to validate device configurations. In particular, a VLAN configuration for a switched port with an empty table. Some configurations can be so full of errors that the Edge's management process will fail.

    Workaround: Review all VLAN Device settings and ensure they are valid as the Orchestrator is not checking.

  • Issue 82680: For customer using MT-GRE Tunnel Automation, when a user turns off the Cloud-to-Cloud Interconnect (CCI) flag on a VMware SD-WAN Gateway which is configured to use CCI, the Zscaler MT-GRE entries may not get deleted from the Zscaler portal consistently.

    After a CCI site has been deleted from the Gateway, the entries for this site should also be removed. This issue has only been seen during test automation and has not been reproduced manually, but remains a risk.

    Workaround: Manually delete the resource from Zscaler before retrying.

  • Issue 82681: For customer using MT-GRE Tunnel Automation, when a user turns off the Cloud-to-Cloud Interconnect (CCI) flag on a VMware SD-WAN Gateway which is configured to use CCI, and the user deactivates the CCI flag from a VMware SD-WAN Edge with CCI configured which is using a Zscaler Cloud Security Service, the Zscaler MT-GRE entries may not get deleted from the Edge or from the Zscaler portal.

    After a CCI site has been deleted from the Gateway, the entries for this site should also be removed. This issue has only been seen during test automation and has not been reproduced manually, but remains a risk.

    Workaround: Manually delete the resource from Zscaler before retrying.

  • Issue 103769: An Operator may observe that a VMware SASE Orchestrator in a large scale deployment is experiencing performance issues which include 100% disk utilization and the Orchestrator no longer accumulating logs.

    This issue arises a change in logging behavior for the 5.1.0 Orchestrator that may result in the folders that store logs becoming full and also causing the Orchestrator CPU to reach 100% utilization. This issue arises a change in logging behavior for the 5.1.0 Orchestrator that may result in the folders that store logs becoming full and also causing the Orchestrator CPU to reach 100% utilization.

    Workaround: A Superuser Operator needs to log into the Orchestrator and clean up the pending logs.

  • Issue 117699: An Operator attempting to upgrade a 4.2.x VMware SD-WAN Orchestrator to become a Release 5.2.0 SASE Orchestrator may observe that the upgrade fails.

    The upgrade does not succeed, effectively stuck at the "Waiting for the CWS service up...". This issue is limited to 4.2.x Orchestrators.

    Workaround: The workaround for this issue is to upgrade the 4.2.x Orchestrator to 4.5.1 first, and then to Release 5.2.0.0.

  • Issue 118501: On the Monitor > Edges page, if a user clicks on CSV to download their list of all SD-WAN Edges, the Orchestrator will only download a maximum of 2048 Edges.

    This impacts customers with greater than 2048 Edges in their enterprise who need to download a complete list of all Edges.

    Workaround: The only workaround is to break up the download into two or more parts by sorting the Edges.

  • Issue 122193: On the Configure > Edges > Firewall page, when configuring a Firewall rule for an Edge, for Firewall Action a user can only select 'Allow'.

    The user would click on the Firewall Action and the dropdown menu appears for a split second and then goes away immediately, and the user cannot change from the default Allow to any other option.

    Workaround: There is no workaround for this issue.

  • Issue 125082: If a user configures a VMware SD-WAN Edge with an overridden DNS Server IP address on a VLAN, and then changes an interface setting for the Profile that Edge is using, the DNS Server IP address is no longer present for the Edge VLAN.

    The UI does not send the override flag inside of the DHCP section and this causes any Profile changes to trigger an override of the DHCP section.

    Workaround: After a Profile change, the user would need to review and correct overridden DHCP options on individual Edges.

  • Issue 125504: If a static route is configured with next hop as a VLAN with IPv4/IPv6 address at the Profile level and then overridden at the Edge level and add an IPv4/IPv6 address to the VLAN, the static route is not marked as N/A and the VMware SASE Orchestrator asks for the interface in a dropdown menu.

    The expected behavior is where a static route configured with a next hop as a VLAN with IPv4/IPv6 address, the Orchestrator does not ask for the interface and the route is marked as N/A.

    Workaround: There is no workaround for this issue.

  • Issue 125663: A user can configure the same IPv4/IPv6 IP address for multiple Edge interfaces.

    The VMware SASE Orchestrator is allowing a user to configure the same IP on multiple WAN, LAN, or Sub Interfaces.

    Workaround: There is no workaround for this issue beyond ensuring you are not configuring the same IP Address for multiple interfaces.

  • Issue 126421: For Partners using a Partner Gateway, when configuring the Hand Off Details, the "Use for Private Tunnels" option is always checked no matter what a user does.

    This is not a cosmetic issue as the Orchestrator will apply the Use for Private Tunnels configuration to the Partner Gateway handoff and can impact customer traffic using the Partner Gateway.

    Workaround: There is no workaround for this issue on an Orchestrator with only a New User Interface.

  • Issue 126425: When looking at Configure > Device > Routing & NAT page at the Profile level, the OSPF On/Off toggle button is missing.

    The OSPF On/Off toggle button was not migrated to the New UI at the Profile level and only shows at the Edge level.

    Workaround: There is no workaround for this issue on an Orchestrator with only a New User Interface.

  • Issue 126465: The VMware SASE Orchestrator UI is not applying changes a user makes to create an Edge Cluster.

    If a user goes to the Configure > Edge > High Availability section of the UI and turns on HA with a Cluster type and creates a Hub Cluster with name xxxx, and saves changes, the user would observe that post-save the Cluster option is not selected under HA section and the created Hub Cluster with name xxxx is not present.

    Workaround: There is no workaround for this issue on an Orchestrator with only a New User Interface.

  • Issue 127152: Users cannot save modified Interfaces with OSPF configurations on the VMware SASE Orchestrator UI.

    At the Profile level, when configuring either OSPFv2/OSPFv3, the Edit Interface dialog becomes invalid after changing any OSPF data.

    Workaround: On an Orchestrator without a fix for this issue, a user would need to activate MD5 Authentication and change the Key ID to any number from 1 to 255, and then deactivate MD5 Authentication.

  • Issue 128070: When a user is configuring OSPFv3 for a VLAN at the Edge level and attempts to add IPv6 Settings to the VLAN, the VMware SASE Orchestrator UI does not save the changes.

    The option to Save is grayed out and not available when attempting to add IPv6 Settings to a VLAN with OSPF3 at the Edge level.

    Workaround: There is no workaround for this issue on an Orchestrator with only a New User Interface.

  • Issue 129232: A user cannot perform a password self-reset on the VMware SASE Orchestrator.

    When the user tries to access the self-password reset link directly in the browser, they are redirected to the login page instead of the password reset page.

    Workaround: A user who needed to reset their password would need to reach out to an Enterprise Superuser in their organization, a Partner Administrator (if applicable), or VMware SD-WAN Support to reset their password.

  • Issue 129412: On the Configure > Edge > Device > Connectivity > VLAN page of the UI, on the IPv4 DHCP Server section, the Number of Addresses displayed may be inaccurate.

    The behavior is seen if a user edits the original DHCP value later to increase the number of addresses and the UI continues to display the older, lower number of addresses.

    Workaround: This is a cosmetic issue and the actual DHCP value is applied.

  • Issue 129662: A user cannot tell if a VMware SD-WAN interface is enabled or disabled when looking at the Configure > Edge > Device > Interfaces page of the Orchestrator UI.

    The VMware SASE Orchestrator UI does not have color differentiation between enabled and disabled interfaces, preventing customers from identifying a sub-interface that is deactivated.

    Workaround: There is no workaround for this issue.

  • Issue 129958: On the Configure > Edge > Device > Connectivity > VLAN page of the UI, on the IPv4 DHCP Server section, the user cannot change the Number of Addresses unless they first override the general VLAN.

    Previously, a user could do an override a subsection of an Edge VLAN like DHCP or OSPF while accepting the remainder of the configuration from the profile. In this instance the user must override the entire VLAN so that they can edit the DHCP portion of it.

    Workaround: A user can only override the entire VLAN to edit settings within it.

  • Issue 131299: On the Configure > Overlay Flow Control page of the UI, when the user changes the segment for a Non SD-WAN Destination via Gateway which uses static routes, the OFC table does not display the updated static routes.

    Instead the OFC table shows the results using the previously selected segment which will mislead the user into thinking their configuration change was not applied when it actually was.

    Workaround: There is not workaround, but this issue is cosmetic and the static routes are indeed to changed to the new segment.

  • Issue 131997: An ICMP probe may be erroneously marked as down when it is configured for one segment but not for another.

    The Orchestrator fails to send the NULL ICMP probe configuration when it is not configured in a segment. As a result, the configuration of a different segment is reused and this causes the probes to fail.

    Workaround: On an Orchestrator without a fix for this issue, configure a dummy ICMP probe for the other segments.

  • Issue 133201: On the Global Settings > User Management page of the Orchestrator UI, If a user is creating or editing a custom role and attempts to change the 'Delete' parameter for PCAP Bundle privileges, the UI also changes all other parameters for PCAP Bundle.

    For example, if a user elects to disable PCAP Bundle Deletion, the UI also disables the Read, Update, and Create parameters as well, even if the user wanted those parameters to remain enabled.

    Workaround: A user must be mindful of the changes being made and revert back the Read, Update, and Create parameters as needed.

  • Issue 133642: On the Configure > Edge > Device > Connectivity > VLAN page of the UI, the Edge's VLAN is automatically set to Override by default, and a user cannot deactivate this setting.

    The expected behavior is that if a user creates a VLAN at the Profile level, that the Edge Override setting is deactivated by default and a user must elect to activate Edge Override on a per Edge basis.

    Workaround: There is no workaround beyond inspecting each Edge using that Profile and deactivating Edge Override as needed.

check-circle-line exclamation-circle-line close-line
Scroll to top icon