times

Updated March 31st, 2022

VMware SD-WAN Orchestrator Version R345-20210201-GA
VMware SD-WAN Gateway Version R345-20210202-GA
VMware SD-WAN Edge Version R345-20210909-GA-53243

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
Revision History
Resolved Issues
Known Issues

Recommended Use

This release is recommended for all customers using a 3.x release.

Release 3.4.5 Orchestrators, Gateways, and Hub Edges supports 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, please consult the warning below for additional details).

The following interoperability combinations were explicitly tested:

Orchestrator	Gateway	Edge
Orchestrator	Gateway	Hub	Branch/Spoke
3.4.5	3.2.1	3.2.1	3.2.1
3.4.5	3.4.5	3.2.1	3.2.1
3.4.5	3.4.5	3.2.1	3.4.5
3.4.5	3.4.5	3.4.5	3.2.1
3.4.5	3.2.1	3.2.1	3.4.5
3.4.5	3.3.2 P2	3.3.2 P2	3.3.2 P2
3.4.5	3.3.2 P3	3.3.2 P2	3.3.2 P2
3.4.5	3.4.5	3.3.2 P2 3.3.2 P3	3.3.2 P2 3.3.2 P3
3.4.5	3.4.5	3.4.5	3.3.2 P2
3.4.5	3.4.5	3.3.2 P2 3.3.2 P3	3.4.5
3.4.5	3.3.2 P2	3.4.5	3.3.2 P2
3.4.5	3.4.2	3.4.1 and 3.4.2	3.4.1 and 3.4.2
3.4.5	3.4.5	3.4.1 and 3.4.2	3.4.1 and 3.4.2
3.4.5	3.4.5	3.4.1 and 3.4.2	3.4.5
3.4.5	3.4.5	3.4.5	3.4.1 and 3.4.2
3.4.5	3.4.3	3.4.3	3.4.3
3.4.5	3.4.5	3.4.3	3.4.3
3.4.5	3.4.5	3.4.3	3.4.5
3.4.5	3.4.5	3.4.5	3.4.3
3.4.5	3.4.4	3.4.5	3.3.2 P3
3.4.5	3.4.4	3.3.2 P3	3.4.5
3.4.2	3.4.5	3.4.2	3.4.3
3.4.3	3.4.2	3.4.5	3.4.4
3.4.4	3.4.3	3.4.2	3.4.5
3.4.1	3.4.5	3.4.3	3.4.2
4.0.1	3.4.5	3.4.2	3.4.5
4.2.0	4.2.0	3.4.5	3.4.5

* Warning * Spoke Edges which connect to Hub Clusters must wait for Gateways to be upgraded to 3.4.2+ prior to being upgraded themselves.

Warning: VMware SD-WAN Release 2.x (e.g. 2.4.4, 2.5.2, etc.) is no longer supported. For more information regarding Release 2.x, including next steps, please consult Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 2.x.x (77221)

Warning: VMware SD-WAN Releases 3.2.x and 3.3.x have both reached the End of Support. Releases 3.2.x and 3.3.x reached End of General Support (EOGS) on December 15, 2021, and End of Technical Guidance (EOTG) March 15, 2022.

Warning: VMware SD-WAN Releases 3.4.x is approaching End of Support for the Orchestrator and Gateway. Release 3.4.x for the Orchestrator and Gateway will reach End of General Support (EOGS) on March 30, 2022, and End of Technical Guidance (EOTG) September 30, 2022.
Note: This is for the Orchestrator and Gateway only. 3.4.x software for the Edge is scheduled to enter its End of Support window beginning on December 31, 2022.

For more information on SD-WAN Release 3.x software lifecycles, please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151)

Important Notes

Extended Upgrade Time for Edge 3x00 Models
Upgrades to this version will take longer than normal (3-5 minutes) on Edge models 3400 and 3800. This is due to a firmware upgrade which resolves issue 53676. For more information, please consult Issue 53676 in the 3.4.5 Release Notes.

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 first added with Release 3.4.5, 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.

