Network Uptime

Planning the Purchase

The most important part of purchasing a network analysis tool is the planning process. The planning process consists of creating goals, product requirements, and vendor considerations.

Goals
Before researching and evaluating products, the network analyst should ask one question; what should the network analysis tool DO? What functions should this product offer to help the network manager? The network administrators should write down goals that this product should help them achieve. Document these goals on paper, so they can be addressed, changed, or appended. These goals should be specific, and could even be based on specific network downtimes or outages that could be avoided in the future.

Some examples of analysis product goals might be:

* The network analysis team would like to produce weekly reports from samples of network traffic across the organization. These reports would include utilization, errors, and protocol distributions.

* Oracle databases are heavily utilized in the organization. This protocol analysis tool should provide extensive information regarding Oracle traffic across the network.

* The Accounting department often reports slow response time during report generation at the end of the month. This analysis tool should have response time analysis features available for tracking applications across the local network, and across the corporate WAN.

* Since most of the network engineers are in different locations, remote accessibility to the analysis tool is important.

These goals are a combination of current networking requirements as well as plans for the future. Keep in mind that the network that exists today may look very different in a number of months. These goals should qualify the ?must have? requirements in a network analysis tool; make another list of ?wouldn?t it be nice? features as a secondary evaluation guide.

The idea of creating a list of goals is to precisely define the analysis tool?s functions without having to create a concrete feature requirement matrix. Different analysis tools provide different methods of solving problems, and an open-ended list of goals allows each manufacturer to describe how their product can solve a particular need. It?s interesting to find that these very similar products can have very different methods of accomplishing the same goal.

Customize these goals to your own requirements. The goals of one organization may not be the same as another organization. Everyone?s network is a little different, and nobody knows your network like you do.

Other Requirements

Product features are important, but so is the usability of the network analysis tool! If the networks are located in different areas, then a more portable tool might be advantageous. Similarly, the network analysis tool might have a distributed function, allowing access across the LAN or via dial-up lines. Some network analysis tools are self-contained units that are a combination of hardware and software. Other tools might only consist of software loaded on any workstation. Some tools have their own operating systems, and others might require a 400mhz CPU running Windows NT.

With all of these options, it?s important to consider the networking environment and the corporate culture. If the network is relatively small, a software analysis tool installed on the network administrator?s PC might be sufficient. Larger organizations may require a more distributed solution with advanced network management capabilities. The key to finding the right requirements is to examine the current analysis techniques and fit the prospective analysis tool to the methods already in place. There are many organizations with portable analysis tools that aren?t being used because portability or distributed capability wasn?t considered when making a purchase decision.

Finally, the budget should be examined to determine the range of products that should be considered. Some very high-end network analysis tools can cost ten thousand to twenty-five thousand dollars for a single topology. Don?t waste time with research and product demonstrations from companies who have products you can?t afford to purchase! Before scheduling time with product representatives, find out the price range for an appropriately sized version of the product. If the price of the network analysis tool doesn?t comply with the budgeting requirements, don?t consider the product.

Vendor Considerations

A vendor or manufacturer has a large impact on the success or failure of a network analysis tool. Of course, considerations related to vendors and manufacturers are not specific to purchasing network analysis tools.

There are many companies selling network analysis tools, and the number of companies continues to grow. Some of these companies have been around for weeks, and others have been around for over a decade. The value a company?s relationship to their network analysis tool is based on service and support, not on longevity or location.

A good way to evaluate a company is to examine their web page. Flashy screen shots and graphics provide good eye-candy, but lack of information might present more questions for the company?s representatives. A good software company would have detailed network information, links, and detailed product specification sheets on their site. Look through the product support area of the web site, and make sure updates, patches, and additional software drivers are easily available.

