Sun Storage 5210 NAS Appliance
 
Sun Storage 5220 NAS Appliance
 
Sun Storage 5310 NAS Appliance
 
Sun Storage 5320 NAS Gateway/Cluster System
 
Sun Storage 5320 NAS Appliance
 
Sun Storage 5310 NAS Gateway System
 

GCS>Sun Microsystems>Storage - Disk>Network Attached Storage
 

Symptoms:

• Network issues
• Troubleshooting

Purpose/scope:

When troubleshooting network related issues on the Sun StorageTek[TM] 5000 series NAS, it is sometimes necessary to examine the specifiics of the network
communication between other systems and the NAS.

This procedure details how to collect this data.

This document with detail the following steps:

• Select the systems to capture data from.
• Load the packet capture tool and configure options.
• Reproduce the network event and capture it.
• List client systems and test conditions.
• Send the test data and capture output.

Step #1 -- Select the clients to capture data from:

The purpose of this step is to create a filter to limit the number of packets captured. This serves two purposes. First, it filters out data that is not pertinent to the issue, so that the Engineer analyzing the data can do so more effectively. Second, it protects against running into the packet limitation described above, which could cause the targeted network event to be missed.

In many cases, it is desirable to collect multiple traces, usually to provide data to compare against a working configuration. For example, if a particular operation works correctly from a Solaris client, but not from a Linux client, capture both and note the differences.

Include Based Filter:

In a case where the systems required to reproduce the issue are easily identified, an include based filter is best. Identify the systems involved in the communication, and determine which direction the traffic should be captured.

Here are a few examples:

Failed attempt to join a Windows domain - Capture traffic between the NAS and the domain controller only.

Failed NIS+ authentication - Capture traffic between a test client and the NAS, and between the NAS and the NIS+ server.

Windows client fails to map a share, or slow copy of a small file - Capture traffic between a test client and the NAS, and between the NAS and the Windows Domain controller.

Another important consideration is that you must ensure that none of the systems involved in the test is generating traffic to the NAS not related to the issue. For this reason, never use the client system that is being used to administer the NAS as part of the test.

Exclude Based Filter:

For cases where the systems involved in the capture are not easily identified, or traffic needs to be captured from more than four pairs of systems, an exclude based filter is needed. Examples of cases that could require this sort of treatment are as follows: an intermittent failure to mount, an intermittent timeout issue, a malformed packet from an unknown source that causes a panic or hang.

In this case, the first line of your filter will be NAS IP <--> any, which is all traffic to and from the NAS. The other entries will used to exclude traffic. One of these will be the system used to administer the NAS and run the packet capture console, other exclusions could be the backup server, NFS servers when working a CIFS issue, etc.

NOTE: On a switched network, the NAS will not be able to capture point to point traffic between other systems. If this is necessary, e.g. comparing NAS behavior to a Windows server, a client-based packet capture utility must be used.

Step #2 -- Load the packet capture tool and configure options.

1. Use telnet, ssh or the system console to connect to the NAS.
2. If prompted with " connect to (for list) [menu]", enter 'admin', otherwise, simply enter the password.
3. At the command line, load the network trace utility by entering "load netm".
4. Invoke the menu by entering "menu" at the CLI.
5. Using the spacebar, scroll the right hand window until "Packet Capture" is visible under the "Extensions" section in the right hand column of the menu.
6. Select "Packet Capture" by entering the corresponding letter.
7. The NAS Packet Capture Configuration screen is then displayed. Configure the packet capture as follows:

Enter "1", Edit Fields, and enter the following data:

Capture File: Provide a full path including volume and a new filename for the capture file, e.g. /vol1/datacollection/trace1.cap.

Frame size: Unless specifically instructed, leave this at the default of "0", which will capture entire frames.

IP Packet Filter: Enter "Y", Yes.

Filter lines: Enter your selections from step #1 by IP address. To capture all traffic to and/or from an address, use the ANY parameter. To collect only incoming or outgoing traffic, use the direction field. Unless specifically instructed, leave the port setting at the default of "0". At a minimum, in almost every case, you must include NAS IP <-> ANY, and exclude the telnet or ssh client.

Dump Enable: Enter "Y", Yes.

NOTE: For a NAS with multiple active network interfaces, each must be included separately.

Step #3 -- Reproduce the network event and capture it:

At this point, the configuration is done, and all that remains is to start the capture. Ensure that what you wish to capture is ready to go, and enter "7", Start Capturing.

Reproduce the event to be captured as soon as possible after starting the trace. Ensure that this is done from the very beginning. For example, for a client issue, start with the client completely disconnected from the NAS, and preferably logged out.

After the symptom has been reproduced, return to the NAS console, telnet or ssh session and enter "7", Stop & Save. For multiple attempts, or for comparing a successful operation to a failed operation, use separate traces for each.

Step #4 -- List client systems and test conditions:

An important and often neglected step is to report exactly what was done in each capture. Timelines and IP addresses are the most important. For a trace of a particular client experiencing slow access, you might record the following in a text file:

 IP addresses: 

 test client #1 - CLI1 192.168.2.2
test client #2 - CLI2 192.168.2.3
NAS - SERVER1 192.168.2.20
Domain Controller ADS3 192.168.2.40.

 Trace CIFS01.cap shows client CLI1 attempted to open share X1 from SERVER1 about 10 seconds after the trace started, there was a 40 second delay, and then a "RTFM0105 - directory read error" message was returned by the client.

 Trace CIFS02 shows client CLI2 successfully openingconnecting to share X1 within 5 seconds.''

Step #5 -- Send the capture output and test data.

Add the above captures and description files to a single file, name the file according to the company name and/or the case number. Unless otherwise instructed, send it to ftp://supportfiles.sun.com/cores. Advise the Engineer you are working with of the file name.

The Knowledge Work Queue for this article is KNO-STO-NAS

The packet data is written in Network Monitor 2.0 format. The most easily available tool to view the captured data is the open source utility Ethereal. Some training is required to be able to understand the output, but you can generally tell from the number and type of packets captured if the trace was successful.

Download ethereal at http://ethereal.com. There are versions for various operating systems.

This solution has no attachment