Reversion of Issue 53243: Traffic may drop to a Non SD-WAN Destination (NSD) that uses a Check Point type.
When the 3.4.5 Release Notes were originally published, Issue 53243 was listed as a Resolved Issue. This resolution was an attempted workaround for a Check Point behavior that impacted a Non SD-WAN Destination (NSD) of the same type. However, feedback from the field indicates that the workaround for 53243 introduced a new issue for customers using a Cloud Security Service (CSS) or a Non SD-WAN Destination (NSD) of any type, including Check Point. When a customer experienced this issue they would observe traffic drops between their Edge and the respective CSS or NSD.

As a result, Issue 53243 has been moved from the Resolved section to the Open section for Release 3.4.5 GA and the workaround for the issue is reverted in Edge build R345-20210909-GA-53243, the new official GA build for 3.4.5. By reverting the workaround for 53243, customers who are using an NSD with a Check Point type remain at risk for this issue but would remediate the risk on other NSD types.

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

Document Revision History

June 14th. First Edition. (From the published PDF edition, last updated May 26th, 2021). All further updates will be posted to this version.

September 15th, Second Edition.

Moved 53243 from the Resolved Issues section to Open Issues section because the fix introduced a regression issue for non-Check Point Non SD-WAN Destinations in the field.
Added an Important Note regarding the reversion of 53243.
Added a new Edge build R345-20210909-GA-53243 which reverts the fix for 53243.

December 21st, 2021. Third Edition.

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 28th, 2022. Fourth Edition.

Under the Compatibility section:
- Added a Warning that Release 3.2.x and 3.3.x software has reached End of Support for all components: Orchestrator, Gateway, and Edge.
- Added a new Warning that Release 3.4.x software is approaching End of Support for the Orchestrator and Gateway with End of General Support (EOGS) on March 30, 2022, and End of Technical Guidance (EOTG) June 30, 2022. This is for the Orchestrator and Gateway only. The 3.4.x Edge software is scheduled to enter its End of Support window beginning on December 31, 2022.

Resolved Issues

The resolved issues are grouped as follows.

Edge/Gateway Resolved Issues
Orchestrator Resolved Issues

Edge/Gateway Resolved Issues

Resolved in Version R345-20210202-GA

The below issues have been resolved since Edge and Gateway versions R344-20201021-GA.

