README VERSION : 1.1 README CREATION DATE : 2012-09-20 PATCH-ID : 5.1.133.000 PATCH NAME : VRTSllt 5.1 SP1RP3 BASE PACKAGE NAME : Veritas Low Latency Transport by Symantec BASE PACKAGE VERSION : VRTSllt 5.1SP1 SUPERSEDED PATCHES : NONE REQUIRED PATCHES : NONE INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : rhel5_x86_64,rhel6_x86_64,sles10_x86_64,sles11_x86_64 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : CORE PATCH CRITICALITY : OPTIONAL HAS KERNEL COMPONENT : YES ID : NONE REBOOT REQUIRED : NO PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer the release notes for installation instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer the release notes for un-installation instructions. SPECIAL INSTALL INSTRUCTIONS: ----------------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- 2818222 (2804891) lltconfig on boot up core dump and unable to send packets using sendto() 2818573 (2818567) LLT ARP flood issue. SUMMARY OF KNOWN ISSUES: ----------------------------------------- KNOWN ISSUES : -------------- FIXED INCIDENTS: ---------------- PATCH ID:5.1.133.000 * INCIDENT NO:2818222 TRACKING ID:2804891 SYMPTOM: When you configure the Low Latency Transport (LLT) module in the verbose mode, an incorrect error message may appear on the console with the message ID V-14-2-15300. LLT then encounters a segmentation fault, and the I18N module dumps a core file. DESCRIPTION: This behaviour occurs due to a buffer allocation failure during the sendto() system call. The call fails and returns the error code ENOBUF. The lltconfig utility tries to print an error message indicating the same. An argument type mismatch occurs between the LLT and I18N modules, which in turn affects the printing of the error message. This mismatch further leads to a segmentation fault, and the I18N module then dumps a core file. RESOLUTION: Symantec has introduced, in the LLT code, a new message related to the sendto() system call failure. This fixes the argument mismatch between the LLT and I18N modules. * INCIDENT NO:2818573 TRACKING ID:2818567 SYMPTOM: During Low Latency Transport (LLT) configuration, an internal check for duplicate cluster IDs may lead to either a private network slowdown, or panic in the Veritas Cluster Server (VCS) cluster. DESCRIPTION: During LLT configuration, LLT broadcasts a packet to detect duplicate cluster IDs, if any. In some cases, LLT may broadcast multiple packets in quick succession. This may slow down the private network (cluster network). This irregular behavior usually occurs on Linux systems due to the Linux poll() system call functionality. In other cases, LLT broadcasts a single packet to detect duplicate cluster IDs. However, the packet may not reach the desired node, especially if you configure LLT soon after a system reboot. As a result, a duplicate cluster ID may go undetected. When the Group Atomic Broadcast module (GAB) comes online, the duplicate cluster ID case leads to panic in the cluster. RESOLUTION: Symantec has modified LLT to generate multiple broadcast packets to detect duplicate cluster IDs, during LLT configuration. As a result, if one packet is lost, the next packet may detect a duplicate cluster ID, if any. To prevent the packets from flooding the private network, LLT broadcasts only one packet per second on each private link. INCIDENTS FROM OLD PATCHES: --------------------------- Patch Id::5.1.132.000 * Incident no::2405391 Tracking ID ::2405387 Symptom::When the Low Latency Transit (LLT) module starts up, the 'lltconfig' command may fail to detect a duplicate cluster ID. Description::When LLT starts up, then the underlying code tries to determine whether the cluster ID that you specified is already in use by another running cluster. If yes, then the command fails and prevents panic in the future. In some cases, this check fails. Resolution::Symantec has modified the LLT code to ensure that duplicate cluster IDs are detected. * Incident no::2439895 Tracking ID ::2434732 Symptom::When the Low Latency Transport (LLT) module starts, the 'lltconfig' command fails and an error message appears. For example, the following error message: ----------------- Starting LLT... LLT lltconfig ERROR V-14-2-15245 cluster id 345 is already being used by nid 0 and has the address - 00:03:BA:CB:F6:D2 LLT lltconfig ERROR V-14-2-15664 LLT could not configure any link ---------------- Where the node with nid 0 is part of the same cluster. Description::When you run the 'lltconfig' command in a cluster, the underlying code tries to determine if the cluster ID that you specified is already in use by another running cluster. If yes, then the command fails and prevents panic in the future. However, in the present case, the code incorrectly detects the peer node to be part of a duplicate cluster. This is due to the unexpected behavior of certain NIC drivers that add a few extra bytes at the end of every packet. The 'lltconfig' command fails to handle these extra bytes, and incorrectly displays the error message. Resolution::Symantec has modified the code for the 'lltconfig' command to truncate the extra bytes received along with LLT packets. * Incident no::2477372 Tracking ID ::2251045 Symptom::A user may witness excessive CPU usage in the 'lltd' process of the Low Latency Transport (LLT) module. Description::During packet transmission, LLT on a receiving node receives packets in the interrupt context, and queues them in separate queues for every port. The 'lltd' process delivers these queued packets to LLT clients by using any one of the available 'lltd' threads. During heavy packet traffic, more than one thread may attempt to serve a single port. Repeated attempts by various threads to serve a port that is already served by another thread lead to high CPU consumption. Resolution::Symantec has modified the LLT code to prevent LLT from invoking multiple 'lltd' threads for a given port.