Updated 25 April, 2023

VMware SD-WAN Orchestrator Version R346-20210623-GA
VMware SD-WAN Gateway Version R346-20210701-GA
VMware SD-WAN Edge Version R346-20210910-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

This release is no longer recommended for use as SD-WAN Release 3.4.x has reached its End of Support Life (EOSL). Customers are encouraged to upgrade to a recommended release as soon as possible.

Compatibility

Release 3.4.6 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

Hub

Branch/Spoke

3.4.6

  3.2.2 *

  3.2.2 *

  3.2.2 *

3.4.6

3.4.6

  3.2.2 *

  3.2.2 *

3.4.6

3.4.6

  3.2.2 *

3.4.6

3.4.6

3.4.6

3.4.6

  3.2.2 *

3.4.6

  3.3.2 P2 *

  3.3.2 P2 *

  3.3.2 P2 *

3.4.6

  3.3.2 P3 *

  3.3.2 P2 *

  3.3.2 P2 *

3.4.6

3.4.6

  3.3.2 P2 / 3.3.2 P3 *

  3.3.2 P2 / 3.3.2 P3 *

3.4.6

3.4.6

3.4.6

3.3.2 P2 *

3.4.6

3.4.6

  3.3.2 P2 / 3.3.2 P3 *

3.4.6

3.4.6

3.4.5

3.4.4 / 3.4.5

3.4.4 / 3.4.5

3.4.6

3.4.6

3.4.4 / 3.4.5

3.4.4 / 3.4.5

3.4.6

3.4.6

3.4.4 / 3.4.5

3.4.6

3.4.6

3.4.6

3.4.6

3.4.4 / 3.4.5

3.4.6

3.4.6

3.4.3

3.4.3

3.4.6

3.4.2

3.4.2

3.4.2

3.4.6

3.4.4

3.4.2

3.4.2

3.4.6

3.4.6

3.4.2

3.4.2

3.4.6

3.4.6

3.4.2

3.4.6

3.4.6

3.4.6

3.4.6

3.4.2

3.4.6

3.4.5

3.4.6

3.3.2 P3

3.4.6

3.4.4

  3.3.2 P3 *

3.4.6

3.4.6

3.4.6

  3.3.2 P3 *

  3.2.2 *

3.4.5

3.4.6

3.4.2

3.4.3

3.4.5

3.4.5

3.4.6

3.4.6

4.0.1

3.4.6

3.4.2

3.4.6

4.2.1

4.2.1

3.4.6

3.4.6

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, 3.3.x, and 3.4.x have all reached End of Support for the Orchestrator and Gateway.

  • 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.
  • Release 3.4.x for the Orchestrator and Gateway reached End of General Support (EOGS) on March 30, 2022, and End of Technical Guidance (EOTG) on September 30, 2022.
  • Release 3.4.x for the Edge reached End of Support (EOGS) on December 31, 2022, and End of Technical Guidance (EOTG) on March 31, 2023.
  • For more information 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. This same workaround was included in the original 3.4.6 GA Edge build.

As a result, Issue 53243 has been moved from the Resolved section to the Open section for the 3.4.5 Release Notes and has also been added to the 3.4.6 Release Notes as an Open Issue, and the workaround for 53243 is reverted in Edge build R346-20210910-GA-53243, the new official GA build for 3.4.6. 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).

Support for New Hardware Platforms

Edge 510N, Edge 610N, Edge 620N, Edge 640N, and Edge 680N

VMware plans to introduce several new SD-WAN Edge hardware models that do not include integrated Wi-Fi. These include the Edge 510N, 610N, 620N, 640N, and 680N. These Edge models will be supported in this release. Any Wi-Fi configurations made in the VMware SD-WAN/SASE Orchestrator’s settings will not impact these Edge models.

Release limitations: In Release 3.4.6, the VMware SD-WAN Orchestrator will continue to display the WLAN interfaces for the non-Wi-Fi Edge devices even though Wi-Fi is not supported.

Note: Mixing Wi-Fi Capable and Non-Wi-Fi Capable Edges in High Availability Is Not Supported 

While the Edge models 510N, 610N, 620N, 640N, and 680N appear identical to their Wi-Fi capable counterparts, deploying a Wi-Fi capable Edge and a Non-Wi-Fi capable Edge of the same model (for example, an Edge 640 and an Edge 640N) as a High-Availability pair is not supported. Customers should ensure that the Edges deployed as a High Availability pair are of the same type: both Wi-Fi capable, or both Non-Wi-Fi capable.

Document Revision History

July 7th, 2021. First Edition.

September 17th, 2021. Second Edition.

  • Moved 53243 from the Resolved Issues section to Open Issues section because the fix has been shown to be ineffective in the field.
  • Added an Important Note regarding the reversion of 53243.
  • Changed the Edge GA build to R346-20210910-GA-53243 which reverts 53243.
  • Added a new ticket 47778 to Edge/Gateway resolved issues that was fixed with the GA build but initially omitted from the Release Notes as an oversight.

September 29th, 2021. Third Edition.

  • Added a warning under the compatibility table that the 3.2.x and 3.3.x Release trains are approaching End of Support with dates and a link to the KB article.  Also added a * to each 3.2.x and 3.3.x Release in the table pointing to that warning.

