VMware SASE 5.2.4 | 30 September 2024

  • VMware SD-WAN™ Gateway Version R5240-20240828-GA

  • VMware SD-WAN™ Edge Version R5240-20240828-GA

Note:

Release 5.2.4 is an Edge/Gateway software release only and does not have a SASE Orchestrator component.

The SASE Orchestrator remains on 5.2.3+ LTS and additional fixes for Orchestrator issues will continue to be added through rollup builds in accordance with LTS policy.

Check for additions and updates to these release notes.

What Is in The Release Notes

The release notes cover the following topics:

This release is recommended for all customers who require the features and functionality first made available in Release 5.2.0, as well as those customers impacted by the issues listed below which have been resolved since Release 5.2.3.

Important:

Release 5.2.4 contains all Edge and Gateway fixes that are listed in the 5.2.3 Release Notes up to Edge/Gateway version R5234-20240826-GA.

5.2.4 is a Long-Term Support (LTS) Release

VMware VeloCloud SD-WAN/SASE introduced a Long-Term Support (LTS) policy to enhance the operational efficiency of our partners and customers during the implementation of new software. Release 5.2.3+ is the first LTS release, and SD-WAN Release 5.2.4 for the Edge/Gateway continues off of 5.2.3+ as an LTS Release.

For additional information about our Long-Term Support program see: VMware SD-WAN/SASE Long-Term Support Release (96246).

Compatibility

Release 5.2.4 Gateways and Hub Edges support all previous VMware SD-WAN Edge versions greater than or equal to Release 4.2.0.

The following SD-WAN interoperability combinations were explicitly tested:

Orchestrator

Gateway

Edge

Hub

Branch/Spoke

5.2.3

5.2.4

4.2.2

4.2.2

5.2.3

5.2.4

5.2.4

4.2.2

5.2.3

5.2.4

4.2.2

5.2.4

5.2.3

5.2.4

4.3.2

4.3.2

5.2.3

5.2.4

5.2.4

4.3.2

5.2.3

5.2.4

4.3.2

5.2.4

5.2.3

4.5.2

4.5.2

4.5.2

5.2.3

5.2.4

4.5.2

4.5.2

5.2.3

5.2.4

5.2.4

4.5.2

5.2.3

5.2.4

4.5.2

5.2.4

5.2.3

5.0.1

5.0.1

5.0.1

5.2.3

5.2.4

5.0.1

5.0.1

5.2.3

5.2.4

5.2.4

5.0.1

5.2.3

5.2.4

5.0.1

5.2.4

5.2.3

5.1.0

5.1.0

5.1.0

5.2.3

5.2.4

5.1.0

5.1.0

5.2.3

5.2.4

5.2.4

5.1.0

5.2.3

5.2.4

5.1.0

5.2.4

5.2.3

5.2.4

5.2.2

5.2.2

5.2.3

5.2.4

5.2.4

5.2.2

5.2.3

5.2.4

5.2.2

5.2.4

5.2.3

5.2.3

5.2.3

5.2.3

5.2.3

5.2.3

5.2.4

5.2.4

5.2.3

5.2.4

5.2.3

5.2.3

5.2.3

5.2.4

5.2.4

5.2.3

5.2.3

5.2.4

5.2.3

5.2.4

5.2.3

5.2.4

5.2.4

5.2.4

5.3.0

5.2.4

5.2.4

5.2.4

6.0.0

5.4.0

5.2.4

5.2.2

6.0.0

5.2.4

5.2.2

5.2.4

6.0.0

6.0.0

5.2.4

5.1.0

6.0.0

5.2.4

5.1.0

5.2.4
Important:

VMware SD-WAN Release 4.0.x has reached End of Support; Releases 4.2.x, 4.3.x, and 4.5.x have reached End of Support for Gateways and Orchestrators.

  • Release 4.0.x reached End of General Support (EOGS) on September 30, 2022, and End of Technical Guidance (EOTG) December 31, 2022. 

  • Release 4.2.x Orchestrators and Gateways reached End of General Support (EOGS) on December 30, 2022, and End of Technical Guidance on (EOTG) March 30, 2023.   

  • Release 4.2.x Edges reached End of General Support (EOGS) on June 30, 2023, and will reach End of Technical Guidance (EOTG) September 30, 2025.

  • Release 4.3.x Orchestrators and Gateways reached End of General Support (EOGS) on June 30, 2023, and End of Technical Guidance (EOTG) September 30, 2023.

  • Release 4.3.x Edges reached End of General Support (EOGS) on June 30, 2023, and will reach End of Technical Guidance (EOTG) September 30, 2025.

  • Release 4.5.x Orchestrators and Gateways reached End of General Support (EOGS) on September 30, 2023, and End of Technical Guidance on (EOTG) December 31, 2023.

  • For more information please consult the Knowledge Base article: Announcement: End of Support Life for VMware SD-WAN Release 4.x (88319).

Upgrade Paths Gateway and Edge

The following lists the paths for customers wishing to upgrade their Gateway or Edge from an older release to Release 5.2.4.

Gateway

Upgrading a Gateway using Release 4.5.0 or later to Release 5.2.4 is fully supported for all Gateway types.

Important:

When deploying a new Gateway using 5.2.4 the VMware ESXi instance must be at least version 6.7, Update 3 up to version 7.0. Using an earlier ESXi instance will result in the Gateway's Dataplane Service failing when trying to run Release 5.2.3 or later.

Important:

Prior to upgrading a Gateway to 5.2.4, the ESXi instance must be upgraded to at least version 6.7, Update 3 up to version 7.0. Using an earlier ESXi instance will result in the Gateway's Dataplane Service failing when trying to run Release 5.2.3 or later.

Edge

An Edge can be upgraded directly to Release 5.2.4 from any Release 4.x or later.

New Hardware Platforms

Release 5.2.4 includes support for VeloCloud Edge models 710-5G, 720, and 740.

For more information, please consult the announcement for these new Edge models.

Important Notes

Limitation with BGP over IPsec on Edge and Gateway, and Azure Virtual WAN Automation

The BGP over IPsec on Edge and Gateway feature is not compatible with Azure Virtual WAN Automation from Edge or Gateway. Only static routes are supported when automating connectivity from an Edge or Gateway to an Azure vWAN.

Limitation When Deactivating Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810

When a user deactivates 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 Deactivating Autonegotiation on VMware SD-WAN Edge Models 520, 540, 620, 640, 680, 3400, 3800, and 3810 (87208).

Document Revision History

