Previous Table of Contents Next View Zoo Finally, when viewing specific packet traces, you'll want to explore your view options. Most analyzers have a menagerie of options that allow you to be flexible about which attributes of the trace you're viewing at one time. Some of these attributes include the following: o Hexadecimal representation of packet o Capture time o MAC and/or protocol and/or service decodes o Protocol or MAC address o Network name (DNS and NetBIOS) ______________________________________________________________ Many network analyzers have a name-gathering feature; that is, they "read" the packets as they go by and see whether there's a name identifier in any of them. If there is, the analyzer will make an entry in its name table, which will allow you to later specify a capture filter or view based on a network name. This, of course, is a much more "user friendly" way to specify a filter or view data. Be aware that some analyzers do not capture names automatically; they offer it as a manual operation on data that you've already captured, during the viewing portion of your analysis. ______________________________________________________________ Even with a Windows-based analysis tool, your brain can only process so much input at one time; being able to specify view options lets you "keep it simple" so as not to overwhelm yourself with too much information. Accordingly, you can view strip charts that summarize certain aspects of your data, as shown in Figure 21.5, which divides network traffic by application. [21-05t.jpg] Figure 21.5 Shomiti Surveyor and other analyzers can graph "top talkers" and other statistics, thus helping you to interpret raw data. You can also change your packet decode display options-in particular, how time and network names are displayed. Because a network is a timing-sensitive animal, the time-related options are particularly important. Your relative or interpacket time is important because it's the delay in between two packets. A value that looks way out of line with other packets indicates a delay caused by network glue such as routers or switches-or, more likely, a delay caused by processing at the other end of the conversation (by a busy server, for example). General Capture As helpful as capturing specific packets can be toward finding a solution to a specific problem, there are times when you'll want to run your analyzer "wide open" in order to get a general overview of your network segment. For example, when everybody on a given segment is complaining that they're running slowly, you would probably want to break out an analyzer that will statistically analyze the segment while it's capturing. The analyzer will likely keep a running total on several things: o Errors per station o Frames received per station o Frames transmitted per station o Total utilization of the network o Total errors on the network On the slow segment, you might see that the total utilization of the network was running high, say, 65 percent (Ethernet tends to degrade after 35 percent, so this is really high). You would probably want to know why the utilization was high: Is it due to many users, all of whom are using a fair portion of the pipe, or a couple of users hogging up the pipe? A good way to find this out would be to sort your statistic list. For example, if you used Novell's LANalyzer to sort your statistics by "packets out," by clicking the column head, you'd immediately find out that there's one station that seems to be hogging up the pipe (see Figure 21.6). [21-06t.jpg] Figure 21.6 Analyzers can sort active stations by just about any statistic. You might want to capture specific data from this station to find out just what type of traffic was being generated-even quicker, check your MAC documentation and make a phone call to determine what the user in question is doing. In this case, let's say your phone call reveals that the user was doing a backup of his hard drive to the network. You'd probably want to politely ask him to stop doing this during peak hours and suggest other methods for hard drive backup, such as a tape drive. Just to make sure the network is otherwise healthy, you would also sort your station list by errors. A couple of errors here or there is fine-you just want to make sure there isn't one station that's jamming up the freeway by behaving badly. Appropriate Analysis Let's take a look at a couple of scenarios in which analyzer use is appropriate. Notice that in all of them, we arrive at a theory, which we then prove through the use of the analyzer. We'll take a look at a vendor-related application and service problem first, examine what to do with a MAC address whose location you're not sure of, and finish up with a problem that requires the use of two network analyzers at one time. Previous Table of Contents Next