Take advantage of the Internet. There is a Usenet Newsgroup dedicated to network analysis called comp.dcom.net-analysis. There are hundreds of people that read and respond to questions posted in this newsgroup. Communication in the newsgroups works best when specific questions are asked. For instance, the question "Has anyone used the reporting features of XYZ analyzer?" will get much better results than a general question such as "What?s the best analysis tool for Ethernet?"

For more information on Usenet Newsgroups, see the official news.newusers.questions web site at:

http://www.geocities.com/ResearchTriangle/Lab/6882/

Product Evaluation

After listing product requirements and researching web pages, it?s time to perform a hands-on evaluation of the network analysis tools. Working with the actual analysis product on a production network will provide much more information than a demonstration that occurred in an hour-long meeting.

Although network analyzers can have many options, not all features may be required in all environments. The three areas of network protocol analysis that should be examined are monitoring, analyzing, and decoding.

Monitoring

Monitoring is the ability of the analysis tool to provide statistical feedback on the network?s health. The network analyzer should have the ability to gather monitor statistics while other functions are being utilized, such as capturing data or displaying protocol decodes. Most analysis tools can produce monitoring statistics such as:

Utilization Percentage
Packets and Packets per Second
Errors and Errors per Second
Broadcasts and Broadcasts per Second
Multicasts and Multicasts per Second
Protocol Distribution
Frame Size Distribution

During the monitoring of the network, no packets are actually captured. The network analyzer is simply observing the traffic on the network and calculating statistics based on the traffic. Many analyzers can include filters, which could create customized statistics based on a workstation, protocol family, application, or other variables.

Monitoring statistics should be easy to gather, and in most cases should be calculated automatically without any user intervention. The graphs and tables compiled by the monitoring features should be easy to read, and should be customizable. Many network analysis tools provide a method of exporting data to a file for use in a spreadsheet or external graphing application.

Not only are the monitoring features of a network analysis tool used to gather statistics, these features can also be used to produce reports of network efficiency over the short-term or long-term. The network analyzer should have a method of providing some type of report output, both graphical and text-based. These reports should vary from very complex reports to simplified views of network performance. Since many network problems are complex in nature, a method to provide easy-to-understand reports will help explain network issues to the less-technical areas of the organization.

Analysis

Most protocol analysis tools are purchased to capture packets from the network, and display those packets in a format that is easy to read and understand. For the purposes of this document, the analysis and decode functions are separated into two separate evaluation areas. Since the latest network analysis tools provide statistics and feedback during the capture process, many network troubleshooting tasks can be performed before the protocol decode is examined!

The analysis function of the network analyzer does not have the same graphical requirements as the monitoring functions. Many protocol analysis tools provide information on network performance while capturing, but other analysis tools show no additional statistics when capturing network traffic. Network analysis tool manufacturers have been using this capture information as ways of differentiating themselves from the competition. This intelligence is often referred to as ?Expert? information.

The Truth About Expert Systems

Before discussing the Expert functions that are included with many network analyzers, there?s an industry secret that should be revealed. NETWORK ANALYSIS TOOLS CANNOT FIX NETWORKS. Network analyzers provide clues that help determine where network inefficiencies are occurring. The network administrator must play the part of the investigator, who can gather information from many sources to find the real cause of the network?s problems. The network analyzer is only one information gathering resource in the network administrator?s arsenal. Other information can be gathered from file server statistics, workstation utilities, and attention to detail. Expert information provides clues that may or may not be important to solving the problems occurring on the network. It?s the responsibility of the network administrator to determine if the issues found by the Expert system are important.

Expert systems can save hours of work when looking through network decodes, and an Expert system can often find problems on the network that could never be located by examining a protocol trace with the human eye. For example, a network slowdown can be very difficult to troubleshoot. With a network slowdown, the network administrator may want to calculate response time measurements from the workstations to the file server. These values can be calculated by hand with a protocol trace and frame delta-time information, but these results would take hours to gather. Expert systems calculate these values automatically, often providing this information during the capture process. With an expert system, this important information can be calculated in real-time, and a protocol decode display is unnecessary!

