Originally Published: Friday, 4 February 2000 Author: Tori Wildstar
Published to: corp_features/General Page: 1/1 - [Printable]

Monitoring your Network with Linux

   Page 1 of 1  

Whether you deploy a large or a medium size network within your enterprise, you have probably experienced small problems like sporadically poor response times and/or delays from your business applications. If your network is exceptionally large (ranging from departmental LANs to interconnected remote locations) you surely know of the implications of a lack of planning or anarchic growth. These implications might include (but are not limited to):
  • Constantly poor response time
  • Network outages
  • Ghost services running in your LAN

Such problems could prove fatal to your day to day operations. I'm sure you know what downtime can mean to your business. Finding an immediate solution is not always plausible but attempting to track the problem is an essential part of proper system administration. There are some tools available for Linux that can help you find your way to network stability. I plan to demonstrate how those tools not only help system administrators but may also be useful for other staff members who have a need to know what type of system resources need to be purchased, when they need to be purchased and, finally, why they need to be purchased..


MRTG (http://www.mrtg.org) can monitor your WAN links. You can also monitor network activity for a particular server if you feel that is necessary. MRTG users SNMP (Single Network Management Protocol) to perform such tasks. MRTG can monitor anything that supports SNMP (http://www.freesoft.org/CIE/RFC/1157/5.htm) (e.g. server load, server uptime, etc.).

MRTG provides a web interface that allows you to monitor your bandwidth utilization and keeps history on the behavior of your link. With this data, you can perform one of the most importants task of an IT manager or consultant: capacity planning. Under- or overestimating system resource utilization is quite common when system monitors are not used. With MRTG you can predict, with some degree of certainty, when you will need to make changes to your current bandwidth.

Another advantage is the ability to track your need for network traffic redistribution. With the help of MRTG, you should be able to notice under- or overutilization of your link. Depending on how often you monitor (the default server monitoring occurs every 5 minutes), it is possible for MRTG to give you the full picture of your bandwidth utilization for any given day.

In my opinion, the greatest advantage of MRTG is generates statistical graphics - which you can publish to the web - to monitor your network from anywhere. Keeping a "visual" history of bandwidth utilization gives you tremendous power to take actions with the information. For example, statistical graphics can help you to prove the need for a link upgrade or even a downgrade.

MRTG may certainly change the perception that you have of your link(s) usage.


NTOP is helpful as an "emergency" tool. When you are experiencing response time delays or you suspect that something is wrong with your network, NTOP allows you to easily monitor the protocols running on your LAN and to determine the utilization of each.

NTOP comes very well when suspicious behavior is found on your network. Suppose you have a set of local clients accessing a database on your LAN. They claim that time response is very poor. You embark on a search to determine who or what is to blame. You generally have 2 options: the application or the network. You ask the application engineer(s) to determine that the application is OK. They determine that it is. You move on to the network engineers who come to find out that you have a very high retransmission packet rate caused by the server's faulty network card (a problem to be detected by the sysadmin using standard linux/unix commands). In a situation like this, it is likely that they were able to determine this by using a tool like NTOP. Without the help of NTOP and similar tools, finding the cause of the problem could have been extremely tedious.

Some very useful sections of NTOP include:

  • 'Active TCP Sessions" - shows what is taking place on your network at that specific moment. For example:
    ClientServer Data SentData RcvdActive SinceLast SeenDuration mail_server3.6 MB3.8 MB 12/08/9919:40:0112/20/99 20:47:3112 day(s) 1:07:02
    All this information can be accessed using any standard web browser. To have enough information to work on, you may wish to run NTOP for at least a couple of days (non-stop) in a production environment. (This may vary depending on the size of your network. For a medium departmental LAN, a couple of days should be fine).
  • 'Connection Matrix' - shows which station is talking to what server and the amount of traffic being exchanged
  • Monitoring of the most intensive bandwidth senders and receivers - Heavy traffic is not only caused by physical media but also by other system intensive actions (e.g. users downloading large files). This can cause severe bottlenecks to your LAN.

The NTOP data presentation is impressive. Bar and Pie charts are used to demonstrate protocol utilization and packet size distribution. Data gathered from the monitoring can be logged in a file for posterior plotting using any spreadsheet application such as Sun's Star Office. If you want to keep all of the information stored for future structured retrieval, NTOP gives you the option to store it in a SQL database.

The author of NTOP has created an excellent document describing how NTOP can be used to measure network traffic. This document can be found at http://jake.unipi.it/~deri/ntp_IEEE.pdf.gz.


Finding network problems does not necessarily lead to instant solutions. Correct interpretation is still needed. Sometimes it can be frustrating to have a lot of information without finding the answer to your problems. That why this task should be taken by a network professional. However, network monitoring can truly be an asset to your corporation as a whole.

   Page 1 of 1