April 15, 2000
Network Uptime - April 15, 2000
The Resource for Network Management and Protocol Analysis Professionals
A Newsletter of http://www.NetworkUptime.com
Issue 02 00 00 00 00 04 01 05
Did everyone make it through April Fool's Day? The idea of an Internet outage or a virus outbreak on the Day of Fools is always in the back of our minds. Fortunately, most of us made it through without any major problems.
April Fool's Day reminded me of some foolish things that I've done in my networking career. I remember one miserable problem I created for myself in a foolish moment. We were across the country in a remote office, upgrading a router through the router's serial connection. The flash upgrade was about 2MB, which took a few minutes over our laptop's serial link. In the middle of the upgrade, I took it upon myself to straighten the router's position on the rack shelf, and accidentally pulled the power out of the back of the router!
Since we had to remove the current code to make room for the upgrade and the new code had not yet transferred completely to the new router, I was suddenly the owner of a completely worthless router! We had to wait another day so another router could be shipped to replace my boat anchor. I remember that my boss was also uncharacteristically onsite to observe the high level of professionalism during the upgrade. I'm still embarrassed when he mentions the experience.
Have you had an April Foolish moment in your networking exploits? The person with the best story will receive a CD-ROM with the Network Uptime tools library! I'll post the winning story in the next issue of Network Uptime, but I'll change the names to protect the guilty.
Send your story to Foolish@NetworkUptime.com, and we'll try to keep the laughing to a minimum. Good luck!
James Messer
Editor, Network Uptime
James@NetworkUptime.com
====
- Uptime Update -
Monitoring Network Statistics - Part 2
Understanding Application Statistics
====
Some applications can be a networking nightmare. A poorly written app can bring a network to it's knees, and others programs can randomly degrade the network at the most inopportune times. To help troubleshoot applications, a network analyzer can provide statistics and feedback at the application's level. Each application can have its own specialized statistics, unlike the finite number of statistics available at the physical and data link layers of the network.
Application Response Time
Unlike the response time measurements from a transport protocol such as TCP, the application response time is specific to the program's traffic between the server and the client. This statistic itself doesn't usually cause a protocol analyzer to report an error, although the percentage of slow responses to normal responses should be observed to determine the responsiveness of a server.
Denied Count
Client applications usually make a request to a server and expect a successful response. If the client's request is for a resource doesn't exist or the client doesn't have rights to the resource, the server denies the client's request. Some analysis tools include a customizable filter time to determine if a denied request should be counted. For instance, if the filter time is set to one second, the analyzer won't report denied requests unless more than one request is denied in that one second period.
Loop Percentage
A poorly designed application can cause the program to repeat a request to the server. A poorly designed application can cause the program to repeat a request to the server. A poorly designed application can cause the program to repeat a request to the server. You get the idea.
A repeated request is one that is continually sent, even though the proper response to the previous request has already been seen by the analyzer. Many analyzers can calculate the ratio of looped requests to normal requests to provide a percentage statistic.
Slow File Transfer
File transfers can be qualified as efficient if they send as much information as possible in the shortest amount of time. The key to this efficiency is the total amount of data in each packet of the transfer. The size of the data within the packets of a file transfer is observed by the analyzer, and a file transfer data size per packet that falls under a predefined threshold is marked as a slow file transfer. Network designers should use this statistic to help configure and maintain all devices along the transfer path to maximize the file transfer efficiency of the network.
Do you have an amazing application layer trace that you'd like to share? Send an email to Traces@NetworkUptime.com, and we'll share your amazing network with the world!
VisualRoute
http://www.NetworkUptime.com/tools/winnt/desktop/ping/
VisualRoute is more than a traceroute program. VisualRoute integrates traceroute, ping, and whois to provide a powerful troubleshooting program in a graphical multi-platform environment. These features are combined with a map of the world to create a visual display to track your communications links!
VisualRoute is shareware, and is available on Windows NT, Sun Solaris, and Linux. Try it out, and watch your network traffic in a new way!
====
Network Uptime Surf Report
====
Do you read the USENET newsgroups? If you've never read through some of the thousands of available lists on the Internet, you're missing one of the most interactive and informational sources of free information in the world!
If you've never worked with USENET newsgroups, visit the official news.newusers.questions web page to find out more:
http://www.geocities.com/ResearchTriangle/Lab/6882/
Your Internet provider may have information on their web page about USENET newsgroup access, so read through your ISP's help pages about newsgroup access.
There are two newsgroups that we visit daily; comp.dcom.net-analysis and comp.dcom.net-management. These newsgroups specialize in network analysis and network management, and they are visited by some of the most knowledgeable folks in the industry. If you have a particularly difficult problem or you're looking for an opinion on a product, you're bound to get some help in these groups!
We've got some links on NetworkUptime.com to help connect to the newsgroups, if your web browser has your USENET newsgroup access configured:
http://www.NetworkUptime.com/links
====
Network Uptime Management Tip
====
The latest network analysis tools have some of the most advanced 'expert' diagnostics available. Unfortunately, the analysis 'expert' feature can't automatically know about everything (it is a computer, after all). Without providing the correct information to the analyzer, it can't accurately provide feedback for finding and fixing problems on your network.
One piece of information that is usually invisible to the analyzer are the subnet masks on the network. Many network analyzers have a configuration section for their diagnostics routines that allow the addition of all IP addresses and subnet masks on the network. If these subnet masks are not manually added, the analyzer may use default settings that do not correspond to the network. The resulting expert analysis could be inaccurate, and troubleshooting could be made more difficult with the addition of problems that don't really exist!
====
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 April 15, 2000 02:04 PM