HP Tru64 UNIX and TruCluster Server Version 5.1B-6 Patch Summary and Release Notes

# sysman ipsec
Once you have started SysMan, you will need to modify the configuration of each IPsec and IKE
connection to add the identity of the remote hosts that are allowed to connect.
You enter this information on the third dialog box you see during the connection configuration
wizard; the dialog box is titled “Manage IPsec: Add/Modify Connection: IKE Proposal.” Although
you can leave the “Restrict To The Following Remote IDs” list empty, doing so will mean that
any identity given to the local machine by the remote hosts will be considered valid as long as
they send the correct certificate or preshared key.
Potential NFS Duplicate Request Cache Scalability Limitation with High Loads and Uncharacteristic
File Access Behavior on Clustered NFS Servers
Repeated simultaneous overwriting of many files can cause retransmitted writes to be processed
after recent writes of a file to the same location. This problem occurs more often on systems
configured with a LAN cluster interconnect than on those configured with Memory Channel.
This behavior is inherent in the "stateless" design of NFS. Although the behavior has been
mitigated via a "duplicate request cache" that replays old replies instead of reexecuting
retransmitted requests, extremely heavy loads on large systems can overwhelm the cache when
requests are stalled. Customers are unlikely to see problems because applications rarely rewrite
files almost immediately.
If the problem occurs, the NFS server displays the following message several times a minute on
the system console, indicating that the NFS server is being overwhelmed with requests :
"NFS server xxx not responding"
When an "overwhelmed duplicate request cache" condition has occurred, the NFS client will
display multiple occurrences of either of the following messages:
NFS3 server xxx not responding still trying
NFS3 server xxx ok
NFS2 server xxx not responding still trying
NFS2 server xxx ok
This indicates that the client is observing transient unresponsive periods at the server. This is
the only notification that the client will display if the server's duplicate request cache becomes
overwhelmed. When the client detects this behavior, it increases the retransmission interval until
it gets a response from the server. This behavior is generally indistinguishable from the server
going up and down, except that the messages are displayed with such frequency that the server
system/member cannot have gone down and then come back up in that short an interval.
You can minimize the likelihood of these problems as follows:
• Avoid congestion on your LAN and cluster interconnect.
• Ensure your servers have enough excess capacity to respond quickly to NFS requests that
modify the file system (writes, file and directory creation, and so forth.)
• Increase the size of the server's duplicate request cache when the nfsstat command shows
a large number of retransmits to clients. For instructions on increasing the size of the cache,
see “Tuning the NFS Server Duplicate Request Cache”.
You can monitor the number of NFS retransmissions using the nfsstat -c command. The
retrans field indicates the number of retransmissions. A retransmission rate higher than 2%
indicates a potential problem.
The following example shows the output from the nfstat -c command. The retransmission
fields are marked with asterisks (*). This example is of a client workstation in a typical
environment.
% nfsstat -c
Client rpc:
52 Tru64 UNIX Patches