November 10th, 2021. Fourth Edition.

  • Moved Fixed Issue #46208, from the Resolved Issues section to the Edge/Gateway Known Issues section and removed the Fixed label. This issue was erroneously marked as Fixed when first compiling the 3.4.6 Release Notes.

December 21st, 2021. Fifth 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 2nd, 2022. Sixth Edition

  • Under Support for New Hardware Platforms, added an important note: "Note: Mixing Wi-Fi Capable and Non-Wi-Fi Capable Edges in High Availability Is Not Supported" to the Edge 510N, Edge 610N, Edge 620N, Edge 640N, and Edge 680N section.

March 28th, 2022. Seventh Edition.

  • Under the Compatibility section, 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.

September 14th, 2022. Eighth Edition.

  • Removed Issue #61797 "Route backtracking is not supported on the VMware SD-WAN Edge which results in false reachability routes" from the Edge/Gateway Resolved Issue section. This issue was included erroneously and because it is an enhancement is being removed entirely from the Release Notes, versus relocating it to Known Issues.

April 25th, 2023. Fourteenth Edition.

Resolved Issues

The resolved issues are grouped as follows.

Edge/Gateway Resolved Issues

Resolved in Version R346-20210701-GA

The below issues have been resolved since Edge and Gateway versions R345-20210202-GA.

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

  • Fixed Issue 34037: A VMware SD-WAN Gateway may encounter a Dataplane Service failure after a peer tunnel drops.

    When a peer tunnel goes dead, the cleanup process takes the fc->vpi and assigns it to NULL. There seems to be a few packets in the pipeline which still had a reference to this fc. As part of processing those packets fc->vpi is accessed which is NULL and hence the Gateway process hits an exception and restarts.

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

  • Fixed Issue 40268: Where a user changes the configuration of a VMware SD-WAN Hub or an Edge-to-Edge via Hub configuration, the Spoke Edge installs routes that are marked as 'False'.

    The Spoke Edge installs routes in the FIB which are marked as False (as there is no tunnel from the Hub for those routes) and these routes stay in the FIB for ~2 minutes before being cleared out.  In that time, these False routes may cause disruption to some networks. 

  • Fixed Issue 41837: The NAT IP address of the source and destination gets printed in a VMware SD-WAN Edge's log instead of the original IP address.

    The Edge firewall logs should display the original source & destination IP address but instead the NAT'd IP gets printed, severely undermining the usefulness of the firewall logs.

  • Fixed Issue 42505: A VMware SD-WAN Gateway may experience a Dataplane Service failure while running a NAT table dump.

    This issue is the result of duplicate entries for a flow being installed in the NAT table when a flow is deleted and added again. A configuration change involving a NAT IP (e.g., changing the NAT IP on a Business Policy) is a way to potentially trigger this issue. The duplicate entries eventually lead to a corruption of the NAT tables and cause the Gateway Dataplane Service to fail and restart. The fix ensures that the NAT entry is freed only after it is deleted from both NAT tables.

  • Fixed Issue 43278: If a user configures an outbound BGP filter to match the default route or prefix, and then sets an AS Path prepend, the default route or prefix is advertised to the BGP neighbor, but no AS Path prepend occurs.

    A BGP outbound neighbor filter set to match a prefix and set AS Path prepend does not work on any prefixes originated by using the BGP Advanced configuration "Networks" statement. This also does not work for a default route originated to a neighbor via the neighbor "DR Originate", via the BGP Advanced "Conditional" Default Route Advertise check box.

    Also when using a static route configuration configuration on the VMware SD-WAN Edge, neither a default route or a non-DR static route set to "Advertise" would be advertised to a BGP neighbor with the AS Path prepended; the only AS in the prefix is the Edge's own AS.

  • Fixed Issue 43401: Application traffic is misclassified resulting in low priority traffic being classified as high priority.

    This issue affected Microsoft Office365 application traffic, where the SD-WAN service was classifying low priority applications like Sharepoint and Outlook as high priority, realtime generic Office365 applications which resulted in these application competing for bandwidth with applications that really are high priority traffic (e.g., Teams).  This is the result of the service "fast learning" Office365 (or any such application) versus waiting for the Deep Packet Inspection (DPI) engine to more specifically identity the application traffic.  The fix ensures that DPI result is preferred over the fast learned application ID.

  • Fixed Issue 43863: On a customer site using VMware SD-WAN Edges in an Enhanced High-Availability topology, a DHCP enabled proxy interface fails to assign an IP address.

    On a Standby Edge, the DHCP reply packet is wrongly sent to the Active edge and the Standby edge fails to configure an IP address for the affected interfaces. Without the fix, the only workaround was to use static IP addresses instead of dynamic IP addresses.

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

  • Fixed Issue 45456: After deleting a user-defined WAN overlay link using the VMware SD-WAN Orchestrator, the VMware SD-WAN Edge retains the link as an auto-discovered link and pushes this configuration to the Orchestrator.

    The Edge and Orchestrator both retain a user-defined link after deletion due to a race between the deletion of the link and the sending of links statistics from the Edge. The reception of link statistics with the deleted link recreates the link as auto-discovered on the Orchestrator.

  • Fixed Issue 46489: If different Partner Gateway enabled profiles are assigned to multiple VMware SD-WAN Edges, the Edges will retain stale routing entries for the VMware SD-WAN Partner Gateways not assigned in their profile.

    If different Partner Gateway enabled profiles are assigned to multiple Edges, the Edge keeps the routing entries which are learned from other Gateways, and those routes are considered stale entries.  The customer impact is traffic not being routed correctly because the Edge is trying to send traffic to invalid routes for that profile.

  • Fixed Issue 47778: VMware SD-WAN Partner Gateway may suffer a Dataplane Service failure and restart.

    The Partner Gateway Dataplane Service failure stems from memory corruption which can be caused in one of two ways: 

    1. When there are a large number of Partner Gateway handoffs with BGP configurations across multiple segments, and the user removes a configured Partner Gateway Handoff configuration.
    2. When there are a large number of Partner Gateway handoffs with BGP configurations across multiple segments, and the user disables a Partner Gateway Handoff configuration altogether with the goal of cleaning up the configurations.
  • Fixed Issue 48958: A VMware SD-WAN Gateway may lose connectivity on a bonded interface.

    When the VeloCloud Management Protocol (VCMP) and the WAN port are set to use the same port, the Partner Gateway VLAN handoff configuration may cause the Gateway to go offline due to ARP resolutions failing. With this fix, when VCMP and the WAN port are the same, the VLAN handoff configuration from the VMware SD-WAN Orchestrator will be rejected in the Gateway.  Without the fix, the workaround is to not assign the same port for VCMP and WAN.

  • Fixed Issue 49612: A VMware SD-WAN Hub Edge on a large deployment where multiple Spoke Edge tunnels are brought down and up may suffer a Dataplane Service Failure and restart as a result.

    A large deployment is understood as a Hub/Spoke topology where a Hub Edge is connected to ~4K Spoke Edges with ~6K tunnels, if over 100 tunnels to Spoke Edges are brought down and then up, the Hub Edge may suffer a Dataplane Service Failure and restart.  The Edge service restart would cause traffic disruption to all Spoke Edge for ~15-30 seconds.

  • Fixed Issue 50233: A VMware SD-WAN Edge using Release 3.4.x or higher will not send information for physical LAN interfaces via SNMP. 

    In releases prior to 3.4.x when VMware SD-WAN used net-snmp, LAN interfaces were sent via SNMP. In Release 3.4.x, we added our own snmpagent, which fetches the data from the command debug.py --interfaces and that output does not have information about LAN interfaces. The fix adds LAN interfaces to that command so that the snmpagent can send the data via SNMP.

  • Fixed Issue 51502: Dynamic Branch-to-Branch tunnels are accepted by VMware SD-WAN Edges that do not have Branch-to-Branch VPN enabled.

    Edges always respond to dynamic tunnels, even when they do not have Branch-to-Branch VPN enabled. Tunnels can also form even if one side is set to 'To Edges within Profile' and the other side is set to 'To All Edges'.  There is impact in the field since inbound tunnels cannot be controlled. In one field case, Branch Edges form dynamic tunnels to Hub Edges of other regions which then causes other routing issues in the enterprise's backbone.

  • Fixed Issue 51915: On a customer site using an Enhanced High-Availability topology, after an HA failover, 'Cloud via Gateway' flows switch to a 'Direct to Cloud' path.

    After an HA failover, if the path to the VMWare SD-WAN Gateway is not up when the traffic reaches the VMware SD-WAN Edge, the traffic goes 'Direct to Cloud' instead of 'Cloud via Gateway'. This can have significant impact for flows that rely on Dynamic Multipath Optimizations like Realtime traffic (e.g. voice and video) because Direct traffic does not use these optimizations.

  • Fixed Issue 53750: A VMware SD-WAN Gateway may suffer a Dataplane Service failure and restart that service as a result.

    If a VMware SD-WAN Edge detects loss for the traffic received from the Gateway, it sends a negative-acknowledgement (NACK) message to the Gateway to retransmit the lost packets. The Gateway checks the retransmission slots to retransmit the packets. Ideally the Gateway should stop retransmission once all the slots are checked, but the Gateway checks the retransmission slots repeatedly until it reaches the sequence number in the NACK message, and this can cause the monitor thread in the Gateway to detect this as a hung thread and restart the Gateway.

  • Fixed Issue 53929: On a customer site using an Enhanced High-Availability topology, after an HA failover, 'Cloud via Gateway' flows switch to a 'Direct to Cloud' path.

    After an HA failover, if the path to the VMWare SD-WAN Gateway is not up when the traffic reaches the VMware SD-WAN Edge, the traffic goes 'Direct to Cloud' instead of 'Cloud via Gateway'. This can have significant impact for flows that rely on Dynamic Multipath Optimizations like Realtime traffic (e.g. voice and video) because Direct traffic does not use these optimizations.

    Note: this is almost identical to 51915 but the underlying cause and fix are slightly different and thus tracked separately.

  • Fixed Issue 54136: On a site using a High Availability topology, a VMware SD-WAN Active Edge may initiate a Dataplane Service restart, resulting in an HA failover.

    The Active Edge consumes a high amount of memory when there are a high number of flows (1.9 million flows per second).  When memory consumption reaches a critical level, the Edge will restart to clear the memory and cause a failover.

  • Fixed Issue 54694: When a customer uses SNMP polling, SNMP monitoring delivers inaccurate measurements for outbound traffic.

    The SNMP call for IF-MIB::ifHCOutOctets delivers TX packets instead of TX Bytes, resulting in inaccurate outbound octet counts which affects the customer's ability to monitor their enterprise. This issue is the result of the snmpagent process monitoring Tx packets versus Tx bytes.

  • Fixed Issue 56149: After Dynamic Cost Calculation (DCC) is enabled on a customer enterprise which is using BGP, a VMware SD-WAN Edge may show an incorrect route preference value for auto-corrected routes if the BGP route for the underlay route flaps.

    The impact to the customer is asymmetric routing due to the incorrect remote route preference, which results in higher latency and poor performance on all customer applications. After DCC is enabled, the new routing information base (RIB) preference value should be updated on the route and the route should be re-advertised to the VMware SD-WAN Gateway with the new RIB preference value which is then communicated to all Edges. The cause of the issue is that when the route is auto-corrected, this RIB preference is not updated in the peer Edge's FIB table, which retains the old, pre-DCC value. 

  • Fixed 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 SD-WAN 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. Without this fix, the only way to recover the Standby Edge is by power cycling it as the HA port is then properly renamed to the 3.4.x standard and can sync up with the Active Edge.

  • Fixed Issue 56346: A customer may observe handoff queue drops when looking at a VMware SD-WAN Edge's Monitor > System page.

    A VCRP (VeloCloud Route Protocol) route event updates leads to handoff queue drops in the VCMP (VeloCloud Management Plane) data thread.  This is because when a route update is received, all the routes in the respective segment are invalidated. This leads to new route lookups in the data path. A particular function that is called as part of the route lookup does a costly hash enumerate operation leading to 40% increased VCMP data thread utilization.  For the instance when this issue was found in the field, the quantity of handoff queue drops was not sufficient to impact network performance.

  • Fixed Issue 56645: There are frequent WAN link flaps when a VMware SD-WAN Edge 610 is connected to certain Meraki Access Points.

    When an Edge 610 is connected to a Meraki M36 access point (or similar models), the Ethernet link encounters frequent link drops. This is the result of a driver issue on the Edge 610.

  • Fixed Issue 56876: A VMware SD-WAN Edges may encounter an issue related to memory management and trigger a kernel panic, which will result in an Edge reboot.

    This resolved issue includes fixes for two different scenarios involving memory management on an Edge which triggers a kernel panic:

    1. In the first scenario, where an Edge is using Dynamic Branch-to-Branch, the dynamic tunnels are created, and a small amount of memory is reserved for storing per-peer counters. When the dynamic tunnel is torn down, this memory is not cleaned up so as to optimize the bring up time the next time this same peer connects. On a small Edge (e.g., Edge 500, 510, 520, 610) which connects to a large number of different destinations over time, this can eventually exhaust available memory and trigger a kernel panic and an Edge reboot.  Without this fix, a user needs to proactively restart the Edge's service if memory usage is greater than 90% of health statistics when looking at an Edge's Monitor > System screen on the VMware SD-WAN Orchestrator.
    2. In the process of fixing the memory leak caused by Dynamic Branch-to-Branch, it was noted that malloc_trim (a process that clears up fragmented memory) was not being properly invoked and this process was modified as well for this fix. Not invoking malloc_trim properly can cause a different issue and can affect any Edge (not just smaller Edges) and does not require the Edge to be using either Dynamic Branch-to-Branch nor does Monitor > System show a memory usage exceeding 90%. This scenario is much more likely to occur if the Edge has a high number of flows.
  • Fixed Issue 57011: For a site configured with a High-Availability topology, whenever segments are added and then deleted on that site, one of the HA Edges may experience a Dataplane Service failure and if the service failure is on the Active Edge, the site would also experience an HA failover.

    When segments are added and then deleted from an HA site, there is the potential for stale segments (in other words, the deleted segments might still show up on one of the Edges in the HA pair). Due to this mismatch in segment information between the HA Edges, any event meant for the stale segment might be sent to the other Edge resulting in a Dataplane Service failure, an HA failover if the service failure is on the Active Edge, and the generation of a core dump that will be found on a diagnostic bundle taken after the failover.

  • Fixed Issue 57253: Customer may observe one or more WAN links on a VMware SD-WAN Edge going dead after a DHCP server update.

    If the DHCP assigned address changes on a server update, the DHCP packets are correctly handled only if the Edge's route lookup fails for the DHCP packets which then marks them as DCHP packets to be sent to the server.  When this issue occurs the route lookup for DHCP packets does not fail and the packets end up with a flow creation path and the DHCP request is not sent to the server which results in the WAN link associated with that address not passing traffic and being marked as Dead.

  • Fixed Issue 58075: On a VMware SD-WAN Edge where High Availability has been enabled. an SNMP walk/query will get timed out.

    SNMP query output will return only partial results and will ultimately get a timeout on a HA enabled Edge.

  • Fixed Issue 58527: When running the Remote Diagnostic "List Active Flows", business policy name output is limited to 24 characters versus the expected 32 and the business policy name is trimmed to 24 characters from the actual 32 characters.

    In .edge.info, the configured biz_policy name is listed properly (even if it occupies the full length in biz_policy_name field). But while displaying the biz_policy_name in user_flow_dump/ flow_dump output, the SD-WAN service is using only 24 characters to store the policy name. As a result, the actual configured biz_policy is not completely displayed.

  • Fixed Issue 58678: If Dynamic Edge-to-Edge is enabled and an invalid Dynamic Edge-to-Edge control message is received on a VMware SD-WAN Edge, the Edge can experience a Dataplane Service Failure and restart as a result.

    To create a tunnel to the peer Edge, the Edge requests Dynamic Edge-to-Edge information from the VMware SD-WAN Gateway. If the reply message from the Gateway is corrupt, it can cause the Edge to restart as proper validation is missing for some of the fields.

  • Fixed Issue 58830: VMware SD-WAN Edge is dropping traffic from a routed client to a VCMP server with catch-all NAT subnet in Partner Gateway.

    Ping from an Edge routed client to VeloCloud Management Protocol (VCMP) traffic fails where a default static route is advertised from a Partner Gateway to an Edge and the Edge itself has the local default static route configured pointing to an underlay L3 switch next hop for routed client reachability. Here, the Edge drops ICMP reply packets from VCMP with error as " rfc1918 cloud route match".

  • Fixed Issue 59008: The link internalID for multiple USB links may be the same across several VMware SD-WAN Edges, causing incorrect USB link statistics on the VMware SD-WAN Orchestrator.

    The USB links in different Edges can have the same internal ID assigned. As a result, the monitoring across different Edges for a customer is impacted, as some data will be missed.

  • Fixed Issue 59166: When a switch port (LAN ports 1-8) on an VMware SD-WAN Edge 520 or 540 is connected to certain types of equipment (notably Meraki or SonicWall firewalls), the link often does not come up when the interface is reconfigured.

    The switch ports on the Edge 520 and 540 models do not handle Energy Efficient Ethernet settings properly, resulting in a failure to negotiate a link with certain types of equipment. Without this fix, the only workaround is to disable EEE (energy-efficient ethernet) on the external firewall, or insert a simple unmanaged switch or other such device between the Edge and the external firewall.

  • Fixed Issue 60010: For a site using VMware SD-WAN Edges with VNF deployed in a High-Availability topology, the VNF on the Standby Edge is not accessible via SSH after a LAN-side port flap.

    The LAN side interface on the Standby VNF is in normally in a disabled state. Due to the LAN-side port flap, it moves to a forwarding state which results in a wrong MAC address port mapping on the bridge interface which results in inaccessibility of the VNF.

  • Fixed Issue 60184: A Branch VMware SD-WAN Edge installs routes marked with uplink community from a non-profile Hub Edge (Dynamic Branch-to-Branch) and prefers these routes before everything else.

    The non-profile Hub Edge is treated as a Branch Edge when Dynamic Branch-to-Branch is used.  So, when there is a dynamic tunnel bring-up, the issue occurs as described. The only workaround is to add Hubs to all profiles but this cannot scale on larger networks where there are 20+ Hub Edges due to the enormous number of routes that would be created..

  • Fixed Issue 60367: Stateful Firewall rules do not drop the first packet in a flow going to a VMware SD-WAN Edge IP even with a VLAN-specific drop rule in place.

    Sending a ping to and Edge's VLAN IP is successful even with VLAN-specific Stateful Firewall drop rules. With VLAN specific Stateful Firewall Drop rules, the behavior is not consistent between ping to a VLAN host and the VLAN IP of the Edge. Ping to a VLAN IP of the Edge is successful. The fix disallows ping to either the Edge VLAN-IP or VLAN host.

  • Fixed Issue 60578: A VMware SD-WAN Edge may encounter a service restart due to exhausted memory.

    Whenever an Edge fails to establish a management tunnel to a VMware SD-WAN Gateway due to a certificate issue like 'certificate error' or 'certificate expiry', the Edge leaks a chunk of memory in the IKE flow. This Edge keeps retrying again and again which will cause the Edge's Dataplane Service to exhaust Edge memory and force a restart.  Without the fix, the only workaround is to disable or block an Edge which is unable to establish a tunnel with a Gateway due to certificate issue.

  • Fixed Issue 60923: When a QuickAssist Technology (QAT) session failure happens with a -log message "QAT session creation failed for SA...", this can trigger a stale security association (SA), which can eventually fill the SA table of a VMware SD-WAN Edge.

    Hardware Edges use QuickAssist Technology to encrypt and decrypt customer traffic. The QAT session failure can happen if a QAT physical memory allocation fails. This is a reallocated structure, with limited space. When it reaches to the last element, QAT has to wait until some other session releases. This can trigger a QAT session failure, which triggers a stale SA, and if enough of these failures occur can fill the Edge's SA table and prevent additional SA's from being created.. Without this fix, the only way to recover from this situation is to reboot the Edge.

  • Fixed Issue 61282: The management tunnel from a VMware SD-WAN Edge to a VMware SD-WAN Gateway is failing due to a ike_child_sa failure on the Gateway side.

    This issue is caused by a very large number of IPsec stale security associations (12,000+) which does not allow creation of any more new IPsec SA`s. In some scenarios there is a possibility that stale IPsec inbound SA`s are not deleted in the Edge which can lead to the Edge running out of IPSEC SA memory space leading to the failure in creating new IPsec SA`s either by rekey or initial SA creation. With the fix, stale SA`s older than 60 seconds + rekey time will be forcefully removed from the system. Without the fix, the only way to temporarily recover this issue is to restart the Edge service, but this is only temporary and there is a possibility that a stale SA buildup will recur.

  • Fixed Issue 61361: When applying a software update to upgrade a VMware SD-WAN Edge 3400, 3800 and 3810 to Release 3.4.5, sometimes these Edge models do not boot back up immediately after the update.

    Release 3.4.5 includes a particular firmware update for the complex programmable logic device (CPLD), and the update triggers a reboot that can sometimes get "stuck", requiring a manual power cycle to restart the system.

  • Fixed Issue 61433: In a cascaded Hub/Spoke topology where one VMware SD-WAN Edge is a Spoke to a Hub-cluster and also a Hub to another Spoke, the underlay routing changes on one of the Hub-cluster members might delete the routes from this Spoke/Hub Edge.

    In case of cascaded Hub topology, the route removal on a Hub-cluster member triggered an unintentional delete message from the VMWare SD-WAN Gateway to the Spoke Edge also serving as a Hub Edge. That message was due to an update from the deep Spoke, that should have been ignored on the Gateway, but due to this issue, the Gateway sent a delete message to the Spoke/Hub Edge, resulting in the Edge losing those underlay routes (learned from the Hub cluster).

    Without the fix in this build, there is no workaround for this issue involving a cascaded Hub topology. It is advised to avoid making an Edge a Spoke to a Hub-cluster and also a Hub to a deep Spoke, otherwise this issue may appear.

  • Fixed Issue 61502: During activation of a VMware SD-WAN Edge, the download of the new software image to be applied is delayed indefinitely.

    In an environment with unreliable network connectivity, or certain types of traffic throttling, the HTTPS download of the new software image can get stuck. Without this fix, should this scenario happen, please power cycle the Edge and wait for a couple of minutes. The download should restart automatically, though it will restart all the way from the beginning.

  • Fixed Issue 61543: If more than one 1:1 NAT rule is configured on different interfaces with the same Inside IP, the inbound traffic can be received on one interface and the outbound packets of the same flow can be routed via different interface.

    For the NAT flows from Outside to Inside, the 1:1 NAT rules will be matched against the Outside IP and the interface where the packets are received. For the outbound packets of the same flow, the VMWare SD-WAN Edge will try to match the NAT rules again comparing the Inside IP and the outbound traffic can be routed via the interface configured in the first matching rule with "Outbound Traffic" enabled.

  • Fixed Issue 61592: With LAN side Source NAT configured, traffic from a remote branch to one hop away clients does not work.

    If SNAT is configured, the inbound flows from remote branches works only to the directly connected subnets. Traffic to clients which are one hop away does not work.

  • Fixed Issue 61596: There is a performance degradation when Partner BGP is enabled with secure option and a static route is configured as unsecure, or vice versa.

    The performance degradation is caused by a miscalculation of IP address maximum length when an unsecure static route picks up the secure flag from a BGP configuration. Initially the VMware SD-WAN Gateway does a route lookup and if it finds an insecure static route, the Gateway then checks if the BGP is enabled or not.  If BGP is enabled, the Gateway checks to see the encryption set and then picks up the encryption set for BGP which is secure, and then fragmentation happens because the secure option is more conservative than insecure.

  • Fixed Issue 62620: On a site deployed with a High Availability topology, direct traffic to some of the destinations might stop working after HA failover.

    The flows from the Active VMware SD-WAN Edge are synced to the Standby Edge along with the port allocated for the NAT entry so that when there is a failover, there is no disruption to traffic after failover. The port allocated on the Standby Edge is never freed even after the flow expires. So when there is a failover, there is a possibility of NAT port exhaustion and NAT failure. As a result, packets can get dropped on the Edge.

  • Fixed Issue 63056: A VMware SD-WAN Edge may encounter a kernel panic with a resulting reboot and core.

    The mutex mon process fails with SIGXCPU and a core is triggered. Allowing all threads to use both cores is the fix along with moving the Edge Dataplane Service < > frr communication to Unix Domain sockets which gains all the benefits of TCP sockets without the heavy kernel overhead and better performance.

  • Fixed Issue 64143: For a site using a High-Availability topology, the VMware SD-WAN Edges may take a long time to reach Active and Standby state after a failover.

    After an HA failover, stale WAN interface heartbeats (which were sent by the peer before it restarted) are seen on the new Active Edge and since the old state of the peer before restarting was Active, these heartbeats convey the same state to the new Active Edge, resulting in a split-brain state (active/active). Now the new Active Edge also goes for a restart to recover the split-brain state. Since the HA state machine waits for 40 seconds or the first heartbeat from the peer, the HA state machine takes time to start since both Edges have gone for a restart one after the other.

  • Fixed Issue 64205: User will observe a high number of handoff queue drops of VCMP Data for a VMware SD-WAN Gateway, leading to a poor user experience.

    When there are continuous flow create events, the packet processing on VCMP (VeloCloud Management Protocol) Data thread gets slower. This fix reduces the VCMP Data thread load by redirecting VCMP Control messages to a different thread and by eliminating some of the continuous log messages.

  • Fixed Issue 64455: When using a VMware SD-WAN Edge 520/540, fiber-based SFP modules like 1000 BASE-SX and 1000 BASE-LX cannot pass traffic with a peer-end device where auto-negotiation is on if the Edges are upgraded to Release 3.4.x (from 3.3.2/3.3.x).

    Examples of SFP modules where this issue was encountered: Cisco GLC SX (1000BASE-SX), Dell 407-BBOO (1000BASE-LX), Cisco GLC-LH-SM1 (1000BASE-SX).

    When looking at a diagnostic bundle logs, the SFP link shows but the RX counter stays at 0 while the TX counter will show increment. This issue was introduced as a regression in Release 3.4.x and is fixed in this release. If using an earlier 3.4.x release, the only workaround is to turni off auto-negotiation on the peer side and hard setting the speed at 1000 with full duplex.

  • Fixed Issue 64961: A VMware SD-WAN Edge may experience a Dataplane Service Failure and restart that service if processing IP packets that include options.

    The processing of IP packets with options, could result in a Dataplane Service Failure due to incorrect parsing of the options fields (the parsing continues beyond the end of the options list). The Dataplane Service failure is triggered by mutex mon. Without this fix, the only way to minimize the risk of this issue is to avoid setting options other than Record Route (RR) and No Option (NOP) in the user-traffic IP packets.

  • Fixed Issue 65521: A VMware SD-WAN Edge may experience a Dataplane Service Failure with message: "Edge dataplane service failed - Service edged failed with error -6, restarting"

    The Edge Dataplane Service fails while processing CTRL_INIT_DONE due to an assert() on NULL tunnel descriptor in the socket buffer (skb). The fix strengthens the sanity checking for VeloCloud Management Protocol (VCMP) and now drops the CTRL_INIT if both CTRL_FLAG_REQ and CTRL_FLAG_INIT_DONE are set.

