kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/19/89)
In article <3763@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > Given a finite but large amount of money (say, anywhere from $5k to >$50k) what equipment would you suggest we need. I'm not so much looking >for specific brands or models, but the type of functionality we should have >on hand to maintain a network of this size and complexity (a half dozen >ethernet and AppleTalk segments spread around 3 or 4 buildings spanning 6 >city blocks interconnected with repeaters, bridges, and kboxes with 50-75 >hosts of various makes running various operating systems talking IP, >DECNet, and AppleTalk). And, of course, we expect the network to keep >growing in as-yet undefined ways. I do know that many of the leased line >links are going to be replaced by fiber some time in the next year or so. > > I already have on my short list some kind of Bit Error Rate Tester >and some kind of hardware ethernet snooper, but don't really know what sort >of features I should be looking for in each. I know that in theory TDRs >are useful for checking cables, but I've never used one and don't really >know how important (or useful) it is to have one. >-- With respect to Ethernet, you most need a hardware analyzer and a protocol analyzer. Our hardware analyzer is the Cabletron LAN-MD. It can test transceiver cables and transceivers on and off net. With a pair, you can blast packets on the Ethernet and test connectivity and break bridges, etc. Then you need a protocol analyzer. The one that catches all the packets is the H-P. It is expensive and not very portable, so we chose the Excelan LANalyzer. There is also the Network General Sniffer and the SpiderMonitor. You could also take a portable PC and run FTP's LANWatch. I think the Excelan board and software is around $5k and then add the cost of a portable PC. We chose, at the time, an NEC portable with a nice screen and hard disk. You might want to think of a 386 machine at this point. With a protocol analyzer, you want to be able to take apart any protocol of the given family. I think tcpdump is a good model of what to look for in terms of filter and display capability, but most analyzers have some nice real-time displays and other features you might like. tcpdump is hard to program. We find that the hosts table and other features are very important. You might like to trap Ethernet addresses by host name as well as IP address by host name. Helps to spot those "new" hosts that might be giving you trouble. We look for arp requests for broadcast addresses, gratuitous forwarding of broadcast addresses, icmp messages (like excessive redirects and other sorts of difficulties), rip exchanges, link level broadcasts, peak and average traffic loads (helps find storms). Lots of stuff, let your imagination run wild. :-) With respect to AppleTalk, you need the same thing. There are protocol analyzer tools for the Mac, but I would favor a dedicated box. Not sure what to do about the hardware analyzer. I think the Sniffer and the LANalyzer both offer EtherTalk, so it shouldn't be hard for them to support LocalTalk as well. TDRs aren't very useful. If your cable plant is so messed up a TDR is useful, then you are already in big trouble. Just joking :-) A TDR is essential when installing cable to check it out and it may be used to find cable faults, although we have never had one that got by the eyeball detector. You have leased lines and you want a BERT? Again, not so useful. I find that leased lines are either up or down. It may be nice to verify that the error rate is such-and-such and beat on your carrier, but that is already a losing game. They won't do anything until the line is really dead. Again, a little humor there :-) --Kent England, Boston University
rpw3@amdcad.AMD.COM (Rob Warnock) (04/19/89)
In article <29783@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: +--------------- | You have leased lines and you want a BERT? Again, not so | useful. I find that leased lines are either up or down. It may be | nice to verify that the error rate is such-and-such and beat on your | carrier, but that is already a losing game. They won't do anything | until the line is really dead. Again, a little humor there :-) | --Kent England, Boston University +--------------- Humor understood... Sometimes when dealing with The Phone Co\\\\\\\ (oops!) your carrier(s) of choice you have to laugh to keep from crying. Nevertheless, if the routers you have on the ends of those lines keep statistics on packet error rates on the lines, and you can write a program on one of your hosts to poll those statistics and keep a "contemporary record" [I just *love* that IRS buzzword!] of error behavior, *sometimes* you can convince your carrier that your line is drifting out of spec *before* it up and dies on you. Sometimes... Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
barr@frog.UUCP (Chris Barr) (04/21/89)
In article <29783@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes: > > With respect to Ethernet, you most need a hardware analyzer With UTP (Lattisnet), I know of 3 levels of hardware debugging: 1. line continuity: telephone tools work here, crudely but often effectively 2. Ethernet heartbeat continuity: Synoptics either sells something or its tech support reps recommend a pair of gizmos 3. When the 'heartbeat' is gone (try plugging a phone into one of those RJ-45s): trial-and-error disconnects of host modules/satellite concentrators. > Then you need a protocol analyzer. The one that catches all > the packets is the H-P. It is expensive and not very portable, so we > chose the Excelan LANalyzer. There is also the Network General > Sniffer and the SpiderMonitor. You could also take a portable PC and > run FTP's LANWatch. Excelan's Lanalyzer is apparently Network General's Sniffer minus the computer: an NP600 card + whatever protocol(s) support you need. One site I know (they use TCP/IP & NetWare) evaluated LANalyzer and instead chose - LANWatch (to filter, then monitor or debug packets) - Lan Patrol (for bar-graph reporting of usage levels) - 'ping' for one level of error detection, which shows what links are up This comes as part of TCP/IP. This costs in the neighborhood of $2K, including a WD Ether Card. Their reasoning is that, as a new site with 300+ nodes, they don't yet know exactly how useful the tools will be, and so are not investing 4-to-8 times bigger bucks in LANalyzer or Sniffer or Spider. LanWatch also has a leaner user interface than the fancy windows: for a technician this is easier/faster.
David@cup.portal.com (Varian Associates Inc) (04/23/89)
In article <29783@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > > You have leased lines and you want a BERT? Again, not so > useful. I find that leased lines are either up or down. It may be > nice to verify that the error rate is such-and-such and beat on your > carrier, but that is already a losing game. They won't do anything > until the line is really dead. Again, a little humor there :-) Strictly speaking, a breakout box that generates a "fox" test pattern could be considered a BERT, but it isn't very useful. What BERT have you been using that has led you to this negative opinion? For my purposes, a "real" BERT is something on the level of a TTC Fireberd 6000. A Fireberd will, in addition to simply telling you how many bit errors have occurred, perform a wide variety of frequency, clock, time, and jitter measurements. Plus, the 6000 processes all of this raw data into analysis categories which are already in the language of common carrier test procedures, such as "errored seconds" and so forth. One of the keys to getting good service from a common carrier is to be able to speak their language. In my opinion, a Fireberd 6000 plus plug-in interfaces is somewhat overpriced at around 15K/ea, and probably can't be justified unless you have a substantial leased line network to maintain. In my case, I purchased three units about 18 months ago; they have been invaluable in resolving difficult troubles and enhancing my reputation as a miracle worker. :) Plus, the units have been completely trouble-free. There are probably other vendors who have equivalent capabilities, but I'd happily buy more 6000s if I ever need them. So, to get back to what Mr. England said, I disagree. My opinion is that BERTs are extremely useful tools in specific situations. However, one caveat: like any other tool, it's performance is limited to the capability of the human operating it. David McCord Senior Telecomm Network Analyst David@cup.portal.com 415/424-5644 Varian Associates, Inc. Disclaimer: The preceding are my personal opinions, not Varian's.
djh@cbnewsh.ATT.COM (daniel.hansen) (04/27/89)
In article <29783@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes: > > With respect to Ethernet, you most need a hardware analyzer > and a protocol analyzer. I would change that to (in order of importance): 1) a network analyzer - monitors traffic for all nodes on the network. You can use its information for both debugging and management. 2) a hardware analyzer - resolves cable/hardware problems. You can use its information for debugging. 3) a protocol analyzer - debugs protocol errors. You can use its information for debugging. Both hardware and protocol analyzers are primarily debugging tools. If you are trying to do real management (load balancing, segmentation, usage reporting, etc.), you need a network analyzer. Dan Hansen
gregb@dowjone.UUCP (Gregory S. Baber) (04/27/89)
In article <1292@frog.UUCP>, barr@frog.UUCP (Chris Barr) writes: >Excelan's Lanalyzer is apparently Network General's Sniffer minus >the computer: an NP600 card + whatever protocol(s) support you need. I doubt you'd get the respective manufacturers to agree on this. From experience (~ 1 year ago) the Sniffer was orders of magnitude easier to use and more complete in protocol analysis. Just my opinion... -- Reply to: Gregory S. Baber Voice: (609) 520-5077 Dow Jones & Co., Inc. UUCP: ..princeton!dowjone!gregb Box 300 or ..uunet!dowjone!gregb Princeton, N.J. 08543-0300 "So long, and thanks for all the fish"
barr@frog.UUCP (Chris Barr) (05/03/89)
In article <440@warlock.UUCP>, gregb@dowjone.UUCP (Gregory S. Baber) writes: > In article <1292@frog.UUCP>, barr@frog.UUCP (Chris Barr) writes: > >Excelan's Lanalyzer is apparently Network General's Sniffer minus > >the computer: an NP600 card + whatever protocol(s) support you need. Correction: it's Interlan's protocol analyzer hw/sw product that looks & feels a lot like Sniffer. (formerly Micom/Interlan, now Racal/Interlan)