Fixed Issue 36956: Symptom: When the Remote Diagnostic “Flush Firewall Sessions” is run or a diagnostic bundle is generated for a VMware SD-WAN Edge where a firewall is enabled and there are at least 22K firewall flows present, the Edge may suffer a Dataplane Service Failure and restart the service to recover.
This issue is extremely rare in the field, and VMware Engineering cannot consistently recreate it. When Engineering does recreate the issue, it is as outlined in the Symptom section. The reason the diagnostic bundle can trigger this issue is that the bundle is pulling a debug log user_firewall_dump and this links the issue to the Edge using a firewall.
Fixed Issue 40038: Symptoms: For some copper SFP models used on a VMware SD-WAN Edge 6x0, when the cable is unplugged and then replugged, the Edge LEDs do not reflect the correct link status and the Edge does not communicate the correct link status to the VMware SD-WAN Orchestrator.
Most SFPs implement RX_LOS (Receiver Loss of Signal) correctly, RX_LOS marks changes when a cable is unplugged and replugged into an SFP module. When the issue arises, it is because the SFP module is not properly supporting RX_LOS and brings up the host-side link independent of the copper side having a link. In field cases and in testing, the Fiberstore SFP modules have had this issue.
Fixed Issue 43630: Where two VMware SD-WAN Edges are deployed in a High-Availability topology, if a user disables HA on a VMware SD-WAN Orchestrator and then immediately enables HA afterwards, the site will go offline and neither Edge will pass traffic.
If the Edges are not using Release 3.4.5 or higher, the user should wait at least one minute before reenabling HA for that site. The only way to recover the Edges once they are in this state is to perform a manual reset of the Edges locally, either by Local UI, or as a hardware reset which varies depending on the Edge model.
Fixed Issue 47954: The Remote Action “Force HA Failover” does not work correctly for a customer site using VMware SD-WAN Edge models 5X0 or 6X0.
For this action, the failover is initiated but the original Active Edge persists as the Active in the HA pair and the Standby Edge is not promoted to the Active role.
Fixed Issue 48612: VMware SD-WAN Virtual Gateways and Edges using a X710/XL710 network adapter strip all Rx packet VLAN tags.
This issue would have a major impact for customers using a Gateway as configured which also has DPDK enabled as they would not be able to process VLAN tagged traffic on its handoff interface. This issue was traced to the i40evf DPDK driver which sent opcode VIRTCHNL_OP_ADD_VLAN to the Physical Function (PF) to add VLAN filtered tags, however, the PF driver enabled VLAN tag stripping as part of the command to enable VLAN tag filtering and consequently all VLAN tags were stripped.
Fixed Issue 49598: When a VMware SD-WAN Gateway has a large amount of traffic backhauled and several tunnels to the Gateway are unstable, the VMware SD-WAN Edges connected to that Gateway will observe degraded performance in the form of intermittent packet loss.
A large amount of backhaul traffic should be understood as ~700k backhauled flows to a Gateway with ~6K tunnels. At that scale, if ~100 Edges have unstable connections that cause tunnels to be repeatedly torn down and rebuilt to the Gateway, the result will be a hash table collision which leads to high CPU usage for a particular thread and intermittent packet loss for connected Edges. When looking in the Gateway logs or using debug.py --handoff a user would observe an exceptionally large number of handoff queue drops for vc_queue_vcmp_ctrl and vc_queue_vcmp_bottom handoffs.
Fixed Issue 49734: When running the Remote Diagnostic 'Troubleshoot BGP - List BGP Redistributed Routes', the output on the VMware SD-WAN Orchestrator UI does not display the entries correctly when filtered by segment.
When a specific segment_id is selected as a filter when running 'Troubleshoot BGP - List BGP Redistributed Routes', the output would be empty. The diagnostic would display the redistributed routes from all segments if the segment_id filter is not specified.
Fixed Issue 47954: For a customer using a High Availability topology where VMware SD-WAN Edge models 5X0 or 6X0 are used, if a user performs a 'Force HA Failover' through the Remote Actions function of the VMware SD-WAN Orchestrator, the result is a double failover with the original Active Edge reclaiming the Active role at the completion of the sequence.
The Remote Action “Force HA Failover” does not work correctly for a customer site using VMware SD-WAN Edge models 5X0 or 6X0. For this action, the failover is initiated but the original Active Edge persists as the Active in the HA pair and the Standby Edge is not promoted to the Active role. This issue is the result of a stale heartbeat from the demoted Active, now Standby Edge which fools the system into thinking there is an Active/Active "split-brain" state and the remedial action in such a situation is to restore the newly demoted Standby Edge back to it's original Active role, and demote the newly promoted Active Edge back to Standby, which defeats the purpose of forcing the failover in the first place.
Issue 49883: For a VMware SD-WAN Edge using SFP modules on routed interfaces, when running the Remote Diagnostic ‘Interface Status’ both Speed and Duplex display no information.
This is a display issue only, there is no customer impact. The Edge knows the speed and duplex status of the SFP interface and the functionality of the SFP interface is not impaired, but the information does not get outputted to the diagnostic or matching log.
Fixed Issue 50067: NAT is skipped for the traffic routed via subinterface when "NAT direct" is enabled on the subinterface and disabled on the 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 the parent interface.
Fixed Issue 50929: In rare cases where a VMware SD-WAN Edge has an extremely high number of TCP and UDP flows, there are unnecessary system level logs that fill up the filesystem causing the Edge's to suffer a Dataplane Service Failure.
While rare, this issue is more likely to impact entry level Edge models like the 500, 510, 520, and 610 which have less RAM and smaller SSD's. Because these system log files completely fill up the Edge's file system the Edge will likely suffer three Dataplane Service Failure's in succession (this will be seen in the Events) and the Edge Service will need to be manually restarted by a user through the VMware SD-WAN Orchestrator.
Issue 51025: When a WAN link flaps (alternates rapidly between an up and down state) on a VMware SD-WAN Edge, the route table entry for the routed interface’s default gateway may be removed and not reapplied.
When an Edge encounters this issue, there is a link flap, and the default gateway route entry gets removed for the interface using that link, resulting in an empty route table for the interface. However, if left with an empty route table, Linux connection tracking (conntrack) will route to the next table by default causing all packets to egress through the wrong routed interface.
Fixed Issue 51108: VMware SD-WAN Edge continues to send traffic to the VMware SD-WAN Gateway of a Non SD-WAN Destination (NSD) even when the NSD tunnels on the Gateway are down.
The Gateway does not send the NSD reachability event to Edges when the NSD public IP address is changed on the VMware SD-WAN Orchestrator and that was causing the Edge to continue to forward traffic to the NSD via Gateway. Without the fix the only corrective action is to bounce the NSD tunnel on the Gateway.
Fixed Issue 51166: On a VMware SD-WAN Edge 610, if GE2 is configured as a routed interface and a VLAN is configured on it, traffic on that VLAN gets dropped.
Due to an incorrect programming of the Edge 610’s switch, the VLAN tables were not properly set up when GE1 or GE2 are converted to routed interfaces. An Edge 610 without this fix should only use GE3 through GE6 as routed interfaces with VLANs.
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 51506: For a site using an Enhanced High-Availability topology, if the Active Edge loses all WAN connectivity while the Standby Edge loses all LAN connectivity, HA Failover does not occur, and the site has no connectivity.
In an Enhanced HA deployment, the Standby Edge must be able to communicate with the Active Edge through its LAN ports for Enhanced HA to work properly. If the Active Edge loses WAN connectivity it would be expected to tunnel through the Standby Edge to use its WAN connectivity and allow the site to continue passing traffic. In this scenario the Active Edge cannot reach the internet on its WAN link(s) but also cannot reach the Standby Edge's still working WAN links while also not being able to initiate a failover. The result is a site that is completely down and unable to pass traffic.
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 51915: For a site where the SD-WAN Edges are deployed in a High-Availability topology, should the site have an HA failover, Cloud via Gateway traffic switches to Direct to Cloud traffic.
After HA failover, if the path to the VMware SD-WAN Gateway is not up when the traffic reaches the Edge, the traffic goes 'Direct to Cloud' instead of 'Cloud via Gateway'. Direct to Cloud traffic does not utilize VMware SD-WAN’s Dynamic Multipath Optimization (DMPO) and traffic sensitive to loss or jitter would not benefit from these enhancements when sent Direct.
Fixed Issue 51959: If a LAN side NAT is configured with inside IP address as the VMware SD-WAN Edge’s local IP address, SNMP walk and ping to the outside IP address will fail.
If the LAN side NAT rule is configured with an inside IP address as one of the LAN interface’s IP addresses, the ping request and SNMP query request to the outside IP address should be translated to the inside IP and the LAN interface should respond to the ping and SNMP request. But the traffic will be dropped at the Edge and the remote branch receives no reply,
Fixed Issue 52141: 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.
Absent this fix, the only way to address this issue is to run the Remote Diagnostic ‘Flush Flows’ on the Hub Edge for the given tuple.
Fixed Issue 52141: If the TCP socket that connects a VMware SD-WAN Edge's OSPF process and SD-WAN process goes down and must recover, the Edge’s OSPF default route may not get refreshed, leading to traffic failure for that site.
If there is a flap in the Zebra channel (the TCP socket) between the OSPF process (ospfd) and the SD-WAN process (edged), and around the same time there is also a link-state advertisement (LSA) refresh scheduled for the default route in OSPF. Due to this timing, ospfd finds that the Zebra channel is not set up and hence it skips the regeneration of the LSA when its timer expired at nearly the same time. After this the LSA is removed (since it was not refreshed) with the result that no traffic can be passed in the network using this Edge. The fix forces the OSPF process to refresh the entire configuration and ensure that the default route is always present.
Fixed Issue 52252: For a site configured with a High-Availability topology, when a failover occurs, traffic that is classified as Cloud via Gateway switches to Direct to Cloud traffic.
After HA failover, if the path to the VMware SD-WAN Gateway is not up when the traffic reaches the Edge, the traffic is sent 'Direct to Cloud' instead of 'Cloud via Gateway'. This issue is for flows that exist prior to the HA failover, and these flows once sent Direct never get steered back to the Gateway. Once the HA failover is completed, new flows with a “Cloud via Gateway” tag would be steered to the Gateway as expected.
Fixed Issue 52300: When a Partner is upgrading a VMware SD-WAN Gateway using the vcg_software_update script, the script may prompt the user to resolve a configuration conflict during the Gateway upgrade, and the Gateway upgrade may fail on some systems if the upgrade is performed in non-interactive (unattended) mode.
Some older Gateway images contain a modified open-vm-tools configuration file. When a new package attempts to replace this file, this causes a configuration conflict.
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 52659: When a VMware SD-WAN Edge is configured as a DHCP relay agent, the Edge does not forward the DHCP NAK packets to a client.
If the DHCP server sends DHCP NAK packets, the Edge which is configured as DHCP relay will drop the packets without forwarding them.
Fixed Issue 52870: TX transmission stalls on an 82599 NIC used by a VMware SD-WAN Edge 1000 and 2000, resulting in all traffic stopping on connected SFP modules.
This issue prevents traffic from being passed on connected SFP ports until an Edge Service restart is performed. The fix detects the TX stall and logs all registers for diagnostic logging.
Fixed Issue 53019: A VMware SD-WAN Edge may suffer a Dataplane Service Failure when receiving a corrupted packet.
The Edge my interpret the corrupted packet (e.g., an invalid message sent by a peer) as a VeloCloud Management Control packet (NACK) which the Edge has no ability to process properly and thus suffers the Dataplane Service failure and restarts the service to recover. The packet in the field case was sent by a peer device.
Fixed Issue 53176: When a VMware SD-WAN Edge 610 undergoes a VRRP state transition from Backup to Active, there is LAN to WAN traffic loss for ~4 minutes.
The Edge 610 does not learn the VRRP MAC address after it becomes Active, so traffic is dropped until the Edge 610 learns the MAC address, which takes ~4 minutes.
Fixed Issue 53283: The link mode specified via a business policy is not honored when 1:1 NAT is also configured.
For outbound traffic, while finding the matching 1:1 NAT rule (if configured), the link mode configured via the business policy is ignored and the first matching 1:1 NAT rule is selected always. Ex: business policy asks to select a link as ‘mandatory’, but 1:1 NAT results in the selection of another link which is specified in the first matching 1:1 NAT rule. Without the fix, the only way to address the issue is to execute a Remote Diagnostic > Flush Flows for the affected VMware SD-WAN Edge.
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.
Fixed Issue 53477: When VMware SD-WAN Edges configured in a High Availability topology are moved to a different configuration profile, the Edges experience repeated Edge service restarts.
For this issue, one of the HA Edges is configured to have more LAN or WAN interfaces than the other HA Edge (e.g., a WAN port is disabled one of the Edges), and then if these Edges are moved to a different profile, the Edges will suffer continuous Edge restarts.
Fixed Issue 53546: If MPLS CoS (Class of Service) is enabled and if one of the CoS in the private link has loss, packets in the other CoS can be dropped due to oversubscription.
If one or more sub-paths in the private link enters an unstable state due to loss, the entire bandwidth of the private link will be excluded from the device bandwidth cap calculation. As a result, some of the packets in the other sub-paths may be dropped if the current bandwidth usage exceeds the device bandwidth cap. The device bandwidth cap is calculated by finding the sum of bandwidth of the stable links.
Fixed Issue 53676: On the VMware SD-WAN Edge 3x00 platform, very brief periods of input voltage instability, as short as 4 milliseconds, can cause the Edge to reboot.
This issue is typically seen when using an Uninterruptible Power Supplies (UPS) that experiences slight output voltage instability when switching from line to battery. The fix for this issue upgrades the Edge’s firmware to tolerate 20-30ms of voltage instability prior to the Edge rebooting.

