FIRMWARE CHANGE HISTORY ----------------------- IBM RackSwitch G8264CS Version 7.7.15.0 (Released August 2014) ** Changes since the 7.7.10.0 release ** Enhancements: None Changes: - Internal debug usernames have been removed from the firmware to prevent potential backdoor access. (XB282666) Fixes: None ================================================================================ IBM RackSwitch G8264CS Version 7.7.10.0 (Released June 2014) ** Changes since the 7.7.5.0 release ** Enhancements: None Changes: - Added the Machine Type Model 7120-64F to identify Lenovo as a distribution channel. (XB275997) - A security vulnerability existed in the OpenSSL Protocol that is used in IBM System Networking Ethernet Switches. (CVE-2014-0224) Fixes: None ======================================================================================== IBM RackSwitch G8264CS Version 7.7.5.0 (Released August 2013) ** Changes since the 7.7.3.0 release ** Enhancements: None Changes: - Dynamic link aggregation (LACP) ports that are not able to converge with peer ports will now result in a link-down state. This will occur when ports configured as members of an LACP trunk are connected to non-LACP ports. This is expected behavior. When connecting different IBMNOS products using LACP ports, it is recommended to install complimentary firmware versions (e.g., 7.7.5) on each device to ensure matching LACP behavior. - Added support for a new front-to-back airflow power supplies (part numbers 94Y8104 and 94Y8105). Fixes: - Inefficiencies in the SNMP-processing code could result in high CPU utilization, SNMP client time-outs, protocol flaps, or a switch reset by the Hardware Watchdog. (66769, 70649) - User-configured ACL Deny rules were not being respected for packets with a Layer-4 (TCP) port of 22 or 23 (i.e., SSH and Telnet, respectively). (69126 / XB202484) - A prolonged period of high CPU utilization can lead to protocol-thread starvation. In one such case, LACP PDUs were not being sent by the CPU, leading to the break down of the LACP trunk forming the ISL in a vLAG topology. The ISL trunk ports that had previously been in the STP Discarding state would then errantly go into the Forwarding state, resulting in flooding of STP BPDUs into the network, and the inevitable network loop. (70887) - A hang of the Switch's I2C bus could occur, leading to a reset of the Switch by the hardware watchdog. (71721) - The SNMP dot1qVlanCurrentEntry OID was not being populated, resulting in SNMP Walks being stuck indefinitely at that point. (71785) - Disabling LACP (from the peer device) on a member port of an LACP trunk that also has STP disabled would result in the port being errantly displayed as FORWARDING in the output of the "show spanning-tree stp" command (and via the BBI), when in fact the port would be in the BLOCKING state (as designed). (71805, 71822) - Inefficiencies in the periodic polling of I2C devices would result in a persistent high CPU-utilization condition. (71814) - Deleting the LACP key (from the peer device) on a member port of an LACP trunk that also has STP disabled would result in the port errantly going into the FORWARDING state. (71841) - With STP in PVRST mode and with a high active-port/STG product, a memory leak could occur while processing BPDUs (this was demonstrable with 47 ports active and more than 127 STGs configured per port). Over time, the memory leak could lead to a reset of the switch by the Memory Monitor. (71844) - A crash would occur when issuing the "show ufp info vport" command without explicitly specifying a vport number. (71951) - A watchdog timeout could occur if an IGMPv3 Report packet was received with the invalid source-IP address of 0.0.0.0. (71749) - Receiving multicast packets on server-facing ports at a high rate could cause FCoE sessions to go down momentarily. (XB148188) - Attempting to set port speed via the CMM would fail. (XB171317) - If the CMMs had "Failover on Physical Network Link" enabled (default), and the network link of the Active CMM went down, ports INTB1 and INTB2 could get disabled when the Standby CMM became active. (XB172285) - An IP address could not simultaneously be configured as a global DHCP server address, and a broadcast-domain DHCP server address. (XB172381) - A crash would occur while handling an SNMP “Get” Request for the Object that contains UFP information pertaining the switch (OID 1.0.8802.1.1.2.1.4.1.1.12.2700.65.4). (XB194463, XB202919) - A crash could occur if an FCoE-related CLI command was issued while the external management port was being flooded with packets. (XB199890) - If in Stacking mode, the switch would no longer receive time-sync updates from NTP servers over IPv6 interfaces after a CMM failover. (XB200147) - NTPv3 authentication information was being added to outgoing NTP Client Requests, even when authentication was disabled on the Switch. The consequence was that NTP servers that do not support authentication would discard the requests (i.e,, not respond to the Client Requests). (XB204541) - A crash could occur while handling an HTTPS request if the connection to the client was suddenly terminated while handling the transaction. (XB205895) - If the switch's Hostname was used to access the switch via BBI (i.e., relying on DNS instead of inputting the raw IP address), attempting to perform an image upgrade would result in redirection to a blank page. (XB206876)