marcus@cpva.saic.com (Mark Jenkins, (619) 458-2794) (03/29/91)
We have been evaluating network analyzers. The list has been narrowed to the Network General Sniffer, Micro Technologies LANager, and the Novell LANalyzer. Our prime protocol requirements are TCP/IP, DECnet, and Appletalk, with Novell, NFS, and OSI to follow at some point in the future. Physical media types are limited to various Ethernets right now, although being able to snoop on V.35 WAN links (between routers) would be a bonus. The Sniffer and the LANager are very similar, because MTI buys the Sniffer software from Network General and supposedly reworks it slightly. MTI seems to be able to price the LANager better than the Sniffer. The Novell LANalyzer is nothing like the Sniffer or LANager, but costs substantially less (about 1/2 the price with a discount). Does anyone have experience with any pair of these to offer a basis for comparison? We have demo'd the Sniffer and the LANalyzer, but its hard to tell without extensive use just how handy some of the features are. Very often *some* kind of analyzer is better than no analyzer at all. The protocol decoding and various media support capabilities (Ethernet, V.35 WAN, LocalTalk) of the Sniffer-type analyzer are great, but are they worth the extensive extra $$$s, especially the extra $$s per protocol suite over the Novell LANalyzer cost? Just how does the LANager differ from the Sniffer - are they exactly the same or substantially the same? Please email any comments/critiques/information to me below. I'll send summaries (including my own information) to persons requesting them via email. Thanks very much in advance for any help - -- Mark Jenkins, SAIC CPVA::Marcus - SPAN [28119::Marcus] Marcus@CPVA.SAIC.COM or Marcus%CPVA.SPAN@sds.sdsc.edu (elsewhere)
lanmaint@nssdcb.gsfc.nasa.gov (Dave Yoest) (03/29/91)
In article <5336.27f1d691@cpva.saic.com>, marcus@cpva.saic.com (Mark Jenkins, (619) 458-2794) writes... >We have been evaluating network analyzers. > (* TEXT DELETED *) > >Does anyone have experience with any pair of these to offer a basis for >comparison? > (* TEXT DELETED *) >-- >Mark Jenkins, SAIC CPVA::Marcus - SPAN [28119::Marcus] >Marcus@CPVA.SAIC.COM or Marcus%CPVA.SPAN@sds.sdsc.edu (elsewhere) We have a LANALYZER (bought from Excelan before the Novell buyout) that we have used for 4 or 5 years. I have also demo'ed the SNIFFER and find them to be comparable. In my opinion the SNIFFER is just a little better at protocol decoding and the LANALYZER is a little better at finding physical layer hardware problems. Overall they are just about equal, If you're more into protocol "problem tracking" then you might be better off with the SNIFFER. If you do more hardware problem solving then the LANALYZER might be a better choice. Not to cloud the issue since you have already narrowed the field, but did you look at the Hewlett Packard 4972 LAN protocol analyzer. I like it better than both the SNIFFER and LANALYZER (my opinion). If you add the plotter option then you can also use the 4972 to create some really impressive multicolor graphs/charts for presentations on paper or overhead projector transparencies. It also doesn't "drop" packets on very busy ethernets. Dave Yoest LAN section Supervisor Allied Aerospace/Bendix Field Engineering NASACOM/Telecommunications Branch Code 543.8 NASA/Goddard Space Flight Center Greenbelt, Md 20771 USA DYOEST@ZAPHOD.GSFC.NASA.GOV DYOEST@128.183.43.16
snorthc@relay.nswc.navy.mil (Stephen Northcutt) (03/29/91)
Mark Jenkins, SAIC writes: >We have been evaluating network analyzers. The list has been narrowed to the >Network General Sniffer, Micro Technologies LANager, and the Novell LANalyzer. >Our prime protocol requirements are TCP/IP, DECnet, and Appletalk, with Novell, >NFS, and OSI to follow at some point in the future. We have two of the three you listed, HPs and several others you didn't. They all work. For what its worth I kinda like FTP SW's LANWatch product, because it is so convienient, many times, I happen to be on the same subnet as the problem, so all I have to do is turn on my PC. The price is also a factor in LANWatches favor. In conjuction with a piece of simtel-ware called robo-key, we have been able to use lan watch to collect data on far flung subnets, then use ftp sw's rcp/rsh to beam the data up to a unix system for awk processing; works pretty durn well. =================================================================== Stephen Northcutt (snorthc@relay.nswc.navy.mil) News Admin Work: (703) 663-7745 High Speed Nets Home: (703) 371-4184 Local GOSIP guru Paper Mail: Code E41, NSWC, Dahlgren VA 22448 Parallel Research
elf@oldearth.EBay.Sun.COM (Ed Fleschute) (04/12/91)
In article <4669@dftsrv.gsfc.nasa.gov>, lanmaint@nssdcb.gsfc.nasa.gov (Dave Yoest) writes: |> (TEXT DELETED) |> We have a LANALYZER (bought from Excelan before the Novell buyout) |> that we have used for 4 or 5 years. I have also demo'ed the SNIFFER |> and find them to be comparable. In my opinion the SNIFFER is just |> a little better at protocol decoding and the LANALYZER is a little |> better at finding physical layer hardware problems. Overall they |> are just about equal, If you're more into protocol "problem tracking" |> then you might be better off with the SNIFFER. If you do more hardware |> problem solving then the LANALYZER might be a better choice. |> I'll second the evaluation that Dave has performed. The LANALYZER is a great tool for doing physical layer analysis. If you are experiencing hardware problems on a cable the LANALYZER is phenominal at pinpointing the source of the trouble very quickly. The SNIFFER is excellent at higher level protocol analysis. If I was looking to find a NFS protocol bug I definitly would prefer the SNIFFER. |> |> Not to cloud the issue since you have already narrowed the field, but |> did you look at the Hewlett Packard 4972 LAN protocol analyzer. |> I like it better than both the SNIFFER and LANALYZER (my opinion). |> (TEXT DELETED) |> Two things I don't like about the HP 4972. 1) It is VERY heavy. If this isn't going to be mounted in a rack or on a cart, get something else. 2) I found the HP difficult to program. With the software they had two years ago it was difficult to do a display sorted on the hosts with the highest error counts. This may have been updated in the last couple of years. Ed Fleschute (My opinion only)
keith@ca.excelan.com (Keith Brown) (04/13/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: <5336.27f1d691@cpva.saic.com> <4669@dftsrv.gsfc.nasa.gov> <6222@male.EBay.Sun.COM> Date: Fri, 12 Apr 1991 01:07:46 GMT In article <6222@male.EBay.Sun.COM> elf@oldearth.EBay.Sun.COM (Ed Fleschute) writes: >I'll second the evaluation that Dave has performed. The LANALYZER is >a great tool for doing physical layer analysis. If you are experiencing >hardware problems on a cable the LANALYZER is phenominal at pinpointing >the source of the trouble very quickly. > >The SNIFFER is excellent at higher level protocol analysis. If I was looking >to find a NFS protocol bug I definitly would prefer the SNIFFER. I should start out by explaining that I *don't* work in our (the Novell) Lanalyzer product division so I'm sort of unbiased, but in a biased kind of way :-) I'm a NetWare NFS type. Anyway.... Have you seen release 3.X of the Lanalyzer software? The folks in the Lanz division have really cranked on the protocol decodes since release 2.X. Flicking through lanz traces of our general backbone traffic there is now hardly a packet passes across our LAN that the Lanz doesn't break out for me. Just recently I was flicking through a packet trace and was horrified to discover that the thing obviously knows more about the SNMP protocol than I do (I had no idea it decoded SNMP!) :-). Also, all these decodes are built into the product. I understand Network General still charge extra for every stack? Another great new feature is its ability to automatically generate mneumonic name files for Mac addresses. We have lots of Macs and NetWare servers (surprise, surprise :-) on our backbone and it now comes with a canned experiment that fires out the appropriate packets to these devices to make them respond with their names. Thanks to this, the Lanalyzer I have a timeshare in has a much more complete namefile than it would if I had had to try and figure out the namefile manually. Alas you still have to punch in the DOS PCs and the UNIX systems manually but I dare say they'll figure something out. Anybody have any suggestions for how to get UNIX systems to respond with their names, by firing a single or even a couple of packets at them? I'd be interesting in hearing any solutions for anyones machines. I'll forward any suggestions to the right people here..... Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
marka@dsinet (Mark Anacker) (04/13/91)
In article <6222@male.EBay.Sun.COM>, elf@oldearth.EBay.Sun.COM (Ed Fleschute) writes: > In article <4669@dftsrv.gsfc.nasa.gov>, lanmaint@nssdcb.gsfc.nasa.gov > (Dave Yoest) writes: .... > I'll second the evaluation that Dave has performed. The LANALYZER is > a great tool for doing physical layer analysis. If you are experiencing .... > The SNIFFER is excellent at higher level protocol analysis. If I was looking > to find a NFS protocol bug I definitly would prefer the SNIFFER. There's a new entry on the market - the Protolyzer (don't you just love the original names :-) from Pro-Tools in Beaverton, Oregon. We just had a 30-minute demo yesterday, and I WANT ONE. It's a software product that runs ideally in a 25Mhz 386 portable (under OS/2), and uses a windowed icon-based programming system to build custom "soft" analyzers. Definitely a neat device - has all sort of external interfacing (stats, alarms, etc) too. > Two things I don't like about the HP 4972. > > 1) It is VERY heavy. If this isn't going to be mounted in a rack > or on a cart, get something else. VERY VERY VERY heavy - try lugging one through an airport sometime... > 2) I found the HP difficult to program. With the software they > had two years ago it was difficult to do a display sorted on the > hosts with the highest error counts. This may have been updated > in the last couple of years. It's a pain to write filters for anything higher than the MAC layer, but I haven't found anything more reliable for physical-level diagnosis. It actually has a decent TDR function. -- Mark Anacker ...{!dsinet,!toybox}!marka Digital Systems International, Inc. Redmond, WA USA (206) 881-7544 "We have a massive leadership vacuum in this country... and we need to change bags" - Sen. Belfry
andrew@jhereg.osa.com (Andrew C. Esh) (04/16/91)
In article <581@elroy> marka@dsinet (Mark Anacker) writes: (about the HP-4972 ...) >diagnosis. It actually has a decent TDR function. > > >-- >Mark Anacker ...{!dsinet,!toybox}!marka >Digital Systems International, Inc. Redmond, WA USA (206) 881-7544 >"We have a massive leadership vacuum in this country... > and we need to change bags" - Sen. Belfry Really? I suppose I could go dig through the manuals and find out what this is, but I'm lazy. Could you expound? While we're on the subject of the 4972, i'd like to say that aside from the weight and the wacked-out user interface, I'd never be without it. The Traffic generator beats a flakey net to a pulp every time. I like to crank up some Metallica and transmit, oh about 93% utilization and watch the collision lights begin to twitter on the cheap boxes. Thrash them bits. By the way, if you've been away from this planet until recently, check out the HP advertising. The replacement for the 4972 is due out. A couple of our people were asked for input in the development process, so it will be nice to see if we got what we asked for. If no one knows what I'm talking about, forget I said anything. (But hold your breath anyway) :-) -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Mpls, MN 55416-1528 Punch down, turn around, do a little crimpin' (612) 525-0000 Punch down, turn around, plug it in and go ...