Note: Upgrading the 3x00's firmware will extend the Edge's upgrade time to 3-5 minutes. For an Edge 3x00 model without this fix, the customer’s only option is to use a more sophisticated UPS that can switch its input without any output voltage instability.
Fixed Issue 53864: The local underlay OSPF route is not correctly sorted in the VMware SD-WAN Edge’s forwarding information base (FIB) relative to the OSPF routes from the Hub Edge(s), and the overlay preferred route on an Edge is not correctly redistributed to the underlay OSPF.
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 OSPF route is initially preferred in the Edge FIB and later, an overlay OSPF 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 OSPF. Without the fix, the Edge must be forced to relearn either the underlay or overlay OSPF route as appropriate.
Fixed Issue 54001: A VMware Edge is unable to send traffic after a Tx queue hang on SFP interfaces.
In rare cases, when the Edge sends an invalid sized packet (less than 17 bytes or greater than 1526 bytes) to DPDK, the transmit queue becomes stalled and causes any further traffic to not be forwarded by the Edge. Rebooting the Edge temporarily corrects the issue, but the problem can happen again when an invalid sized packet is sent from the Edge service to DPDK. Only upgrading to a level with the fix avoids this problem.
Fixed Issue 54227: When a WAN link goes down and up in rapid succession (i.e., flaps) on either a VMware SD-WAN Edge or Gateway with DPDK enabled the system may suffer a Dataplane Service failure.
There is an issue with how the SD-WAN Service handles link state changes in DPDK that creates a race condition and potential memory corruption during handling link state events which leads to the Dataplane Service failure and the subsequent restart to recover the Edge or Gateway.
Fixed Issue 54529: The routing services on a VMware SD-WAN Gateway using a 3.4.4 Release may function improperly, potentially leading to a Dataplane Service failure.
Release 3.4.4 did not include the correct version of the Quagga network routing suite and this caused the Gateway routing services to not function as expected and, in a few field cases where the Gateway was passing large amounts of traffic, resulted in the Gateway’s Dataplane Service needing to restart.
Fixed Issue 55181: For a customer enterprise that uses a Hub/Spoke network topology where the VMware SD-WAN Spoke Edge backhauls traffic to the Hub Edge, should the Spoke Edge’s tunnel to the Hub Edge go down, the traffic continues to be marked as ‘backhaul’ and is routed to the Hub versus being routed direct branch-to-branch.
Immediately after a Spoke to Hub failover or after recovering from a WAN connectivity loss on all overlay links, routes may not be learned, and flows may be considered as internet flows and match a backhaul business policy. However, once the correct routes are learned, sometimes the business policies are not re-evaluated for these flows and do not recover from this state.

