| Updated March 31st, 2022 VMware SD-WAN Orchestrator Version R341-20200423-GA Check regularly for additions and updates to these release notes. |
What's in the Release Notes
The release notes cover the following topics:- Recommended Use
- Compatibility
- Important Notes
- New Features
- Revision History
- Resolved Issues
- Known Issues
Recommended Use
This release is no longer recommended for use. Customers who require the features and functionality made available in this release, as well as those customers impacted by the issues listed below which have been resolved since Release 3.4.0. are encouraged to upgrade to Release 3.4.5 or newer.
Compatibility
Release 3.4.1 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.1 |
3.4.1 |
3.4.1 |
3.4.0 |
| 3.4.1 |
3.3.2 |
3.3.2 |
3.3.2 |
| 3.4.1 |
3.4.1 |
3.3.2 |
3.3.2 |
| 3.4.1 |
3.4.1 |
3.4.1 |
3.3.2 |
| 3.4.1 |
3.2.2 |
3.2.1 |
3.2.1 |
| 3.4.1 |
3.2.2 |
3.2.2 |
3.2.2 |
| 3.4.1 |
3.4.1 |
3.2.1 |
3.2.1 |
| 3.4.1 |
3.4.1 |
3.2.2 |
3.2.2 |
| 3.4.1 |
3.4.1 |
3.4.1 |
3.2.1 |
| 3.4.1 |
3.4.1 |
3.4.1 |
3.2.2 |
| 3.4.1 |
3.4.0 |
3.4.1 |
3.4.1 |
| 3.4.0 |
3.4.1 |
3.4.1 |
3.4.1 |
| 3.4.1 |
3.4.0 |
3.4.1 |
3.4.1 |
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
SFP module testing during the COVID-19 pandemic
Due to the ongoing COVID-19 crisis, the VMware Quality Engineering teams across the world have been forced to shelter in place. For the standard Release Qualification process, remote access to our worldwide set of test laboratories has ensured the same level of testing and quality as every other VMware SD-WAN software release.
However, the testing of SFP modules requires a physical presence in the laboratory to enable testing the full combination of modules and VMware SD-WAN Edge models. As a result, only a subset of SFP module testing has been performed in Release 3.4.1. Please note that there have been no changes to the operator system or drivers that could cause SFP modules to not work as expected. Also, no issues were observed during the subset of SFP test cases the teams were able to execute.
VMware Edge 510-LTE configurations on CELL1
Release 3.4.1 resolves an issue where a VMware SD-WAN Edge 510-LTE could lose connectivity on CELL1 interfaces after upgrading the Orchestrator to Release 3.4.0 and making a Device Settings change.
The release also addresses a specific VMware SD-WAN Orchestrator upgrade issue where the Profile configuration of Edge 510-LTE devices using Release 3.3.2 P1 and below would not be copied over to the new Edge 510-LTE model family configuration on the same Profile. This issue is resolved in this release by copying the Edge 510 Profile model configuration into the new Edge 510-LTE model family.
The resolution for this issue means that any Edge 510-LTE configuration that was customized at the profile level between the initial rollout of Release 3.4.0 and Release 3.4.1 will be lost and will reflect that of the latest existing 510 model configuration on the same configuration profile. As a result, Edge 510-LTE specific configurations made at the profile level between the Orchestrator upgrade to Release 3.4.0 and Release 3.4.1 will need to be manually restored by the user.
Note: Any Edge level configurations (using Edge override) of an Edge 510-LTE will persist through the upgrade. This includes LTE modem configurations made at the Edge 510-LTE level.
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).
New Features
Note: Beginning with Release 3.4.0, VMware SD-WAN has adopted a standardized set for release numbering: Major.Minor.Patch. Typically, patch releases are reserved for bug fixes and do not introduce new features. However, the ongoing COVID-19 Pandemic has resulted in an overwhelming number of urgent customer requests for the below feature. The introduction of the Private Segments feature in a patch release reflects these exceptional circumstances.
Private Segments
Segments can now be marked as Private. When a segment is marked as Private, there are two functional changes that take place:
- Flow statistics for this segment are not sent to the VMware SD-WAN Orchestrator. This allows administrators to create segments (for instance for Work at Home users) which do not give a user's employer visibility into the flows that are traversing the private segment.
- Flows on private segments will not use the VMware SD-WAN Gateway to access the Internet—even if the flow matches a Business Policy configured with “Internet Multipath”. This is because without visibility into flow statistics, VMware SD-WAN is not able to fulfil the audit obligations required in case of improper behavior of user flows.
Note: For partners operating their own SD-WAN Partner Gateways, configuring NAT routes as secure will still allow Private Segment traffic to exit at the Gateway. Partners are responsible for managing the decision on whether to allow this traffic to traverse their Gateways using these settings.
Document Revision History
June 14th. First Edition. (From a previously published edition at original 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 Issues
Resolved in Gateway Version R341-20200428-GA-44354-44451
The below issue has been resolved since 3.4.1 Gateway version R341-20200425-GA-44354.
- Fixed Issue 44451:
Established flows on the VMware SD-WAN Gateway may time out after 5 minutes (instead of 2 hours and 4 minutes) when the flows are idle (no packets received in either direction).
Resolved in Gateway Version R341-20200425-GA-44354
The below issue has been resolved since 3.4.1 Gateway version R341-20200410-GA.
- Fixed Issue 44354:
VMware SD-WAN Spoke Edges may unlearn routes for their VMware SD-WAN Hub Cluster when the Hub loses connectivity to the VMware SD-WAN Gateway.
Resolved in R341-20200410-GA
The below issues have been resolved since 3.4.0 Edge and Gateway version R340-20200218-GA.
- Fixed Issue 24406:
When upgrading or activating a VMware SD-WAN Edge with a 2.x release installed to a 3.x release, the Edge may go offline after the software upgrade if the lowest numbered routed interface with WAN overlay enabled cannot reach the internet (i.e. static IP address but not connected, private WAN overlay attached).
- Fixed Issue 32933:
User is unable to configure multiple communities in BGP filters.
- Fixed Issue 34297:
The NAT service on the VMware SD-WAN Gateway may experience a Dataplane Service Failure if more than 1 million NAT entries are created.
- Fixed Issue 35370:
In certain scenarios with Hub-to-Hub backhaul configurations, routes are not installed in the VMware SD-WAN Edge—affecting traffic flow.
- Fixed Issue 35564:
A VMware SD-WAN Edge will report a WAN link as down to the VMware SD-WAN Orchestrator if the path to the Primary Gateway is down and there is a bandwidth test.
- Fixed Issue 36779:
If a VMware SD-WAN Spoke Edge is connected to multiple inter-connected Hub Edges, there may be traffic loss to one of the Hubs for up to three minutes if the Spoke initiates traffic to a different Hub.
- Fixed Issue 37066:
In rare scenarios involving a large number of VRFs and routes the VMware SD-WAN Gateway may suffer a Dataplane Service failure, resulting in a Gateway Service restart.
- Fixed Issue 38137:
A VMware SD-WAN Edge model 520/540 which is running a monitoring script implemented by VMware SD-WAN Support to address issue 17322 will repeatedly reboot when upgrading to Release 3.3.2, 3.3.2P1, or 3.4.0.
- Fixed Issue 38598:
The SNMP ifDescr OIDs on the VMware SD-WAN Edge do not show the expected interface names (e.g. GE1, GE2, etc.).
- Fixed Issue 38995:
After either a High-Availability failover or a BGP flap, some BGP routes may never sync to the VMware SD-WAN Orchestrator.
- Fixed Issue 39300:
On a VMware SD-WAN Edge 510-LTE, the LTE modem may get disconnected and not reconnect until the system is restarted.
- Fixed Issue 39733:
The VMware SD-WAN Edge exports invalid ifindex values that do not match the ones returned by SNMP polling.
- Fixed Issue 39962:
LAN-Side NAT fails when the "Outside Address" is the same as one of the VMware SD-WAN Edge's currently assigned IP addresses (e.g. VLAN IP, routed interface IP).
- Fixed Issue 40176:
Both CPS (Connections Per Second) and throughput are lower than expected on a VMware SD-WAN Edge 520.
- Fixed Issue 40285:
A VMware SD-WAN Edge model 3400 deployed in a High-Availability topology and configured as a Hub which suffers a link flap on the GE1 interface (which pairs the two Edges in HA) will result in all GE interfaces to stop passing traffic and the Active Edge does not failover to the Standby Edge.
- Fixed Issue 40321:
IP option 7 (record route) is not handled properly by the VMware SD-WAN Edge nor VMware SD-WAN Gateway.
- Fixed Issue 40425:
Underlay traffic from a Non-Global segment which is received on a WAN-overlay enabled interface will fail if there is a matching route for that traffic on the Global segment.
- Fixed Issue 40492:
When a VMware SD-WAN Partner Gateway is upgraded or restarted, there may be spurious ARP packets broadcasted.
- Fixed Issue 40522:
A voice call may drop when a VMware SD-WAN Edge deployed in a High Availability topology fails over.
- Fixed Issue 40673:
The front status LED shows an incorrect Red status (no internet connectivity) for non-activated VMware SD-WAN Edges, even if they have been properly configured with a WAN link.
- Fixed Issue 40972:
When a VMware SD-WAN Edge Spoke has only tunnels to the Hub Edge (all Gateway tunnels down) and a Hub tunnel towards a Gateway also goes down, the Spoke routes are erroneously retracted.
- Fixed Issue 41072:
The VMware SD-WAN Edge stops generating the appropriate events when it detects a switching loop between VLAN interfaces.
- Fixed Issue 41177:
VMware SD-WAN Edges running software versions between 3.3.0 and 3.3.2 P1 will drop DHCP packets with null yiaddr, most commonly when using a PXE (Preboot Execution Environment).
- Fixed Issue 41258:
On a VMware SD-WAN Edge with a public wireless and private wired link, the latency on the private link may be measured incorrectly when the wireless link is active.
- Fixed Issue 41271:
MPLS CoS Sub-Path status is not available for display when running the Remote Diagnostics utility “List Paths” on the VMware SD-WAN Orchestrator UI.
- Fixed Issue 41463:
A VMware SD-WAN Virtual Edge with SR-IOV interfaces reorders its interfaces after a software upgrade to release 3.4.0.
- Fixed Issue 41504:
When configuring a large BGP community string, the configuration is incorrectly updated on the VMware SD-WAN Edge with the last digit missing for the community string.
- Fixed Issue 41535:
When the routed interface on a VMware SD-WAN Edge is VLAN tagged, ICMP “fragmentation needed” messages are sent without the VLAN ID on the global segment.
- Fixed Issue 41567:
VMware SD-WAN Edge 3800 discards 1500 byte ICMP packets when the packets are VLAN tagged.
- Fixed Issue 41830:
VMware SD-WAN Gateway may suffer a deadlock after enabling Dynamic Bandwidth Adjustment.
- Fixed Issue 41855:
A software upgrade of a VMware SD-WAN Edge in a high-availability topology may fail because the Standby Edge is listed with an incorrect serial number.
- Fixed Issue 41975:
When Branch-to-Branch VPN is enabled and "Use Hubs for VPN" is selected, a small amount of memory may be leaked when a flow is created that transits the VMware SD-WAN Hub.
- Fixed Issue 42169:
VMware SD-WAN Spoke Edge routes on Hub Edges may be redistributed into BGP/OSPF with the wrong metric value.
- Fixed Issue 42187:
On the cloud interface of a VMware SD-WAN Gateway, IP fragments which arrive out of order are not reassembled and the fragments are dropped.
- Fixed Issue 42190:
A memory leak can occur when using SNMPv3 to monitor the VMware SD-WAN Edge that over several months may result in a reduction of memory capacity sufficient to induce a kernel panic and reboot.
- Fixed Issue 42246:
A VMware SD-WAN Edge will not have routes to a VMware SD-WAN Gateway if the Gateway was initially deployed with a software build in the 1.x branch.
- Fixed Issue 42505:
A VMware SD-WAN Gateway may experience a Dataplane Service failure while running a NAT table dump.
- Fixed Issue 42879:
Ping requests received on PPPoE or USB modem interfaces can cause the VMware SD-WAN Edge’s packet buffer used to store the ping request to be lost, eventually leading to exhaustion of packet buffers and traffic failure on the Edge.
- Fixed Issue 42893:
The NAT process fails to start properly on a VMware SD-WAN Gateway that is deployed with >= 32GB of RAM.
- Fixed Issue 43018:
When Stateful Firewall is disabled on a VMware SD-WAN Edge, the Remote Diagnostic utilities “List Active Firewall Sessions” and “Flush Firewall Sessions” are still displayed.
- Fixed Issue 43178:
DHCP requests which request a specific IP address via the "Client-IP" parameter to the VMware SD-WAN Edge can cause the DNS/DHCP service to fail.
- Fixed Issue 43208:
In rare circumstances when a VMware SD-WAN Edge is receiving an inordinately large number of DNS queries, the Edge will begin dropping traffic as the DNS cache size increases, resulting in a degradation in Edge performance.
Resolved in Version R341-20200423-GA
The below issues have been resolved since Orchestrator version R340-20200218-GA.
- Fixed Issue 32968:
The VMware SD-WAN Orchestrator allows the configuration of more than one community per filter
- Fixed Issue 37768:
Custom applications added to a VMware SD-WAN Edge-specific Application Map (as opposed to an Enterprise-global one) did not appear among the selectable applications in the configuration dialogs for business policies or firewall rules.
- Fixed Issue 38410:
When a user has multiple web browser tabs opened for the same VMware SD-WAN Orchestrator Web UI, the walkaway timeout incorrectly determines a walk away based on tabs without user activity versus the tab with user activity, resulting in the user being logged out from that Orchestrator on all tabs.
- Fixed Issue 40756:
VMware SD-WAN Orchestrator displays the incorrect copyright for service provider and telecom branding packages.
- Fixed Issue 40839:
A logical error in a reverse DNS cache lookup may cause the VMware SD-WAN Orchestrator to fail to resolve a disproportionate number of hostnames for Internet destinations appearing in Edge-reported traffic flows.
- Fixed Issue 40887:
Superuser Operators are unable to view the Sources monitoring page under Monitor > Edge.
- Fixed Issue 41506:
When configuring Edge Hub Backhaul on a Business Policy rule, an incorrect association to the segment could occur and cause the configuration to not take effect.
- Fixed Issue 41646:
User is unable to create a new Business Policy after refreshing the Profile level Business Policy page.
- Fixed Issue 41818:
The VMware SD-WAN Orchestrator does not provide an option to export firewall logs from all segments to a collector.
- Fixed Issue 41891:
When Strict IP Precedence is disabled for a Private Link configuration, Class Group Validation is skipped.
- Fixed Issue 41987:
A VMware SD-WAN Edge running release 3.3.2 or higher will have its existing DSCP class of service configuration rejected after the VMware SD-WAN Orchestrator is upgraded to 3.4.0.
- Fixed Issue 42082:
The Application Maps screen loads very slowly on a VMware SD-WAN Orchestrator where many different application maps are in use.
- Fixed Issue 42152:
On the Monitor > Edge > Transport tab, the time menu does not offer “Past 6 months” and “Past 12 months” as options.
- Fixed Issue 42199:
If a validation error occurs while saving VMware SD-WAN Edge Hub configurations on an Enterprise Profile, there is a chance that the configuration could be caught in a bad state and cause VMware SD-WAN Orchestrator UI failures on both the Enterprise Profile and the Edges associated with that Profile.
- Fixed Issue 42201:
A VMware SD-WAN Edge 510-LTE running software release 3.3.2 P2 or earlier will lose the use of the CELL1 interface when the VMware SD-WAN Orchestrator is upgrade to 3.4.0.
- Fixed Issue 42311:
VMware SD-WAN Spoke Edge may not form a tunnel with a Hub Edge running Release 3.3.2 when both the VMware SD-WAN Orchestrator and Gateways are upgraded to Release 3.4.0.
- Fixed Issue 42652:
Dynamic tunnels are not formed when WAN link type is not correctly detected by the VMware SD-WAN Orchestrator.
- Fixed Issue 42664:
When a routed interface is configured for static addressing in a Profile, Edge-specific DHCP server settings are not honored (i.e. not propagated to the device) unless the interface “override” option was selected for each VMware SD-WAN Edge.
- Fixed Issue 42864:
Firewall logging uses Allow/Deny/Open/Close/Update as the Action code instead of A/D/O/C/U and causes the VMware SD-WAN Orchestrator firewall log parser to fail with all the logs displaying Action code “Deny”.
- Fixed Issue 43217:
A user-defined Private MPLS WAN Overlay Changes to Public WAN Overlay without user changes.
- Fixed Issue 43873
User is not able to configure new backhaul business policies for a VMware SD-WAN Edge Cluster Hub.
Known Issues
Open Issues in Release 3.4.1
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 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.
- 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 40565:
The NetFlow record for direct internet traffic matching a default business policy or underlay routed traffic on a WAN overlay enabled interface gets exported in the 256 template ID instead of the expected 259 template ID.
- 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 42307:
Static routes on a VMware SD-WAN Partner Gateway may be incorrectly marked as unreachable when they are monitored using ICMP probes.
- 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 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.
- 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 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 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 42867:
Enabling syslog forwarding at the Profile level is not applied to VMware SD-WAN Edges using that Profile.
- Issue 43276:
User cannot change the Segment type when a VMware SD-WAN Edge or Profile has a VMware SD-WAN Partner Gateway configured.
