mas@bridge2.ESD.3Com.COM (Mike Smith) (11/11/89)
In article <25303@pprg.unm.edu> cyrus@pprg.unm.edu (Tait Cyrus) writes: > >There were many different network monitors/analyzers shown at INTEROP 89 >each doing a little something different. . . . > . . . I would like to conduct a very >informal survey in the hope that maybe the results could be used to >show vendors what tools are 'really' needed. I would want a diagnostic that tells me what is "wrong" with the network. That would include all levels of all protocols for all sessions. Nothing I saw at InterOp '89 operated above the MAC/LLC. However, there is some work going on a Stanford and MIT to look for sick TCP/IP, some using AI. Something that looks at higher layers and does more analysis of actual traffic against published specs should be coming out in the next year or two. Expect to need a 20 MIPS machine or to wait all night.
jbvb@ftp.COM (James Van Bokkelen) (11/15/89)
In article <1093@bridge2.ESD.3Com.COM>, mas@bridge2.ESD.3Com.COM (Mike Smith) writes: > I would want a diagnostic that tells me what is "wrong" with the network. > That would include all levels of all protocols for all sessions. Nothing > I saw at InterOp '89 operated above the MAC/LLC. However, there is some work > going on a Stanford and MIT to look for sick TCP/IP, some using AI. Saying "Nothing ... operated above the MAC/LLC." is going a bit far. Existing monitors can do quite well at detecting individual malformed packets, if the problem is detectable without keeping context on a per-session basis. Bad checksums in IP headers and TCP or UDP packets are easy to detect (if you're capturing enough of the packet), and LANWatch does (TCP is new in 2.0). Bogus options in IP, TCP, CLNP and TP headers are easy, and we do (or will in 2.0). Off-line analyzers can (and do) crunch through a packet dump and identify TCP retransmits, out-of-sequence packets, etc. Telling what is "wrong" is another issue: I greatly prefer to just highlight a bad checksum (and explain what this means in the manual), rather than raise an alarm. Likewise, an option I don't recognize is "unknown". Crying "wolf" on benign network quirks or new developments can get expensive in support calls. > Something that looks at higher layers and does more analysis of actual > traffic against published specs should be coming out in the next year or > two. Expect to need a 20 MIPS machine or to wait all night. Informing you that a TCP connection ended abnormally because one side wouldn't retransmit unacknowleged data after it had sent the FIN requires per-session context and capture of ALL the packets (excellent hardware, routes must be symmetrical). This is where the AI is needed, and the knowlege base will have to be pretty big (the ISO version will have to grok 'session' as well) to avoid setting off false alarms. -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901