I'd like to hear from the list as to what your preferred means of
determining what the hell is going on at a packet level at the other side
of a WAN/MAN/frame/etc link.
It seems to me that the means available are A) a very expensive distributed
NAI Sniffer installation B) standard RMON probes and the NMS of your choice
and C) A linux box with a ton of interfaces running Ethereal accessed via
Xwindows/VNC/whatever.
Personally, I'm inclined to explore option C. The bells & whistles of a
commercial package like NAI's Distributed Sniffer are not really a
compelling value added to me. It's a shame there's no Open Source RMON
agent available.
I'm asking NANOG because I figure this is something pretty much every
network engineer bumps into at one time or another.
thanks,
-carl
Date: Thu, 28 Mar 2002 08:27:02 -0600
From: CARL.P.HIRSCH@sargentlundy.com
I'd like to hear from the list as to what your preferred means
of determining what the hell is going on at a packet level at
the other side of a WAN/MAN/frame/etc link.
It seems to me that the means available are A) a very expensive
distributed NAI Sniffer installation B) standard RMON probes
and the NMS of your choice and C) A linux box with a ton of
interfaces running Ethereal accessed via Xwindows/VNC/whatever.
[ snip ]
"C" is close. Not sure what you mean by "a ton of interfaces".
Most (all?) good managed switches have a "monitor port" or
"mirror port" where they can blind copy traffic from other ports
to the one that's set aside for snooping.
Four-port ethernet cards are readily available. How many
switches do you wish to monitor simultaneously? Even with only
four ports (more in one box is certainly possible), you can have
a fair amount of traffic to digest.
I am starting to deploy GigE as a WAN technology. One nice
benefit is that the equipment (Cisco 6500/7600 class) has
capabilities not usually found in routers (such as remote
port mirroring). Coupled with VLAN ACL's, this can be quite
useful for ad-hoc remote diagnostics.
One particularly interesting adaptation is sFlow (RFC 3176),
currently only implemented by Foundry (I don't know of any
other vendors planning to implement sFlow). sFlow is usually
pitched against Netflow, I see it more as a diagnostic tool.
It works quite like port mirroring, but also allows sampling
and only sends header information to the collection server.
Pete.
sFlow is great! I've used InMon's (www.inmon.com) sFlow probe along with the
xRMON built into some HP switches to get packet sampling. The math on packet
sampling is pretty deep. NTOP also supports sFlow and it is open source.
www.ntop.org
Tony Wasson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Also note that sFlow can export it's data into tcpdump format.
.chance
The sFlow toolkit provides command line utilities and scripts for
analyzing sFlow data.
The core component of the sFlow toolkit is the sflowtool command line
utility. sflowtool interfaces to utilities such as tcpdump, ntop and
Snort for detailed packet tracing and analysis, NetFlow compatible
collectors for IP flow accounting, and provides text based output
that can be used in scripts to provide customized analysis and
reporting and for integrating with other tools such as MRTG or
rrdtool.
For example, the command:
sflowtool -t | tcpdump -r -
will provide a decoded packet trace. Advanced packet filtering is
easily performed using tcpdump. In addition, many other packet
analyzers are capable of processing packets in tcpdump format.
I'd like to hear from the list as to what your preferred means of
determining what the hell is going on at a packet level at the other side
of a WAN/MAN/frame/etc link.
Another commercial product to consider may be netIntercept from Sandstorm (www.sandstorm.com). They came out and talked to BayLISA (www.baylisa.org) about this a short time ago, and while it isn't yet doing the line rates talked about here, it was interesting. It's more about demultiplexing TCP and decoding protocols without regard to the port number; sort of an expert-system. (I saw it pluck out and display thumbnails of images from a gzipped tar file that was FTPd on a high port, IIRC.)
It's a FreeBSD box already built and already tuned. If I had the money, I'd have bought one on the spot.
Ran into this and went with C but couldn't fit as many NIC's in the newly christened sniffer box that I wanted.
My solution was to take an Cisco Cat 2900 (and a Foundry Workgroup switch later) and I worked up a series of rancid scripts (since changed to SNMP Set commands in a perl script) that would enable and disable ports along with setting the port mirroring. This gave me 22 ports to play with, each into a different switch so that I could directly monitor almost every FE port in the Co-lo. Its a little 'hacky' but it works surprisingly well (after a bit of up-front work). I haven't attempted to monitor a GigE port yet but Im sure that a Cisco Cat 3508 would be able to do the job as well.
Hope this helps someone.
-tdawson
-Network Geek (Bit Pusher)
-BlueMartini Software