Orchestrator Resolved Issues

Resolved in Version R345-20210201-GA

The below issue has been resolved since Orchestrator version. R344-20201103-GA.

Fixed Issue 50380: For a VMware SD-WAN Orchestrator deployed in a Disaster Recovery (DR) topology, if a failover is performed, the reporting service no longer works.
The backend service does not restart the reporting service after a DR failover, and this causes the reporting service to run in an unexpected mode. Without this fix, an administrator would need to restart the reporting service as another failover does not address the issue.
Fixed Issue 50590: The VMware SD-WAN Orchestrator sends out Cloud Security Service (CSS) tunnel alerts with a UTC timestamp versus the VMware SD-WAN Edge’s local time zone.
The issue occurs when CSS tunnel alerts are triggered and sent via email, webhook, etc. This issue should not have any functional impact but is annoying for customers not interested in converting UTC to several different time zones depending on the Edge’s location.
Fixed Issue 50719: When a pair of VMware SD-WAN Edges configured in a High Availability topology are upgraded to Release 3.4.1 or 3.4.2 or 3.4.3, the Standby Edge will no longer be detected.
When the Edges are upgraded, the HA interface (i.e. LAN1 or GE1) is programmed as a trunk port when it should be configured as an access port and this results in the HA interface failing to come up. The fix adds a validation to ensure the HA interface is configured as an access port. Without the fix, the only workaround is to reconfigure the HA port to “Access” using the VMware SD-WAN Orchestrator.
Fixed Issue 52379: The VMware SD-WAN Orchestrator sends out an ‘Edge Down’ alert email if the VMware SD-WAN Edge recovers within the configured delay interval.
Administrators can be falsely alerted of an Edge being down in their network even though they configured a delay to allow an Edge to be down for a period of time before triggering that alert.
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, because the Standby Orchestrator is continuously attempting to open SSH connections to the Active Orchestrator to copy files it has already copied.
Fixed Issue 54586: For a VMware SD-WAN Edge which has static routes configured, when a new business policy is created on the VMware SD-WAN Orchestrator, several of the static routes may be removed.
The issue is caused by an Edge function that uses segmentId as an index which causes an issue when one of the segmentId's is missing.