September 30th, 2024. Second Edition.

  • Added a new, verified interoperability scenario of 5.2.3 Orchestrator, 5.2.3 Gateway, and 5.2.4 Hub/Spoke Edge to the Compatibility section.

  • Added Open Issue #151654 to the Edge/Gateway Known Issues section.

September 5th, 2024. First Edition.

Edge/Gateway Resolved Issues

Resolved in Edge/Gateway Version R5240-20240828-GA

Edge/Gateway version R5240-20240828-GA was released on 09-05-2024 and resolves the following issues since Edge/Gateway build R5234-20240826-GA. This means that a fix for an Edge or Gateway issue listed in the 5.2.3 Release Notes up to the listed version is included in all Release 5.2.4 builds.

  • Fixed Issue 23333: The Orchestrator may report incorrect throughput for Edge interfaces when the Edge is configured to use Multicast.

    Bandwidth utilized by multicast traffic on a link reported on the Orchestrator is multiples higher than the actual utilized bandwidth. This is caused by the Edge accounting for multicast packets multiple times during the link_stats accounting because key flags on the packet are not set during the cloning of these packets for multicast traffic. As a result, the Edge reports these excessively high usage statistics to the Orchestrator and a user can observe these in multiple locations on the Edge > Monitor section of the UI.

  • Fixed Issue 118710: The IP address and mask are not allocated to the VLAN interfaces that are created on the WLAN interfaces.

    The Edge kernel fails to assign the VLAN interfaces onto the WLAN interfaces, which prevents the Edge from applying the configuration to these VLAN interfaces. Additionally, the assignment of network interface (netif) corresponding to vc-ifaces is also omitted, rendering these interfaces unusable since there are no IP addresses assigned to them.

    On an Edge without a fix for this issue, the workaround is to assign a physical interface (in other words, an Edge port like GE1, GE2 or the like) to the VLANs.

  • Fixed Issue 128150: For an Edge with Wi-Fi enabled, if a user changes the location to a different country they may observe Events.

    The Edge events would show as either MGD_DEVICE_CONFIG_ERROR or MGD_DEVICE_CONFIG_WARNING. When the Edge location country is changed, the .wireless file is populated for a non Wi-Fi radio Edge. This results in the Edge sending out these events.

  • Fixed Issue 130326: When a customer deploys a Cloud Security Service with redundant tunnels (in other words, active and standby) and L7 Health Check is toggled on, he secondary tunnel L7 state shows as up even if the tunnel is down on the Orchestrator's Edge tunnel monitoring page.

    The Orchestrator displays L7 health information for standby CSS tunnels, even though the Edge is not building a standby CSS tunnel unless it is needed, it is thus impossible to do an L7 health check through a non-existent tunnels. However, despite this the Edge sends this false information to the Orchestrator which are then displayed in the UI's Monitor section.

    The issue is the result of the Edge erroneously initialing the L7 state with a default "Up" value instead of the correct "Unknown" value.

  • Fixed Issue 131674: ICMP traffic from a Spoke Edge using internet backhaul via a Hub Edge fails if the ICMP flow has to be steered from one link to a different one.

    ICMP traffic passing on one of two or more links in a Spoke/Hub backhaul topology is expected to be steered to a different link if the existing link goes down or is unusable per QoE. Even if spoke starts sending the traffic back to the Hub, the Hub fails to process the return traffic.

  • Fixed Issue 131845: When the Firewall is enabled on the Edge, the Edge in rare cases may experience a Dataplane Service failure and restart to recover.

    When the issue is encountered, it is caused by a race condition in the Edge's Firewall code that results in an out of boundary memory access event which triggers the Edge service failure.

  • Fixed Issue 132004: For a customer enterprise site deployed with a High Availability topology, the Standby Edge may send management traffic (VCMP) not destined for its IP Address/MAC Address back to the Virtual Private LAN Service (VPLS), resulting in unicast flooding.

    Since there is no destination MAC check for unicast packets received on a Standby Edge, the Edge processes these VCMP packets as valid packets destined for it, updates the TTL and sends it back, and this causes the unicast flooding.

  • Fixed Issue 133004: For a customer enterprise site configured with an Enhanced High Availability topology, after an HA failover it make take more than expected time for links to reestablish tunnels with the Orchestrator.

    In an Enhanced HA topology, the management (VCMP) tunnel over a DHCP-enabled link takes more time to move to a "Stable" state.

    After the HA failover, the DHCP request is sent after a few seconds and as a result tunnel establishment can take more than 35 seconds.

  • Fixed Issue 133081: For a customer enterprise site configured with a High Availability topology, the Standby Edge may experience a Dataplane Service failure and restart.

    The Standby Edge service can fail when an invalid route is synchronized to it. The issue is triggered by corrupted data in the route synchronization message, which triggers the Edge service failure when processed. The fix adds a checksum for the synchronization data and if the checksum does not match on the Standby Edge then the packet is ignored and not processed.

  • Fixed Issue 137083: An Edge may initiate a service restart when a user generates a diagnostic bundle for it.

    When diagnostic bundle trigger is received from the Orchestrator, the Edge's Dataplane Service experiences a failure and restarts to recover.

    The issue is caused by the diagnostic bundle script running debug.py --dns_name_cache, which still has some freed entries and triggers the Edge service failure.

    Without a fix for the issue, a user should seek to generate a diagnostic bundle in a maintenance window, if possible.

  • Fixed Issue 137932: For a customer using Partner Gateways, when the Handoff IP Address is changed on the Orchestrator UI, this change is not applied to the Gateway even though the UI shows that it has been applied, which leads to customer traffic failure.

    This can be confirmed on the Gateway using the debug.py --ifaces command. The issue is caused by a defect in the Gateway process for handling only a handoff IP address update, though a first time handoff configuration does work.

    On a Partner Gateway without a fix for this issue, the workaround is to disable handoff for the enterprise + the segment and save the configurations. Then re-enable handoff and configure the new handoff IP. This should only be done in a maintenance window.

  • Fixed Issue 138452: For a customer enterprise using either a Cloud Security Service (CSS) or a Non SD-WAN Destination (NSD), a user may observe duplicate tunnel entries and traffic drops if an Edge interface is changed.

    When an Edge interface overlay is modified (for example, from auto-detect to user-defined) the Edge is expected to delete all the CSS and NSD paths linked with the interface. When this issue is encountered, the Edge is only deleting one path linked to the interface, and this results in duplicate tunnels where one tunnel is invalid and traffic is dropped that is steered towards it.

    On an Edge without a fix for this issue, the user should only change the Edge interface WAN overlay in a maintenance window. After the change is made, disable all CSS or NSD's via Edge and then reenable them as this will delete all the tunnels.

  • Fixed Issue 138464: On a customer enterprise site using a High Availability topology, a user may observe high memory utilization on the Active Edge which can result in an HA failover due to high memory usage.

    With this issue, the Active Edge's memory utilization increases rapidly when the HA Edge is handle a higher number of concurrent connections per second. Once the memory utilization reaches 60% and is sustained there for more than 90 seconds, then the Active Edge's service defensively restarts to recover memory, resulting in an HA failover. In an Enhanced High Availability topology this can cause customer traffic disruption for traffic using a WAN link on the Active Edge that is affected by this issue.

    On an Edge without a fix for this issue, a should navigate to the Monitor > Events page for that HA Edge and monitor the memory utilization threshold limit warning Event or monitor memory utilization on the Monitor > Edges > System page and reduce the number of concurrent connections per second to maintain the memory utilization to less then 60%.

  • Fixed Issue 138900: For a customer site deployed with a High Availability topology, the customer may observe Standby edge restart resulting from Standby Edge having high memory usage.

    If memory usage is sufficiently high, the Edge defensively restarts the Dataplane Service to clear the issue, and this impacts traffic, if that Standby has any enhanced HA interface configured. In case of standard HA, there is no functionality impact. The high memory usage is the result of a memory leak which is caused by Edge refreshing all IPsec tunnel certificates which triggers a tear down and rebuilding of all IPsec tunnels when there is change in the certificate. Buildup is relatively small.

    On an HA site without a fix for this issue, the only workaround is to monitor memory usage and, should usage get too high, defensively restart Standby edge during a maintenance window to clear memory.

  • Fixed Issue 139049: When an Edge is configured as a DHCP server for LAN clients, after a software upgrade from release 5.1.x or older to release 5.2 or later, DHCPOFFER messages are no longer sent with the fields sname/file (server name/filename) populated.

    DHCP options 66 and 67 are not sent after upgrade to software version 5.2.x or later. If a DHCP client requires the information from the sname/file fields in the DHCPOFFER message to boot, the DHCP client may not be able to boot after the Edge is upgraded from release 5.1 or older to release 5.2 or later.

  • Fixed Issue 139622: For customers using Edge Network Intelligence, there may be a discrepancy between the statistics shown on the SASE Orchestrator and the Edge Network Intelligence portal.

    Sometimes traffic is misclassified from the Analytics perspective and this results in the Analytics metadata being dropped on the Edge Network Intelligence back-end.

  • Fixed Issue 140033: For a customer enterprise deployed with a Hub/Spoke topology, a Spoke Edge may experience a Dataplane Service failure and restart when sending a high number of flows to the Hub Edge when the Hub Edge restarts.

    When there are large scale number of backhaul flows to the Hub Edge and the Hub Edge goes down (as during a restart), the Spoke Edge's route lookup process is performed for every flow and ends up iterating all the peer routes by holding the peer routes lock in a tight loop since the peer route reachability would be marked as false, this triggers a mutexmon induced SIGXCPU as the other threads wait for the peer routes lock.

  • Fixed Issue 140919: A change made to the Address Group or Port Group used by a current Firewall or Business Policy rule may not affect traffic established prior to the rule modification.

    Traffic which is expected to match a particular Firewall or Business Policy rule after a change to either the Address Group and/or Port Group fails to match the rule. This results in inconsistent behavior as new traffic will match the modified rules but existing traffic with the same parameters does not match the rule.

  • Fixed Issue 141327: If a user performs a VNF insert using a Palo Alto Networks (PAN) VNF for an Edge model 520v, the VNF Insertion remains down after the required Edge Service restart.

    The issue occurs when using the VM-50 lite Authcode.

    On an Edge without a fix for this issue, the user needs to redeploy the VNF.

  • Fixed Issue 141330: For a customer enterprise where a user configures a Business Policy, and under Link Policy enters a value other than 0 for Loss %, that value may not be respected on the return path for traffic between Edges or between an Edge and Gateway, and a value of 0 is instead used in the return path.

    Certain fields in the QoS synchronization message between Edges or between an Edge and Gateway are incorrectly encoded and decoded, resulting in the value always being decoded as 0. The major parameter encoded in the qos_sync message is the "Error Correct Before Steering" and results in the configured value not being respected for that rule.

  • Fixed Issue 141943: An Edge 3800 running at maximum scale may experience memory consumption issues to the point of frequently triggering defensive Edge service restarts to recover the memory.

    Maximum scale is understood as an Edge 3800 with 3.8M Edge to Edge flows and 4K peers, 6K tunnels, and 100K routes. Under those conditions the Edge 3800's memory utilization reaches 75% and triggers a restart which is repeated until the flows are reduced to below maximum scale.

  • Fixed Issue 142388: An Edge model with a status LED on the front may remain dark if the user restarts the Edge service immediately after performing an Identify remote action on the Edge's local UI.

    This includes Edge 510's, 5x0s, 6x0s, and 7x0's, and can be remediated by performing another Identify remote action on either the Local UI or the Orchestrator.

  • Fixed Issue 143079: An Edge may experience a kernel panic due to an OS memory exhaustion and reboot to recover.

    The processes that handle the Edge's system status may accumulate memory usage to a level that leads to the Edge's OS experiencing an Out of Memory event which triggers the kernel panic.

  • Fixed Issue 143681: The Edge service may restart when there there are a large number of Edges in the enterprise and the Edge receives Edge-to-Edge routes from multiple remote Edges while the connectivity to these remote Edges flaps.

    On a connectivity flap to a peer Edge, the Edge flushes the flows. When a flush event for a destination ID is received on an Edge, all the peer entries in the peer table and then all routes received from each peer are traversed and then the routes having the given destination ID and nexthop ID are are marked as stale. In the case of a highly scaled number of routes, traversing all the routes may consume a lot of time which can lead to mutex monitor failure.

  • Fixed Issue 143730: For an Edge where the Enhanced Firewall Service is enabled and Intrusion Detection System/Intrusion Prevention System (IDS/IPS) is activated, if the Edge is then hard reset and reactivated to the same configuration, even though (IDS/IPS) is configured, the rules associated with it are not loaded, leading to traffic drop.

    With this issue, LAN-side clients connecting to the Edge will experience no outbound connectivity through the device and the Orchestrator will post a long string of Enhanced Firewall Service not-ready messages for the dropped flows.

    On an Edge without a fix for this issue, disabling and then reenabling Enhanced Firewall Service will trigger a download of the IDS/IPS signature rules.

  • Fixed Issue 144143: On a site deployed with a Standard High Availability topology, if the HA link is down, the Orchestrator will report the Standby Edge state as "Unknown".

    This is not an expected result as the Standby Edge status can be verified through a heartbeat packet confirmation through a WAN link.

  • Fixed Issue 145454: Traffic may be sent or received over an Edge WAN link configured as a Hot Standby.

    When an Edge WAN link is configured as Hot Standby, data traffic is not expected to be sent or received over that link unless the active link fails. However this bug may cause traffic to be received at a Edge in a Spoke/Branch role over a Hot Standby link even when the primary link is stable.

  • Fixed Issue VLENG-146814: When a user navigates to Monitor > Edge > Flows tab, they may observe that the Orchestrator displays incorrect Source and Host Names for local IP addresses.

    The Source and Destination IP Addresses for peer generated flows will always be in reverse order. This is also the case for Source and Destination ports. When the chat stats are generated the ports are reversed for peer flows, but the Source and Destination IP addresses were not. Because of this the Orchestrator shows incorrect Source and Host Names.

  • Fixed Issue 146904: On a Partner Gateway with a single hop PG-BGP session, for any traffic destined to the PG VRF IP address, the return traffic may get dropped.

    For PG-BGP scenario (single hop), the Gateway checks to determine if a PG-BGP nexthop IP address is configured or not. If it is not present, the Gateway tries to assign the arp dst_ip to the ip-packet destination IP address. As a result, egress traffic can get dropped due to ARP failure.

    For a Gateway without a fix for this issue, the Partner should use a multi-hop PG-BGP session instead of a single hop session.

  • Fixed Issue 147015: For a customer using the Stateful Firewall with Flood Protection (Rate Limiting and Deny List) enabled, client users may observe that Edge tunnels go down and traffic latency increases.

    Since the rate-limiting table size is not limited, in the case of a random source attack the Edge can be tracking millions of source IP addresses for rate-limiting. This consumes a lot of Edge memory with constant lookups and results in a slower cleanup of stale entries, and this can bring down the Edge.

  • Fixed Issue 147137: An Edge may experience a Dataplane Service failure and restart to recover during the Edge's boot sequence.

    On boot up, an Edge can experience a deadlock between the configuration thread and the Edge's OS kernel interface state change message handling thread. The configuration thread takes the device_settings lock and looks to acquire the g_iface_lock while trying to create a new segment. At the same time, the Edge OS kernel message handling thread acquires g_iface_lock and tries to reapply configurations for a br-network interface while looking to acquire device_settings lock, and this results in a deadlock that triggers an Edge service failure.

  • Fixed Issue 147800: For a Business Policy configured with an Object Group, if a user modifies the Object Group's Address or Port Group, these changes may not be immediately applied to existing flows.

    Traffic expected to match this Business Policy rule after changing the Object Group do not match the rule because the change is not triggering the Edge to re-lookup of all such rules.

  • Fixed Issue 148303: For a customer enterprise deploying one or more Non SD-WAN Destinations where BGP over NSD is configured on the Edge, the NSD over BGP IP address route is being advertised into the overlay.

    In scenarios when BGP is turned off completely with NSD BGP configured and re-enabled again, the NSD BGP peer IP address route gets advertised to overlay, this is due to a defect in the best route advertisement logic.

  • Fixed Issue 148823: For customer enterprises using OSPF for routing, there may be a failure of the OSPF process on an Edge, resulting in the OSPF routes bouncing for that Edge with traffic disruption for client users.

    As part of processing the OSPF LSA (link state advertisement), the LSA will be deleted from the neighbor retransmit list using ospf_ls_retransmit_delete. However, prior to this lookup being done, the local variable still points to the freed memory and accessing it leads to the OSPF process failure.

  • Fixed Issue 149471: For a customer enterprise where the Stateful Firewall is enabled and Network Flood Control is configured, during a flooding attack on an Edge, the Edge may appear offline on the Orchestrator and not receive configuration updates from the Orchestrator or send usage statistics to it.

    A flooding attack should not prevent the Edge from maintaining communication with the Orchestrator, but in this instance that can occur.

  • Fixed Issue 149862: For a Virtual Edge that does not have a LAN adapter, when this Edge is upgraded to Release 5.2.3.3, it does not form tunnels and sends out the message: "VeloCloud Edge service started in mgmt-only mode" .

    This issue is the result of network configurations not being fully generated on Virtual Edges (including AWS, Azure, and GCP) that do not have LAN adapters.

  • Fixed Issue 150297: A Virtual Edge may generated logs which include errors regarding not being able to set autonegotiation on its interfaces.

    When attempting to change the autonegotiation setting on a Virtual Edge with VMXNET3 NICs (or other such NICs that do not support autonegotiation), the log is littered with errors about being unable to set autonegotiation on the interface. These error messages are erroneous and should be excluded from logs since it is impossible to set autonegotiation on these interfaces.

