HP Virtual Connect Version 3.18 Release Notes

Resolved issues 10
Resolved issues
The following issues have been resolved in the VC 3.18 release:
• Resolved an issue where a Virtual Connect domain could experience a network outage when a VC
Ethernet module experienced one of the following:
o Power cycle (Off/On) from the Onboard Administrator
o Reset/reboot from the Onboard Administrator
o Removal/replacement in the interconnect bay
o Power cycle of the entire enclosure
This issue applied to domains configured as follows:
o Virtual Connect 1/10Gb Ethernet Modules—More than 55 networks
o Virtual Connect 1/10Gb-F Ethernet Modules—More than 55 networks
o Virtual Connect Flex-10 10Gb Ethernet Modules—More than 70 networks
o Virtual Connect FlexFabric 10Gb/24-port Modules—More than 70 networks
The following issues have been resolved in the VC 3.17 release:
• Resolved an issue where the primary VC module could not communicate with other modules due to an
implementation problem in the reverse DNS lookup support function when DNS was enabled in the VC
infrastructure. With VC 3.15, enabling DNS in the EBIPA settings of the OA resulted in the primary VC
module not communicating with other Ethernet modules in the domain due to its inability to perform a
DNS reverse lookup of the IP address. However, if DNS was not configured in the EBIPA settings of the
OA, the VC modules did not exhibit this behavior because they did not need to perform the reverse
lookup. VC release 3.17 resolves this implementation problem in the DNS reverse lookup function.
• Resolved an issue where the VCM GUI was using HTTP instead of HTTPS. Some VCM GUI pages were
using the HTTP protocol instead of HTTPS, which required an open, unsecure HTTP port 80 in the data
center firewall. The VCM GUI was changed to utilize the secure HTTPS port 443.
• Resolved an issue where changes in the SNMP configuration caused an outage. When two or more
subsequent changes to the SNMP configuration were processed by VC Manager, they were processed
sequentially. If multiple changes were performed in a relatively small window of time (under 20
seconds), the first change was not fully synchronized with all the modules in the domain when a second
change to the SNMP configuration was processed by VCM. This caused a timing/race condition with
the SNMP configuration changes, resulting in the VC modules getting out of sync and causing the
stacking links between modules and enclosures to be reset until the domain fully synchronized. The
potential network outage was up to 2 minutes.
• Resolved an issue where updating gen numbers while creating or assigning a profile caused a
NO-COMM state. During VC server profile creation or assignment performed by VCEM and VCM
(3.00 or later) as a one-step operation, VCM attempted to synchronize the configuration information
across all of the modules in the domain. If the domain was a multi-enclosure domain and the enclosure
that was not getting the profile assigned was in a NO-COMM state, the configuration synchronization
failed when VCM was not able to communicate with that enclosure. Stacking links became
disconnected due to the out of sync configuration, which caused an interruption of Ethernet traffic