Known Issues

Open Issues in Release 3.4.5

The known issues are grouped as follows.

Edge/Gateway Known Issues
Orchestrator Known Issues

Edge/Gateway Known Issues

Issue 08744:
Passive FTP and TFTP will not work via 1:1 NAT

Workaround: Please consult https://kb.vmware.com/s/article/2913337
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 17411:
1:1 NAT fails if a rule is created on a routed interface that has a subinterface, and the subinterface has a different IP than the 1:1 NAT rule.
Issue 25302:
If the dataplane service is disabled on the VMware SD-WAN Edge, a "Restart Services" does not work properly and a "Reboot" must be triggered to recover the Edge.
Issue 25855:
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 32917: The output is not accurate for the Multicast PIM Neighbors monitoring page on the VMware SD-WAN Orchestrator.
The inaccurate output for Multicast PIM Neighbors on the Edge monitoring page may include the PIM interface for some of the Edges showing a garbage value instead of an actual interface and PIM neighborship still showing in monitoring even after it gets deleted from the Edge.

Workaround: There is no workaround for this issue.
Issue 34626: Invalid control packets from a VMware SD-WAN Edge to a VMware SD-WAN Gateway may cause the Gateway service to restart.
For flows from an Edge to a Gateway, the Edge sends a control message to the Gateway to synchronize the business policy actions for each flow. If the control message has an invalid action the Gateway is not marking the action as invalid and is attempting to route the data packets of the flow with the invalid action set, and this can cause the Gateway to suffer a Dataplane Service Failure with a resulting service restart.