These timesaving features become more important when working with applications over the network. Programs using Microsoft Exchange, Oracle databases, web browsers, and other applications have their own proprietary methods of communicating from one application workstation to another. Many protocol analysis companies have worked closely with the application companies to provide Expert feedback when the application isn?t running at peak efficiency. Network administrators rarely have extensive Oracle database experience, but an Expert system can help the network administrator understand that an inefficiency exists with an Oracle database conversation on the network. The Oracle database administrators can be consulted further to determine if changes need to be made to the network or the application servers and workstations.

Not all Expert systems are created equally. Some Expert systems are designed to watch hundreds of possible network problems, while other analyzers boast of Expert capabilities but deliver only a handful of network exceptions. Examine the Expert capabilities of a network analysis tool to determine if the Expert provides helpful feedback or only provides a small list of possible network issues. Ask the manufacturer of the network analysis tool to provide a list of all Expert issues that are identified by the network analyzer.

Optimizing the Network Analyzer

In today?s network analysis market, almost all products are Windows-based. Network analysis tools running in Windows have technical requirements that are greater than most Windows applications. For instance, a network analysis tool works best with a large amount of RAM, plenty of room on a hard drive, and special network drivers.

Memory

Most analysis tools use the workstation?s memory to buffer information received by the network. This buffer requires memory that is in addition to the RAM required by the workstation?s operating system. The minimum RAM requirement for most network analysis tools is 128MB or more. For best results, provide the maximum amount of memory as possible in the network analyzer.

Hard Drive Space

Most applications require enough hard drive space to install, and then the hard drive requirements are minimal. With network analysis tools, hard drive space is much more important. If the buffer size of a network analyzer were 128 megabytes, the total size of a captured trace would also be 128 megabytes! Saving many network traces to the hard drive of the analyzer will quickly deplete whatever space was originally available. Some network analyzers allow network traffic to be constantly saved to disk, occupying gigabytes of free space! Like buffer memory, a large hard drive will provide the network administrator with more flexibility when analyzing or troubleshooting the network.

Network Cards and Drivers

Not all Ethernet and token ring cards are designed to operate effectively as a network analysis tool. A normal network card is designed to see the packets on the network that are specifically directed to the card. This would consist of broadcasts (which are directed to all stations), and packets that have a destination address that matches the burned-in or administratively assigned Media Access Control (MAC) address of the network card. To see all traffic on the network, the physical network card must support a function called promiscuity. A network analysis tool that isn?t promiscuous will have a very limited view of network traffic! Usually, the manufacturer of the network analyzer will provide a list of recommended cards. Other manufacturers prefer to supply both the software and network cards to assure proper capturing of network traffic.

If a network analysis tool captures information in a Microsoft Windows 95, 98, or Windows NT environment, the network drivers that are associated with the network card become very important. The drivers written for Microsoft Windows? environments are designed for normal desktop applications, not for specialized network analysis software. The problem is that most network card drivers do not pass low-level errors from the network card to the operating system. Since a word processing application is not interested in knowing the number of collisions on an Ethernet network, the normal network drivers can?t provide this important network information to the network analysis software.

Because of these network driver limitations, the companies that manufacture the network analysis software create customized network drivers that pass all low-layer errors to the analysis application. Some companies produce a single customized driver, which limits the analysis application to a single brand and model of network card. Other companies create many different customized drivers, allowing the user to choose between different network cards.

Protocol Decodes

The foundation of any network analysis tool is the quantity and quality of protocol decodes included in the analyzer. The total number of decodes is important, but the completeness and robustness of decodes is just as important to the network administrator.

Quantity of Decodes

Almost every network analyzer provides decodes for the most popular protocols. The analyzers that provide proprietary or newer protocol decodes differentiate themselves from other tools on the market. Many manufacturers will provide a total number of decodes available for their analyzer. When evaluating network analyzers, be sure to get a list of the protocols instead of a total number. If a list of protocols isn?t available from the manufacturer, a list can usually be gathered from the display filter function of the analyzer.

