Loading...
Loading...
Intermittent VLTi instability has been reported, where one switch within a VLT pair unexpectedly loses communication or visibility of its peer, even though the physical interconnect remains operational. The nature and frequency of the symptoms may differ across deployments, depending on traffic characteristics, configuration, and operating conditions. The following behaviors have been observed during customer escalations and engineering investigations: Intermittent VLTi instability or failure. Traffic loss or forwarding disruption. Loss of peer visibility between VLT switches despite the physical interconnect remaining operational. Split-brain conditions within the VLT domain. Error-Correcting Code (ECC) events. MMU faults & RDB stuck conditions. These symptoms may occur either individually or in combination. Due to their intermittent and inconsistent nature, reliably reproducing the issue across different environments has been challenging.
The investigation has identified a Hardware-level defect within the chipset ASIC, associated with the use of Egress true mirroring. According to the vendor's findings, continued use of this functionality may expose affected systems to the reported behavior. The defect is present across the relevant hardware revisions of the chipset.
If the symptoms described in this advisory are encountered, the following recovery steps are recommended: Identify the affected VLT pair and determine which switch is exhibiting the reported behavior. Examine system logs and diagnostic information for relevant indicators, including VLTi failures, traffic disruption, ECC events, MMU faults, and RDB stuck conditions. Where the observed symptoms align with the behavior described in this advisory, reboot the affected switch in accordance with the applicable operational procedures and change-management requirements. Once the switch has recovered, verify VLT peer synchronization, inter-switch connectivity, and normal traffic forwarding. Important: A switch reboot is a recovery measure and does not address or eliminate the underlying hardware defect. Although it may restore normal operation, the issue may re-occur if the associated triggering conditions remain present. To minimize exposure to the identified hardware defect, Dell recommends reviewing the mirroring configurations deployed on affected platforms. Where operationally and functionally feasible, the following alternatives should be evaluated: 1. Disable Egress True Mirroring Where egress true mirroring is not an essential operational requirement, disabling this functionality is the primary recommended mitigation. 2. Evaluate Ingress Mirroring Ingress mirroring may be considered as an alternative where it meets the required network monitoring, traffic analysis, and visibility requirements. 3. Evaluate FP-Based Mirroring FP-based mirroring may also be considered where supported by the platform and suitable for the intended monitoring requirements. Important considerations: Ingress mirroring and FP-based mirroring may have functional differences compared with egress true mirroring. Customers should assess the functional and operational suitability of these alternatives within their specific network environments before making configuration changes. The effectiveness and suitability of any mitigation may depend on individual deployment and configuration. Alternative Platform Considerations For customers whose network monitoring requirements necessitate egress true mirroring, and where the alternative mirroring methods described above do not meet their operational needs, Dell recommends engaging with the Dell Sales team to evaluate alternative platform options. Such alternatives should be assessed to ensure they meet the required functional, architectural, and deployment requirements without relying on the affected chipset.
Click on a version to see all relevant bugs