----------
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.