Known Issues

Open Issues in Release 5.2.4.

Note:

Release 5.2.4 is an Edge/Gateway Release only and does not include an Orchestrator component. As a result, no Orchestrator known issues are listed in 5.2.4 Release Notes and such issues continue to be tracked in the 5.2.3 Release Notes.

Edge/Gateway Known Issues

  • 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 25504:

    Static route costs greater than 255 may result in unpredictable route ordering.

    Workaround: Use a route cost between 0 and 255.

  • Issue 25595:

    A restart may be required for changes to static SLA on a WAN overlay to work properly.

    Workaround: Restart Edge after adding and removing Static SLA from WAN overlay.

  • Issue 25742:

    Underlay accounted traffic is capped at a maximum of the capacity towards the VMware SD-WAN Gateway, even if that is less than the capacity of a private WAN link which is not connected to the Gateway.

  • Issue 25758:

    USB WAN links may not update properly when switched from one USB port to another until the VMware SD-WAN Edge is rebooted.

    Workaround: Reboot the Edge after moving USB WAN links from one port to another.

  • Issue 25885:

    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 25921:

    VMware SD-WAN Hub High Availability failover takes longer than expected (up to 15 seconds) when there are three thousand branch Edges connected to the Hub.

    Workaround: No workaround available.

  • Issue 25997:

    The VMware SD-WAN Edge may require a reboot to properly pass traffic on a routed interface that has been converted to a switched port.

    Workaround: Reboot the Edge after making the configuration change.

  • Issue 26421:

    The primary Partner Gateway for any branch site must also be assigned to a VMware SD-WAN Hub cluster for tunnels to the cluster to be established.

    Workaround: No workaround available.

  • Issue 28175:

    Business Policy NAT fails when the NAT IP overlaps with the VMware SD-WAN Gateway interface IP.

    Workaround: No workaround available.

  • Issue 31210:

    VRRP: ARP is not resolved in the LAN client for the VRRP virtual IP address when the VMware SD-WAN Edge is primary with a non-global CDE segment running on the LAN interface.

    Workaround: No workaround available.

  • Issue 32731:

    Conditional default routes advertised via OSPF may not be withdrawn properly when the route is deactivated.

    Workaround: Reactivating the route, followed by deactivating it again will retract it successfully.

  • Issue 32960:

    Interface “Autonegotiation” and “Speed” status might be displayed incorrectly on the Local Web UI for activated VMware SD-WAN Edges.

    Workaround: Refer to the Orchestrator UI under Remote Diagnostics > Interface Status.

  • Issue 32981:

    Hard-coding speed and duplex on a DPDK-configured port may require a VMware SD-WAN Edge reboot for the configurations to take effect as it requires turning DPDK off.

    Workaround: There is no workaround for this issue.

  • Issue 34254:

    When a Zscaler CSS is created and the Global Segment has FQDN/PSK settings configured, these settings are copied to Non-Global Segments to form IPsec tunnels to a Zscaler CSS.

  • Issue 35778:

    When there are multiple user-defined WAN links on a single interface, only one of those WAN links can have a GRE tunnel to Zscaler.

    Workaround: Use a different interface for each WAN link that needs to build GRE tunnels to Zscaler.

  • Issue 36923:

    Cluster name may not be updated properly in the NetFlow interface description for a VMware SD-WAN Edge which is connected to that Cluster as its Hub.

  • Issue 38682:

    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 38767:

    When a WAN overlay that has GRE tunnels to Zscaler configured is changed from auto-detect to user-defined, stale tunnels may remain until the next restart.

    Workaround: Restart the Edge to clear the stale tunnel.

  • 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 39608:

    The output of the Remote Diagnostic “Ping Test” may display invalid content briefly before showing the correct results.

    Workaround: There is not workaround for this issue.

  • Issue 39624:

    Ping through a subinterface may fail when the parent interface is configured with PPPoE.

    Workaround: There is no workaround for this issue.

  • Issue 39753:

    Toggling Dynamic Branch-to-Branch VPN to off may cause existing flows currently being sent using Dynamic Branch-to-Branch to stall.

    Workaround: Only deactivate Dynamic Branch-to-Branch VPN in a maintenance window.

  • 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 40096:

    If an activated VMware SD-WAN Edge 840 is rebooted, there is a chance an SFP module plugged into the Edge will stop passing traffic even though the link lights and the VMware SD-WAN Orchestrator will show the port as 'UP'.

    Workaround: Unplug the SFP module and then replug it back into the port.

  • Issue 42278:

    For a specific type of peer misconfiguration, the VMware SD-WAN Gateway may continuously send IKE init messages to a Non-SD-WAN peer. This issue does not disrupt user traffic to the Gateway; however, the Gateway logs will be filled with IKE errors and this may obscure useful log entries.

  • Issue 42872:

    Activating Profile Isolation on a Hub profile where a Hub Cluster is associated does not revoke the Hub routes from the routing information base (RIB).

  • Issue 43373:

    When the same BGP route is learnt from multiple VMware SD-WAN Edges, if this route is moved from preferred to eligible exit in the Overlay Flow Control, the Edge is not removed from the advertising list and continues to be advertised.

    Workaround: Activate Distributed Cost Calculation (DCC) on the VMware SD-WAN Orchestrator.

  • Issue 44995:

    OSPF routes are not revoked from VMware SD-WAN Gateways and VMware SD-WAN Spoke Edges when the routes are withdrawn from the Hub Cluster.

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

  • 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 46053:

    BGP preference does not get auto-corrected for overlay routes when its neighbor is changed to an uplink neighbor.

    Workaround: An Edge Service Restart will correct this issue.

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

    Workaround: If a customer is using AES-256, they must explicitly deactivate GCM from the Orchestrator prior to upgrading their Edges to a 4.x Release. Once all their Edges are running a 4.x release, the customer may choose between AES-256-GCM and AES-256-CBC.

  • Issue 46216:

    On a Non SD-WAN Destinations via Gateway or Edge where the peer is an AWS instance, when the peer initiates Phase-2 re-key, the Phase-1 IKE is also deleted and forces a rekey. This means the tunnel is torn down and rebuilt, causing packet loss during the tunnel rebuild.

    Workaround: To avoid tunnel destruction, configure the Non SD-WAN Destinations via Gateway/Edge or CSS IPsec rekey timer to less than 60 minutes. This prevents AWS from initiating the re-key.

  • Issue 46391:

    For a VMware SD-WAN Edge 3800, the SFP1 and SFP2 interfaces each have issues with Multi-Rate SFPs (i.e. 1/10G) and should not be used in those ports.

    Workaround: Please use single rate SFP's per the KB article VMware SD-WAN SupportedSFP Module List (79270). Multi-Rate SFPs may be used with SFP3 and SFP4.

  • Issue 47664:

    In a Hub and Spoke configuration where Branch-to-Branch via Hub VPN is not configured, 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 activate 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 48530:

    VMware SD-WAN Edge 6x0 models do not perform autonegotiation for triple speed (10/100/1000 Mbps) copper SFP's.

    Workaround: Edge 520/540 supports triple speed copper SFPs but this model has been marked for End-of-Sale by Q1 2021.

  • Issue 50518:

    On a VMware SD-WAN Gateway where PKI is configured, if >6000 PKI tunnels attempt to connect to the Gateway, the tunnels may not all come up because inbound SAs do not get deleted.

    Note:

    Tunnels using pre-shared key (PSK) authentication do not have this issue.

  • Issue 52955: DHCP decline is not sent from Edge and DHCP rebinding is not restarted after DAD failure in Stateful DHCP.

    If DHCPv6 server allocates an address which is detected as duplicate by the kernel during a DAD check then the DHCPv6 client does not send a decline. This will lead to traffic dropping as the interface address will be marked as DAD check failed and will not be used. This will not lead to any traffic looping in the network but traffic blackholing will be seen.

    Workaround: There is no workaround for this Issue.

  • Issue 53219: After a VMware SD-WAN Hub Cluster rebalances, a few Spoke Edges may not have their RPF interface/IIF set properly.

    On the affected Spoke Edges, multicast traffic will be impacted. What happens is that after a cluster rebalance, some of the Spoke Edge fail to send a PIM join.

    Workaround: This issue will persist until the affected Spoke Edge has an Edge Service restart.

  • Issue 53934: In an enterprise where a VMware SD-WAN Hub Cluster is configured, if the primary Hub has Multihop BGP neighborships on the LAN side, the customer may experience traffic drops on a Spoke Edge when there is a LAN side failure or when BGP is not configured on all segments.

    In a Hub cluster, the primary Hub has Multihop BGP neighborship with a peer device to learn routes. If the physical interface on the Hub by which BGP neighborship is established, goes down, then BGP LAN routes may not become zero despite BGP view being empty. This may cause Hub Cluster rebalancing to not happen. The issue may also be observed when BGP is not configured for all segments and when there are one or more Multihop BGP neighborships.

    Workaround: Restart the Hub which had the LAN-side failure (or BGP not activated).

  • Issue 57210: Even when a VMware SD-WAN Edge is working normally and is able to reach the internet, the LED in the Local UI's Overview page shows as "Red".

    The Edge's Local UI determines the Edge's connectivity by whether it can resolve a well known name via Google's DNS resolver (8.8.8.8). If it cannot do so for any reason, then it thinks it is offline and shows the LED as red.

    Workaround: There is no workaround for this issue, except to ensure that DNS traffic to 8.8.8.8 can reach the destination and be resolved successfully.

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

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

    Workaround: There is no workaround for this issue outside of ensuring no more than one 1:1 NAT rule is configured with a particular Inside IP address.

  • Issue 65560: Traffic from a customer to PE (Provider Edge) device fails.

    BGP neighborship between a Partner Gateway and Provider Edge does not get established when tag-type is selected as "none" on the handoff configuration. This is because ctag, stag values get picked from /etc/config/gatewayd instead of the handoff configuration on the Orchestrator when tag-type is "none".

    Workaround: Update the ctag, stag values to 0 each under vrf_vlan->tag_info in /etc/config/ gatewayd. Do a vc_procmon restart.

  • Issue 67879: A Cloud Security Service (CSS) tunnel is deleted after a user changes a WAN Overlay setting from auto-detect to user-defined on a WAN interface setting.

    After saving the changes, the CSS tunnels do not come back up until the customer takes down and then puts back up the tunnel. Changing the WAN configuration will bring down the CSS tunnel and parse the CSS setup again. However, in some corner cases, the nvs_config>num_gre_links is 0 and the CSS tunnel fails to come up.

    Workaround: Deactivate the CSS setup, and then reactivate it and this will bring the CSS tunnel up.

  • Issue 68057: DHCPv6 release packet is not sent from the VMware SD-WAN Edge on the changing of a WAN interface address mode from DHCP stateful to static IPv6 address and the lease remains active till reaching its valid time.

    The DHCPv6 client possesses a lease which it does not release when the configuration change is done. The lease remains valid till its lifetime expires in the DHCPv6 server and is deleted.

    Workaround: There is no way of remediating this issue as the lease would remain active till valid lifetime.

  • Issue 68851: If a VMware SD-WAN Edge and VMware SD-WAN Gateway each have the same TCP syslog server configured, the TCP connection is not established from the Edge to the syslog server.

    If the Edge and Gateway each have the same TCP server and if the syslog packets from the Edge are routed via the Gateway, the syslog server sends a TCP reset to the Edge.

    Workaround: Send the syslog packets direct from the Edge instead of routing via a Gateway or configure a different syslog server for the Edge and Gateway.

  • Issue 81852: For a VMware SD-WAN Edge that is using a Zscaler type Cloud Security Service (CSS) which uses GRE tunnels that has turned on L7 Health Check, when that Edge is upgraded to Release 5.0.0, in some instances the customer may observe L7 Health Check errors.

    This is typically seen during software upgrade or during startup time. When L7 Health check for a CSS using GRE tunnels is turned on, error messages related to socket getaddress error may be seen. The observed error is intermittently seen, and not consistent. Because of this, L7 Health Check probe messages are not sent out.

    Workaround: Without the fix, to remediate the issue, a user needs to turn off and then turn back on the L7 Health Check configuration, and this feature would then work as expected.

  • Issue 82184: On a VMware SD-WAN Edge which is running Edge Release 5.0.0, when a traceroute or traceroute6 is run to the Edge's br-network IPv4/IPv6 address, the traceroute will not properly terminate when a UDP probe used.

    Traceroute or traceroute6 to the Edge's br-network IPv4/IPv6 address will not properly when Default Mode (in other words, UDP probe) is used.

    Workaround: Use -I option in traceroute and traceroute6 to use ICMP probe and then traceroute to br-network IPv4/IPv6 address will work as expected.

  • Issue 85402: For a customer enterprise using BGP with Partner Gateways configured, a user may obseve that some BGP neighborships are down and this causes customer traffic issues.

    If a customer has maximum-prefix configured on a router which has BGP peering with the Edge and Gateway, the BGP session may be dropped by the router.

    For example, if the router has BGP configured to only receive max 'n' number of prefixes, but the Edge and Gateway have more than 'n' number of prefixes to be advertised in the absence of any filters. Now if the BGP filter configuration is changed on the Orchestrator, even if the total number of prefixes allowed in the outbound direction is less than 'n', the issue will be encountered where more than 'n' prefixes are sent to the peer before any filters are applied. This causes the router to tear down the session.

    Workaround: If BGP goes down due to this issue (Maximum Number of Prefixes Reached), flap BGP on the peer using CLI (For FRR/Cisco, "neighbor x shut" followed by "no neighbor x shut"), and the BGP will produce only the desired number of prefixes advertised to the peer.

  • Issue 92421: When a public and private overlay are configured on the same Edge interface with different custom VLAN tags, there is a chance that the underlay routed traffic may get dropped.

    When a public and private overlay are configured on the same interface with different custom VLAN tags, the Edge may learn the ARP entries with the wrong VLAN tags, resulting in the traffic being dropped.

    Workaround: Avoid using this configuration. This issue is fixed on Release 5.4.0 and later.

  • Issue 98136: For customer enterprises using a Hub/Spoke topology where Dynamic Branch To Branch VPN is configured, client users behind a SD-WAN Spoke Edge may observe that some traffic has unexpected latency resulting from the traffic using a sub-optimal path.

    Spoke Edge traffic that experiences this issue uses a route that was initially a non-uplink route for a Hub Edge not included in the Profile the Spoke Edge was using. A Dynamic Branch-to-Branch VPN tunnel can be formed from the Spoke Edge to the Hub Edge because of traffic being sent towards some other unrelated prefix and in this instance the non-uplink route is installed in the Spoke Edge.

    As a result of this non-uplink route, all traffic towards this prefix starts going through the

    Hub Edge and the non-uplink route becomes uplink (community change to uplink community) but the non-uplink route installed previously is not revoked and the traffic takes the Hub Edge path as long as the Dynamic Branch-to-Branch VPN tunnel remains up.

    Workaround: Wait for the Dynamic Branch-to-Branch VPN tunnel to tear down, after which the uplink route will not be installed in the Spoke Edge when a new Dynamic Branch-to-Branch VPN tunnel is formed towards the Hub Edge.

  • Issue 110561: Dynamic tunnels may not come up between the same set of VMware SD-WAN Edges with bidirectional traffic when traffic stops and then restarts.

    Issue is observed in a test environment where there are 6000 dynamic tunnels with high bidirectional traffic being sent between the Edges. Even in lower scale testing at 1000 dynamic tunnels, not all the tunnels come up.

    Workaround: There is no workaround for this issue.

  • Issue 111085: When a VMware SD-WAN Edge's WAN link is configured with an IP address in the same network as the Edge's loopback IP, the Edge uses the MAC address of the WAN interface while responding to an ARP request for the Edge's loopback IP address.

    This can cause ARP spoof and results in the Management IP being deprecated and network disruptions as a result.

    Workaround: There is no workaround for this issue.

  • Issue 113877: For customers who configure BGP/GRE LAN, those using a TGW GRE will experience BGP flaps and traffic interruption on the TGW secondary tunnel in all segments when the BGP configuration for TGW GRE is modified on the Global segment.

    When customer changes a BGP configuration of TGW GRE on the global segment then the secondary tunnel in the global and other segments flap, leading to a BGP connection reset and reconvergence and traffic interruption. The BGP connection will form again, and traffic will restore.

    Workaround: There is no workaround for this issue.

  • Issue 117876: In a customer site using a High Availability topology, if a user activates or deactivates the Enhanced Firewall Services, a VMware SD-WAN HA Edge may experience multiple restarts.

    When Enhanced Firewall Services is activated or deactivated, only the Active Edge's Device Settings configuration is synchronized immediately with the Standby Edge, with the remainder of the configuration synchronization is only in response to a Standby Edge heartbeat. When the Active Edge is restarted to apply the latest configuration prior to receiving a heartbeat from the Standby Edge it will result in a configuration mismatch between the two HA Edges and they will undergo multiple restarts to complete the configuration synchronization.

    Workaround: The only workaround is to turn on or off Enhanced Firewall Services during a maintenance window for HA Edges.

  • Issue 125274: When a customer runs an SNMP walk, the loopback interface of the VMware SD-WAN Edge is not discovered.

    The Edge loopback interface is a unique interface category that the Edge does not classify as either WAN or LAN. As a result, the loopback interface is not in the allow list of interfaces to process for the snmp-request.

    Workaround: There is no workaround for this issue. The loopback interface status would have to be individually monitored through the Orchestrator UI.

  • Issue 130674: IPv6 remote routes may be missing if the only physical interface configured with IPv6 is disconnected during Edge boot up and only later reconnected.

    An Edge will not install any IPv6 remote routes when the only physical interface configured with IPv6 is not connected to the Edge while it is rebooting and then only later connected.

    Workaround: Enable IPv6 loopback, or use a switched interface assigned to a IPv6 VLAN.

  • Issue 130885: An OSPFv3 route tag may not be updated for an IPv6 external route.

     In some corner cases, OSPFv3 does not consider the tag updated by the neighbor for an external route if the update is received within very short interval.

    Workaround: Withdraw and re-advertise the external route from the OSPFv3 neighbor.

  • Issue 131674: ICMP traffic from a Spoke Edge using internet backhaul via a Hub Edge fails if the ICMP flow has to be steered from one link to a different one.

    ICMP traffic passing on one of two or more links is expected to be steered to a different link if the existing link goes down or is unusable per QoE.

    Workaround: There is no workaround for this issue.

  • Issue 132492: For a customer who has one or more Non SD-WAN Destinations via Edge configured and uses BGP, when no traffic is passing through the IPsec tunnels, the customer may observe that the tunnels are torn down and BGP routes flap.

    This issue is only seen when there is no traffic on the path from the NSD via Edge to the peer. The issue stems from a premature IKE Phase 1 rekey on the Edge and the peer sends multiple Dead Peer Detection (DPD) packets with an old cookie that the Edge does not acknowledge. This results in the peer side deleting both Phase 1 and Phase 2 IKE and tearing down the tunnels which also causes BGP flaps.

    Workaround: A user could set up a LAN side client to send a continuous ping to the NSD via Edge peer to prevent the scenario from arising.

  • Issue 133678: If a VMware SD-WAN Edge is configured for IPv4/IPv6 dual stack, the Edge may lose connectivity to the Orchestrator if the IPv4 link is down.

    This issue can occur if the Edge was activated with only an IPv4 link, and an IPv6 link is added only later to the device. At the time the Edge is activated, only the IPv4 Orchestrator address is written to the Edge that manages Orchestrator connectivity. Adding an IPv6 link later does not add the IPv6 address to the file and so if the IPv4 link is removed, the Edge loses connectivity to the Orchestrator.

    Workaround: An Edge activated with only an IPv4 link would need to keep at least one IPv4 WAN link connected even though the Edge is dual stack.

  • Issue 135827: For a customer site deployed with a High Availability topology, the customer may observe multiple HA failovers due to the site experiencing an active-active (split brain) condition.

    Under extreme load/scale environments where the flow, tunnel, and routes scale to the limits of a hardware Edge model in conjunction with aggressive route timers (OSPF = 3/12, BGP = 1/3), the HA Standby Edge can sometimes miss an HA heartbeat and be moved to an Active state. When the HA heartbeat is resumed it will report the HA_SPLIT_BRAIN_DETECTED event to the Orchestrator and the Standby Edge will restart to tie-break the HA split brain.

    Workaround: To mitigate the risk of an active-active panic, configure the HA failover time to a higher value.

  • Issue 135938: For an Edge configured with a routed LAN interface and a secondary IP address configured on the routed interface, traffic sent to the secondary IP address connected interface is NAT'd with the parent interface's IP address.

    Whether the user checks the NAT Direct Traffic option or not has not impact, as the traffic is sent out based on the NAT direct configuration of the parent interface.

    Workaround: There is no workaround beyond ensuring that the secondary IP address is configured with the expectation that the NAT Direct Traffic option is only applied at the parent level.

  • Issue 136336: For a customer who configures a Cloud Security Service (CSS) with a Zscaler type, return traffic from Zscaler may get dropped if the Edge has the Common Criteria Firewall enabled.

    The Edge would have a Business Policy rule to backhaul internet traffic via that Zscalar tunnel and in this case the return traffic is dropped due to a Reverse Path Forwarding (RPF) failure that occurs during the route lookup for the return traffic.

    Workaround: Do not use the Common Criteria Firewall feature while also using Zscaler as a CSS.

  • Issue 138023: For a customer using a Partner Gateway (PG), a PG-BGP session does not come up when the BGP local IP address and PG Handoff local IP address are from the same subnet.

    SD-WAN treats this scenario as two interfaces on a router from the same subnet, which is not supported and can lead to ARP related issues.

    Workaround: Change the configuration to avoid the above scenario.

  • Issue 139855: For a customer enterprise where a High Availability topology is used and the Edges are virtual (not hardware Edges), if a user changes any Edge device setting, the Edge may delete the default route.

    This issue is limited to sites where the virtual HA Edges use a unique MAC Address on the LAN interface and have routing configured on the LAN interface. In that scenario the default route via a route interface (WAN overlay) and LAN interface may be removed after any changes on the Configure > Edge > Device page, resulting in customer traffic disruption.

    Workaround: Perform a network service restart to repopulate the default routes.

  • Issue 140194: For a customer enterprise site deployed with an Enhanced High Availability topology where a PPPoE link is used on the Standby Edge interface, an SNMPWalk does not work properly for this site.

    SNMPWalk output is incomplete for interface related MIBs when there is a PPPoE interface on the Standby Edge in Enhanced HA.

    Workaround: None.

  • Issue 140785: An SD-WAN Edge configured with IPv4 and IPv6 loop back interfaces and their advertise flags enabled may experience a Dataplane Service Failure and restart to recover.

    Packet fragmentation from packets 1350 bytes and greater is triggering an exception with the Edge service if configured as above and causing a service failure.

    Workaround: There is no workaround for this issue.

  • Issue 141008: On the Diagnostics > Remote Diagnostics page of the Orchestrator UI, Traceroute using an IP/Hostname destination does not for IPv6 addresses.

    The result from an IPv6 Traceroute shows the destination alone, and intermediate hops do not display. IPv4 addresses work as expected.

    Workaround: There is no workaround for this issue.

  • Issue 141041: For a customer enterprise site deployed with a High Availability topology with VNFs installed, where the HA Edge pair or either Edge models 520/540 or 610, reachability to the Standby Edge's VNF from a LAN-connected client may fail.

    The Ethernet switch board on these Edge models drops ARP reply packets sent to a LAN client from a Standby Edge's VNF resulting in a loss of reachability.

    This issue was first observed for the 5.4.x Edge build and documented in 102583 of the 5.4.0 Release Notes. This ticket tracks the issue for 5.2.3.

    Workaround: There is no workaround for this issue.

  • Issue 141113: An SNMP walk may get timed out and fail to complete when the Edge has an interface configured for a PPPoE link which is stuck in a down state.

    This issue only occurs if the PPPoE link on the interface is never up, if the interface is up and goes down for some reason the SNMP walk will successfully complete.

    Workaround: Ensure that any configured PPPoE link is capable of coming up, in other words ensure the peer PPPoE server is enabled.

  • Issue 141273: For a customer enterprise site deployed with a High Availability topology, when HA is later deactivated, the virtual MAC addresses persist on the now standalone Edge ports.

    The virtual MAC addresses (VMAC) are programmed on the Active and Standby Edge when HA is activated to facilitate faster convergence during HA failover. However, when HA is deactivated on the Edge, the VMAC is still programmed on it. Also, if the Standby Edge is removed and also used as a separate standalone Edge, the result is duplicate MAC addresses and this leads to switch loop if both Edges (old Active and old Standby) are on the same broadcast Network.

    A user can confirm this issue is present because the virtual MAC address prefix always begins with F0:8E:db.

    Workaround: On an Edge without a fix for this issue the user can either force a factory reset on each standalone Edge to clear the port configuration, or the Support team can remove the /velocloud/ha/virtualmacs file from the Edge and reboot it.

  • Issue 143450: On a customer enterprise site configured with an Enhanced High Availability topology where Dynamic Branch to Branch VPN is also enabled, client users may observe extended traffic loss after an HA failover.

    The issue can be encountered if the Enhanced HA site also has a Business Policy rule configured which includes mandatory link steering. Combined with Dynamic Branch to Branch, this combination can result in a prolonged period of traffic disruption after an HA failover.

    Workaround: A customer can either remove the Business Policy rule with mandatory link steering entirely, or modify that rule to remove the mandatory link steering option.

  • Issue 143828: A customer may observe that an Edge has an unexpectedly high level of memory usage that may get sufficiently high to reach a critical level and trigger a defensive Edge service restart to recover the memory.

    One of the factors that contributes to this memory leak is extensive use of CLI commands on the Edge by either a Partner or Operator as part of troubleshooting or monitoring the Edge. These commands are accumulated and never cleared from the relevant Edge process. The use of Remote Diagnostics on the Orchestrator UI does not contribute to this issue.

    As with any Edge memory usage issue, entry level Edge models with lower RAM specifications (in other words, the Edge models 510, 610, 710, or 520) would be more likely to experience the issue, but it can happen on any Edge model with sufficiently high memory usage.

    Workaround: Extensive use of CLI commands on the Edge by either an Operator or Partner should be avoided, and if troubleshooting work is done, the customer should check the Edge's memory usage on the Edge > Monitor > System page.

  • Issue 145393: A customer enterprise site deployed with an Edge model 620, 640, or 680 where firewall logging is configured may observe that the Edge no longer stores new firewall or standard debugging logs.

    When this issue is encountered, a 6x0 Edge's eMMC storage experiences an excessive level of wear due to the high volume of writes and rewrites that can be triggered by enabling logging for firewall rules which are matched by a large number of new connections per second in a high traffic customer environment. This issue results in the Edge defensively moving the file partition which hosts logging to a read-only state, and no additional logs are stored.

    Workaround: If a customer has an Edge 620, 640, or 640 Edge model and is also using firewall logging, they should avoid enabling logging for firewall rules which can potentially match a large number of new connections in a high traffic environment. The excessive logging frequency that would result can cause undue wear on the Edge's storage and trigger this issue.

  • Issue 151654: A link may not come up on a VeloCloud Edge where both the Edge's Ethernet port and the peer port have auto-negotiation set to off.

    For the Edge port, auto-negotiation is set to off and the user has manually configured the speed and duplex of the port through the UI. The issue is the result of differing implementations of auto-negotiation between the Edge and the peer device.

    Workaround: On an Edge without a fix for this issue, the user should turn on autonegotiation on the Edge's Ethernet port.

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