Network management is tradition-ally associated with the Simple Network Management Protocol (SNMP), yet few networks make real use of SNMP or other central management systems. The need for network administration is increasing as the number and diversity of devices rises, but standards-based management has developed relatively slowly. Moves are now being made to bring the Internet protocols up to date, but this may not be enough to spur widespread adoption. The problems lie in the low-level nature of SNMP, compared with the high-level goals of network managers.
SNMP is over 10 years old, and its predecessor, Simple Gateway Management Protocol (SGMP) was first developed 20 years ago. Networks have changed dramatically in that time. Instead of isolated local area networks (LANs), with the occasional wide area network (WAN) link, firms now deploy massive switched networks that link offices and buildings, and demand high-speed Internet connections. The number and variety of devices attached to networks has grown, and their capabilities have increased in complexity.
SNMP limitations
SNMP has coped poorly with this development, so firms are looking for alternatives. SNMP's shortcomings include security problems, the large bandwidth it requires and its inability to cope with new devices. In addition, it does not allow IT managers to make changes to the entire network easily. This means many network administrators simply choose not to use SNMP at all. Instead, vendors' solutions  or the command-line interfaces of devices themselves  are used for management. This often makes network management far more difficult than it should be.
The obvious solution is to update SNMP to include more facilities. To this end, SNMP version 3.0 has been ratified by the Internet Engineering Task Force (IETF) for some time, and provides better features than the preceding version. SNMP 2.0 suffered from poor security, thanks to poor authentication. Several more secure offshoots were proposed but never ratified. SNMP 3.0 addresses many of the limitations, but leaves the overall management architecture unchanged.
SNMP 3.0 adds user-based security, allowing access control to individual SNMP agents, backed with authentication and encryption of data. The view-based access control model (VACM) defined in RFC 2575 allows network managers to choose which attributes of an SNMP device each user can access and change. Previously, the only access levels were none, read-only or read-write for the entire SNMP entity. The new capability allows more tasks to be delegated to support staff without them introducing errors into device configuration, since they could be denied access to any properties unconnected with their tasks.
Another recent addition to SNMP management is Agent Extensibility (AgentX). This uses a system of master and sub-agents to allow a more complex model for a network node. The sub-agents connect to specific parts of the node  the storage and networking components of a server, for instance  and exchange information with the master agent. AgentX defines the protocol used for communication between the master agent and sub-agents. AgentX is not SNMP-based, although it has very similar semantics, but the master agent is an SNMP agent.
The advantage of AgentX is that for multipart hardware, a sub-agent for each part can be created. For instance, a chassis-based switch can have modules of different types, such as routing, switching and load balancing modules, each of which will have its own sub-agent. Similarly, a server may have components, such as adapter cards and peripherals, from different manufacturers. Each manufacturer can create its own AgentX sub-agent without having to worry about interfacing it with a proprietary server management system.
None of these changes alter SNMP's model of operation, which still requires configuration and fault management to be set up for each device. The goal of network management is to control the network as a whole, rather than as a series of individual items. This means proprietary systems that can only manage equipment built by a single vendor are not suitable. But a system that only manages one device at a time, irrespective of manufacturer--which is basically what SNMP does--fails to meet this requirement too.
Businesses simply want network management to ensure that the network is available and performing as it should. This is service-level management, requiring coordination between the devices on the network and measurement of what is going on, even if there are no error conditions. Remote Network Monitoring (RMON) is used to collect performance data from network devices. Typically, however, this is only partially implemented in devices such as switches and routers, and a separate hardware probe is needed to collect comprehensive statistics.
Obtaining network statistics allows IT managers to see whether the network is performing as it should, but this only works if the statistics are accurate and comprehensive. Versions of RMON that use 32bit counters cannot store enough data to provide good statistics for modern networks. And statistics alone will not necessarily bring problems to the attention of IT managers unless alerts are generated when problems occur.
Future developments
The Distributed Management Task Force (DMTF) is an industry grouping that promotes some alternative management standards. Its Directory Enabled Networks (DEN) initiative uses policy-based management stored centrally in an enterprise-wide directory, so that devices can be automatically configured to give set service levels to individual users.
However, DEN does not address fault management and so is not a complete solution. Because it does not come under the auspices of the IETF, it is also unlikely to be incorporated into Internet standards. The IETF's Common Open Policy Service (Cops) has a similar facility, but is designed for use with the Resource Reservation Protocol (RSVP) and does not integrate with SNMP at present.
The IETF has outlined its idea of what a modern network configuration management system should include in RFC 3139, published in June. This lays out how the IETF sees the problem of managing IP-based networks, and the capabilities such a system should include. It acknowledges that no standardised framework offers a way of configuring devices en masse to provide a particular service characteristic.
What is proposed is a higher-level network management framework able to configure multiple network devices based on the topology they are connected in, and the desired service levels and behaviour. This network-wide configuration is similar to the capability the DEN initiative is designed to achieve, but is intended to use existing Web standards wherever possible. This includes SNMP and Cops. By configuring the network as a whole, it should also be possible to audit all configuration changes and roll back to a previous configuration. With the per-device management used in SNMP, this is all but impossible.
An important concept in RFC 3139 is the configuration data translator. This takes generic, policy-based information and converts it to specific instructions for a network device. This translation of policy to configuration is normally the job of the network manager, who in turn needs to know the details of each device's configuration. By providing a standard way of representing policy information it should be easy to create the translators, either in software on a network management station or in the devices themselves.
It may be that software-based translators will communicate with the devices they are controlling through SNMP, since this would not require firmware updates for those devices. SNMP would therefore be invisible to the network manager, since only the policy-based interface would be used. However, this would provide a migration path from device-level to policy-level management.
SNMP has been improved, but it still only addresses some of the needs of modern network management. The IETF is planning a more sophisticated system, but standards approval is never a fast process and is not guaranteed to produce a workable solution. SNMP may not go away, but could eventually be hidden behind a more intelligent network management system.
This is one of the good article. I agree with the author. We need to have a better solution to manage the network as a whole. Without even having proper standard based way to manage the network(as a whole), the market expectation is much higher than that. i.e. Managing by service(above network layer). As per authors view, policy based management is a good solution.
I have doubt about DMTF based DEN solution here. DMTF standards are never widely accepted. I also have a feeling that SNMP will never die.