Updated 31 March, 2023 VMware SD-WAN™ Orchestrator Version R420-20211220-GA VMware SD-WAN™ Gateway Version R420-20210208-GA-53243-54800 VMware SD-WAN™ Edge Version R420-20201218-GA Check regularly for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

• Recommended Use
• Compatibility
• Important Notes
• New Features
• New Hardware Platforms
• Feature Enhancements
• Orchestrator API Changes
• Revision History
• Resolved Issues
• Known Issues

Recommended Use

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

Compatibility

Release 4.2.0 Orchestrators, Gateways, and Hub Edges support all previous VMware SD-WAN Edge versions greater than or equal to Release 3.0.0 
Note: this means releases prior to 3.0.0 are not supported.

The following interoperability combinations were explicitly tested:

Orchestrator	Gateway	Edge
		Hub	Branch/Spoke
4.2.0	4.0.0	4.0.0	4.0.0
4.2.0	4.2.0	4.0.0	4.0.0
4.2.0	4.2.0	4.2.0	4.0.0
4.2.0	4.2.0	4.0.0	4.2.0
4.2.0	3.4.4	3.4.4	3.4.4
4.2.0	4.2.0	3.4.4	3.4.4
4.2.0	4.2.0	4.2.0	3.4.4
4.2.0	4.2.0	3.4.4	4.2.0
4.2.0	3.3.2 P2	3.3.2 P2	3.3.2 P2
4.2.0	4.2.0	3.3.2 P2	3.3.2 P2
4.2.0	4.2.0	4.2.0	3.3.2 P2
4.2.0	4.2.0	3.3.2 P2	4.2.0
4.2.0	3.2.1	3.2.1	3.2.1
4.2.0	4.2.0	3.2.1	3.2.1
4.2.0	4.2.0	4.2.0	3.2.1
4.2.0	4.2.0	3.2.1	4.2.0

Note: Release 3.x did not properly support AES-256-GCM, which meant that customers using AES-256 were always using their Edges with GCM disabled (AES-256-CBC). If a customer is using AES-256, they must explicitly disable 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.

Important Notes

BGPv4 Filter Configuration Delimiter Change for AS-PATH Prepending

Through Release 3.x, the VMware SD-WAN BGPv4 filter configuration for AS-PATH prepending supported both comma and space based delimiters. However, beginning in Release 4.0.0 and forward, VMware SD-WAN will only support a space based delimiter in an AS-Path prepending configuration.
Customers upgrading from 3.x to 4.x need to edit their AS-PATH prepending configurations to "replace commas with spaces" prior to upgrade to avoid incorrect BGP best route selection.

Local User Interface

Beginning in Release 4.2.0, the VMware SD-WAN Edge's Local User Interface (UI) will switch from using http to https for any browser session.

Added Capabilities From Release 4.1.0

Some hosted Orchestrators will upgrade directly from 4.0.x to 4.2.0, so please review Release 4.1.0 for additional capabilities available after the upgrade.

Reverse-Path Forwarding (RPF) Enabled by Default

In previous releases, packets with an unknown source were allowed from the LAN interface of a VMware SD-WAN Edge. This behavior was the result of the Edge's LAN interfaces not having reverse-path forwarding (RPF) enabled by default. As part of Fixed Issue 52628, this behavior is changed with RPF enabled on all Edge LAN interfaces, and packets from LAN interfaces would be allowed only if the packets are sourced from the configured LAN subnet.

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

When a user disables 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 Disabling Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810 (87208).

New Features

Multihop BGP Support 

Previous versions of the VMware SD-WAN Edge required that BGP peers were on the same subnet as the BGP-enabled interface, which may not always be achievable in customer topologies. With the addition of Multihop BGP support, the BGP peers can be in different subnets which are one or more hops away from the Edge.

Multihop BFD Support

In addition to the Multihop BGP feature above, a generic next hop resolution framework has also been added which extends this to support BFD peers in different subnets that are one or more hops away from the Edge or Gateway.

New Hardware Platforms

Edge 610-LTE

The 610-LTE includes integrated LTE (similar to the Edge 510-LTE) along with higher performance, a greater number of available network interfaces, and support for the FirstNet responder network.

Edge 3810

The Edge 3810 is a variant of Edge 3800 with 8x 10GE SFP+ ports. All performance and scale capabilities of the Edge 3810 match those of the Edge 3800.

Please contact your sales team for further details about these new hardware models. 

Feature Enhancements

Zscaler API Automation 

Zscaler Automation now supports Sub-Locations. This enables customers to define associate Zscaler sub-locations with a group of subnets within a branch on the VCO. Customers can define security policies per segment, per subnet or a group of subnets. To learn more, please consult VMware SD-WAN's Zscaler documentation.

Support for Secondary IP Addresses on LAN VLANs 

Similar to routed interfaces, users may now add multiple secondary IP address to VLANs that are used on LAN switch ports.

Conditional Backhaul

Business Policy Based Conditional Backhaul now supports failover for Cloud Security Service (CSS) traffic, allowing traffic to fail over when the CSS tunnel(s) are down, even if the public Internet link(s) are up.

GPON Support on Edge 6X0

Fiber to the home (FTTH) is now supported via Gigabit Passive Optical Network, or GPON. GPON support is added to VMWare SD-WAN Edge models 610, 620, 640, and 680 when installing the Nokia G-010S-A GPON ONT SFP.

