| Updated March 31st, 2022 VMware SD-WAN Orchestrator Version R344-20201103-GA Check regularly for additions and updates to these release notes. |
What's in the Release Notes
The release notes cover the following topics:Recommended Use
This release is recommended for all customers using a 3.4.x Release who are impacted by the issues listed below.
Note: The recommended release for 3.4.x customers is Release 3.4.5.
Compatibility
Release 3.4.4 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.4 |
3.2.1 |
3.2.1 |
3.2.1 |
| 3.4.4 |
3.4.4 |
3.2.1 |
3.2.1 |
| 3.4.4 |
3.4.4 |
3.2.1 |
3.4.4 |
| 3.4.4 |
3.4.4 |
3.4.4 |
3.2.1 |
| 3.4.4 |
3.3.2 P2 |
3.3.2 P2 |
3.3.2 P2 |
| 3.4.4 |
3.3.2 P3 |
3.3.2 P2 |
3.3.2 P2 |
| 3.4.4 |
3.4.4 |
3.3.2 P2 |
3.3.2 P2 3.3.2 P3 |
| 3.4.4 |
3.4.4 |
3.4.4 |
3.3.2 P2 |
| 3.4.4 |
3.4.4 |
3.3.2 P2 |
3.4.4 |
| 3.4.4 |
3.4.4 |
3.3.1 |
3.4.4 |
| 3.4.4 |
3.4.0 |
3.3.2 P2 3.3.2 P3 |
3.3.2 P2 |
| 3.4.4 |
3.4.1 |
3.4.1 |
3.4.1 |
| 3.4.4 |
*3.4.1* |
*3.4.4* |
* 3.4.4 * |
| 3.4.4 |
3.4.4 |
3.4.4 |
3.4.1 |
| 3.4.4 |
3.4.4 |
3.4.1 |
3.4.4 |
| 3.4.4 |
3.4.2 |
3.4.2 |
3.4.2 |
| 3.4.4 |
3.4.4 |
3.4.4 |
3.4.2 |
| 3.4.4 |
3.4.2 |
3.4.2 |
3.4.4 |
| 3.4.4 |
3.4.3 |
3.4.3 |
3.4.3 |
| 3.4.4 |
3.4.4 |
3.4.4 |
3.4.3 |
| 3.4.4 |
3.4.3 |
3.4.3 |
3.4.4 |
| 3.4.2 |
3.4.4 |
3.4.2 |
3.4.2 |
| 3.4.2 |
3.4.2 |
3.4.4 |
3.4.2 |
| 3.4.3 |
3.4.2 |
3.4.2 |
3.4.4 |
| 3.4.3 |
3.4.4 |
3.4.3 |
3.4.2 |
| 3.4.1 |
*3.4.1* |
*3.4.4* |
*3.4.4* |
| 3.4.1 |
3.4.2 |
3.4.4 |
3.4.2 |
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
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.
December 21st, 2021. Second 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. Third 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 IssuesResolved in Version R344-20201021-GA
The below issues have been resolved since Edge and Gateway versions R343-20200803-GA.
- Fixed Issue 33195:
PIM joins may fail on the VMware SD-WAN Hub when it has more than 1280 multicast neighbors.
- Fixed Issue 37746:
In rare scenarios, if a VMware SD-WAN Gateway develops stale NAT entries and a user flow has the same 5-tuple as the stale NAT entry, the user flow would be dropped at the Gateway.
- Fixed Issue 39232:
On a VMware SD-WAN Edge with BGP or OSPF is turned on, the Edge may encounter an Edge dataplane service failure following a timeout waiting for a blocking socket to return from Tx.
This is typically observed with the following signature:
#0 0x00007f5c09f34754 in send () from deps/lib/libpthread.so.0
#1 0x000000000092cc7a in vc_zeb_send_to_client (buf=0x7f5aa7fed580 "", length=<optimized out>, client=0x7f5ad402ec90) at /mnt/build/workspace/master-nightly-build/common/libs/drp/vc_zebra.c:188The Edge routing and dataplane processes communicate with a TCP socket on the localhost. Depending on the runtime of some threads, it is possible for the task queuing system (ksoftirqd) on the local core to receive minimal runtime to deliver packets to the opened socket to the routing process, leading to a blocked Tx call for the OSPF and/or BGP thread.
Thread priority of the OSPF and BGP threads are now reclassified for all cores which leverage the use of the kernel scheduler to preempt rather than voluntarily yielding the core and allows for more runtime and cooperative pre-emption with ksoftirqd.
- Fixed Issue 39965:
Flow creation takes more time when creating many flows whose application type cannot initially be determined by the Deep Packet Inspection (DPI) engine.
- Fixed Issue 40497:
Downloading a VNF image from AWS S3 will not succeed if the S3 bucket only supports Signature V4 authentication.
- Fixed Issue 42987:
Peer initiated flows do not contain correct Application and Class ID which results in a VMware SD-WAN Hub Edge:
- Reporting Orchestrator statistics for an application name different than the Spoke Edge.
- The Hub Edge is unable to match based on applications for peer flows.
- Fixed Issue 43698:
For a site using a High Availability topology, under rare conditions the VMware SD-WAN Edge may receive some events out of sequence resulting in the Standby Edge getting deactivated after becoming active.
- Fixed Issue 43875:
A VMware SD-WAN Gateway limits the number creates a shared memory segment for each connected edge to track per peer counters. System has a default max limit of 4096, which would limit the tunnels with new peers if number of edges connected to the gateway cross this limit. Fixed by increasing the limit to 16K for future proof.
- Fixed Issue 44233:
A VMware SD-WAN Edge will suffer a Dataplane Service Failure while generating a diagnostic bundle if the command debug.py --remote_routes is executed on a VMware SD-WAN Gateway to which the Edge is connected.
Workaround: There is no workaround for this issue.
- Fixed Issue 44376:
A memory leak is possible on a VMware SD-WAN Edge when MPLS Classes of Service are configured and the MPLS link is unstable, potentially leading to a Dataplane Service Failure over time
- Fixed Issue 44640:
For a site using a High Availability topology, the VMware SD-WAN Standby may suffer a Dataplane Service Failure and restart when the Active Edge tries to sync a high number of flows (e.g., ~1.8M UDP flows) with the Standby Edge. The user will also observe a large number of HA_FAILED and HA_READY messages on the Orchestrator.
- Fixed Issue 45661:
For VMware SD-WAN Edge models 610, 620, 640, and 680, SFP ports 1 and 2 have the following LED behaviors: the 1G speed will show an amber LED, and the 10G speed will show green.
- Fixed Issue 45810:
On A VMware SD-WAN Edge model 3400 or 3800 where the Intel X722 Controller uses older firmware, if the SFP1 and SFP2 interfaces are either empty, or populated with unsupported SFP modules, those SFP interfaces are not usable. This condition in turn prevents the Edge Dataplane Service from starting, resulting in no customer traffic traversing the Edge.
Workaround: Disable the SFP1 and SFP2 interfaces on the Interfaces section of the Configure > Edge > Device page on the VMware SD-WAN Orchestrator UI.
- Fixed Issue 45842:
When there are multiple routes learnt for the same prefix on a VMware SD-WAN Edge, a remote route that has been previously advertised to the BGP peer might be revoked during a tunnel flap with the remote peer and may never get advertised again.
- Fixed Issue 46053:
BGP preference does not get auto-corrected for overlay routes when its neighbor is changed to an uplink neighbor. Without the fix, an Edge Service Restart will correct this issue.
- Fixed Issue 46249:
For a site using a High Availability topology where the HA Edges are configured as a Hub and the default route is advertised via BGP/OSPF, after a failover the WAN interface default route may be installed above the Primary Gateway default route which leads to all internet traffic taking a direct path.
- Fixed Issue 46253:
For a site using a High Availability topology, if the site is downloading a file from the Cloud and an HA failover occurs, higher than expected traffic loss is observed post-failover for the file download flow.
- Fixed Issue 46306:
After a VMware SD-WAN Edge is rebooted, especially after an Edge software upgrade, the BGP configuration may not be present on the Edge configuration.
- Fixed Issue 46361:
The jitter and latency values measured on a sub-path is reset and re-measured only when the sub-path is used again for data transmission.
- Fixed Issue 46373:
In rare cases a VMware SD-WAN Edge may suffer a Dataplane Service Failure if a WAN link goes down immediately before an IKE packet is being sent over that WAN link.
- Fixed 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”.
- Fixed Issue 46794:
User is unable to deploy Fortinet VNF with VM00 / VM01 licenses which require a single core CPU.
- Fixed Issue 46918:
A VMware SD-WAN Spoke Edge using the 3.4.2 Release does not update the private network id of a Cluster Hub node properly.
- Fixed Issue 47020:
A VMware SD-WAN Gateway using Release 3.4.0 may mark a Non-VeloCloud Site tunnel as UP even though the tunnel is down.
- Fixed Issue 47166:
The snmpagent reports multiple datasets incorrectly from a VMware SD-WAN Edge, leading to incorrect measurements via SNMP polling which adversely affects a customer's monitoring service.
- Fixed Issue 47382:
When a tunnel to a VMware SD-WAN Gateway goes down and flows fail over direct, there is a small chance that the direct flow fails due to the NAT entry being erroneously removed during the cleanup of the tunnel to the Gateway.
- Fixed Issue 47591:
The first flow of a stream classified as Realtime that uses dynamic Edge-to-Edge tunnels may have packet loss due to asymmetric routing across VMware SD-WAN Gateways and VMware SD-WAN Spoke Edges.
- Fixed Issue 47731:
A VMware SD-WAN Edge with a business policy configured to rate limit traffic does not actually enforce rate limiting for downstream traffic. This issue is more likely to be seen in high bandwidth (e.g., 1 Gbps) traffic.
- Fixed Issue 47925:
A route which is learned over BGP will have an incorrect neighbor IP if the nexthop on the route is not the same as the neighbor’s IP.
- Fixed Issue 47937:
For a site using High-Availability, the VMware SD-WAN Active Edge unnecessarily pushes Edge-to-Edge flow synchronizations to the Standby Edge.
- Fixed Issue 48159:
A site which deploys VMware SD-WAN Edges in a High Availability topology may find both Edges deactivated after an HA failover, and the Edges would need to be reactivated. This issue is the result of a rare condition where the site gets into a “split brain” scenario where both Edges act as Active after a failover caused by the Active Edge restarting. While both are Active, each Edge sends an incorrect serial number to the Orchestrator and the Orchestrator compares both incorrect serial numbers to the stored serial numbers it has and, when the Orchestrator sees a mismatch, it sends a deactivation command to each HA Edge.
- Fixed Issue 48291:
A VMware SD-WAN Edge restart may be required to receive IGMP and PIM packets properly if multicast is turned off and then turned back on for a specific Edge.
- Fixed Issue 48391:
When a Cloud Security Service (CSS) is configured with a domain name (instead of an IP address), the VMware SD-WAN Edge resolves the CSS via a locally generated DNS request and stores this in the Edge's DNS cache, which will be lost once the DNS cache times out. However, the Edge does not also store the last resolved IP address in the event DNS resolutions fails. As a result, if the Edge needs to resolve the CSS domain name again as part of a retry of an IPsec tunnel or IKE rekey due to a network issue the IPsec tunnel will not come up due to DNS failure.
- Fixed Issue 48462:
When a VMware SD-WAN Edge is upgraded to Release 3.4.1, the default routes (i.e. route destination = 0.0.0.0) are removed from the Edge’s routing table and will result in users using that Edge not being able to access the internet. Without the fix, a user would need to restart the Edge Service, which will restore the default routes. On the VMware SD-WAN Orchestrator for the affected Edge, go to Remote Actions > Service Restart.
- Fixed Issue 48502:
In some scenarios, a VMware SD-WAN Hub Edge being used to backhaul internet traffic may suffer a Dataplane Service Failure due the improper handling of backhaul return packets.
- Fixed Issue 48627:
In rare instances, the VMware SD-WAN Edge may suffer a Dataplane Service Failure while processing TCP_SYN packets which include an 'Options' payload as the packet processing may continue beyond 'End of Options List' and trigger an exception.
- Fixed Issue 48696:
DPDK bonding for VMware SD-WAN Gateways which use Intel x710 network adapters do not work because Q-in-Q MTU size accounting is not applied.
- Fixed Issue 48824:
With 'Stateful Firewall' and 'Syslog Forwarding' both turned on, the VMware SD-WAN Edge may suffer multiple Dataplane Service Failures due to asymmetric flows.
- Fixed Issue 49005:
When MPLS CoS is turned on for a VMware SD-WAN Edge, the sub-path statistics are not included in the statistics the Edge sends to the VMware SD-WAN Orchestrator.
- Fixed Issue 49060:
In rare scenarios, a VMware SD-WAN Edge while handling control packets amidst path impairments (e.g., link flaps, route revocations, route redistributions), may lead to gradual memory buildup on the Edge.
- Fixed Issue 49052:
In rare cases, the SD-WAN Edge crashes due to timing issues when the tunnel flaps during transit flows.
- Fixed Issue 49111:
A memory leak can occur when error conditions are encountered trying to NAT traffic on a VMware SD-WAN Gateway. This issue was discovered during extended stress testing of boundary conditions and has not been observed in production Gateways.
- Fixed Issue 49170:
A VMware SD-WAN Edge may suffer a Dataplane Service Failure when a retransmit flow switches from the overlay to the underlay due to a route reconvergence (e.g., public WAN link flap).
- Fixed Issue 49209:
On the VMware SD-WAN Edge models 520 or 540, when a LAN port from LAN 1-4 and a LAN port from LAN 5-8 are each configured for the same VLAN, the ports do not forward packets to each other.
- Fixed Issue 49485:
First packet application classification does not work on a VMware SD-WAN Hub Edge for flows that were backhauled from other Edges.
- Fixed Issue 49531:
Policy Based NAT entries may disappear from a VMware SD-WAN Partner Gateway which, if it occurs, will cause customer outages.
- Fixed Issue 49538:
In rare scenarios a VMware SD-WAN Edge may suffer a Dataplane Service Failure if the route lookup for a new flow is not successful.
- Fixed Issue 49561:
If one VMware SD-WAN Edge has CoS turned on and another Edge has CoS turned off, WAN link aggregation will not work properly when the Edges are sending traffic to one another.
- Fixed Issue 49611:
A VMware SD-WAN Edge 520V is incorrectly identified as an Edge 520.
- Fixed Issue 50078:
A VMware SD-WAN Edge may suffer a Dataplane Service Failure on receipt of a routing control message that could not be decrypted properly (e.g. after IKE rekey or the rapid re-establishment of a tunnel).
- Fixed Issue 50231:
For a customer whose enterprise uses the special MGMT-IP build for their VMware SD-WAN Edges (i.e., where the Edge Management IP is configured for customers with requirement for global segment loopback), the Edge Management IP Address is not redistributed to BGP/OSPF.
- Fixed Issue 50399:
The VMware SD-WAN Gateway is not checking the IKE policy configured for a Non-VeloCloud Site versus the incoming IKE version from the peer site and automatically overwriting the VMware IKE version to match the peer side IKE version. As a result, both the Gateway and VMware SD-WAN Edge are processing packets for a tunnel with an IKE version mismatch.
- Fixed Issue 50494:
In extremely rare instances, a VMware SD-WAN Gateway may suffer a Dataplane Service failure during a tunnel tear down/rebuild (i.e., “flap”) as a result of a race condition in accessing data in an internal routing structure.
- Fixed Issue 50841:
For a VMware SD-WAN Edge where Stateful Firewall is turned on, if tunnels to other sites are torn down and then rebuilt in rapid succession (i.e., “flap”), some packets may leak.
- Fixed Issue 51010
When Stateful Firewall is turned on, a TCP session that is initiated using the same ports as a session closed within the past 4-minutes (RFC 5382 timeout period) will be dropped.
Resolved in Version R344-20201103-GA
The below issue has been resolved since Orchestrator version R344-20201019-GA.
- Fixed Issue 43213:
Azure Virtual Hub Non-VeloCloud Site deployment fails when the target Hub has an existing site-to-site VPN connection.
Resolved in Version R344-20201019-GA
The below issue has been resolved since Orchestrator version R343-20200910-GA.
- Fixed Issue 44917:
A user’s connection to a VMware SD-WAN Orchestrator may fail abruptly with a “502 Server Error” due to a mismatch on the keepalive timeouts between communicating servers.
- Fixed Issue 44674:
Traffic which matches Microsoft Teams or Skype for Business application is categorized as regular Skype traffic with a low priority and transactional class.
- Fixed Issue 47279:
The IKE IPsec Configuration template for the Non-VeloCloud Site type “Generic Firewall” (Policy Based VPN) displays the wrong Lifetime value.
- Fixed Issue 47910:
When a Non-VeloCloud Site with type Checkpoint has its configuration modified through the Monitor > Network Services screen, the primary VPN goes down due to the VMware SD-WAN Orchestrator pushing a configuration update which includes the wrong NVS type.
- Fixed Issue 48361:
Stable links are being counted as 'Unstable' on the Network Overview page.
- Fixed Issue 48895:
After upgrading a VMware SD-WAN Orchestrator to 3.4.x, profiles that do not contain VLAN1 are unable to be modified.
- Fixed Issue 48951:
Customer Administrators with a Standard role can still edit BGP settings even after the Standard role has been set to read-only for that setting through role customization.
- Fixed Issue 50580:
In rare conditions, the VMware SD-WAN Orchestrator's alert delivery mechanism encounters an unexpected error when delivering webhook alerts. This may cause delays in the delivery of future alerts of all types across all customers. If this issue occurs enough times, it may also cause alert deliveries to fail altogether for all customers as the Orchestrator retries delivery of the failed alerts indefinitely.
Known Issues
Open Issues in Release 3.4.4
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.
- 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 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 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.
- 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 49883:
When running the Remote Diagnostic ‘Interface Status’ the output for SFP links may not show the correct speed and duplex.
- 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 51025:
If WAN link goes down and then up in rapid succession (i.e. a link flap) on a VMware SD-WAN Edge, the route table entry for the interface DHCP default Gateway may be removed and not reapplied.
- 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.
