Previous Table of Contents Next Net Therapy 101: Techniques for Using Your Analyzer Each analyzer is different; choosing your weapon appropriately is one of the first steps toward success with a network analyzer. For example, when having general trouble with a Token-Ring segment (the segment is beckoning and therefore "down"), I would never use Network Associate's Sniffer Token-Ring Analyzer, because it doesn't keep up with the Token-Ring NAUN list during capture (an important part of troubleshooting Token-Ring segment errors). They make another tool, the Sniffer Token-Ring Monitor, that would be more appropriate, because it does keep up with the NAUN list. When troubleshooting a NetWare Token-Ring network, I like to use Novell's LANalyzer. It, too, supports a NAUN list (which Novell calls the ring monitor) and is good with NetWare-specific protocols and services. For instance, for a problem that involved NT workstations, Token-Ring, and Novell, I planned on using Novell's LANalyzer, because my problems seemed to be Novell related. I was not having problems talking to UNIX hosts or Microsoft hosts. I also knew that the problem was only Token-Ring related (Ethernet stations were not having the problem), so I planned on using Triticom's LANDecoder if I didn't see anything obvious with LANalyzer. I've found LANDecoder's Token-Ring decodes to be very complete. (We'll talk more about this problem later on in this hour-it's a goodie!) Here's the bottom line: Your scenario always dictates which tool you need. There's more than one tool out there because there's more than one problem out there! Because you can't buy all the tools available, it pays to know your network environment thoroughly before you invest. This way, you can buy the most appropriate tools for you. Cold-Filtered Ice-Brewed Packets As I mentioned earlier, knowing how and when to filter your capture data is one of the most important skills you can have when using a network analyzer to capture network traffic. Otherwise, you'll likely be searching for a very small needle in a very large haystack! Even veteran computer geeks get discouraged if they do not filter their data. Several types of filters are available: o Station filters-Which workstation and/or server data to capture o Protocol filters-TCP/IP, IPX/SPX, and NetBEUI o Service filters-Which services to show o Generic filters-Hexadecimal values within a packet Not every kind of filter is available on all analyzers; for instance, some analyzers won't filter every kind of service, but you can get around this by using a generic filter. ______________________________________________________________ Let's look at how to make one analyzer filter by service. For example, Novell's LANalyzer won't allow you to specify "display" Telnet sessions, but it will tell you when a packet is a Telnet session (or another kind of session). All you need to do is to click the section of the decode display that you're interested in. In our case, we're interested in a NetBIOS session, TCP socket 139, which translates to hexadecimal 8B (see Figure 21.3). Notice how several bytes are highlighted; these are the bytes in the packet that are the hex codes that identify this packet as a NetBIOS session. You can then double-click these bytes, and LANalyzer will bring up a generic filter window already filled with these values. You can apply this to other services as well. Very cool! ______________________________________________________________ [21-03t.jpg] Figure 21.3 Novell's LANalyzer allows you to filter on any field in the decode area just by double-clicking it. Here are the two ways an analyzer can filter: o Precapture-This is useful when you don't want your buffer to overflow with needless data. o Postcapture-This is good for when you've already captured the general data in question and want to refine your search. Previous Table of Contents Next