IBM RackSwitch G8264CS Version 7.7.8.0 (Released December 2013) ** Changes since the 7.7.5.0 release ** Enhancements: None Changes: - A security vulnerability existed in the TLS protocol versions TLS1.0 and earlier, in that an attacker could potentially discover the TLS session key. To prevent this, a configurable CLI option was added to restrict the minimum allowable protocol version of TLS, from SSLv3 through TLS1.2. (CVE-2011-3389) Fixes: - A crash would occur when routing packets to an unreachable IPv6 gateway. (68081) - A crash would occur during TACACS+ authentication when receiving optional attributes (during the authorization stage). (68473) - With Layer-2 Failover configured, data traffic would momentarily be interrupted while transitioning from the active port to the standby port during a failover. (XB172186, XB222079) - The ACL logging feature would not report incoming packets that matched an ACL qualified by a TCP or UDP destination port. (XB208108) - Valid LLC frames received would erroneously be reported as ingress errors if they included a 802.1Q VLAN tag. (XB208414, XB227573) - A crash would occur if a data port was used to upload a file to an FTP server, if the file already existed on the server and had read-only access permissions. (XB209257) - A crash would occur if the traceroute command was executed with an IPv6 address specified, and no IPv6 management interfaces were configured. (XB215717) - Connecting to a Secure FTP server using a human-readable hostname would fail(would only work when an IP address was explicitly specified). (XB216488) - A crash would occur if a ping was issued to a random host name, and an IPv6 DNS server was unreachable or non-existent (XB216882) - A crash would occur during a second attempt to authenticate a user via an unreachable or non-existent LDAP server. (XB217674) - In a VRRP topology, when the Nessus security-scanning tool performed the "failed login" test via SSH, the VRRP process on the backup switch could fail to receive advertisement packets from the VRRP master within the specified threshold, leading to an oscillation between master and back-up states. (XB217716) - A crash would occur if a TFTP upload or download was attempted, and no IPv6 interfaces were configured. (XB218041) - The switch's Browser-based Interface (BBI) was vulnerable to attacks by Web scanning tools, potentially resulting in crashes. (XB218795) - FCoE connections could be lost when receiving FLOGI packets in rapid succession from servers hosting a large number of FCoE-enabled Virtual Machines. (XB220347) - Invalid TCP packets (e.g., having both SYN and FIN flags set) received by the switch would not be discarded, resulting in a potential security vulnerability. (XB220985) - A crash would occur when performing an SNMP Get operation upon index 128 of the stpInfoPortTable object. (XB249428) - An over-temperature could occur, leading to a loss of FCoE connections and traffic. (XB255903) ======================================================================================== 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)