Workaround: There is no workaround for this issue.
Issue 36970:
VMware SD-WAN Edge Firewall logging may incorrectly list the incoming interface as “VLAN-1” for traffic that was received from the cloud via 1:1 NAT.
Issue 37308:
If a user deletes all the links configured to build GRE tunnels to Zscaler (but does not disable Cloud Security Service), then changes the Zscaler IP addresses and re-configures the links, the Edge must be restarted to route traffic over the GRE tunnels.
Issue 37664:
When Edge-to-Edge via VMware SD-WAN Gateway is configured on the spoke, the routes of the cluster Hub remain unreachable for a few seconds.
Issue 37955:
NetFlow Exporter may export the wrong flow path for peer-initiated flows sent directly between VMware SD-WAN Edges.
Issue 38682:
A 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 38925:
VPN flows are not synchronized properly between VMware SD-WAN Edges in a High Availability pair, which may cause stateful firewall sessions via VPN to stall on an HA failover.
Issue 39014:
A VMware SD-WAN Edge service restart may be required when changing established Zscaler tunnels from IPsec to GRE to the same Zscaler IP address.
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 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 39384:
Traffic initiated on a WAN-overlay configured interface may be double counted in NetFlow statistics.
Issue 39464:
When an SNMP agent is configured to listen on a non-default port, the SNMP Access firewall rule is not updated to that configured port.
Issue 39609:
Incorrect packet loss may be reported when MPLS Classes of Service are turned on for one VMware SD-WAN Edge but not the peer Edge and link steering via business policy is configured.
Issue 40360:
A default route learned through a VMware SD-WAN Hub Edge may not be removed on all Spoke Edges after deleting the route at the Hub.
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 40442:
Enabling LAN-side NAT rules may reduce the maximum throughput possible through the VMware SD-WAN Edge by up to 10% (depending on the Edge model).

Workaround: There is no workaround for this issue.
Issue 40696:
Disabling BGP on a VMware SD-WAN Hub Edge that is active in a Cluster does not set the BGP route count for this Hub Edge to 0 and trigger an automatic failover as expected.
Issue 40777:
Syslog export of VMware SD-WAN Edge events does not work to a server that is reachable over VPN only via a default (0.0.0.0/0) route.
Issue 40988:
On VMware SD-WAN Edge models 500, 510, and 520, the Local UI may take a very long time to come up, or time out.
Issue 42577:
Dynamic Bandwidth Adjustment does not run for a wired link that is converted to wireless.
Issue 42872:
Routes on VMware SD-WAN Edge Spokes may not be removed as expected after enabling profile isolation when the Edges are connected to a VMware SD-WAN Hub Cluster.
Issue 43613:
OSPF neighborship may not be established over a routed interface when the interface receives its DHCP IP after a delay.
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 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.