The number of decodes is important, but only if the network is using those protocols! If the network analyzer has extensive Novell NetWare decodes but the network has no NetWare servers, the protocol decodes aren?t very applicable. To properly evaluate the number of decodes, make a list of all protocols, applications, and functions that are currently running on the network, and all protocols and applications that are planned for the future. Compare this list to the manufacturer?s list, or ask the manufacturer?s representatives about support for the required applications.

The analyzer?s Expert function is also built on these decodes. A protocol decode doesn?t guarantee Expert capabilities for that decode, but without the protocol decode there can be no Expert functions based on those protocols.

Quality of Decodes

The number of protocol decodes listed on a specification sheet is only half of the story. For protocol decodes to assist the network administrator, they must be accurate and complete.

Protocol decode accuracy is rarely an issue with most protocols. Protocols such as IP, TCP, UDP, or IPX have been used for years, they are very well documented, and they have very simplified functions when compared to application layer protocols. Often, protocol inaccuracy is manifested by protocols that aren?t recognized by the network analyzer but clearly exist on the network. Often a misinterpretation of the protocol decode will occur because of a bug in the network analysis program! Again, inaccuracies in decodes rarely occur.

Most issues related to the quality of protocol decodes is the lack of completeness of some manufacturer?s decodes. For instance, a manufacturer might list Oracle as one of the protocol decodes provided in their network analysis software. In reality, the protocol decode recognizes the Oracle application layer protocol, but only displays hexadecimal information after the header of the Oracle decode. This is dramatic contrast to a real Oracle decode, which often provides many screens of detailed application information after the Oracle header is found.

Easy-to-Read Decodes

The most important part of a protocol decode is readability. Readability refers to the information that?s shown in the protocol decode, not the font displayed in the protocol decode window. Protocol decodes can differ dramatically between network analyzers, with some protocol decodes easier to follow than others. The value of a protocol decode can be seen best when comparing one protocol analysis tool with another. Some companies have put years of development into the readability of their protocol decodes, and a comparison of these protocol decodes across different network analysis tools can easily show the differences between products.

After the Purchase

New protocols are created constantly, and network analysis software can be out of date in just a few months. The Internet, LAN switching, e-commerce, and new applications are creating more protocols for the network analysis tools to understand. If the network administrator keeps the network analyzer updated to the latest version, network problems related to the newer protocols can be found quickly. It is important that manufacturers constantly upgrade their software, and that they provide a method of maintaining the software through the life of the network analysis product. A minimum upgrade schedule should be once every six months.

Final Summary

The quality of network analysis tools can vary greatly, but network administrators can use some common sense to get the most for their money.

* Before researching network analysis tools, make a list of goals. Goals help define the potential purchase, and keep everyone heading in the same direction.

* The usability of the network analyzer should be considered. Will the tool be portable or distributed?

* Always consider the budget! Looking outside your price range only wastes time. There are always many options in every price range.

* Evaluate the companies that manufacture the products. Research company web pages, and use Usenet Newsgroups to gather information from other network professionals.

* Evaluate the monitoring capabilities of the network analyzer, assessing readability, ease of use, and reporting options.

* Expert capabilities sound great, but very few network analyzers deliver helpful expert capabilities. Research the Expert system, and verify that it provides helpful feedback.

* Network analysis tools require plenty of memory, lots of available hard drive space, and specific kinds of network cards. Plan on spending appropriately for all three of these required resources.

* Protocol decodes are the foundation of any network analysis tool. Make a list of the protocols on the network, and compare this list with the manufacturers? available protocol decodes.

* Make sure the network analysis software is constantly updated. New protocols are created constantly, and an updated network analysis tool can be a lifesaver in a network emergency.

These purchase tips should help the network administrator find the perfect analysis tool for the job!