Orchestrator Resolved Issues

Resolved in Version R346-20210623-GA

The below issue has been resolved since Orchestrator version.R345-20210201-GA.

  • Fixed Issue 56931: The health statistics for a Non SD-WAN Destination (NSD) via Edge are not showing correctly on a VMware SD-WAN Orchestrator.

    For NSD's configured from the Edge, the SD-WAN service sends the health statistics from the Edge to the Orchestrator with a start time of 0 after an Edge reboot. This causes the Orchestrator to display the wrong data prior to the Edge reboot.

  • Fixed Issue 57163: Customer cannot receive notifications via SNMP trap for Cloud Security Service (CSS) or Non SD-WAN Destinations (NSD) via Edge tunnel alerts.

    The issue occurs when a customer wants to use a SNMP trap to receive CSS/NSD via Edge tunnel alerts, but the SNMP traps are not being triggered for those events.

  • Fixed Issue 61412: A user is prompted to save when they navigate from an Edge or Profile > Device settings page of a VMware SD-WAN Orchestrator even though no changes has been made.

    The Orchestrator has data that shows a change has been made even though no change has been made, so the popup appears asking customers to save.  This is a result of the wrong object being compared to the existing object to check the changes. Because of a wrong comparison, data was considered as modified. The fix replaces the wrong object with the correct object to compare and thus ensure no false requests to save.