Note: The Nokia G-010S-A GPON ONT SFP, 1 x GE UNI (Part # 3FE46541AA) with firmware 3FE47111BFHB32 is tested and supported on Edge models 610, 620, 640, and 680. VMware SD-WAN does not support any other GPON SFP modules. GPON is only supported in Release 4.2.0 and later.

Enhanced High Availability

LTE modems (USB 4G modems as well as the integrated LTE modem in the VMware SD-WAN Edge 510-LTE and 610-LTE) are now supported in Enhanced High Availability deployments. To learn more, please consult the Enhanced HA documentation.

Reports

The following enhancements are added to Reports:

• Four new reports are available:
  • Top talkers
  • Top non SD-WAN sites from Edge
  • Top Non SD-WAN sites from Gateway
  • Top backup links by usage  
• Any previously run report can be used as a template to create a new report, allowing a user to start a new report from the configurations of a prior report. A user can also change the report configuration as needed.
• Branding is available on the New Orchestrator UI and reports. Report branding will align with the Orchestrator.
• Reports can be generated in all the languages supported on the Orchestrator.

Orchestrator Localization

The VMware SD-WAN Orchestrator UI now supports localization in French and German. Please use the browser language setting to select the Orchestrator language.

Orchestrator API Changes

Introducing APIv2

Release 4.2.0 introduces a new VMware SD-WAN Orchestrator REST API, which will be referred to as “APIv2” because it is intended to gradually replace the Orchestrator Portal API (i.e., APIv1) as the primary interface supported for Partner and Customer development. 

APIv2 aims to address many persisting usability and scalability issues reported by users of the Orchestrator Portal API, and revisits some of the fundamental design conventions and abstractions in order to produce an interface more accessible to first-time users. 

APIv2 debuts with support for customer monitoring operations (e.g., querying device statistics, customer events, customer alerts, Edge and link availability, etc.). We expect to introduce incremental functionality in future releases until the API achieves feature parity with the existing Orchestrator Portal API. 
For the time being, the Orchestrator Portal API will continue to be developed and supported alongside APIv2 as the new API undergoes further development. 

The APIv2 Documentation is available via developer.vmware.com. 

Portal API 

The complete 4.2.0 Portal API reference is available via code.vmware.com. 

Notable changes in this release include: 

• Addition of support for VLAN "secondaryIp" options in deviceSettings configuration module. 

• Addition of "sourceFromSecondaryIp" option to "dhcpRelay" settings for VLANs and routed interfaces. 

• Addition of support for configuration of Zscaler sub-locations via an array of "css->subLocations" options contained within deviceSettings configuration modules. 

• Addition of “multihop” boolean option in BFD rule settings. 

• Addition of “maxHop” and “localIP” settings in BGP neighbor configuration. 

• Addition of read-only logicalId field on Edge "site" entity (exposed in responses to e.g., /edge/getEdge, /enterprise/getEnterpriseEdges, etc.) 

• Addition of read-only logicalId field on Edge License entity (exposed in responses to e.g., /license/getEnterpriseEdgeLicenses, /license/getEnterpriseProxyEdgeLicenses, etc.) 

• Addition of read-only logicalId field on Gateway Pool entity (exposed in responses to e.g., /network/getNetworkGatewayPools, /enterpriseProxy/getEnterpriseProxyGatewayPools etc.) 

SDK Deprecation

VMware SD-WAN deprecates the support for the VMware SD-WAN Orchestrator Software Development Kit (SDK) beginning with Release 4.2.0.

Note: This announcement is only for the SDK client libraries and not for the APIs. VMware SD-WAN will continue to support the Orchestrator APIs.

Document Revision History

December 22nd, 2020. First Edition.

January 7th, 2021. Second Edition.

• Added a new Gateway build: R420-20210106-GA; added a Gateway Resolved section for this build which includes the new ticket resolved in this build: #53439.

January 14th, 2021. Third Edition.

• Corrected the URL target for the APIv2 documentation hyperlink.

January 26th, 2021. Fourth Edition.

• Added a new Orchestrator build: R420-20210122-GA; added an Orchestrator Resolved section for this build which includes the new ticket resolved in this build: #56033.

February 10th, 2021. Fifth Edition.

• Added a revision to the Feature Enhancement "GPON Support on Edge 6x0".  The revision adds a note to make it explicitly clear that only one GPON SFP module, the the Nokia G-010S-A GPON ONT SFP, 1 x GE UNI (Part # 3FE46541AA) with firmware 3FE47111BFHB32 has been tested and is supported on Edge models 610, 620, 640, and 680. And that VMware SD-WAN does not support any other GPON SFP modules. Also notes GPON is only supported in Release 4.2.0 and later releases and has no backward compatibility with Release 4.1.x or earlier.

February 11th, 2021. Sixth Edition.

• Added a new Gateway hotfix build: R420-20210208-GA-53243-54800; added a Gateway Resolved section for this build which includes two new tickets resolved in this build: #53243 and #54800.

February 19th, 2021. Seventh Edition.

• For the section covering APIv2 Documentation, the hostname and target shortcut have been changed to reflect the permanent location for this documentation: developer.vmware.com.

March 9th, 2021. Eighth Edition.

• Added a new Orchestrator hotfix build: R420-20210306-GA; added a new Orchestrator Resolved section for this build which includes three new tickets resolved in this build: #56436, #58627.

March 12th, 2021. Ninth Edition.

• Deleted two entries in the Interoperability Table under the Compatibility section that were included in error, where the Gateway version (4.0.0) was lower than the Edge version (4.2.0).

April 28th, 2021. Tenth Edition

• Added Fixed Issue 51092 to the Edge/Gateway Resolved section.  The fix was included with the Edge R420-20201218-GA build but had not been documented in the Release Notes.

June 7th, 2021. Eleventh Edition.

• Added "Reverse-Path Forwarding (RPF) Enabled by Default" entry to the Important Notes section to explicitly call out the change in behavior that results from Fixed Issue 52628.
• Added Issue 44526 to Edge/Gateway Known Issues.

June 16th, 2021, Twelfth Edition.

• Added Issue 54107 to Edge/Gateway Open Issues.

September 16th, 2021. Thirteenth Edition. 

• Added to Important Notes the Note: BGPv4 Filter Configuration Delimiter Change for AS-PATH Prepending.

December 21st, 2021. Fourteenth Edition.

• Added a new Orchestrator build R420-20211220-GA to Orchestrator Resolved Issues. This Orchestrator build remediates CVE-2021-44228, the Apache Log4j vulnerability, by updating to Log4j version 2.16.0. For more information on the Apache Log4j vulnerability, please consult the VMware Security Advisory VMSA-2021-0028.5.
• Added to Important Notes the Note: Limitation When Disabling Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810. This note covers an issue that may be encountered when configuring a forced speed on some Ethernet ports of the listed Edge models.

March 23rd, 2022, Fifteenth Edition

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

April 9th, 2022. Sixteenth Edition

• Added Fixed Issue #44270 to Edge/Gateway Resolved Issues. This issue was omitted from the original Release Notes in error.

Resolved Issues

The resolved issues are grouped as follows.

• Gateway Resolved Issues
• Orchestrator Resolved Issues

Gateway Resolved Issues

Resolved in Version R420-20210208-GA-53243-54800

The below issues have been resolved since Gateway version R420-20210106-GA.

• Fixed Issue 53243: Traffic may drop to a Non SD-WAN Destination (NSD) that uses a Check Point type because the Gateway does not delete the Phase 2 Security Association (SA).

  Peers would be out of sync in terms of the SA and the link would be down until the SA expires. In an NSD using a Check Point firewall type, when the link is not stable it is possible to end up with a situation when the peer sends a Delete Notify, but the Gateway cannot delete Phase 2 SA because the corresponding Phase 1 SA has already been deleted.

• Fixed Issue 54800: During an IKE rekey with the VMware SD-WAN Gateway, a Non SD-WAN Destination via Gateway may have a tunnel drop which does not recover.

  When a VMware SD-WAN Gateway triggers an IKE rekey with a Non SD-WAN Destination (NSD) and during this rekey the IKE link goes down or the tunnel establishment fails for any reason, the Gateway will not be able to retrigger a new IPsec tunnel because the triggering logic assumes that a Security Policy ID should be available. As a result the tunnel will not re-establish even when data traffic is sent. Without the fix, the only way to recover the tunnel is to bounce it by changing the NSD configuration on the VMware SD-WAN Orchestrator.

Gateway Resolved Issue

Resolved in Version R420-20210106-GA

The below issue has been resolved since Gateway version R420-20201218-GA.

• Fixed Issue 53439: A VMware SD-WAN Gateway stops attempting a VPN's IKE rekey after several unsuccessful attempts.

  This issue may impact customers using Non SD-WAN Destinations via Gateway that are policy-based (route-based VPNs are not affected). For a policy based VPN (e.g., Cisco ASA, Generic Firewall), user traffic sent via the VPN must initiate a new security association (SA) if for whatever reason the previous SA was deleted. When this happens, the IKE rekey uses the wrong traffic selectors, which causes the new SA creation to fail. In this situation traffic to the Non SD-WAN Destination will be down indefinitely until a new configuration change is pushed from the VMware SD-WAN Orchestrator. If the previous SA has not been deleted when rekey happens there is no issue, meaning not all customers and all rekeys will be impacted by this issue.

Edge/Gateway Resolved Issues

Resolved in Version R420-20201218-GA

The below issues have been resolved since Edge version R401-20201110-GA and Gateway version R401-20201124-GA-53090.

• Fixed Issue 37807: When the IP address of a DHCP interface of a VMware SD-WAN Edge is moved to another subnet range, the default route and local route corresponding to previous subnet range are not removed

  The Edge acts as a DHCP client and receives a IP address from the DHCP server. Once it receives the IP address it will install routes for the IP address. Now if the DHCP server is moved to different subnet, the Edge will request a DHCP renew and this will fail since the server has moved to a different range and result in a DHCP timeout. After the DHCP timeout, the Edge will send another DHCP request and this request will get an IP address from the new subnet, but the issue is that the Edge will not delete the routes it has installed with the old subnet.

• Fixed Issue 44270: The VMware SD-WAN Edge MIB sysObjID (.1.3.6.1.2.1.1.2.0) reports the OID subtree for net-snmp (1.3.6.1.4.1.8072.3.2.10) instead of the VMware SD-WAN subtree (.1.3.6.1.4.1.45346.1.1).

  On configuring snmpd, the Edge fails to explicitly set the sysObjID to an SD-WAN specified subtree and as a result snmpd uses the default subtree.

• Fixed Issue 45258: In the Remote Diagnostics page, the "Troubleshoot BGP- Show Routes per Prefix" shows the entire route table.

  Configuring BGP and going to the Remote Diagnostics >Troubleshoot BGP - Show BGP Routes per Prefix shows the entire route table instead of showing just the prefix routes, which defeats the purpose of running the diagnostic.

• Fixed Issue 46628: The GE5 and GE6 ports on a VMware SD-WAN Edge 620/640/680 do not detect a link if the ports are configured with either 10 Mbps or 100 Mbps and duplex.

  This is a Edge firmware issue and not a VMware software issue. The fix for this issue ONLY applies to newly manufactured Edge 6x0 models that are shipped with a new BIOS that has been certified by Dell.  Existing Edge 6x0 models in the field will continue to have this issue and the only workaround is to use ports GE1 - GE4 if 10 Mbps or 100 Mbps speeds are required. 

  Note: to fix this issue on an existing In a future release, VMware will have the ability to upgrade Edge firmware and only then will existing Edge 6x0's have a path to fix this issue.

   

• Fixed Issue 48502: In some scenarios, a VMware SD-WAN Hub Edge being used to backhaul internet traffic may experience a Dataplane Service Failure due the improper handling of backhaul return packets.

   The dataplane service failure is caused by memory corruption on the Hub Edge when cloud traffic is backhauled via the Hub Edge. The fix for this issue addresses the causes of the memory corruption in this scenario.

• Fixed Issue 50067: NAT is skipped for the traffic routed via sub-interface when "NAT direct" is enabled on sub-interface and disabled on parent interface.

  The "NAT direct" configuration of the parent interface is always checked to apply NAT for the traffic routed via the sub-interface. The sub-interface "NAT direct" configuration has no effect on the traffic and the traffic goes out without NAT if "NAT direct" is enabled on sub-interface and disabled on parent interface.

• Fixed Issue 50231: For a customer whose enterprise uses the special MGMT-IP build for their VMware SD-WAN Edges (i.e., where the Edge Management IP is enabled for customers with requirement for global segment loopback), the Edge Management IP Address is not redistributed to BGP/OSPF. 

  Local/remote management IP address of Edges is not being redistributed into underlay BGP/OSPF protocols. This would affect customers that rely on reachability to Edge's management IP for monitoring purposes.

• Fixed Issue 50782: VMware SD-WAN Edge interface statistics do not include sub-interface statistics.

  Traffic traveling across sub-interfaces is being accounted for in the main interface with a VLAN header, rather than the subinterface, which leads to incorrect results when pulling the subinterface data using SNMP.

• Fixed Issue 50920: VMware SD-WAN Edge does not send a warning when the number of connected tunnels reaches 60% of the hardware defined limit for that Edge model.

  The Edge sends a warning when the number of connected tunnels reaches its hardware limit that reads “Established tunnel count exceeds the device capacity”. Once this limit is reached, the Edge will not allow additional dynamic tunnels until existing tunnels are torn down. However, there is no intermediate warning sent to warn the customer that this tunnel limit has the potential to be reached, leaving the customer without proper lead time to manage their network.

• Fixed Issue 51092: A VMware SD-WAN Edge configured with OSPF and outbound filtering enabled may experience a memory leak that leads to a kernel panic and a reboot of the Edge.

  The leak can be observed by checking the Edge's Monitor > System page of the VMware SD-WAN Orchestrator UI. The critical memory usage threshold which triggers the kernel panic is 90% or higher.  The memory leak issue happens when route recovergence happens with OSPF outbound filtering enabled. A kernel panic which leads to an Edge reboot would disrupt all customer traffic for 2-3 minutes. Without this fix, the customer's only option is to enable the route advertisement option, which will mitigate the memory leak.  Also to clear the memory leak without this fix, the customer could perform a Restart Service from the Orchestrator's Remote Actions page.  Restarting an Edge's service should only be done in a maintenance window.

• Fixed Issue 51291: A VMware SD-WAN Edge 3400 or 3800 that is deployed in Japan may lock up and reboot spontaneously.

  The Edge 3400 and 3800 have an incorrect voltage warning threshold (100V) set in the system's Baseboard Management Controller (BMC), which happens to match the 100V electrical supply in Japan. The result for an Edge 3400 or 3800 in this region is a continuous series of power supply alarms and if the volume of alarms is sufficiently frequent, the Edge will lock up and reboot.

• Fixed Issue 51583: SMB application traffic may get misclassified as BITS application traffic.

  The Deep Packet Inspection (DPI) engine used by VMware SD-WAN will sometimes misclassify SMB application traffic as BITS traffic. This issue impacts a customer using strict firewall or business policy rules for SMB or BITS application traffic. The 4.2.0 default application map (and all subsequent application maps) is corrected to include port 445 as a standard application port for SMB application traffic and to instruct the DPI to not slow learn BITS application traffic.

• Fixed Issue 52253: When a traceroute is run from a client on a secondary IP subnet to a VMware SD-WAN Edge, the secondary interface IP subnet shows the first hop as the Edge's primary interface IP instead of the secondary IP.

  When executing traceroute from the client in the secondary IP subnet, the Edge responds with the primary IP instead of the secondary IP and hence the traceroute shows the first next hop as the primary IP. This issue also causes ICMP error messages meant to source the secondary interface IP address to be sent with the primary interface's IP address.

• Fixed Issue 52342: The Remote Diagnostics page on the VMware SD-WAN Orchestrator UI may fail to load.

  For Release 4.x, VMware introduced WebSocket to replace the live-heartbeat previously used in Remote Diagnostics. However, the VMware SD-WAN Edge sourced the WebSocket connection on the default WAN IP, causing random traffic drop on the middleware or the Edge itself. Binding the WebSocket with a VMware-specified IP resolves the issue.

• Fixed Issue 52628: Packets with an unknown source are allowed from the LAN interface of a VMware SD-WAN Edge. 

  With this issue packets which are sourced from a subnet different from the LAN subnet are allowed to pass through the Edge. This is caused by the Edge LAN interfaces not having reverse-path forwarding (RPF) enabled. The fix enables RPF on all Edge LAN interfaces and packets from LAN interfaces would be allowed only if the packets are sourced from the configured LAN subnet.

• Fixed Issue 53090: Tunnels to a Non SD-WAN Site via Gateway may fail after an IKE Phase 1 rekey or when a tunnel goes down and IKE Phase 1 must be reinitiated.

  When the VMware SD-WAN Gateway initiates tunnels to non SD-WAN sites, the security association (SA) involves a source and destination port. Once there is an SA, both these ports need to be populated correctly to ensure that IKE Phase 1 SA is recreated properly.  As referenced in the VMware SD-WAN Release 4.0.0 Release Notes, VMware SD-WAN Release 4.0.0 replaced the IPsec libraries with FIPS 140-2 compliant IPsec libraries. As part of this replacement, the SA destination port was inadvertently set incorrectly on the second and subsequent negotiation attempts for a given peer.  

  For some non SD-WAN sites, the peer discards this invalid port and returns a proper Traffic Selector (TS). For peer sites which do not correct this, the peer responds with the invalid port in the TS which the VMware SD-WAN Gateway rejects and this results in Gateway tunnels failing at rekey or when a tunnel goes down and IKE Phase 1 must be reinitiated.

  A customer is more likely to encounter this issue if the Non SD-WAN Site is misconfigured (e.g. the site is configured to use IKEv1 when the peer site uses IKEv2).

• Fixed Issue 53260: BFD packets are discarded by an HP 5510 or an equivalent switch using source port validation.

  The VMware SD-WAN Edge sends BFD packets with a source port that violates RFC 5881.  If a peer switch is configured with source port validation per RFC 5881, the switch will discard the VMware BFD packets as invalid. 

• Fixed Issue 53426: The local underlay BGP route is not correctly sorted in the VMware SD-WAN Edge’s forwarding information base (FIB) relative to the BGP routes from the Hub Edge(s), and the overlay preferred route on an Edge is not correctly redistributed to the underlay BGP.

  When the DCC flag is enabled, the route's preference and advertise values are changed but the underlay route is not being correctly re-sorted in the Edge FIB. Also, when the underlay BGP route is initially preferred in the Edge FIB and later, an overlay BGP route is preferred over the locally learned route, due to an issue in the redistribution logic, the overlay route is not being correctly redistributed to the underlay BGP. Without the fix, the Edge must be forced to relearn either the underlay or overlay BGP route as appropriate.

Orchestrator Resolved Issues

Orchestrator version R420-20211220-GA

Orchestrator version R420-20211220-GA was released on 12-20-2021. This Orchestrator build remediates CVE-2021-44228, the Apache Log4j vulnerability, by updating to Log4j version 2.16.0. For more information on the Apache Log4j vulnerability, please consult the VMware Security Advisory VMSA-2021-0028.5.

___________________________________________________________________

Resolved in Version R420-20210306-GA

The below issues have been resolved since Orchestrator version  R420-20210122-GA.

• Fixed Issue 56436: The tunnels to a Non SD-WAN Destination (NSD) via Gateway may get torn down and built up in quick succession (i.e., "flap") every thirty seconds.

  This issue is caused when an NSD configuration change is sent by the VMware SD-WAN Orchestrator at exactly the same time as the VMware SD-WAN Gateway heartbeat check.  When this happens the configuration change is not recognized, and the NSD configuration change is then resent with every heartbeat with each change also not being recognized. When a configuration change is received on the Gateway, the connection gets restarted and normally this is a one-time event, but here the connection is reset and the NSD tunnels are torn down on every Gateway heartbeat.  The Gateway heartbeat interval is 30 seconds and thus this issue results in the NSD tunnels flapping every 30 seconds.

• Fixed Issue 58627: A WAN link that is marked as down by the VMware SD-WAN Orchestrator still shows as up on the Monitor page of the Orchestrator's UI, and may also cause the Orchestrator to send out an erroneous 'Link Up' Alert.

  The VMware SD-WAN Edge continues to send link statistics to the Orchestrator for a WAN link even when the link only has layer one connectivity, and the link statistics are just zeroes. The Orchestrator interprets these empty statistics as falsely indicating the WAN link is up and marks the link incorrectly on the Monitor page while also sending a 'Link Up' Alert if the customer is configured to do so. This issue misleads a customer monitoring their enterprise into thinking a down WAN link is actually up. This issue does not affect Events.

______________________________________

Resolved in Version R420-20210122-GA

The below issue has been resolved since Orchestrator version R420-20201216-GA.

• Fixed Issue 56033: A Partner administrator is not able to configure a customer's Partner Gateway handoffs on the Configure Customer page of the VMware SD-WAN Orchestrator.

  On an Orchestrator with this issue, a partner using Partner Gateways is effectively unable to provision new clients. The issue occurs because of newly added validations which do not allow partners to configure gateway handoffs with gatewayLogicalIds present in the global scope.

______________________________________

Resolved in Version R420-20201216-GA

The below issues have been resolved since Orchestrator version R401-20201214-GA.

• Fixed Issue 46281: VMware SD-WAN Orchestrator allows a user to configure an invalid BGP subnet with 5 octets.

  The Orchestrator is not performing a validation check for an invalid BGP configuration and allows the user to save the configuration.  For example, with this issue a user could configure a BGP filter 0.0.0.0.0/0 and the Orchestrator would not prevent it.

• Fixed Issue 48793: If an invalid VLAN segmentId is added, the Edge deviceSettings page does not load completely and has blanks where information should be.

  The API configuration/updateConfigurationModule does not check for the segmentId specified in the call to ensure validity, leading to the possibility of an incorrect one being specified. This invalid segmentId leads to the broken page. The fix ensures that a segmentId specified when adding new VLAN's via API is an existing, valid segmentId.

• Fixed Issue 48084: VMware SD-WAN Orchestrator allows API call 'insertOrUpdateEnterpriseGatewayHandoff' to insert a non-valid or wrong 'segmentLogicaltId' or 'gatewayLogicalId'.

  The Gateway handoff configuration validation does not catch errors pertaining to segment metadata parameters. With this fix, invalid gateway logical id and invalid segment logical ID will throw an error and not be applied to the configuration.

• Fixed Issue 48895: After upgrading a VMware SD-WAN Orchestrator to either 3.4.x or 4.x, profiles that do not contain VLAN1 are unable to be modified. 

  With this issue, only VLAN with ID = 1 can be used on a VMware Edge model's interface settings. This issue is hit when VLAN with ID = 1 was removed and new VLAN(s) were added. In this case a VLAN will not be set in the Edge's interface settings when the Edge model is newly enabled in a configuration profile.

• Fixed Issue 50119: On the Administration > System Settings page, the purpose of the "Grant access to <Partner_Name> Support" setting is not described accurately.

  If a Customer Administrator Superuser disabled this setting based on the description, they would expect a Partner Administrator to no longer be able to edit, configure, or troubleshoot their enterprise.  In contrast, this setting is actually meant to regulate a Partner's ability to view and manage enterprise users and user identifiable traffic statistics. 

• Fixed Issue 52271: When a VMware SD-WAN Orchestrator is upgraded to Release 4.0.0, a user is not able to change Edge-overridden Cloud Security Service (CSS) configurations if there is a business policy using that CSS present on any VMware SD-WAN Edge in a customer enterprise.

  The user would encounter this issue on Configure > Edge > Device, in the Cloud Security Service section. This issue impacts a customer because the user is unable to change the CSS provider. This issue is the result of an added UI validation on 4.0.0 that is designed to prevent a user from changing an Edge-overridden CSS provider if that CSS is being used for any Edge-level business policy of the same Edge. However, instead of limiting the check to business policies of the configured Edge, the Orchestrator checks all of the Edges in the customer's enterprise.

• Fixed Issue 52491: When a new port forwarding rule is added in a VMware SD-WAN Orchestrator, the configuration cannot be saved.

  This issue occurs when a segment is mapped to a port forwarding rule after deleting a few segments. The user is unable to save a firewall configuration with error "Cannot read property 'logicalId' of undefined".

• Fixed Issue 52571: The link status of a VMware SD-WAN Edge shows differently on the Monitor > Edges page versus the Monitor > Edge Overview page on the VMware SD-WAN Orchestrator.

  If the peer end of a network is disconnected and the Edge sent a "DISCONNECT" event to the Orchestrator while "Live Mode" is also enabled, the Orchestrator may think the link is not actually down because the Edge will keep sending link data with value 0 to the Orchestrator.  The end result is inconsistent Edge link states on the Monitor > Edge screen and the Monitor > Edge Overview screen.

• Fixed Issue 52682: For a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) topology, the Standby Orchestrator may continually attempt to copy reports and Orchestrator diagnostic bundles it has already copied from active VMware SD-WAN Edges and Gateways and both will continually report receipt of "new managementPlane configuration" from the Standby Orchestrator.

  Edges and Gateways report frequent receipt of "new managementPlane configurations" and the Orchestrator disaster recovery will repeatedly go through a cycle of failing to synchronize, and then synchronizing due to the Standby Orchestrator continuously attempting to open SSH connections to the Active Orchestrator to copy files it has already copied.

• Fixed Issue 52949: WAN link status may be incorrect on the Monitor > Edge Overview page or the VMware SD-WAN Orchestrator.

  The Orchestrator is not pulling WAN link status from the correct API and that may cause an incorrect WAN link status to be displayed.

• Fixed Issue 53199: There is a discrepancy in the IKE and IPsec lifetime values displayed by the VMware SD-WAN Orchestrator and the VMware SD-WAN Gateway for a Non SD-WAN Destination via Gateway with a Palo Alto type.

  This is a display issue only, there is no functional impact to the Non SD-WAN Destination via Gateway. The Orchestrator shows Phase 1 lifetime as 8 hours and Phase 2 as 1 hour, while the Gateway (using debug.py -v ike) shows Phase 1 as 24 hours and Phase 2 as 8 hours. In reality, both the Orchestrator and the Gateway use 24 hours for Phase 1 and 8 hours for Phase 2 as the default value for IKE and IPsec lifetimes for the Palo Alto type Non SD-WAN Destination via Gateway.

• Fixed Issue 53411: When configuring an VMware SD-WAN Edge interface with PPPOE addressing type, the "username" configured is seen correctly through either the Orchestrator UI or an API, but propagated to the Edge with the value "null".

  This is caused due to a part of code using "name" instead of "username" when picking attributes from addressing type object to be added as part of the composite configuration sent down to the Edge. As the "name" key does not exist on the object, "username" is added as "null".

Known Issues

Open Issues in Release 4.2.0

The known issues are grouped as follows.

• Edge/Gateway Known Issues
• Orchestrator Known Issues

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 25855:

  A large configuration update on the Partner Gateway (e.g. 200 BGP-enabled 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.  

• 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.  

• Issue 28175:

  Business Policy NAT fails when the NAT IP overlaps with the VMware SD-WAN Gateway interface IP.  

• 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. 

• Issue 32731:

  Conditional default routes advertised via OSPF may not be withdrawn properly when the route is turned off. Re-enabling and disabling the route 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.

• Issue 32981:

  Hard-coding speed and duplex on a DPDK-enabled port may require a VMware SD-WAN Edge reboot for the configurations to take effect as it requires disabling DPDK.

• 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 35807:

  A DPDK routed interface will be disabled completely if the interface is disabled and re-enabled from the VMware SD-WAN Orchestrator. 

• 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:

  A VMware SD-WAN Edge acting as a DHCP server on a DPDK-enabled 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 39134:

  The System health statistic “CPU Percentage” may not be reported correctly on Monitor > Edge > System for the VMware SD-WAN Edge, and on Monitor > Gateways for the VMware SD-WAN Gateway.

  Workaround: Users should use handoff queue drops for monitoring Edge capacity not CPU percentage.

• 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.

• Issue 39624:

  Ping through a subinterface may fail when the parent interface is configured with PPPoE.

• Issue 39659:

  On a site configured for Enhanced High Availability, with one WAN link on each VMware SD-WAN Edge, when the standby Edge has only PPPoE connected and the active has only non-PPPoE connected, a split brain state (active/active) may be possible if the HA cable fails.

• Issue 39753:

  Disabling Dynamic Branch-to-Branch VPN may cause existing flows currently being sent using Dynamic Branch-to-Branch to stall.

• 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 40421:

  Traceroute is not showing the path when passing through a VMware SD-WAN Edge with an interface configured as a switched 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 42388:

  On a VMware SD-WAN Edge 540, an SFP port is not detected after disabling and reenabling the interface from the VMware SD-WAN Orchestrator.

• Issue 42488:

  On a VMware SD-WAN Edge where VRRP is enabled for either a switched or routed port, if the cable is disconnected from the port and the Edge Service is restarted, the LAN connected routes are advertised.

  Workaround: There is no workaround for this issue.

• Issue 42872:

  Enabling 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: Enable distributed cost calculation on the VMware SD-WAN Orchestrator.

• Issue 44526: For an enterprise where two different sites deploy their VMware SD-WAN Edges as Hubs while also using a high-availability topology, and each site uses the other Hub site as a Hub in its profile.  If one of the Hub sites triggers an HA failover, it may take up to 30 minutes for both Hub Edges to reestablish tunnels with each other. 

  On an HA failover, both Hub Edges try to initiate a tunnel with each other at the same time and neither replies to the peer, the packet exchange between both Hubs occurs, but IKE never succeeds. This leads to a deadlock that has been observed to take up to 30 minutes to resolve on its own. The issue is intermittent and does not occur after every HA failover. 

  Workaround: To prevent this issue from occurring, the customer should configure only one of the two HA Hub sites to use the other Hub site as a Hub for itself.  For example, where there are two HA Hub sites, Hub1 and Hub2, Hub1 could have Hub2 as a Hub for itself in its profile, but Hub2 must not use Hub1 as a Hub in its profile.

• Issue 44832:

  Traffic from one Non SD-WAN Destinations via Edge to another Non SD-WAN Destinations via Edge (i.e. 'hairpinning' or 'NAT loopback'), is dropped on the VMware SD-WAN Edge.

• 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.

• 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 re-key.  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 Supported SFP Module List (79270).  Multi-Rate SFPs may be used with SFP3 and SFP4.

• Issue 46918:

  A VMware SD-WAN Spoke Edge using the 3.4.2 Release does not update the private network id of a Cluster Hub node properly.

• Issue 47084:

  A VMware SD-WAN Hub Edge cannot establish more than 750 PIM (Protocol-Independent Multicast) neighbors when it has 4000 Spoke Edges attached.

• Issue 47244:

  On an activated VMware SD-WAN Edge 6x0 with DPDK enabled, some Copper SFPs, the Edge will show the link as 'UP' even when no cable is inserted on the VMware SD-WAN Orchestrator UI.

  Workaround: Plugging and unplugging a cable removes the false state.

• Issue 47355:

  When the same route is learned via local underlay BGP, Hub BGP and/or statically configured on the Partner Gateway, the sorting order of the routes is incorrect with the Hub BGP being preferred over the underlay BGP.

• Issue 47664:

  In a Hub and Spoke configuration where Branch-to-Branch via Hub VPN is disabled, 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 enable 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 48166:

  A VMware SD-WAN Virtual Edge on KVM is not supported when using a Ciena virtualization OS and the Edge will experience recurring Dataplane Service Failures.

• Issue 48175:

  A VMware SD-WAN Edge running Release 3.4.2 will form an OSPF adjacency on a non-global segment if the non-global segment has an interface configured in the same IP range as an interface configured on the global segment

• 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 48666:

  IPsec-fronted Gateway Path MTU calculation does not account for 61 Byte IPsec overhead, resulting in higher MTU advertisement to LAN client and subsequent IPsec packet fragmentation.

  Workaround: There is no workaround for this issue.

• Issue 49172:

  A Policy Based NAT rule configured with the same NAT subnet for two different VMware SD-WAN Edges does not work.

• Issue 49738:

  In some cases, when a VMware SD-WAN Spoke Edge is configured to use multiple Hub Edges, the Spoke Edge may not form tunnels to one of the Hubs configured in the Hub list.

• Issue 50518:

  On a VMware SD-WAN Gateway where PKI is enabled, 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 51428: Multicast traffic loss may be observed on a site where the VMware SD-WAN Edge has a sub-interface configured with PIM.

  When a sub-interface configured with PIM is moved from a segment to another on the fly, pimd (the process that manages PIM) may restart and the site would experience intermittent multicast traffic loss.

  Workaround: Disable the sub-interface first, and then move the sub-interface to another segment. Once moved, re-enable the sub-interface.

• 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 52102: For an enterprise using a Hub/Spoke topology, existing flows are dropped on a VMware SD-WAN Spoke Edge when recovering from a Hub Edge failover for a given tuple.

  The sequence of events leads to this issue when a primary Hub Edge recovers from failover:
  1. When the primary Hub Edge goes down, the route is removed from the FIB for that primary Hub Edge while retaining the routes in the RIB.
  2. Existing flows will now switch to the secondary Hub Edge.
  3. When the primary Hub comes back up, a tunnel is immediately established between the primary Hub from the Spoke Edge.
  4. Routes in the RIB which were previously learned from the primary Hub via the Gateway are scanned and routes are installed in the FIB pointing to this primary Hub.
  5. Traffic will switch back to the primary Hub whereas the primary Hub would not have learned the routes from its BGP neighbor.
  6. This causes route lookup to match on the default route and return traffic is marked with a backhaul flag.
  7. The Spoke Edge is not expecting return traffic with a backhaul flag set and this leads to traffic being dropped. 

  Workaround: On the Hub Edge, run the Remote Diagnostic "Flush Flows" for the given tuple and traffic will be restored.

• Issue 52483: If underlay accounting is enabled for an interface, the VMware SD-WAN Edge wrongly forwards the traffic back to the same interface instead of forwarding to the overlay.

  This behavior is caused by an issue with underlay accounting and a recursive route resolution.

  Workaround: Disable underlay accounting for the affected interface.

• 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 53337: Packet drops may be observed with an AWS instance of a VMware SD-WAN Gateway when the throughput is above 3200 Mbps.

  When traffic exceeds a throughput above 3200 Mbps and a packet size of 1300 bytes, packets drops are observed at RX and at IPv4 BH handoff.

  Workaround: There is no workaround for this issue.

• Issue 53359: BGP/BFD session may fail during some DDoS attack scenarios.

  If traffic is flooded from the client connected to the routed interface to the LAN client, the BGP/BFD session can fail. Also when real-time high priority traffic is flooded to the overlay destination, the BGP/BFD session can fail.

  Workaround: There is no workaround for this issue.

• Issue 53830: On a VMware SD-WAN Edge, some of the routes in BGP view may not have the correct preference and advertise values when DCC flag is enabled causing incorrect sorting order in the Edge's FIB.

  When Distributed Cost Calculation (DCC) is enabled in a scaled scenario with a large number of routes on an Edge, when looking at an Edge diagnostic bundle for the log bgp_view some of the routes may not be correctly updated with the preference and advertise values.  This issue, if found at all, would be a found in a few Edges as part of a large enterprise (100+ Spoke Edges connected to either Hub Edges or Hub Clusters).  

  Workaround: This issue can be addressed by either relearning the underlay BGP routes or performing a "Refresh" option on the OFC page of the VMware SD-WAN Orchestrator for the affected routes. Please note that executing a "Refresh" of a route would re-learn the routes from all the Edges in the enterprise.

• 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 disabled 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 disabled 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 disabled).

• Issue 54107: For a customer deploying VMware SD-WAN Edges in an Enhanced High Availability topology which also has Dynamic Branch-To-Branch VPN configured, in the event of an HA failover, the customer may observe site traffic traversing a VMware SD-WAN Gateway instead of a more efficient path to a Branch Edge. 

  After an HA failover, Dynamic Branch-to-Branch tunnels do not always reestablish, and this results in Branch-to-Branch traffic taking a path via a Gateway until a new flow is initiated. The impact to a customer could be in one of two ways, first if the path to the Gateway has loss then this would be reflected on that flow, second if the Gateway is located farther away than the peer branch Edge to which the site is sending and receiving traffic, there could be observed an increase in latency on that flow.  This issue is seen on flows which existed prior to the HA failover, and once a new flow is created post-failover the Branch-to-Branch tunnel will build as expected and all existing flows will be steered to that tunnel.  

  Workaround: If the site is one where new flows are not frequently created, a user could run the Remote Diagnostic "Flush Flows" for some or all affected flows. 

• Issue 84825: For a site deployed with a High-Availability topology where BGP is configured, if the site has greater than 512 BGPv4 match and set rules configured, the customer may observe the HA Edge pair continuously failing over without ever recovering.

  Greater than 512 BGPv4 match and set rules is understood as a customer configuring more than 256 such rules on the inbound filter and 256 rules on the outbound filter. This issue would be disruptive to the customer as the repeated failover would cause flows for real time traffic like voice calls to be continuously dropped and then recreated. When HA Edges experience this issue, the process that synchronizes Edge CPU threads fails causing the Edge to reboot to recover, but the promoted Edge also experiences the same issue and reboots in turn with no recovery reached at the site.

  Workaround: Without a fix for this issue, the customer must ensure that no more than 512 BGPv4 match and set rules are configured for an HA site.

  If a site is experiencing this issue and has more than 512 BGP/v4 match and set rules configured, the customer must immediately reduce the number of rules to 512 or less to recover the site.

  Alternatively, if the customer must have more than 512 BGPv4 match and set rules, they can downgrade the HA Edges to Release 3.4.6 where this issue is not encountered, but at the cost of Edge features found in later releases. This can only be done if their Edge model is supported on 3.4.6 and the customer should confirm that is so before downgrading.

Orchestrator Known Issues

• Issue 19566:

  After High Availability failover, the serial number of the standby VMware SD-WAN Edge may be shown as the active serial number in the Orchestrator.

• Issue 20900:

  If the MaxMind geolocation service is enabled and cannot reach the MaxMind server, new VMware SD-WAN Edge activations will not work.

• 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 32913:

  After Enabling 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 34828:

  Traffic cannot pass between a VMware SD-WAN Spoke Edge using release 2.x and a Hub Edge using release 3.3.1.

• 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: Disable and then reenable GRE at the Edge level 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: Disable and then reenable GRE at the Edge level 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 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 hyper link 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 40341:

  Though the Skype application is properly categorized on the backend as Real Time traffic, when editing the Skype Business Policy on the VMware SD-WAN Orchestrator, the Service Class may erroneously display “Transactional”.

• 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.

• Issue 44153:

  The VMware SD-WAN Orchestrator does not consistently send alert emails to the email addresses configured in the 'Alerts and Notifications' section.

• Issue 46254:

  During a VMware SD-WAN Edge activation, the VMware SD-WAN Orchestrator does not detect a changed WAN link MTU or the presence of a VLAN ID for DHCP configured interfaces.

• Issue 47269:

  The VMware SD-WAN 510-LTE interface may appear for Edge models that do not support an LTE interface.

• Issue 47713:

  If a Business Policy Rule is configured while Cloud VPN is disabled, the NAT configuration must be reconfigured upon enabling Cloud VPN.

• Issue 47820:

  If a VLAN is configured with DHCP disabled at the Profile level, while also having an Edge Override for this VLAN on that Edge with DHCP enabled, 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.

• Issue 48737:

  On a VMware SD-WAN Orchestrator which is using the Release 4.0.0 new user interface, If a user is on a Monitor page and changes the Start & End time interval and then navigates between tabs, the Orchestrator does not update Start & End interval time to the new values.

• Issue 49225:

  VMware SD-WAN Orchestrator does not enforce a limit of 32 total VLANs.

• Issue 49790:

  When a VMware SD-WAN Edge is activated to Release 4.0.0, the activation is posted twice in Events.

  Workaround: Ignore the duplicate event.

• Issue 50531:

  When two Operators of differing privileges use the same browser window when accessing the New UI on a 4.0.0 Release version of the VMware SD-WAN Orchestrator, and the Operator with lesser privileges tries to login after the Operator with higher privileges, that lesser privileged Operator will observe multiple errors stating that the "user does not have privilege".

  Note: There is no escalation in privileges for the Operator with lower privileges, only the display of error messages.

  Workaround: The next operator may refresh that page prior to logging in to prevent seeing the errors, or each Operator may use different browser windows to avoid this display issue.

• Issue 51722: On the Release 4.0.0 VMware SD-WAN 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.