| Updated March 31st, 2022 VMware SD-WAN Orchestrator Version R342-20200708-GA Check regularly for additions and updates to these release notes. |
What's in the Release Notes
The release notes cover the following topics:- Recommended Use
- Compatibility
- Important Notes
- Feature Enhancements
- Revision History
- Resolved Issues
- Known Issues
Recommended Use
This release is recommended for all customers who plan to upgrade to Release 3.4.x, as well as those customers impacted by the issues listed below which have been resolved since Releases 3.4.0 and 3.4.1.
Compatibility
Release 3.4.2 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.2 |
3.4.2 |
3.2.1 |
3.2.1 |
| 3.4.2 |
3.4.2 |
3.3.2 P2 |
3.3.2 P2 |
| 3.4.2 |
3.4.0 |
3.3.2 P2 |
3.3.2 P2 |
| 3.4.2 |
3.3.2 P2 |
3.3.2 P2 |
3.3.2 P2 |
| 3.4.2 |
3.4.1 |
3.4.1 |
3.4.1 |
| 3.4.2 |
*3.4.1* |
*3.4.2* |
*3.4.2* |
| 3.4.1 |
*3.4.1* |
*3.4.2* |
*3.4.2* |
| 3.4.2 |
3.4.2 |
3.4.2 |
3.4.1 |
| 3.4.2 |
3.4.2 |
3.4.1 |
3.4.2 |
| 3.4.2 |
3.4.2 |
3.4.2 |
3.3.2 |
| 3.4.2 |
3.4.2 |
3.3.2 |
3.4.2 |
| 3.4.2 |
3.2.1 |
3.2.1 |
3.2.1 |
| 3.4.2 |
3.4.2 |
3.2.1 |
3.4.2 |
| 3.4.2 |
3.4.2 |
3.2.1 |
3.2.1 |
| 3.4.2 |
3.4.2 |
3.4.2 |
3.2.1 |
| 3.4.2 |
3.4.2 |
3.2.1 |
3.2.1 |
As a result, Spoke Edges which connect to Hub Clusters must wait for Gateways to be upgraded to 3.4.2 prior to being upgraded themselves.
Warning: VMware SD-WAN Release 2.x (e.g. 2.4.4, 2.5.2, etc.) is no longer supported. For more information regarding Release 2.x, including next steps, please consult Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 2.x.x (77221)
Warning: VMware SD-WAN Releases 3.2.x and 3.3.x have both reached the End of Support. Releases 3.2.x and 3.3.x reached End of General Support (EOGS) on December 15, 2021, and End of Technical Guidance (EOTG) March 15, 2022.
Warning: VMware SD-WAN Releases 3.4.x is approaching End of Support for the Orchestrator and Gateway. Release 3.4.x for the Orchestrator and Gateway will reach End of General Support (EOGS) on March 30, 2022, and End of Technical Guidance (EOTG) September 30, 2022.
Note: This is for the Orchestrator and Gateway only. 3.4.x software for the Edge is scheduled to enter its End of Support window beginning on December 31, 2022.
For more information on SD-WAN Release 3.x software lifecycles, please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151)
Important Notes
Change in the Edge 520/540 switch port MAC address
On a VMware SD-WAN Edge using release 3.3.x or lower, the internal port naming (as seen when querying SNMP) was a logical name such as "sw1p0". In Release 3.4.0+, this was improved to assign proper logical names (e.g. lan1") so that users can easily map them to the actual connected ports.
In addition, when an Edge 520 or 540 is upgraded to 3.4.0 or higher, not only does the port naming change, the switchports sw1p0 - sw1p3 will have their MAC address changed as well. For an Edge 520/540, the switchports sw1p0 -sw1p3 correspond to LAN ports LAN1-LAN4.
Any downstream device which filters for a specific source MAC exiting from an Edge 520/540’s LAN1-LAN4 interfaces must be made aware of this MAC address change. The new MAC address upon upgrade to 3.4.0 or higher will only differ in the final character of the address. The eth1 MAC change to eth0 MAC will be the current MAC address with the final character one lower value. For example, if the MAC address ends in 1, the new MAC will end in 0. If the MAC ends in B, the new MAC will end in A.
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).
Feature Enhancements
Upgrade Banners
Operator users can post an Upgrade Banner on the VMware SD-WAN Orchestrator when an upgrade is scheduled to notify users of the scheduled upgrade. Previously, when the banner was posted, all users who logged into the Orchestrator would see the banner.
In Release 3.4.2, the display of this banner may be configured so that only certain groups will see the banner. Specifically, the banner can be configured to be visible for the following user groups:
- Operator only
- Operator and Partner only
- Operator, Partner, and Customer
System Information
For a VMware SD-WAN Edge using Release 3.4.2, the Remote Diagnostic “System Health” is renamed “System Information”. In addition to displaying Edge system load and recent WAN link stability statistics as before, “System Information” adds information on the monitoring services NetFlow and Syslog.
The new Monitoring Services field includes the service type, the destination IP, the source interface, the segment being used, and the interface selection type.
Document Revision History
June 14th. First Edition. (From a previously published edition at time of GA).
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.
- Gateway Resolved Issue
- Gateway Resolved Issue
- Edge/Gateway Resolved Issues
- Orchestrator Resolved Issue
- Orchestrator Resolved Issues
Resolved in Gateway Version R342-20200706-GA-46261-47204
The below issue has been resolved since 3.4.2 Gateway version R342-20200630-GA-46261.
- Fixed Issue 47204:
When a VMware SD-WAN Cluster Hub Edge reaches 70% or greater tunnel capacity, the VMware SD-WAN Gateway will re-balance the Spoke Edges. If the total tunnel capacity is greater than 70% of all other Hubs in the Cluster, the Gateway’s re-balancing will not work properly and lead to continuous re-balancing.
Resolved in Gateway Version R342-20200630-GA-46261
The below issue has been resolved since 3.4.2 Gateway version R342-20200610-GA.
- Fixed Issue 46261:
A VMware SD-WAN Gateway will leak peer objects over time, which eventually results in a Dataplane Service Failure. The frequency of failures will be dictated by the number of Edges connected to the Gateway, and the volume of path flaps. In the worst case, a Dataplane Service Failure occurs approximately every two weeks for a Gateway with 3000+ Edges and unstable tunnels.
Resolved in R342-20200610-GA
The below issues have been resolved since 3.4.1 Edge version R341-20200410-GA, and Gateway version R341-20200428-GA-44354-44451.
- Fixed 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.
- Fixed Issue 26392:
Flows traversing a VPN waypoint (Gateway or Hub) may not switch to a newly established Dynamic Branch-to-Branch VPN tunnel until the next new flow to that destination is created.
- Fixed Issue 30822:
When a VMware SD-WAN Edge is configured to backhaul Internet traffic, a route lookup may fail, and the traffic gets dropped.
- Fixed Issue 32898:
Route table does not include the Gateway IP address as a next hop for routes between a VMware SD-WAN Edge and a VMware SD-WAN Partner Gateway.
- Fixed Issue 33870:
A VMware SD-WAN Gateway may experience a Dataplane Service Failure while bringing up VPN tunnels with a High Availability enabled Edge device during an upgrade from Release 3.2.x to Release 3.4.0/3.4.1.
- Fixed Issue 33903:
When a VMware SD-WAN Edges deployed in a High-Availability topology are upgraded from release 3.2.x/3.3.x to 3.4.1, Edge-to-Cloud destined packets from the HA site may be dropped by the VMware SD-WAN Gateway until the Gateway is restarted.
- Fixed Issue 34233:
Outbound 1:1 NAT flows do not failover to another interface when the configured interface is down.
- Fixed Issue 34973:
When a VMware SD-WAN Gateway has ~1.2M routes or more, the Gateway experiences a Dataplane Service Failure.
- Fixed Issue 37355:
A VMware SD-WAN Edge with a large number of routes and an exceptionally large number of route and/or tunnel flaps may suffer a Dataplane Service Failure.
- Fixed Issue 37955:
NetFlow Exporter may export the wrong flow path for peer-initiated flows sent directly between VMware SD-WAN Edges.
- Fixed Issue 38986:
In rare circumstances a VMware SD-WAN Edge will experience a Dataplane Service Failure while there is SIP traffic.
- Fixed Issue 39199:
Traffic flows that match the Workplace by Facebook application (URLs workplace.com or work.facebook.com) may not be correctly classified.
- Fixed Issue 39605:
Remote Diagnostics > Ping Test does not display DHCP enabled interfaces in the drop down menu.
- Fixed Issue 39637:
A VMware SD-WAN Edge with conditional backhaul configured may suffer a Dataplane Service Failure if the Edge’s WAN links flap.
- Fixed Issue 39880:
There is a discrepancy between what the VMware SD-WAN Edge reports to the VMware SD-WAN Orchestrator for Transport statistics versus Application statistics.
- Fixed Issue 40563:
When LAN side NAT rules are configured for a VMware SD-WAN Edge, traffic from WAN to LAN is dropped in the case of 1:any SNAT or SDNAT.
- Fixed Issue 40565:
For “Direct via underlay” traffic on a Private WAN overlay interface, the NetFlow records are exported with the next hop field incorrectly listed as 0.0.0.0.
- Fixed Issue 40717:
A link using a user-defined WAN overlay for a private CELL interface does not come up.
- Fixed Issue 40744:
For some Direct traffic NAT'd due to a default business policy, only the NAT type 259 NetFlow records should be sent, but NetFlow records of Non-NAT type 256 are being sent erroneously.
- Fixed Issue 40745:
A Cloud Security Service tunnel may fail and stay in a PENDING state if the CSS is configured with a domain name instead of an IP address.
- Fixed Issue 40897:
Under rare scenarios, a VMware SD-WAN Edge experiences a Dataplane Service Failure when BGP routes flap.
- Fixed Issue 40950:
Disabling NetFlow may result in some timers getting overwritten unconditionally.
- Fixed Issue 41024:
On the VMware SD-WAN Orchestrator monitoring page, Application statistics show a lesser value than Transport statistics.
- Fixed Issue 41498:
Path MTU does not account for the additional 60 bytes of overhead that an IPsec-fronted Gateway adds with resulting packet fragmentation.
- Fixed Issue 42073:
Performance for encrypted traffic via the VMware SD-WAN Gateway using AES-256 is approximately half of the expected performance.
- Fixed Issue 42230:
Strict/Loose IP precedence is not supported for MPLS CoS.
- Fixed Issue 42247:
Under rare scenarios, the VMware SD-WAN Gateway using Release 3.4.x may suffer a Dataplane Service Failure due to issues with memory management.
- Fixed Issue 42869:
Under rare scenarios, a VMware SD-WAN Edge may experience a Dataplane Service Failure if a route is deleted from a WAN overlay to a VMware SD-WAN Gateway.
- Fixed Issue 42307:
Static routes on a VMware SD-WAN Partner Gateway may be incorrectly marked as unreachable when they are monitored using ICMP probes.
- Fixed Issue 43044:
In rare cases, a VMware SD-WAN Edge being used as the Standby in a High Availability topology may experience a Dataplane Service Failure during flow synchronization with the Active Edge.
- Fixed Issue 43132:
When a site using a High Availability topology has an HA failover, the connected routes may not be redistributed to the site’s BGP neighbors.
- Fixed Issue 43168:
Syslog Firewall event notification to a Syslog collector is lost when collector reachability is down for a transient duration due to half-open TCP connections.
- Fixed Issue 43202:
For a customer site using Enhanced High Availability, a VMware SD-WAN Edge promoted to Active takes up to 70 seconds to detect and sync with the new Standby Edge which results in high latency on the links connected to the Standby.
- Fixed Issue 43268:
For a site using a High Availability topology which has NAT hand-off configured, user traffic may break (e.g. voice calls drop or SSH sessions timeout) upon an HA failover event.
- Fixed Issue 43309:
On a VMware SD-WAN Cluster, when the Super Gateway restarts, the Spoke Edges are re-balanced.
- Fixed Issue 43333:
When a customer with a very high route count adds a Non-VeloCloud site to a VMware SD-WAN Gateway and backhauls internet traffic through it, the route lookup causes high packet latency which impacts NVS throughput. This issue affects other customers with an NVS using the same Gateway.
- Fixed Issue 43344:
When a custom VLAN is configured on a user defined overlay, the next hop ARP fails, and a tunnel does not form.
- Fixed Issue 43434:
Upgrading VMware SD-WAN Edges in a High Availability topology from 2.x to 3.x takes up to 25 minutes to complete.
- Fixed Issue 43472:
The Maximum segment size (MSS) value is incorrect for the return traffic from an IPsec-fronted Gateway.
- Fixed Issue 43788:
The application Amazon Chime is not correctly categorized as Business Collaboration.
- Fixed Issue 43845:
Path MTU Discovery (PMTUD) will discover a very low MTU (down to 576 bytes) when an external device sends an ICMP fragmentation needed message reporting such an MTU, rather than honoring the PMTUD floor of 1300 bytes.
- Fixed Issue 43941:
Application Maps can only be configured with subnets and not individual IP addresses.
- Fixed Issue 44048:
When all public links are down for a site, firewall rules are not enforced for all traffic using the Conditional Backhaul path.
- Fixed Issue 44346:
On a VMware SD-WAN Edge upgraded to Release 3.4.1 and using SNMP monitoring, ifOperStatus in IfTable is incorrectly set as zero, resulting in the customer losing visibility for that Edge.
- Fixed Issue 44354:
Routes for a VMWare SD-WAN Hub Cluster may be lost if one of the Cluster Hubs disconnects from a VMware SD-WAN Gateway.
- Fixed Issue 44395:
If Syslog is configured at the profile level, the service may not work at a site using that profile if the site’s VMware SD-WAN Edge reboots.
- Fixed Issue 44451:
VMware SD-WAN Gateway deletes a TCP flow if it is idle for 5 minutes.
- Fixed Issue 44472:
After a VMware SD-WAN Spoke Edge configured to backhaul traffic to a Hub is upgraded to Release 3.4.1, peer initiated traffic to the Hub may fail.
- Fixed Issue 44484:
On a VMware SD-WAN Edge upgraded to Release 3.4.1, the ipAddressIfIndex in the ipAddressTable is incorrectly set.
- Fixed Issue 44507:
Non-VeloCloud Sites (NVS) configured with Gateway static routes are not set with correct route reachability states on a VMware SD-WAN Edge if the primary tunnel is up and the backup tunnel is down. As a result, traffic from the Edge is routed to the wrong Gateway when “Redundant VeloCloud Cloud VPN” is enabled for that NVS.
- Fixed Issue 44596:
When a packet greater than the Path MTU is received by a VMware SD-WAN Edge, fragmentation may not work.
- Fixed Issue 44702:
NetFlow sources from the management IP on the global segment when it should be using an up and advertised LAN interface IP.
- Fixed Issue 44745:
Under rare scenarios, a VMware Edge may experience a Dataplane service failure while handling application flows for cloud traffic that traverses a VMware SD-WAN Gateway.
- Fixed Issue 44759:
A VMware SD-WAN Edge’s iPAddrIfIndex is shown as the wrong value after upgrading to Release 3.4.1.
- Fixed Issue 44792:
If a VMware SD-WAN Cluster’s tunnel to the Super Gateway flaps, the Spoke Edges failover due to a lack of Spoke to Gateway feedback during reassignment.
- Fixed Issue 44825:
When a VMware SD-WAN Edge receives an overlay route update for a prefix learned via another protocol, the flags are not updated properly when installing it in the FIB.
- Fixed Issue 44923:
TCP MSS adjustment may not work properly for Cloud Security Service tunnels when a WAN link has an MTU that is less than 1500 bytes, if the server does not use the MSS from the SYN in the SYN|ACK.
- Fixed Issue 44958:
ifAlias cannot be used as the name that is set under WAN setting for SNMP.
- Fixed Issue 44980:
1:1 NAT rule fails unless an inbound rule is configured in the outbound firewall section.
- Fixed Issue 45153:
When a VMware SD-WAN Edge is configured with a secure Partner Gateway-based default route, the direct flows destined for the Edge’s WAN interface which use an inbound Port Forwarding rule experience packet drops.
- Fixed Issue 45154:
TCP MSS adjustment may not work properly for tunnels from the VMware SD-WAN Edge to a Cloud Security Service on a WAN link with an MTU less than 1400 bytes.
- Fixed Issue 45231:
Multicast packets are not received on routed interfaces for VMware SD-WAN Edge models 500, 510, 520, and 610.
- Fixed Issue 45313:
When attempting to send packets to unreachable destinations (e.g. during an IP scan) behind a Partner Gateway or a VMware SD-WAN Edge, the buffer holding the packet is leaked, which can eventually lead to a service outage on the respective platform.
- Fixed Issue 45324:
Some copper SFPs are not recognized by the VMware SD-WAN Edge after upgrading the Edge from Release 3.3.x or earlier to Release 3.4.0 or 3.4.1.
- Fixed Issue 45571:
ICMP Ping from a client behind a VMware SD-WAN Hub Edge to a Spoke Edge LAN IP does not work as the return packet uses the default Gateway route instead of the default route from the Hub Edge.
- Fixed Issue 45663:
A VMware SD-WAN Virtual Edge using a KVM image running in OpenStack that is upgraded to Release 3.4.1 may lose all its interface configurations.
Resolved in Version R342-20200708-GA
The below issue has been resolved since Orchestrator version R342-20200604-GA
- Fixed Issue 47015:
On a VMware SD-WAN Orchestrator with a large number of enterprises and a high route volume, if one or more customer enterprises has the OFC Cost Calculation > Distributed Cost Calculation feature enabled, other customer enterprises on the same Orchestrator may have VMware SD-WAN Edges that do not update the UPLINK cost properly.
Resolved in Version R342-20200604-GA
The below issues have been resolved since Orchestrator version R341-20200423-GA.
- Fixed Issue 31450:
On the Monitor > Alerts screen of the VMware SD-WAN Orchestrator, the default Notification Time for pending Alerts and Alerts for which notifications were not sent is based on the current browser time.
- Fixed Issue 32415:
Sensitive data stored in Network Service (e.g. pre-shared keys for Cloud Security) are not encrypted by default for users of all types in response payloads for some API methods (e.g. getEdgeConfigurationStack or get Configuration).
- Fixed Issue 32937:
Disabling a VMware SD-WAN Edge model in a customer profile when that Edge model is in use throws a validation error that does not specify the reason for the error.
- Fixed Issue 39882:
In rare conditions, an Edge may not receive a configuration update when the VPN settings are changed in the profile that Edge uses.
- Fixed Issue 41183:
User is unable to clone enterprises which contain VNF capable VMware SD-WAN Edges even though the Edge’s VNF is not enabled.
- Fixed Issue 42448:
If an enterprise removes MD5 authorization from the interface OSPF configuration, the enterprise may not be able to establish OSPF with neighbors.
- Fixed Issue 42867:
Enabling Syslog forwarding at the Profile level is not applied to VMware SD-WAN Edges using that Profile.
- Fixed Issue 43382:
When a routed interface is either enabled or disabled at the customer profile level, the VMware SD-WAN Orchestrator does not update the interfaces associated with the VLANs in that profile.
- Fixed Issue 43469:
Operator users who log in using Single Sign-On are not able to see Advanced Options on the Diagnostics Bundle screen.
- Fixed Issue 43626:
When a customer enterprise is migrated to a different VMware SD-WAN Orchestrator, some encrypted data like Single Sign-On is not correctly migrated.
- Fixed Issue 43693:
Partner and Customer administrators are unable to revoke Edge certificates.
- Fixed Issue 43712:
A user can configure duplicate alerts for an enterprise through the API resulting in multiple alert notifications for the same alert type.
- Fixed Issue 43873:
User is unable to configure Internet Backhaul business policies which use a VMware SD-WAN Hub Cluster.
- Fixed Issue 43920:
When a customer enterprise is migrated to a different VMware SD-WAN Orchestrator, some tables that are specific to Release 3.4.x are not migrated.
- Fixed Issue 43995:
VRRP configuration disappears from a VMware SD-WAN Edge after enabling a routed interface.
- Fixed Issue 44039:
When configuring BGP for a VMware SD-WAN Edge, if 0.0.0.0/0 is configured as a default route for Networks, the VMware SD-WAN Orchestrator does not add that route to BGP.
- Fixed Issue 44218:
On the VMware SD-WAN Orchestrator under Configure > Edge > Device, the VMware Edge model 510 displayed a CELL1 interface even though this interface is exclusive to the Edge 510-LTE model.
- Fixed Issue 44767:
In some instances, VMware SD-WAN Edges repeatedly switch from Online to a false Degraded state and back to Online on the Monitor > Edge screen of the VMware SD-WAN Orchestrator.
Known Issues
Open Issues in Release 3.4.2
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-enabled VRFs) may cause latency to increase for approximately 2-3 seconds for some traffic via the VMware SD-WAN Gateway.
Workaround: No workaround available.
- Issue 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-enabled 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 enabled 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 enabled on 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 40425:
Direct Internet traffic from non-Global segments will fail if it matches a route that was learned in the Global segment.
- 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 43141:
If a customer enterprise has the OFC Cost Calculation > Distributed Cost Calculation feature enabled, the VMware SD-WAN Edges on this enterprise do not update the UPLINK cost properly.
- Issue 43613:
OSPF neighborship may not be established over a routed interface when the interface receives its DHCP IP after a delay.
- 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.
- 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.
- 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 45345:
When a VMware SD-WAN Edge connected to a Zscaler GRE tunnel sends IP fragmented traffic, ISPs in France have been observed to incorrectly set the IP length in the GRE packet set to the length of the entire reassembled packet instead of the length of the first fragment and as a result the packets are dropped on the GRE tunnel.
- 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 45820:
Port forwarding works for one LAN subnet when the same NAT IP is configured for multiple LAN subnets.
- 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 46320:
A pair of VMware SD-WAN Edge model 610’s may not be able to form a High Availability pair.
- 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 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 48502:
In some scenarios, a VMware SD-WAN Hub Edge being used to backhaul internet traffic may experience a Dataplane Service Failure due the improper handling of backhaul return packets.
- Issue 19566:
After High Availability failover, the serial number of the standby VMware SD-WAN Edge may be shown as the active serial number in the Orchestrator.
- Issue 20900:
If the MaxMind geolocation service is enabled and cannot reach the MaxMind server, new VMware SD-WAN Edge activations will not work.
- Issue 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: Disable and then reenable GRE at the Edge level to resolve the issue.
- Issue 35667:
When a VMware SD-WAN Edge is moved from one profile to another profile which has the same CSS setting but a different GRE CSS name (the same endpoints), some GRE tunnels will not show in monitoring.
Workaround: Disable and then reenable GRE at the Edge level to resolve the issue.
- Issue 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.
