toasters

toasters@lists.teaparty.net

13531 discussions

DLT recommendations
by Ethan Torretta 15 Mar '00

15 Mar '00

I need to buy a DLT device to backup a single F760 in an IS environment. The DLT7000 devices I've found, though, are single-ended. Does anyone have a favorite DLT7000 differential single- or multi-tape device? I've seen people have good luck with minilibraries, but that's an unnecessary expense in this case. I'm also curious about the DLT8000, as I'm buying a new drive anyway. Can they be set to be compatible with a filer? ejt

3 2

NetApp Reseller
by TTSG 15 Mar '00

15 Mar '00

Hi, Can anyone suggest a good NetApp reseller? (In the North East is extra points, able to ship to Germany for even more extra points) (New or used) Also, wondering what the general availability/delivery of one is... Private replies please. Tuc/TTSG

1 0

RE: Incremental backup of snapshots
by Anders Ljungberg S (QDT) 15 Mar '00

15 Mar '00

Hi! I think your problem is the way Legato is handling archive bits in NT. On the readonly snapshot area archive bits cant be reseted. On the NT frontend set the variable NSR_AVIODE_ARCHIVE to YES ( i think ). This will take archive bits out of play and you'll be using mtime. Unfortunally NT is'nt always that consekvent about modifying mtime. Good Luck Anders Ljungberg -----Original Message----- From: Christopher Algar [mailto:christopher.algar@s1.com] Sent: Tuesday, March 14, 2000 5:02 PM To: toasters Subject: Incremental backup of snapshots Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

RE: Incremental backup of snapshots
by Muhlestein, Mark 14 Mar '00

14 Mar '00

Snapshots are read only. That means the backup app can't clear the DOS archive bit. It sounds like the solstice backup app is using the archive bit. If they were using the times on the files it would work. Incremental mode should work on the live filesystem. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Christopher Algar [mailto:christopher.algar@s1.com] Sent: Tuesday, March 14, 2000 9:02 AM To: toasters Subject: Incremental backup of snapshots Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

Incremental backup of snapshots
by Christopher Algar 14 Mar '00

14 Mar '00

Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

SQL Server 7 and I/O error 59
by Jack Verdirame 14 Mar '00

14 Mar '00