Workaround: Configure a firewall rule to drop the traffic if the NAT subnet in not advertised.
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 45542:
When a VMware SD-WAN Hub Edge is removed from a Hub Cluster, the Spoke Edges remain associated with that removed Hub Edge and are not reassigned to other Hub Edges in the Cluster.

Workaround: For the Hub Edge that is removed, run the Remote Diagnostic utility “Redistribute Spokes excluding this Hub” found under the “Rebalance Hub Cluster” section.
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 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 100 Mbps and duplex.
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 turn on 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 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 50223:
If a VMware SD-WAN Edge is upgraded to Release 3.4.x, the Edge does not report LAN interfaces via SNMP.

Workaround: There is no workaround for this issue.
Issue 51005:
Interface IP configurations are missing for VMware SD-WAN Edges when deployed using a cloud-init file which uses the newer 3.4.x syntax.
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 are out of sync in terms of the SA and the link is 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.
Issue 55348: For a site using an Enhanced High-Availability topology, one of the Edges may suffer a Dataplane Service failure when a WAN interface flaps.
When a WAN interface goes down and comes up rapidly (i.e. flaps) there is a memory corruption that triggers the Dataplane Service failure which results in the Edge restarting. If this happens on the Active Edge on the Enhanced HA site, that Edge will fail over and promote the Standby Edge.

Workaround: There is no workaround for this issue.
Issue 55374: Under certain traffic , TX transmission stalls on an 82599 NIC, which is used by VMware SD-WAN Edge models 1000 and 2000.
82599 HW transmit path is hung under certain conditions, recreating the exact root cause remains in process.

Workaround: Restarting the Edge is the only way to recover the SFP link.
Issue 56218: For a site using a High-Availability topology, when upgrading VMware SD-WAN Edge models 520 or 540 from a 3.3.x or lower to Release 3.4.x or higher, the Standby Edge will go down and not recover until it is rebooted.
As noted in the 3.4.0 Release Notes, VMware renames the internal ports for the Edge models 520 and 540. The HA port (GE1) is renamed from sw1p1 to lan1. However when this network file that changes the port naming is copied to an Edge 520 or 540 running 3.3.x or lower as part of the upgrade, the Standby Edge’s HA port is not renamed and does not sync up with the Active Edge.

Workaround: Rebooting by way of power cycling the Standby Edge recovers it as the HA port is then properly renamed to the 3.4.x standard and can sync up with the Active Edge.
Issue 56223: In a scale environment which uses a Hub/Spoke topology and multicast with 1500+ PIM neighbors, even though PIM JOIN is successful for the VMware SD-WAN Spoke Edges, their logical IDs are missing in the Hub Edge’s Outgoing Interface List (OIL) entries in the MCR table.
The current maximum virtual interface count is not enough to support a large multicast enterprise with 1500+ Edges.

Workaround: There is no workaround for this issue.

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 turned on and cannot reach the MaxMind server, new VMware SD-WAN Edge activations will not work.
Issue 24269:
Monitor > Transport > Loss not graphing observed WAN link loss while QoE graphs do reflect this loss.
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 33026:
The ‘End User Service Agreement’ (EUSA) page does not reload properly after deleting the agreement.
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: Turn off and turn back on 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: Turn off and then turn back on GRE at the Edge level to resolve the issue.
Issue 38843:
When pushing an application map, there is no Operator event, and the Edge event is of limited utility.
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 40567:
A user is able to clone a customer enterprise even though the customer's profile includes partner gateways (which cannot be cloned) and there is no clear error message about why attempting this will not work.
Issue 40746:
Connected subnets and static routes associated with subinterfaces may not show up as expected on the Configure > Overlay Flow Control screen of the VMware SD-WAN Orchestrator.

Workaround: Ignore the duplicate event.
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 VMware SD-WAN Partner Gateway configured.
Issue 46482:
If a site using VMware SD-WAN Edge 540’s configured in High-Availability is upgraded to Edge software release 3.4.1, the VMware SD-WAN Orchestrator will display this site’s HA status as “Standby Failed”.
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 turned on, 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.