Network Uptime

Welcome to Network Uptime, the newsletter from the team that brings you http://www.NetworkUptime.com/. Thanks for joining us! As always, you can subscribe to Network Uptime or view this issue on the web:

http://www.NetworkUptime.com/newsletter/

We've made a big change to the newsletter - our name! The Uptime Update has changed its name to Network Uptime. The name is different, but the content remains the same. Send us an email, and let us know what you think of the name change!

James Messer
Editor, Network Uptime
James@NetworkUptime.com

====
- Starting Delimiter -
Monitoring Network Statistics - Part 1
====

Network analyzers are powerful tools. Unfortunately, they can also be so powerful (and confusing!) that much of the important information displayed on the analyzer is lost to even the most technical of engineers.

Fortunately, most network analyzers and management tools use similar statistical explanations to describe the health of network segments. Globally recognizable variables such as 'utilization' and 'packets per second' can assist the network engineer in applying a standard set of variables across network segments, regardless of the device used to gather the statistics. In this multiple part series of columns, we'll provide in-depth explanations of network statistics and a more complete view of each variable.

Utilization

Utilization is one of the most important network statistics to have available. Most reporting tools provide utilization values as their primary reporting variable.

While utilization values are an important gauge of network activity, they do not provide an exclusive representation of network health. An accurate view of network health would consist of many other network variables, not just a single utilization value. Too often, a chart of network utilization is used as an explanation of a network slowdown or outage - don't fall into that trap!

From a network analysis perspective, it's important to be informed about network utilization after the value has peaked for a short period of time, such as one to five seconds. Network traffic can be bursty, and a burst of network traffic for a short period is not as important as traffic that remains active for an extended period of time.

Small percentages of network utilization are expected. Network segments that exceed 50% utilization should be watched closely to prevent a larger increase of traffic that may cause network delays or low throughput.

Errors per Second

An important variable on any network is errors per second. A number of errors occurring on the network over a period of time can cause congestion, decreases in response time, and throughput degradation. An error report can also help to find small problems before they become network outages.

Errors per second should be compared to total packets or total bytes to determine the percentage of errors as a total of the entire network's traffic. An efficient network will maintain less than 1% errors for all network traffic.

Packets per Second

Packets per second sounds like a simple statistic, but there is some important information that can be derived from this seemingly generic variable.

Packets per second can provide the network engineer with a method for watching the overall traffic type of a network. If the network is highly utilized and the packets per second value is relatively low, then the network traffic consists of larger frame sizes. If the network utilization is high and the packets per second value is also high, then smaller frames are traversing the network.

For example, a tape backup application will use large frame sizes to send as much data across the network as quickly as possible. Smaller frames might be used by an application sending small pieces of information, such as short broadcasts or file requests. The network analyst can use packets per second to quickly understand the current network traffic patterns.

Broadcasts per Second

Switched networks have reintroduced a demon of the bridged network; broadcast storms. Each interface card on the network is required to present broadcast frames to the operating system of the device, regardless of the frame's relevance. If too many broadcast frames are seen at the same time, system slowdowns and throughput delays can occur. The key to tempering broadcasts over the network is to remove the unnecessary broadcast frames while keeping the 'good' broadcasts.

Broadcasts should remain under 40 broadcasts per second. Values of 120 broadcast per second or higher are considered excessive and should be addressed immediately!

Multicasts per Second

Multicasts are slightly different animals than broadcasts. While broadcasts are intended to be viewed by every workstation, multicasts only address a smaller subset of devices. For instance, the Bridge Protocol Data Unit (BPDU) protocol uses the Bridge Group multicast MAC address of 0180C2000000. As these frames traverse the network they are copied by all bridges, but are ignored by all other devices.

Since multicasts only affect small groups of devices, they are scrutinized to a smaller degree than broadcast frames. However, multicasts still utilize the network resources that would normally be available for other traffic. Large quantities of multicasts can also cause throughput and response time problems for devices that are part of the multicast group.

Forty multicasts per second are considered the low-end threshold for multicast traffic. If multicasts are exceeding 120 per second, network throughput and response time could be affected through the devices in that specific multicast group.

Next Issue: Application Layer Statistics!

====
Free/Shareware Pick of the Moment
====

tcptrace
http://www.NetworkUptime.com/tools/unix/analysis/analysis/

If you've ever needed to provide an analysis of a TCP connection on your network, then you'll be amazed at tcptrace! Tcptrace uses traces that have been captured with tcpdump to produce amazing charts and reports of TCP communication statistics. Tcptrace allows you to view time sequences, throughput information, and round trip time information in graphical or detailed text reports.

Do you use a network tool that makes your life easier? Tell us about it at James@NetworkUptime.com!

====
Network Uptime Surf Report
====

NetAnalysis Institute
http://www.netanalysis.org

Laura Chappell is well known for her technical books on network analysis, protocols, and router troubleshooting. She has also trained thousands of technicians and engineers in her protocol analysis workshops. Perhaps you've seen her articles in Network World and NetWare Connections magazine. Now, visit her web page!

The NetAnalysis Institute contains a trace file library, downloadable technical books, sample network analysis reports, and much more! Visit her web site at

http://www.netanalysis.org

Want to see more great Internet links? Visit our links page at

http://www.NetworkUptime.com/links/

====
Network Uptime Management Tip
====

Is your network hot?

We don't want to know if you're running the latest multi-gigabit router, or the newest non-blocking core switch. We're warning you that you might have a device on the network that's overheating!

Temperature can play a large role in the availability of your network. We have seen many routers and core switches fail because of an overheating condition. As our networks become larger and more distributed, our network devices are located in different locations, and often in different states or countries. We can't easily walk into a computer room to check the temperature if it's located 3000 miles away!

If you have a SNMP-based network monitoring system, you should consider setting SNMP traps for high temperature, or configure a polling mechanism that will retrieve the temperature over a period of time. Each network device has a manufacturer's technical specification that details the operational temperature range for the device.

Increases in the internal temperature of a network device could be caused by dust collecting on fan blades, an air conditioning problem, or someone leaving their notebook on the intake vent of a device! An environmental alarm on a management console may provide enough warning to prevent any network downtime.

Many manufacturers are including a temperature sensor and other environmental sensors in their SNMP MIB. For instance, many Cisco devices include a Cisco Environmental Monitor MIB:

iso.org.dod.internet.private.enterprise.ciscoMgmt.ciscoEnvMonMIB

or

1.3.6.1.4.9.9.13

Other manufacturers have similar MIB entries. Check your documentation for your environmental MIB variables!

Y'all be cool.

Send us your tips, and we'll tell the world! Email us at James@NetworkUptime.com, and we'll add your name and ideas to a future Network Uptime.

====
Ending Delimiter
====

If you enjoyed Network Uptime, please tell a friend about us! Visit our recommendation page at

http://www.NetworkUptime.com/recommend/

and we'll send an email to a friend with your comments!

If you're reading a forwarded copy of Network Uptime, sign up for your own free subscription:

http://www.NetworkUptime.com/newsletter/

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!

==== End of Network Uptime Issue 02 00 00 00 00 04 00 01 (c)2000, NetworkUptime.com, Inc. James@NetworkUptime.com http://www.NetworkUptime.com ====