Known Issues

Open Issues in Release 3.4.6

The known issues are grouped as follows.

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

  • Fixed Issue 38632: A VMware SD-WAN Gateway may restart intermittently.

    When a tunnel for a VMware SD-WAN Edge is terminated and torn down by the Gateway, the Edge may reinitiate a tunnel to the same Gateway. As part of cleanup of the Edge and reinit of the tunnel, shared memory is not synchronized, thus an error is returned on allocation of the new Edge reinit causing the Gateway to restart.

    Workaround: No workaround for this issue.

  • 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 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 46208: When High-Availability is enabled on a pair of KVM-based VMware SD-WAN Virtual Edges where Multicast is also being used, the Standby Edge will not be detected.

    When HA is enabled on a pair of KVM Edges, the HA multicast heartbeat packet is getting dropped due to a lack of multicast support on SRIOV.

    Workaround: There is no workaround for this issue.

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

    Workaround: 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.

  • 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 51999: VMware SD-WAN Edge paths to a VMware SD-WAN Gateway deployed in an ESXi environament intermittently become unstable due to be being marked as quiet.

    The Gateway is intermittently delaying Edge sourced packets as a result of an irqbalance process used in a Gateway using an ESXi environment.  The process is supposed to load balanced processes across all CPU cores.  A 3.4.x version of the Gateway uses irqbalance version 1.0.6, which will not execute depending on the detection of shared cache for all cores and all levels of CPU cache are shared for all software versions for 3.4.x and below.  All kernel interrupts will execute on core0 as a result.

    Workaround: There is no workaround for 3.4/x and prior releases.  This issue is fixed in 4.x builds.

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

    Workaround: There is no workaround for this issue.

  • Issue 54141: VMware SD-WAN Edges intermittently show zero Tx latency when looking at the Monitor > Transport section of the VMware SD-WAN Orchestrator.

    Zero Tx Latency reported by multiple Edges intermittently when there should be latency recorded. Issue is still being investigated but probable root cause is asymmetric latency in the network.

    Workaround: There is no workaround for this issue.

  • 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 (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 conditions, TX transmission traffic stalls on an 82599 NIC, which is used by VMware SD-WAN Edge models 1000 and 2000 for SFP ports.

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

  • Issue 58791: A site deployed with a High-Availability topology where BGP is used may encounter an issue where the VMware SD-WAN Edge repeatedly fail over.

    When BGP is used with multiple network commands configured and while the Standby Edge is coming up it parses the all configurations symmetrically and for every network command vtysh is spawned and as a result this is causing the verp thread to not run.  The verp thread being delayed results in a delay in heartbeat processing which causes the Standby Edge to believe the Active Edge is down and the Standby Edge then becomes active which leads to a split-brain state (active-active).  To recover from the split-brain state, the Standby Edge restarts which merely repeats the cycle.

    Workaround: Reduce the number of BGP network configurations by aggregating them.

  • Issue 60234: VLAN configuration for i40evf in KVM XML configuration file will drop anything larger than max MTU packet - 4 bytes.

    If a VLAN tagged packet matches the same VLAN tag configured in the XML for the guest, anything over 1496 bytes will be dropped.

    Workaround: There is no workaround for this issue.

  • Issue 61716: VMware SD-WAN Edge shows as offline when looking at the VMware SD-WAN Orchestrator UI even though the Edge is actually up and passing customer traffic normally.

    The Edge is dropping traffic destined for the Orchestrator because of a route lookup failure for management traffic which causes the Orchestrator to conclude the Edge is offline.  All other Edge traffic is working as expected and there is no impact beyond the Orchestrator falsely showing the Edge as down. This issue arises out a fix that was put into 4.2.x VMware SD-WAN Gateways that has them prefer an underlay BGP route for management (Orchestrator) traffic. Management traffic is supposed to prefer Cloud Routes but this got broken if there is a default route advertised on either a BGP or OSPF underlay peer.

    Workaround: Workaround is to make sure underlay BGP peer does not advertise a default route. 

  • Issue 62701: For a VMware SD-WAN Edge deployed as part of an Edge Hub Cluster, If Cloud VPN is not enabled under the Global Segment but is enabled under a Non-Global Segment, a control plane update sent by the Orchestrator may cause all the WAN links to flap on the Hub Edge.

    The Hub Edge's WAN links going down, then up in rapid succession (flap) will impact real time traffic like voice calls. This issue was observed on a customer deployment where Cloud VPN was not enabled on the Hub Edge's Global segment, but the Cluster configuration was enabled which means this Hub Edge was part of a Cluster (and a Cluster configuration is applicable to all segments). When a configuration change is pushed to the Hub Edge, the Hub Edge's dataplane will start parsing data and will start with the Global Segment where it will see Cloud VPN not enabled and the Hub Edge erroneously thinks clustering is disabled on this Global Segment. As a result, the Hub Edge will tear down all tunnels from the Hub's WAN link(s) which will cause link flaps on all that Edge's WAN links. For any such incident the WAN links only go down and recover a single time per control pane update.

    Workaround: The workaround is to activate Cloud VPN on all Segments, meaning the Global Segment and all Non-Global Segments.

  • Issue 62801: For a site using an Enhanced High-Availability topology, SNMP walk fails on the VMware SD-WAN Standby Edge's WAN interfaces.

    If a user tries to perform an snmp-walk on a WAN interface which is not connected to an Active device, the response does not come back because the local kernel was not aware of the WAN link.

    Workaround: There is no workaround for this issue.

  • Issue 65348: For a site using an Enhanced High-Availability topology, when using a pair of VMware SD-WAN Edge models 6x0's, the packet drop counter will get incremented on the Active Edge even though the interface is up and running on the Standby Edge.

    In Enhanced HA mode, the Active Edge forwards traffic to a proxy interface (which is connected on the Standby Edge) via the HA interface but a copy of those packets is sent to the local interface which is in a 'sys down' state and the drop counter gets incremented as a result. Even though there is no functionality impact due to this behavior, the customer would observe unnecessary drop counter.

    Workaround: There is no workaround for this issue.

  • Issue 65839: For flows initiated from a client behind a VMware SD-WAN Hub Edge to the LAN behind a VMware SD-WAN Spoke Edge, the return traffic from the Spoke Edge is routed via the VMware SD-WAN Partner Gateway if the default route is advertised from the Partner Gateway.

    The customer impact is that some traffic does not operate well if the return route is different from the sent route (example, Office365 traffic). If there is no default route or Edge-to-Edge route advertised from the Hub Edge to the Spoke Edge, the route lookup on the Spoke Edge for the return traffic matches the Partner Gateway's default route and the return traffic is routed to the Partner Gateway instead of the Hub Edge. 

    Workaround: Advertise a default route or an Edge-to-Edge route from the Hub Edge to the Spoke Edge.

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.

  • Issue 61000: Newly created Operator Profiles may not be selectable from the Partner Overview page on the VMware SD-WAN Orchestrator UI.

    When an Orchestrator has over 100 Operator Profiles, and then a user attempts to select some of them from the Partner Overview page, only 100 will be displayed in the UI. Without the fix, the only way to address this is to have VMWare SD-WAN Technical Support assign the requested Operator Profile.

    Workaround: Delete unused Operator Profiles to reduce the total to below 100.

  • Issue 62058: The VMware SD-WAN Orchestrator displays WLAN interfaces for VMware SD-WAN Edge 510-N and 6x0-N models even though these models are not equipped with Wi-Fi.

    The Orchestrator UI should hide WLAN interfaces for 510-N and 6X0-N Edge models.  An Edge model with a '-N' designator indicates it is built without a Wi-Fi chip populated on board. When these Edge models are activated, the model number should be used by the Orchestrator to hide WLAN interfaces.  The impact to a customer is minimal as while the WLAN interfaces show, any attempt to configure them will be ignored by the Orchestrator.

    Workaround: Ignore the WLAN interfaces on -N Edge models.

check-circle-line exclamation-circle-line close-line
Scroll to top icon