December 15, 2000
Network Uptime - December 15, 2000
The Resource for Network Management and Protocol Analysis Professionals
A Newsletter of http://www.NetworkUptime.com
Issue 02 00 00 00 01 02 01 05
December 15, 2000
ISSN: 1529-6938
This Issue:
* Starting Delimiter - New Year's Resolutions
* Network Uptime Tutorial - Matrix, ART, and History Class
* Surf Report - Network Analysis Training Classes
* Network Uptime Tip-Of-The-Month - Sniffer Pro and the Microsoft VM
* Ending Delimiter
*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
====
Starting Delimiter
- New Year's Resolutions -
====
It's a new year (well, almost), and it's a good time to look to the future. As a team of networking professionals, there are big and small changes that can add functionality and reliability to our networks.
* Fix the Cablegami - I know your network has one of these closets or backbone connectors, filled to the ceiling with cables that seem to go in every direction. These cables work perfectly well, regardless of their seemingly unkempt state. The problems will begin to occur when you are troubleshooting a network problem and need to verify an individual port on a switch. You should never be placed into a position that would question the physical integrity of your network. Never.
* Get the Tools - You're gathering a nice cache of network analysis equipment, but what about the supporting tools? If you've got fiber connections, then you need a fiber test kit. At the very minimum, you should be able to determine the optic power and dB loss through the fiber connection. Do you have a copper punch-down kit? Have you considered some of the tools we mentioned in our last Network Uptime newsletter?
http://www.NetworkUptime.com/newsletter/archives/20001115.html
* Get Trained - Training is sometimes placed on the back-burner, but almost all network managers would agree that training provides a powerful resource for the organization that didn't exist one week prior. Five days of training can be powerful stuff - don't sell it short.
* Get Organized - Is your network documented? When was the last time it was updated? Some of the best network diagrams I've seen have been scrawled on a white board or piece of paper. The excuse of 'The network changes too much to document' doesn't hold much water when the network is having a problem or changes are planned. A scrawl on a piece of paper is better than nothing. Get writing, already.
* Right-Size Network Management - Too many network management systems are well thought-out designs of polling and notifications, but they often bite off more than the existing network team is able to chew. Instead of having an overdone management system that manages nothing, try sizing the system to provide the maximum amount of information with the minimum amount of effort. The system should manage the network, not require full time management of the system by a network team. Refer to the Network Uptime file library for some ideas and suggestions for network management systems.
http://www.NetworkUptime.com/tools
* Sync the Network to the Business - One of the most difficult objectives of a network designer is to create a system that satisfies the objectives of the organization. Too often, technology gets in the way of solving the organization's problems. By examining the goals of the company, the network team can design a network that will more effectively lead the organization.
The Network Uptime team would like to thank everyone for another great year. Have a happy and healthy new year!
- James 'Happy New Year' Messer
Editor, Network Uptime
James@NetworkUptime.com
There's nine more shopping days until Christmas, and time to provide your end-of-year requests to the Purchasing department before they leave for the year. Check last month's newsletter for the Network Uptime Propeller-Head Holiday Guide!
http://www.NetworkUptime.com/newsletter/archives/20001115.html
*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
====
Network Uptime Surf Report
- Network Analysis Training Classes -
====
The beginning of a new year brings the dawn of a new training budget! Pack your bags, you're going to spend your days in a strange classroom and your nights in a strange hotel room. Have a nice trip!
* Sniffer University
http://www.nai.com/asp_set/services/educational_services/sniffer.asp
Network Associates' Sniffer University has some of the broadest training curriculums in the network analysis business, and they're offered throughout the country.
* Laura Chappell Courseware
http://www.packet-level.com
Laura Chappell is well known for her seminars, books, and her training courses. While you're visiting, check out her new book on Advanced Network Analysis Techniques!
* WildPackets / Net3Group
http://www.net3group.com/Courses.asp
The Net3Group has recently been acquired by WildPackets, but continues to offer extensive training in the Minneapolis/St. Paul area.
* Pine Mountain Group
http://www.pmg.com/
The Pine Mountain Group offers training that prepares a network administrator for the NetAnalyst certification.
* Global Knowledge
http://www.globalknowledge.com/
Global Knowledge provides training classes worldwide, and focuses on education of networking technologies and vendor-specific training.
====
Network Uptime Tutorial
- Matrix, ART, and History Class -
====
We've added more 'real-world' monitoring tutorials in the last month, and we're receiving great reviews on our continually growing online seminar. Check out the latest installment at:
http://www.NetworkUptime.com/realworld
This month, we'll discuss the Traffic Matrix, Application Response Time, and History Samples.
The matrix statistics and the host table statistics are closely related. The host table displays traffic statistics from a single host; the matrix (or traffic map) displays traffic statistics between hosts. The difference is subtle, but the information gathered from the host matrix traffic map is very different than the host table!
The graphical view of the host matrix traffic map displays the network's Top Talkers. In this graph, the traffic statistics between two separate hosts are detailed, and the results are sorted in the graph by the highest traffic levels.
At first glance, the matrix view traffic map doesn't seem to have much analytical value. The round circle displays lines that are heading in all directions, and there are often hundreds of hosts identified around the outside of the circle. How can anyone make sense of this view? When analyzing the traffic map, don't focus on the details of the picture; you'll go crazy trying to follow all of those lines! Instead, try to identify the traffic patterns that are occurring underneath the ongoing conversations. On many networks, a couple of stations will begin to emerge as servers, because a set of communication lines will exist from that station to every other station on the network! With practice, it becomes easy to quickly find the servers.
The Top Talkers list also provides some real-world assistance. The host table is able to provide traffic statistics on the station that is sending the most information over the network. If that station is sending so much information, to what other stations is it communicating? In some cases, a server may be one of the Top N Hosts, but not one of the Top N Talkers. You should always be looking for the Top N Host that is communicating as a Top N Talker because of a file transfer, large application request, or some other high-bandwidth purpose. The network manager can find the workstations using the largest amount of bandwidth with the combination of the Host Table and Host Matrix statistics.
Application Response Time (ART) is a recent addition to the Sniffer Pro monitoring statistics. This set of monitoring statistics is based on the ART SNMP MIB defined in RFC 2564. Although SNMP isn't active on the portable version of Sniffer Pro, the distributed version of Sniffer Pro does provide SNMP accessibility to the ART MIB.
The ART specification provides a way to define the unit of work that is used to calculate ART because a unit of work can vary greatly between different applications. For example, an Oracle application works very differently on the network than a web-based application. Unfortunately, most implementations of the ART MIB aren't complex enough to understand the differences.
Most manufacturers have implemented the ART MIB as a UDP or TCP response time monitor, which doesn't really correspond to the original purpose behind gathering ART statistics. With this kind of implementation, the ART MIB really turns into a network response time measurement, regardless of the word 'application' somewhere in the name.
This doesn't mean that the ART statistics are worthless. In fact, these statistics can help resolve those ongoing concerns regarding network slowdown and response time. The following ART table shows communication to a number of web servers:
Before we go much further, let's make sure we all understand what ART is really showing. The current implementation of the ART MIB in Sniffer Pro version 4.0 (and every other implementation on the market) is really showing NETWORK response time. Sniffer Pro watches the communication between hosts, and counts the response time between a TCP request and the corresponding TCP acknowledgment.
That's easy for TCP traffic, since the connection-based nature of TCP always requires an acknowledgement to all data that is sent. For UDP traffic, the calculation would be much more difficult, since UDP doesn't require a response for every data frame that is sent. So how is ART calculated for UDP?
UDP is a connectionless protocol. Workstations that receive UDP packets aren't required to send a response acknowledging the reception of the UDP frame containing application data. If a UDP packet doesn't make it to the other end of the conversation, the upper-level application makes the decision of what to do next. UDP sends the data through the network, and doesn't concern itself about acknowledging the data once it is received.
Back to the question - how is ART calculated for UDP? In the Sniffer Pro implementation (and the one used in almost every industry implementation), the UDP response time is measured by watching the UDP frame leave a workstation, and timing when a UDP frame is returned to the workstation. But UDP doesn't send acknowledgment packets, so the UDP ART isn't really a network response time. However, its the best you have when working with UDP, so it's included in the ART monitoring statistics. It's very important that any UDP-based applications on the network are analyzed for their traffic patterns.
Here's an important note: Some UDP applications DO send an acknowledgement back from the application to the workstation when data is received, or when the data is processed. The application is in charge of sending the acknowledgement, which means the returned UDP frame is measuring true application response time! Not all applications work this way, so analysis of the existing UDP-based application must occur before any assumptions are made about the ART statistics relating to that application.
Once the ART information is gathering, it's easy to sort the tables by average response time to determine which servers or workstation to server conversations are the slowest. The downside to these stats is that they are not sorted by their proximity. If a workstation is communicating over a WAN link, that workstation will probably have the slowest response time to a server. For more precise response time measurements, use the Sniffer's Expert. The Expert will watch the average response time between stations, and will only inform of slow response times when the response times are greatly increased over the average.
The ART statistics provide important information to understanding the traffic flows and response times through the network. Make sure you fully understand how these ART statistics are associated with the actual flow of packets through the network!
The history samples included with Sniffer Pro provide a built-in method of baselining a network over an long period of time.
The graphical history sample display shows the statistics gathered over time, providing immediate visual feedback of the network's health. These statistics can also be combined into a single graph to display many statistics simultaneously.
These graphs can be saved to disk for later retrieval. The data contained within the graphs can be exported to a variety of text-based files.
The older DOS version of the Sniffer provided a similar function to the history samples, but it was contained in a completely different executable program (the Monitor), and it only provided statistics up to OSI layer 2 - the MAC layer. The DOS version of the Sniffer would not show monitor statistics for the IP or IPX protocol family.
The new monitor functions are completely integrated within the Sniffer Pro application, which means that the Sniffer can monitor and capture simultaneously. This functionality becomes very helpful with baselining an network with the history sample monitor.
History sampling is almost too simple - gather statistics from the network and display them on a graph. It's the analysis of this data that makes this monitoring function so powerful. Like most of the Sniffer's monitoring features, the value of this function is the analysis of the information - not the information itself.
A baseline of broadcasts and multicasts is a good example. A simple one-hour history sample of broadcasts and multicasts sampled each second gathers powerful information to use for additional analysis. A capture filter for broadcasts and multicasts can also capture simultaneously to disk, providing an extensive trail of 'evidence' that can be used to determine why the graph looks a certain way. Why did the network peak during a certain timeframe? What kind of broadcasts or multicasts were causing the peaks of traffic during that hour? Are any of these broadcasts necessary for the operation of the network, or did something show up that was unexpected?
Each history sample can be scrutinized over an hour, day, or week timeframe. The data from the network can be captured simultaneously, and additional detailed analysis can be created from the network traffic.
Sometimes, the analysis of the data is quite simple. For example, a history sample of network utilization may show utilization rates that are under 5% for an entire day. In this case, no further examination of the data is necessary. If there was a peak in the afternoon that sent the network to 50% utilization for five minutes, then additional analysis may be warranted. Additional analysis is dependent on the network, the users, and the available time of the network manager!
*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
====
Network Uptime Tip-Of-The-Month
- Sniffer Pro and the Microsoft VM -
====
Have you upgraded to the latest version of Sniffer Pro? Don't you love those new graphs in the Dashboard? You don't see any new graphs? You must not be running the right web browser version.
That's right, the new version of Sniffer Pro requires Internet Explorer version 5.0 or later! Sniffer Pro doesn't use the browser for surfing the net, but some very important Dynamic HyperText MarkUp Language (DHTML) screens in Sniffer Pro (such as the dashboard) are built with the DHTML libraries from Microsoft's Internet Explorer.
When you install Internet Explorer, the key piece of software you'll need to include will be the Microsoft Virtual Machine (Microsoft VM). If you choose the 'Typical' install, the Microsoft VM will be installed automatically. If you choose a 'Custom' install, the Microsoft VM will not be selected automatically - you'll have to check the box manually!
If you didn't install the Microsoft VM with your original Internet Explorer installation, you can choose Windows Update from the 'Tools' pull-down menu, or simply run setup again.
Netscape users, don't panic! Just because Sniffer Pro requires the libraries from Internet Explorer doesn't mean you have to change browsers. Although the Internet Explorer files will be installed on your Sniffer Pro system, Netscape can still remain your browser of choice on the desktop.
====
Ending Delimiter
====
If you're reading a forwarded copy of Network Uptime, sign up for your own FREE subscription:
http://www.NetworkUptime.com/newsletter/
Promote Network Uptime! Add Network Uptime graphics and banners to your web page:
http://www.NetworkUptime.com/graphics
To unsubscribe from Network Uptime, use the above URL, or email Majordomo@NetworkUptime.com with the following text in the body of the message:
unsubscribe NetworkUptime
For questions or comments, email us at James@NetworkUptime.com or visit the web page!
Posted by james_messer at December 15, 2000 02:10 PM