White Paper: Network management - who needs it?

No one can doubt the importance of networks, but it is important to remember that they need to be managed – especially with the...

No one can doubt the importance of networks, but it is important to remember that they need to be managed – especially with the complex network structures that exist today

What is network management?

The need for network management tools

Network management: an administrator's wish list

Fault management

Device management

Configuration management

Performance management

History maintenance



Software maintenance/upgrades


Remote access

Ease of use

Low cost

Integrated with workflow of organisation

Available solutions to network management problem


Current technology

Key players

Shortcomings of current NMS architectures

Future trends

Compiled by Craig Hinton

(c) CyberManage 1999

Network management is the set of actions that ensures that all network resources are put to productive use as best as possible. It consists of maintaining all network resources in good shape and making them available to users in accordance with the users' expectations. The person who performs network management is called a network administrator or a network manager. The earliest computer networks were simple, consisting mainly of one or more mainframes connected to a few peripherals. Since the number of network resources was quite small, managing such networks was relatively simple and ad hoc techniques were sufficient. In comparison, today's networks are considerably more complex and in addition, network complexity is constantly increasing. Network complexity arises mainly from two aspects: the large number of devices and the diversity of devices on the network. Typical networks may consist of hundreds or thousands of devices. It is quite common for organisations to have networks with one PC per individual. Besides, today's networks are typically composed of a variety of devices such as PCs, workstations, file servers, printers, routers, hubs, firewalls, etc. Each device on the network could be manufactured by a different vendor and as a result, even the characteristics of similar devices could be widely dissimilar. Because of the increased network complexity, we need to use automated tools to perform network management. An added problem is that networks are dynamic. Networks typically change constantly. We are frequently adding more devices or replacing old devices with newer ones. As organisations grow, the network also grows. More machines are added and as the number of machines on a LAN increases, the LAN is often broken up into segments which are connected by routers. Further, vendors often come up with new devices offering improved capabilities. Such devices are often incorporated into networks replacing older devices. Keeping track of a changing network necessitates the use of sophisticated network management tools. Lack of reliability of network components is another motivating factor for good network management tools. Large networks are typically built using communication links that traverse long distances. These communication links may fail because they are subject to hostile environmental factors such as inclement weather, people severing cables while digging trenches or even users tripping over a cable in the machine room. In addition, machines may crash due to errors in the operating system. Printers may jam or run out of paper/toner etc. Disks may get corrupted causing file servers to become unavailable. Or hardware components may fail bringing down a network device. Tracking and rectifying such failures in network components are other important actions where Network Management tools are useful. We define a network management system (NM system) as a methodology and a set of tools that help in performing network management. In this section we describe the set of desirable features of an NM system in the form of a network administrator's wish list. At this point, we are not concerned with whether the items on this wish list are easy to provide, how much they cost or even if it is even possible to provide the features listed. The main objective of this section is to capture all that one could possibly want from a NM system. A NM system should help in rectifying network faults. Many organisations provide a helpdesk where employees call if they experience any network problems. The helpdesk staff records the problem and take corrective action. This form of management is often called Reactive Network Management. In contrast, a NM system may autonomously monitor the network to detect faults. When faults are detected, the NM system records it and may either take corrective action on its own or inform the appropriate personnel who then decide what to do. This form of management is often called Proactive Network Management. Proactive Network Management is generally better since it minimises the impact on the users. Ideally, a network fault should be detected and rectified before users even become aware of it. Often a single network fault could appear as a number of different faults. For example, if a link goes down, all machines on the other side of the link may appear to be down. A NM system should provide the ability to correlate multiple network faults and identify which fault is the root cause and which ones are side effects. When a new device is added to a network, some form of customisation or configuration may be required. For example, the port speeds may have to be set or a device may have to be told what its IP address is. The NM system should help simplify this process. In addition, the NM system should be able to monitor devices and perform any management actions required by them. It is important for the NM system to be able to handle all devices on the network, regardless of the manufacturer of the device. It is also important that all devices be accessible using a single user interface. Most networks are dynamic, with frequent addition and removal of devices. In addition, as networks grow, they may also be split into multiple pieces and connected using gateways. The NM system should ease the task of managing changes in network configuration. For example, it should help in keeping track of which IP addresses have been assigned and what the IP addresses of each device are. A good NM system should simplify the task of monitoring network performance. It should help in identifying and removing network bottlenecks. For example, an inordinate amount of network traffic may be routed through a single gateway resulting in poor response times observed by users. The NM system should be able to detect this situation and help in reconfiguring the network to alleviate the problem. Maintaining a history of past network problems and the reasons for their occurrence can be useful in future planning. For example, if it is apparent that a certain device fails often, we may decide to replace all such devices with an equivalent device from a different vendor. Organisations often need a mechanism to track the usage of network resources by various users. This mechanism will be useful if an organisation decides to implement a policy of charging users based on their resource usage. Even otherwise, an accounting mechanism will be useful in the analysis of network usage. Network security is a top priority for most network administrators. The NM system should aid the task of enforcing network security. It should help in detecting and preventing security breaches. For example, the NM system should maintain logs of important events such as people logging into bridges or routers. Also, if a security violation has been observed, the NM system should provide facilities for identifying the violator. Going a step further, it should be possible to set up some kind of tripwire so that an alarm is raised when a hacker breaks into the network. Mechanisms should be provided to record the activities of the hackers and track them down. In many networks, identical software may be installed on multiple systems. When a new release of the software becomes available, it is often necessary to upgrade all the systems. Performing this manually is cumbersome and error prone. It is desirable to have an automated mechanism for distributing the upgrades. This is another area where a good NM system can help the administrator. The capabilities of the NM system should grow with the network. It should not be necessary to throw out a NM system and buy a new one just because the network size crossed some threshold. Ability to access the NM system remotely is another item on the administrator's wish list. The network administrator may not always be able to access the NM system from its main console. It is useful to permit him/her to access the NM system from a variety of locations, perhaps even from home. It is important that the administrator interact with the same kind of user interface to the NM system, regardless of where the access is from. It is also important to ensure that remote access is provided securely. Unauthorised persons should not be able to access the NM system and start messing with the network. The NM system should be easy to use. Specifically, the NM system should be usable by a person with limited training. Highly skilled network administrators are expensive and difficult to find. The NM system should be inexpensive. The software should be inexpensive and it should run on inexpensive hardware. It should not be necessary to buy expensive or special purpose hardware to run the NM system. Often organisations have their own established policies for reporting and recording network problems. They may also have established methods for ordering and procuring new equipment. The NM system should be able to integrate well with the existing policies and methodologies of an organisation. In this section we discuss solutions to Network Management, starting with a brief history followed by a description of currently available network management solutions from various vendors. We also discuss some of the future trends in network management. In the initial stages of networking, when the networks were relatively small, there was little done by way of network management. Generally, one or more system administrators employed a variety of ad hoc methods to perform primitive network management. Typically, the administrator would walk up to the machine, log on to it and execute commands on it to perform the required management operations. As remote access commands such as rlogin, rsh and telnet became available, the administration task was somewhat simplified, since the administrator could connect to multiple machines from a single location. However, it was essential that the machines were up and in an appropriate running state. For these, remote access commands are useful. UNIX tools, like ping, could be used to check if a particular device was connected to the network. Ping basically sends a small packet to a device asking it to echo the packet back to the sender. If there is a path to the device and if it is up, the ping packet returns to the sender. This way one can check if a device is up and connected to the network. Another tool called traceroute is available to trace the path packets take in getting from one point in the network to another. This tool can be used to determine the network configuration, albeit in a cumbersome manner. Monitoring network load was generally a tough problem. In the case of Ethernet networks, the rate of packet collisions provided an indication of whether the network was overloaded. Also there were tools called network analysers, that connected to the network and collected statistics on the amount and type of traffic on a single portion of the network. In many of the currently available NM solutions, the NMS is organised as an underlying component called the framework on which applications are run. The framework provides some standard features such as a graphical user interface and an SNMP protocol engine. The framework may also come with a set of standard applications, such as those which interpret (display and allow updates of) standard MIB objects, discover the devices on a network, etc. The NMS vendor only supplies the framework and some standard applications. Device vendors develop the agent software and also develop applications on top of one or more frameworks. These applications enable the management of their devices using the NMS framework. One might ask why the management application should be developed by device vendor rather than the NMS vendor. The main reason is that the device vendor is the only one who knows how the device is to be managed. If, for example, the device has some private MIB objects, the NMS vendor has no way of knowing what the objects mean or how they should be interpreted. In addition, a network may consist of a wide variety of devices, each with its own specifics. The NMS vendor has no way of understanding each and every device category. The key players in the NMS framework market are HP, Sun and Cabletron, accounting for about 73 per cent of the total market. The respective products are called HP OpenView, Sun NetManager and Cabletron Spectrum. All three products offer a number of network management features, along with facilities to manage view and modify standard MIB modules. These products are somewhat limited in their portability; they run only on a small set of high-end workstations. Device vendors are usually under pressure to deliver their product to the market quickly. However, as noted above, in addition to developing the device itself, the vendor is required to develop the agent software and a management application. The current NMS architecture of a framework plus applications offers substantial power to device vendors in order to develop sophisticated management applications. But the first problem a device vendor faces is having to learn the APIs provided by the framework. An added problem is that these APIs have not been standardised. Therefore, management applications are not portable across frameworks. As a result, a device vendor typically decides on one particular framework and develops the management application on top of that framework. Device customers are then required to purchase that specific framework and the management application. If a customer has two devices from two different vendors and the corresponding management applications run on two different frameworks, the customer has to purchase the two frameworks and possibly two different workstations to run them. In addition, the network administrator at the customer's site is required to learn how to use both network management systems. Device customers are generally reluctant to accept these terms. A customer may have a favourite NMS framework and pressure device vendors to develop management applications to run on that framework. Vendors resist this pressure since it is both expensive and time-consuming for them to develop applications on each framework. In addition, some device vendors target low price markets, where their customers may not be willing to purchase an expensive framework and an associated high-end workstation. These device vendors typically develop a stand-alone management application. Although a stand-alone application may be harder to build, it can be built to run on less expensive hardware. A new trend in network management is RMON, Remote MONitoring. A RMON device sits on a network and gathers information on network traffic and also records SNMP traps. RMON devices may also be instructed to perform some automatic actions based on SNMP messages they see. A NMS may communicate with a RMON device to obtain information from it or instruct it on what to do. A new standard has been defined to represent the MIB parameters supported by RMON devices. Another trend that is just beginning to show up is the use of web technology in network management.

Read more on Business applications