After upgrading appliance to 2.6.0.2 , backups fail intermittantly with error 24 and 14

We have seen customers who are experiencing this issue as well. In several of our cases we made the changes below and the issue immediately went away. 

Symptoms:

Network related errors/status code 14, 24, 40, and/or 42 are occuring in large numbers on Symantec NetBackup Appliances running 2.6.0.1, 2.6.0.2, or 2.6.0.3 code. 

Cause:

Symantec attempted to tune the TCP stack on the appliances in the 2.6.0.x and one of the settings changed, the net.ipv4.tcp_timestamps kernel setting, is resulting in these errors.  In prior versions of the appliances, 2.5.x, this setting had been a value of 1 but in the 2.6.0.x code this was changed to 0 (zero). 

Resolution:

1. Using Putty, another SSH utility, or via the IPMI/remote console connection, log into the appliance as the admin user and become root in the maintenance mode.

    A.  Go to the Main Menu->Support->Maintenance option and enter the maintenance password.

    B.  run "/opt/Symantec/scspagent/IPS/sisipsoverride.sh" to temporarily override the security policy.  This should take the same maintenance password as entered above.

    C.  type "elevate" to become root

2. Confirm the current setting is equal to zero by running

    sysctl -a | grep tcp_timestamps

3. As the root user, make a backup copy of the file to edit:

    cp "/etc/sysctl.conf  /etc/sysctl.conf.tcptimestampsoff"

4. Then if comfortable using vi to edit files run "vi /etc/sysctl.conf" and change the line that reads: 

        net.ipv4.tcp_timestamps = 0

        To instead read:

        net.ipv4.tcp_timestamps = 1

        Save the file using either ESC + :wq or ESC + Z + Z       *without entering the plus sign

    Else run from the command line

        sed -i /etc/sysctl.conf -e 's/^net\.ipv4\.tcp_timestamps =.*/net\.ipv4\.tcp_timestamps = 1/'

5. Verify the tcp_timestamps now equals 1 in the file by running

    grep timestamps /etc/sysctl.conf

6. Run "sysctl -p" at the command line.

     Note:  This change does not require a reboot.

7. Confirm the setting change by running the below again

    sysctl -a | grep tcp_timestamps

Note:  If after making the above change there are still jobs that end with a status 14 or 24 make sure the TCP Chimney setting is disable on the clients experiencing the errors.  This can be done on Windows 2008 and greater servers by running "netsh int tcp set global chimney=disabled" from an elevated command prompt; this also does not require a reboot.  There can also be other reasons a client gets a status 24 error for example because of firewalls or virus scanners but this KB article does not cover those troubleshooting steps.