Hello, We are running into an issue with the TCP/IP stack on an NT SQL Server machine over multi-gigabit ports. We have tried eliminating ports, reconfiguring and the error never seems to go away. We have not seemed to isolate the problem other then it seems to be the NT machine. We see no errors in the etc/messages and the interfaces seems to be running flawlessly (246 million packets and only 10 errors, 27 CRC's). We have seen only a few CP to CP but never when the problem occurs. We currently are simulating approx 20 - 40 meg of traffic over 2 gig cards using the test software that comes with SQL server 7. It is built on the traffic simulator and load generator IOMeter. The filer seems to be running great - 11,000 + ops per second without a problem. Any ideas or things to look for would be helpful. I have found some problems with NT and the net use command and found a service pack but it was for terminal server. The error was an I/O error 59 problem with tearing down multiple TCP sessions over UNC path mapped file transfers. Thanks for your time, Jack Verdirame www.zerowait.com www.loadbalancing.net Las Vegas: 302.559.5962 Corp: 302.266.9408

1 0

problem in .profile
by bhaskar.g＠philips.com 13 Mar '00

13 Mar '00

Hi, We started creating user accounts with their home folders on the filer 720. But the new users are unable to set the environment as they login. The problem is the terminal doesnot read the .profile in the home folder though .profile exists and the user owns it. But when we remsh to some other system or the same system the .profile is working. When the user logs in from the Xterm this problem occurs. Please let us know what is the problem. regards Bhaskar G Systems Engineer, Philips Semiconductors, #3, Sterling Square,Madras Bank Road, Off St Mark's Road,BANGALORE-560 001. Voice : +91 80 222 9200 Ext 5060 Fax: +91 80 2229700

2 1

None
by bhaskar.g＠philips.com 13 Mar '00

13 Mar '00

Hi all, Please can any one tell me how to solve the following problem. sunitha@detroit$ ll total 336 -rwxrwxr-x 1 sunitha WEB 1936 Jan 28 10:17 Glite_To_do27thJan.html -rwxrwxr-x 1 sunitha WEB 5945 Feb 11 16:49 Glite_to10Feb.html -rwxrwxr-x 1 sunitha WEB 20992 Mar 1 11:51 Glite_to24thFeb.xls -rwxrwxr-x 1 sunitha WEB 30068 Feb 28 17:48 estimation_back.html drwxrwxr-x 2 sunitha WEB 4096 Mar 7 14:42 images -rwxrwxr-x 1 sunitha WEB 690 Mar 2 16:52 index.html -rwxrwxr-x 1 sunitha WEB 418 Feb 5 16:03 innovteam.html -rwxrwxr-x 1 sunitha WEB 2466 Mar 7 14:45 right_innov.html sunitha@detroit$ cp -p right_innov.html /home/www/htdocs/groups/innov/. cp: utime failed right_innov.html: Not owner sunitha@detroit$ regards Bhaskar G Systems Engineer, Philips Semiconductors, #3, Sterling Square,Madras Bank Road, Off St Mark's Road,BANGALORE-560 001. Voice : +91 80 222 9200 Ext 5060 Fax: +91 80 2229700

1 0

Solaris NFSv3 read-ahead kernel parameter...
by Eyal Traitel 13 Mar '00

13 Mar '00

Have someone played with / checked / benchmarked with this setting in Solaris kernel ? I'm speaking about nfs3_nra .... Eyal.

2 1

Re: filter-side packet tracing.
by Guy Harris 11 Mar '00

11 Mar '00

To clear up some confusion, "captrans" isn't a "Solaris command" in the sense of something that comes with Solaris - it happens to be installed on the Solaris/SPARC machines inside NetApp, but it's in "/usr/local/bin", not "/usr/bin" or "/usr/sbin". It's built atop a version of libpcap modified to be able to read non-libpcap files as well as libpcap files. There's probably no reason why we couldn't make available captrans source and the changes to libpcap... ...but, as per my other message, I'm not really interested in captrans, or those changes to libpcap, any more - recent distributions of Ethereal: http://ethereal.zing.org/ comes with a better capture-conversion program, editcap, which reads and writes more capture file formats than captrans, and which has more people developing stuff for it than just me (and, as indicated, I'm not doing any more stuff with captrans or the modified libpcap; my capture file reader and writer efforts are directed towards the Wiretap library that Ethereal, Tethereal, and editcap use). So, whilst we *could* share those utilities, I'd rather people download Ethereal and build and install that instead; if anybody asks for new features in captrans, or new capture file types to read or write, or finds a bug in captrans or in the capture file reading code in the modified libpcap, I will probably check to see whether Wiretap and editcap do what they want and, if not, try to make them do so and point the asker at editcap instead. (Besides, as noted, if you download Ethereal and build and install it, you get, in addition to a capture-file-translation program, a really nice GUI packet capture and analysis program, and a really nice tty-based packet capture and analysis program, as a free bonus. :-))

1 0

Re: filer-side packet tracing.
by Jagan Bearelly 11 Mar '00

11 Mar '00

---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 156 Steve, Little correction, "captrans" is a NetApp tool, please follow recommendation from Guy Harris earlier today. Thank you. Regards, Jagan Bearelly >From guy(a)netapp.com Fri Mar 10 11:37:27 2000 From: Guy Harris <guy(a)netapp.com> Subject: Re: FW: filer-side packet tracing. To: "Uren, Jim" <jim.uren(a)netapp.com> Date: Fri, 10 Mar 2000 11:24:37 -0800 (PST) CC: armijo(a)cs.unm.edu, toasters(a)mathworks.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? As the author of captrans (the utility in question) and the changes to libpcap required to make it read other capture file formats, I don't have any problem making that stuff available. *However*, there's a better program than captrans - editcap. It's part of the Ethereal packet capture/analysis program package: http://ethereal.zing.org/ and uses the same library that Ethereal (and the text-mode - snoop/tcpdump-like - utility Tethereal that also comes with Ethereal) uses to read and write capture files. That library can read more capture file formats than can the patched libpcap I have here, and can also write more formats than can captrans. I don't plan to add any new capture file formats to the patched libpcap, but there are many people who have added new formats to the Wiretap library in Ethereal, and we will probably continue to add new formats as they come up (and as we can figure them out - a lot of the formats were figured out by reverse-engineering, as no documentation was available). Ethereal requires GLib 1.2[.x] and GTK+ 1.2[.x], so you'd have to have them installed on your system in order to build editcap (unless you tweak the Makefile by hand so as to build only the Wiretap library and editcap, in which case you need only GLib 1.2[.x], but once you've installed GLib, you might as well install GTK+ while you're at it), but, once you've done that, you not only have a program to convert capture files, you have a pretty nice GUI packet capture and analysis program, and a pretty nice text-mode packet capture and analysis program as well. (It also runs on Win32 operating systems such as Windows 9x and Windows NT - you have to get versions of GLib, GTK+, and libpcap that have been ported to Win32, but those all exist, and Ethereal can even capture packets on Win32 OSes with that version of libpcap.) There's also, on the "Download" page of the Ethereal Web site, a list of links to binary packages that have been made of Ethereal - or, at least, links to archive sites for binary packages for various OSes - although there's no guarantee that the latest version of Ethereal has been so packaged, in which case the package might not include editcap or Tethereal. > From jagan(a)netapp.com Fri Mar 10 15:48:25 2000 > Date: Fri, 10 Mar 2000 15:48:17 -0800 (PST) > From: Jagan Bearelly <jagan(a)netapp.com> > To: jonas.jonsson(a)proact.se, armijo(a)cs.unm.edu, jagan(a)netapp.com > Subject: Re: filer-side packet tracing. > Cc: Adam.Fox(a)netapp.com, toasters(a)mathworks.com > > Steve, > > Here is a documentation on "pktt" too. Please see the attachment. > Thank you. > > Regards, > Jagan Bearelly > > > From jagan(a)netapp.com Fri Mar 10 15:43:26 2000 > > Date: Fri, 10 Mar 2000 15:23:56 -0800 (PST) > > From: Jagan Bearelly <jagan(a)netapp.com> > > To: jonas.jonsson(a)proact.se, armijo(a)cs.unm.edu > > Subject: Re: filer-side packet tracing. > > Cc: Adam.Fox(a)netapp.com, toasters(a)mathworks.com > > > > > > Steve, > > > > The solaris command "captrans" can be used for conversion and > > Solaris has man pages for this command. For example, to convert > > pktt trace file called "e0.trc" into a snoop format, the following > > command works on Solaris: > > > > captrans -f snoop e0.trc > e0.trc.snoop > > > > Please let me know if you need man pages for "captrans". > > I hope that helps. > > > > Regards, > > Jagan > > > > > From armijo(a)cs.unm.edu Fri Mar 10 15:07:59 2000 > > > Date: Fri, 10 Mar 2000 15:59:35 -0700 > > > From: Steve Armijo <armijo(a)cs.unm.edu> > > > To: Jonas Jonsson <jonas.jonsson(a)proact.se> > > > Cc: "'Steve Armijo'" <armijo(a)cs.unm.edu>, "Fox, Adam" <Adam.Fox(a)netapp.com>, > > > toasters(a)mathworks.com > > > Subject: Re: filer-side packet tracing. > > > Mime-Version: 1.0 > > > > > > On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote: > > > > > > > > Well, > > > > > > > > In netcache v4.1 there is a presentation of this so it > > > > is somewhat documented. > > > > > > > > I can't say that I know the documentation of the filer side as > > > > well ;) > > > > > > > > > -----Original Message----- > > > > > From: Steve Armijo [mailto:armijo@cs.unm.edu] > > > > > Sent: den 10 mars 2000 10:34 > > > > > To: Fox, Adam > > > > > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > > > > > Subject: Re: filer-side packet tracing. > > > > > > > > > > > > > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > > > > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > > > > > which is convertable into snoop with the right utilities. > > > > > > > > > > would you folks(NetApp) be willing to share these utilities? > > > > > > ok, i guess i should have been more specific. would you be willing to > > > share the conversion utilities? > > > > > > -s > > > > > > -- > > > Cue the music, fade to black, no such thing as no payback. -PWEI > > > > > > [ armijo(a)cs.unm.edu ] > > > > > > > > ---------- X-Sun-Data-Type: default X-Sun-Data-Name: pktt_doc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225 Packet trace facility With the increased use of fast, switched networks it is becoming harder to get network traces from customers. Yet frequently that is the only way to debug certain problems. For that reason we have added a primitive facility for capturing network traffic on the filer, since it is the one place which has access to all network data. There are two main uses. If a customer site is experiencing crashing bugs it is often useful to have a trace of recent network activity, because the crash is frequently caused by an incoming request. It is possible to log packet traces to memory, where they can then be extracted from the core file. Since the filer is a storage device, it is also possible to save the packet traces on disk. This can be used to diagnose connectivity problems or unexpected requests, particularly for CIFS where the application/redirector/network combination may make it difficult or impossible to recreate the customer situation. Command usage The new command is "pktt" and it is invoked as follows: pktt start <if>|all [-d dir] [-s size] [-m pklen] [-b bsize] [-i ipaddr ...] [-v] pktt pause <if>|all pktt dump <if>|all [-d dir] pktt stop <if>|all pktt status [<if>|all] [-v] Each of the subcommands must be followed by an interface name or the word "all." A small exception to this is that "pktt status -v" is equivalent to "pktt status all -v". The available interface names can be found via "ifconfig -a" or "pktt status." pktt start The "start" subcommand is used to start tracing, (or restart if it has been paused). The packet trace data is stored in "tcpdump" format in a circular buffer in memory. The flags that can optionally be supplied are as follows: -d dir This specifies the path to an existing directory in which the trace data file will be written. The file will always have the name "<if>.trc" where "<if>" is the interface name (e.g. e4, fa3, etc.). If this option is missing the trace data will only be collected in memory, and after the buffer fills, new packets will replace existing packets. However, it is always possible to dump the contents of the buffer at any time using the "pktt dump" command. One thing to be aware of when writing trace data to disk is that if the filesystem cannot keep up with the network traffic you may not log all packets. This will show up in the "dropped" counts when looking at status. Along with this, you should remember that logging all traffic may generate a heavy write load on the filer which may bog it down. If possible, use the IP filter to reduce the amount of data to log. Note that the default value of the -b flag is too small when logging to disk if there is much traffic. You should set -b 128k or larger. (But not too large! See below.) -s size This allows you to set a maximum size of the trace file. If you don't specify this the file can grow to 32GB, so you should be careful to set it to a reasonable value if you think there is a chance you might forget you have left the trace going. This parameter is only useful in conjunction with the "-d" option. After the maximum size has been reached, packets continue to be logged to the buffer, but not to disk. -m pklen This sets the length at which packets will be truncated. The default is 1500 bytes, which results in full packets for ethernet. Note that in 5.3 the default of 1500 is incorrect for ethernet. You must override with "-m 1514" to get the full packets. It is sometimes useful to limit the data stored when every byte of the packet is not critical. However, for many debugging tasks it is useful to have the entire packet. In the case where the packet size can be larger than 1500 you may want to specify a larger maximum. However, many of the decoders refuse to deal with packets larger than 1500 bytes so you should only specify a larger value if that seems critical to finding the problem. -b bsize This sets the buffer size, which may be specified as a number with an optional trailing 'k' or 'm' multiplier. The default is 32K, which is fairly small but may be OK for finding "packet of death" bugs and the like. You should use a value of at least 128K when using the -d option. The value may range from 8K to 128M, but only in the most exceptional cases would it be necessary to increase the size beyond 1-2M. In cases where the network is very busy and it is not practical to log all the traffic to disk you may need to use a larger buffer. Warning! Do not specify a value larger than 3MB, even on a 1GB 760 filer! You may hang the system console or cause WAFL to run out of memory. This will be enforced in later versions, but in 5.3 you have to be careful not to specify too large a buffer size. -i ipaddr [-i ipaddr] ... This allows a kind of primitive filtering capability. Up to four IP address may be specified, which causes only traffic to or from any of those IP addresses to be logged. This will, of course, prevent logging of any non-IP (e.g. arp/rarp) traffic. -v This causes "pktt status -v" information to be displayed as tracing starts. Examples of "pktt start" pktt start e0 This will start capturing network traffic from the "e0" interface. All traffic will be logged to a 32K circular buffer. Or, if tracing had been suspended previously it would be restarted. pktt start fa3 -d / -s 100m -b 128k This starts capturing traffic on the "fa3" interface, writing to a file called "/fa3.trc" which will be allowed to grow to a maximum size of 100MB, with a 128K buffer. pktt start el10 -d /home -m 10k -b 1m -i ehost1 -i ehost2 This starts capturing traffic to and from the hosts "ehost1" and "ehost2", storing the traces into the file "/home/el10.trc". Up to 10K of each packets will be stored, in a 1MB buffer. pktt start all -b 128k -i 172.20.4.1 All interfaces will start capturing traffic to and from the specified IP address. This is a quick way to look at traffic if you're not sure which interface to use but you want to see the packets from one or more IP addresses. pktt pause The "pause" subcommand is used to temporarily stop capturing traffic from one or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. Use "pktt start" without any options to restart a paused interface. pktt dump The "dump" subcommand causes the contents of the packet trace buffer to be written to a file. If the "-d <dir>" option is used the file will be written to that directory, otherwise it will be written to the root directory of the root volume. The name of the file is always <if>.trc, and the contents are in "tcpdump" format. If a file by that name already exists it will be overwritten. pktt stop This causes all tracing to stop on the named interface, or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. If you have not dumped the trace data and you were not tracing to a disk file, the trace data will be lost. This action is not confirmed, so be careful when using this command. pktt status This can be used to display the buffer and file status of an existing trace. Using "pktt status -v" will give you full tracing status for all interfaces. Using pktt with "captrans" and "tcpslice" Guy Harris' "captrans" program is your friend. It allows you to convert between "tcpdump" format and "snoop," "netmon," or "sniffer" formats so that you can use your favorite packet parser to look at the traffic. For example, tooting> captrans -f snoop /n/filer/root/e4.trc > ~/mycap.snoop tooting> snoop -i ~/mycap.snoop | more See the captrans man page for more details on how to use it. Another useful program is "tcpslice," which can be used to extract time slices from trace files. Unfortunately it won't merge trace files from multiple interfaces. Someday we should enhance it to do that, since it frequently happens that traffic for one client appears on multiple interfaces.

1 0

Re: filer-side packet tracing.
by Jagan Bearelly 10 Mar '00

10 Mar '00

---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 77 Steve, Here is a documentation on "pktt" too. Please see the attachment. Thank you. Regards, Jagan Bearelly > From jagan(a)netapp.com Fri Mar 10 15:43:26 2000 > Date: Fri, 10 Mar 2000 15:23:56 -0800 (PST) > From: Jagan Bearelly <jagan(a)netapp.com> > To: jonas.jonsson(a)proact.se, armijo(a)cs.unm.edu > Subject: Re: filer-side packet tracing. > Cc: Adam.Fox(a)netapp.com, toasters(a)mathworks.com > > > Steve, > > The solaris command "captrans" can be used for conversion and > Solaris has man pages for this command. For example, to convert > pktt trace file called "e0.trc" into a snoop format, the following > command works on Solaris: > > captrans -f snoop e0.trc > e0.trc.snoop > > Please let me know if you need man pages for "captrans". > I hope that helps. > > Regards, > Jagan > > > From armijo(a)cs.unm.edu Fri Mar 10 15:07:59 2000 > > Date: Fri, 10 Mar 2000 15:59:35 -0700 > > From: Steve Armijo <armijo(a)cs.unm.edu> > > To: Jonas Jonsson <jonas.jonsson(a)proact.se> > > Cc: "'Steve Armijo'" <armijo(a)cs.unm.edu>, "Fox, Adam" <Adam.Fox(a)netapp.com>, > > toasters(a)mathworks.com > > Subject: Re: filer-side packet tracing. > > Mime-Version: 1.0 > > > > On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote: > > > > > > Well, > > > > > > In netcache v4.1 there is a presentation of this so it > > > is somewhat documented. > > > > > > I can't say that I know the documentation of the filer side as > > > well ;) > > > > > > > -----Original Message----- > > > > From: Steve Armijo [mailto:armijo@cs.unm.edu] > > > > Sent: den 10 mars 2000 10:34 > > > > To: Fox, Adam > > > > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > > > > Subject: Re: filer-side packet tracing. > > > > > > > > > > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > > > > which is convertable into snoop with the right utilities. > > > > > > > > would you folks(NetApp) be willing to share these utilities? > > > > ok, i guess i should have been more specific. would you be willing to > > share the conversion utilities? > > > > -s > > > > -- > > Cue the music, fade to black, no such thing as no payback. -PWEI > > > > [ armijo(a)cs.unm.edu ] > > > > > ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: pktt_doc X-Sun-Charset: us-ascii X-Sun-Content-Lines: 225 Packet trace facility With the increased use of fast, switched networks it is becoming harder to get network traces from customers. Yet frequently that is the only way to debug certain problems. For that reason we have added a primitive facility for capturing network traffic on the filer, since it is the one place which has access to all network data. There are two main uses. If a customer site is experiencing crashing bugs it is often useful to have a trace of recent network activity, because the crash is frequently caused by an incoming request. It is possible to log packet traces to memory, where they can then be extracted from the core file. Since the filer is a storage device, it is also possible to save the packet traces on disk. This can be used to diagnose connectivity problems or unexpected requests, particularly for CIFS where the application/redirector/network combination may make it difficult or impossible to recreate the customer situation. Command usage The new command is "pktt" and it is invoked as follows: pktt start <if>|all [-d dir] [-s size] [-m pklen] [-b bsize] [-i ipaddr ...] [-v] pktt pause <if>|all pktt dump <if>|all [-d dir] pktt stop <if>|all pktt status [<if>|all] [-v] Each of the subcommands must be followed by an interface name or the word "all." A small exception to this is that "pktt status -v" is equivalent to "pktt status all -v". The available interface names can be found via "ifconfig -a" or "pktt status." pktt start The "start" subcommand is used to start tracing, (or restart if it has been paused). The packet trace data is stored in "tcpdump" format in a circular buffer in memory. The flags that can optionally be supplied are as follows: -d dir This specifies the path to an existing directory in which the trace data file will be written. The file will always have the name "<if>.trc" where "<if>" is the interface name (e.g. e4, fa3, etc.). If this option is missing the trace data will only be collected in memory, and after the buffer fills, new packets will replace existing packets. However, it is always possible to dump the contents of the buffer at any time using the "pktt dump" command. One thing to be aware of when writing trace data to disk is that if the filesystem cannot keep up with the network traffic you may not log all packets. This will show up in the "dropped" counts when looking at status. Along with this, you should remember that logging all traffic may generate a heavy write load on the filer which may bog it down. If possible, use the IP filter to reduce the amount of data to log. Note that the default value of the -b flag is too small when logging to disk if there is much traffic. You should set -b 128k or larger. (But not too large! See below.) -s size This allows you to set a maximum size of the trace file. If you don't specify this the file can grow to 32GB, so you should be careful to set it to a reasonable value if you think there is a chance you might forget you have left the trace going. This parameter is only useful in conjunction with the "-d" option. After the maximum size has been reached, packets continue to be logged to the buffer, but not to disk. -m pklen This sets the length at which packets will be truncated. The default is 1500 bytes, which results in full packets for ethernet. Note that in 5.3 the default of 1500 is incorrect for ethernet. You must override with "-m 1514" to get the full packets. It is sometimes useful to limit the data stored when every byte of the packet is not critical. However, for many debugging tasks it is useful to have the entire packet. In the case where the packet size can be larger than 1500 you may want to specify a larger maximum. However, many of the decoders refuse to deal with packets larger than 1500 bytes so you should only specify a larger value if that seems critical to finding the problem. -b bsize This sets the buffer size, which may be specified as a number with an optional trailing 'k' or 'm' multiplier. The default is 32K, which is fairly small but may be OK for finding "packet of death" bugs and the like. You should use a value of at least 128K when using the -d option. The value may range from 8K to 128M, but only in the most exceptional cases would it be necessary to increase the size beyond 1-2M. In cases where the network is very busy and it is not practical to log all the traffic to disk you may need to use a larger buffer. Warning! Do not specify a value larger than 3MB, even on a 1GB 760 filer! You may hang the system console or cause WAFL to run out of memory. This will be enforced in later versions, but in 5.3 you have to be careful not to specify too large a buffer size. -i ipaddr [-i ipaddr] ... This allows a kind of primitive filtering capability. Up to four IP address may be specified, which causes only traffic to or from any of those IP addresses to be logged. This will, of course, prevent logging of any non-IP (e.g. arp/rarp) traffic. -v This causes "pktt status -v" information to be displayed as tracing starts. Examples of "pktt start" pktt start e0 This will start capturing network traffic from the "e0" interface. All traffic will be logged to a 32K circular buffer. Or, if tracing had been suspended previously it would be restarted. pktt start fa3 -d / -s 100m -b 128k This starts capturing traffic on the "fa3" interface, writing to a file called "/fa3.trc" which will be allowed to grow to a maximum size of 100MB, with a 128K buffer. pktt start el10 -d /home -m 10k -b 1m -i ehost1 -i ehost2 This starts capturing traffic to and from the hosts "ehost1" and "ehost2", storing the traces into the file "/home/el10.trc". Up to 10K of each packets will be stored, in a 1MB buffer. pktt start all -b 128k -i 172.20.4.1 All interfaces will start capturing traffic to and from the specified IP address. This is a quick way to look at traffic if you're not sure which interface to use but you want to see the packets from one or more IP addresses. pktt pause The "pause" subcommand is used to temporarily stop capturing traffic from one or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. Use "pktt start" without any options to restart a paused interface. pktt dump The "dump" subcommand causes the contents of the packet trace buffer to be written to a file. If the "-d <dir>" option is used the file will be written to that directory, otherwise it will be written to the root directory of the root volume. The name of the file is always <if>.trc, and the contents are in "tcpdump" format. If a file by that name already exists it will be overwritten. pktt stop This causes all tracing to stop on the named interface, or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. If you have not dumped the trace data and you were not tracing to a disk file, the trace data will be lost. This action is not confirmed, so be careful when using this command. pktt status This can be used to display the buffer and file status of an existing trace. Using "pktt status -v" will give you full tracing status for all interfaces. Using pktt with "captrans" and "tcpslice" Guy Harris' "captrans" program is your friend. It allows you to convert between "tcpdump" format and "snoop," "netmon," or "sniffer" formats so that you can use your favorite packet parser to look at the traffic. For example, tooting> captrans -f snoop /n/filer/root/e4.trc > ~/mycap.snoop tooting> snoop -i ~/mycap.snoop | more See the captrans man page for more details on how to use it. Another useful program is "tcpslice," which can be used to extract time slices from trace files. Unfortunately it won't merge trace files from multiple interfaces. Someday we should enhance it to do that, since it frequently happens that traffic for one client appears on multiple interfaces.

1 0

Re: filer-side packet tracing.
by Jagan Bearelly 10 Mar '00

10 Mar '00

Steve, The solaris command "captrans" can be used for conversion and Solaris has man pages for this command. For example, to convert pktt trace file called "e0.trc" into a snoop format, the following command works on Solaris: captrans -f snoop e0.trc > e0.trc.snoop Please let me know if you need man pages for "captrans". I hope that helps. Regards, Jagan > From armijo(a)cs.unm.edu Fri Mar 10 15:07:59 2000 > Date: Fri, 10 Mar 2000 15:59:35 -0700 > From: Steve Armijo <armijo(a)cs.unm.edu> > To: Jonas Jonsson <jonas.jonsson(a)proact.se> > Cc: "'Steve Armijo'" <armijo(a)cs.unm.edu>, "Fox, Adam" <Adam.Fox(a)netapp.com>, > toasters(a)mathworks.com > Subject: Re: filer-side packet tracing. > Mime-Version: 1.0 > > On Fri, Mar 10, 2000 at 11:59:30AM +0100, Jonas Jonsson wrote: > > > > Well, > > > > In netcache v4.1 there is a presentation of this so it > > is somewhat documented. > > > > I can't say that I know the documentation of the filer side as > > well ;) > > > > > -----Original Message----- > > > From: Steve Armijo [mailto:armijo@cs.unm.edu] > > > Sent: den 10 mars 2000 10:34 > > > To: Fox, Adam > > > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > > > Subject: Re: filer-side packet tracing. > > > > > > > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > > > which is convertable into snoop with the right utilities. > > > > > > would you folks(NetApp) be willing to share these utilities? > > ok, i guess i should have been more specific. would you be willing to > share the conversion utilities? > > -s > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] > >

1 0

RE: filer-side packet tracing.
by Jonas Jonsson 10 Mar '00

10 Mar '00

Well, In netcache v4.1 there is a presentation of this so it is somewhat documented. I can't say that I know the documentation of the filer side as well ;) /// Cheers, Jonas Performance, Simplicity, Network Necessity! NetCache! NetCache! PROVEN! FAST & FRESH! NetCache is Scaling the Internet! NetCache is Moving Content to the Edge! Speed! Control! Intelligence! NetCache! This email is cache friendly :) ---------------------------------------- > -----Original Message----- > From: Steve Armijo [mailto:armijo@cs.unm.edu] > Sent: den 10 mars 2000 10:34 > To: Fox, Adam > Cc: 'Ronan Mullally'; toasters(a)mathworks.com > Subject: Re: filer-side packet tracing. > > > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? > > -s > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] >

2 1

Re: FW: filer-side packet tracing.
by Guy Harris 10 Mar '00

10 Mar '00

> On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? As the author of captrans (the utility in question) and the changes to libpcap required to make it read other capture file formats, I don't have any problem making that stuff available. *However*, there's a better program than captrans - editcap. It's part of the Ethereal packet capture/analysis program package: http://ethereal.zing.org/ and uses the same library that Ethereal (and the text-mode - snoop/tcpdump-like - utility Tethereal that also comes with Ethereal) uses to read and write capture files. That library can read more capture file formats than can the patched libpcap I have here, and can also write more formats than can captrans. I don't plan to add any new capture file formats to the patched libpcap, but there are many people who have added new formats to the Wiretap library in Ethereal, and we will probably continue to add new formats as they come up (and as we can figure them out - a lot of the formats were figured out by reverse-engineering, as no documentation was available). Ethereal requires GLib 1.2[.x] and GTK+ 1.2[.x], so you'd have to have them installed on your system in order to build editcap (unless you tweak the Makefile by hand so as to build only the Wiretap library and editcap, in which case you need only GLib 1.2[.x], but once you've installed GLib, you might as well install GTK+ while you're at it), but, once you've done that, you not only have a program to convert capture files, you have a pretty nice GUI packet capture and analysis program, and a pretty nice text-mode packet capture and analysis program as well. (It also runs on Win32 operating systems such as Windows 9x and Windows NT - you have to get versions of GLib, GTK+, and libpcap that have been ported to Win32, but those all exist, and Ethereal can even capture packets on Win32 OSes with that version of libpcap.) There's also, on the "Download" page of the Ethereal Web site, a list of links to binary packages that have been made of Ethereal - or, at least, links to archive sites for binary packages for various OSes - although there's no guarantee that the latest version of Ethereal has been so packaged, in which case the package might not include editcap or Tethereal.

1 0

RE: filer-side packet tracing.
by Haag,Dennis 10 Mar '00

10 Mar '00

I stand corrected, it was introduced in 5.3. I was not aware of it until 5.3.2. -----Original Message----- From: Haag,Dennis [mailto:Dennis.Haag@netapp.com] Sent: Friday, March 10, 2000 6:54 AM To: 'toasters(a)mathworks.com' Subject: RE: filer-side packet tracing. Pktt was introduced in 5.3.2 as an rc_toggle_basic command, it was changed to a regular command in 5.3.4. Although it doesn't show up on the list when you type ? it is there. -----Original Message----- From: Steve Armijo [mailto:armijo@cs.unm.edu] Sent: Friday, March 10, 2000 1:34 AM To: Fox, Adam Cc: 'Ronan Mullally'; toasters(a)mathworks.com Subject: Re: filer-side packet tracing. On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > Yes. pktt will do this. It creates a file in tcpdump format, > which is convertable into snoop with the right utilities. would you folks(NetApp) be willing to share these utilities? -s -- Cue the music, fade to black, no such thing as no payback. -PWEI [ armijo(a)cs.unm.edu ]

1 0

RE: filer-side packet tracing.
by Fox, Adam 10 Mar '00

10 Mar '00

> > On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > > > Yes. pktt will do this. It creates a file in tcpdump format, > > which is convertable into snoop with the right utilities. > > would you folks(NetApp) be willing to share these utilities? > Aaron Simms mentioned etherreal which is publically available. We do provide the tcpdump program on NOW if you can't find it anywhere else. I may have to check on the availability of other tools. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

1 0

RE: filer-side packet tracing.
by Haag,Dennis 10 Mar '00

10 Mar '00

Pktt was introduced in 5.3.2 as an rc_toggle_basic command, it was changed to a regular command in 5.3.4. Although it doesn't show up on the list when you type ? it is there. -----Original Message----- From: Steve Armijo [mailto:armijo@cs.unm.edu] Sent: Friday, March 10, 2000 1:34 AM To: Fox, Adam Cc: 'Ronan Mullally'; toasters(a)mathworks.com Subject: Re: filer-side packet tracing. On Thu, Mar 09, 2000 at 03:18:52PM -0800, Fox, Adam wrote: > > Yes. pktt will do this. It creates a file in tcpdump format, > which is convertable into snoop with the right utilities. would you folks(NetApp) be willing to share these utilities? -s -- Cue the music, fade to black, no such thing as no payback. -PWEI [ armijo(a)cs.unm.edu ]

1 0

Sequential reads on NetApps
by Riasat_Amin＠notes.amdahl.com 10 Mar '00

10 Mar '00

Can anybody tell me how the NetApps box performs with sequential reads with a database that has grown slowly over time ? I understand that the WAFL fs does not re-write the modified data block to the same place but writes it anywhere ie. to the current position of the heads. Does this mean that the heads get thrashed around when a full sequential read is performed on the data base and consequentially the reads are slow compared to doing random reads? Any information on this would be gratefully received Rgds Riasat

1 0

RE: filer-side packet tracing.
by Fox, Adam 10 Mar '00

10 Mar '00

> Folks, > > Is there any facility on a filer to run a packet trace similar to > something like snoop or tcpdump on a unix host? > > Yes. pktt will do this. It creates a file in tcpdump format, which is convertable into snoop with the right utilities. Hope this helps. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

2 1

RE: filer-side packet tracing.
by Sims, Aaron 10 Mar '00

10 Mar '00

I will often use 'ethereal' to load up the packet dumps and view them in a nice graphical manner. You can find ethereal at: http://ethereal.zing.org/ Aaron -- Aaron Sims Professional Services Engineer Network Appliance aaron.sims(a)netapp.com 404-226-7382 (cell) 408-822-8947 (voice mail) > -----Original Message----- > From: Fox, Adam [mailto:Adam.Fox@netapp.com] > Sent: Thursday, March 09, 2000 6:19 PM > To: 'Ronan Mullally'; toasters(a)mathworks.com > Subject: RE: filer-side packet tracing. > > > > Folks, > > > > Is there any facility on a filer to run a packet trace similar to > > something like snoop or tcpdump on a unix host? > > > > > > Yes. pktt will do this. It creates a file in tcpdump format, > which is convertable into snoop with the right utilities. > > Hope this helps. > > -- Adam Fox > NetApp Professional Services, NC > adamfox(a)netapp.com > >

1 0

RE: Filer showing held locks
by Sims, Aaron 10 Mar '00

10 Mar '00

One of the fields that 'lock_dump' produces is the inode for the file held. I will often use 'find' and specify the inode number to figure out which file is locked. You'll probably have to convert the inode number from hex to decimal. Aaron -- Aaron Sims Professional Services Engineer Network Appliance aaron.sims(a)netapp.com 404-226-7382 (cell) 408-822-8947 (voice mail) > -----Original Message----- > From: Muhlestein, Mark [mailto:mark.muhlestein@netapp.com] > Sent: Thursday, March 09, 2000 7:04 PM > To: 'Stephen C. Woods' > Cc: 'toasters(a)mathworks.com' > Subject: RE: Filer showing held locks > > > You can use the rc_toggle_basic command lock_dump: > > lock_dump -f > lock_dump -h > > -f dumps by file, -h dumps by host. > > Mark Muhlestein -- mmm(a)netapp.com > > -----Original Message----- > From: Stephen C. Woods [mailto:scw@seas.ucla.edu] > Sent: Thursday, March 09, 2000 3:17 PM > To: toasters(a)mathworks.com > Subject: Filer showing held locks > > > Is it possable to see file locks on a filer? > That is to say, 'Is there an equivalent to lslk?'. > > ----- > Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; > (310)-825-8614 > Finger for public key scw(a)cirrus.seas.ucla.edu,Internet > mail:scw@SEAS.UCLA.EDU >

1 0

RE: Filer showing held locks
by Muhlestein, Mark 10 Mar '00

10 Mar '00

You can use the rc_toggle_basic command lock_dump: lock_dump -f lock_dump -h -f dumps by file, -h dumps by host. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Stephen C. Woods [mailto:scw@seas.ucla.edu] Sent: Thursday, March 09, 2000 3:17 PM To: toasters(a)mathworks.com Subject: Filer showing held locks Is it possable to see file locks on a filer? That is to say, 'Is there an equivalent to lslk?'. ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

1 0

filer-side packet tracing.
by Ronan Mullally 09 Mar '00

09 Mar '00

Folks, Is there any facility on a filer to run a packet trace similar to something like snoop or tcpdump on a unix host? -Ronan

2 1

Filer showing held locks
by Stephen C. Woods 09 Mar '00

09 Mar '00

Is it possable to see file locks on a filer? That is to say, 'Is there an equivalent to lslk?'. ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters