Search the Catalog
Windows NT SNMP

Windows NT SNMP

By James D. Murray
1st Edition January 1998
1-56592-338-3, Order Number: 3383
464 pages, $34.95, Includes CD-ROM

Chapter 3.
Network Management and SNMP

In this chapter:
What Is Network Management?
System and Network Management
Functional Areas of Network Management
To Network or Not To Network . . .
Network Management Using SNMP

In this chapter we look at the concept that inspired the creation of SNMP: network management. We've talked briefly about network management, but what do we really mean by this term?

What Is Network Management?

Ask ten different people what "network management" is and you will receive ten different answers. This isn't so bad if the ten people you ask are just walking around the local shopping mall (and if you count each "I don't know" as a separate answer). But when the ten people are in your company's network engineering group or the Management Information Systems department, you may begin to suspect that something is amiss. Now throw in another ten different answers from the salesmen and marketing types. You've now realized that with all these different definitions of network management, probably very few people know what it really is.

This is really nobody's fault. A network can be managed on several different levels. At the lowest level is network maintenance. The technicians at this level use crimpers, wire cutters, soldering irons, digital multimeters, and network analyzers to manage the network's "physical plant." They argue about the benefits of 10BaseT over 10Base2 cables and remark on how much better the network is operating now that they replaced those 75 ohm terminators with the 50 ohm'ers. Network maintenance people may also talk fondly of the time they "pinned some lid's coax," but that shouldn't concern you (unless you are operating an amateur radio obnoxiously and without a license).

At the next level are the folks in a group we might call configuration management. This is where decisions are made involving the planning of the physical and logical construction of the network. The configuration is defined by the devices connected to the network, how they are connected, and what is used to connect them. Configuration decisions include how to segment the routers, what kind of system management software to use on the hosts, whether to provide fixed IP addresses or use a DHCP server, and how we convince the people in finance that we need T1 service for our Internet connection. Anger one of these people, and they'll configure the router on your segment to swallow all packets originating from your workstation--and then claim for days that they are "working on the problem."

At the next higher level are the network administrators. Once the network's configuration is stable (but is it ever, really?), the netadmins sit atop their management-given thrones and reign supreme over the network. It is their task to perform logical configuration and service operations, such as monitoring the number of available ports on hubs and routers, adding the 300th user to a server licensed for only 256, finding the Network Interface Controller that's abandoned the concept of CSMA/CD, noting how little bandwidth is available on the company's Internet connection between the hours of 9:00 a.m. and 6:00 p.m., and answering--or ignoring--all email sent to "helpdesk." A netadmin is either chasing or being chased, sort of like Harrison Ford in Bladerunner or The Fugitive.

Management or Administration?

The terms management and administration are often used synonymously, but they are actually two different aspects of the same concern. Administration is concerned with forming policies, performing accounting and cost analysis, and maintaining facility, equipment, and personnel records. Management is concerned with the execution of administrative policies, delegating responsibility, and making sure that all is running smoothly. You could say that administration is mostly strategic, while management tends to be more tactical and logistical. Both also require a fair amount of diplomatic skill.

And at the highest level are the network users themselves--the most helpless "managers" of any network. For a user, performing network management is usually no more than logging in and out of servers, deleting old files, and occasionally changing a password or a default printer queue. From a user's point of view, access to the network should be fast and the network itself should provide most of the services the user will need. The real network managers just want to keep the users from accidentally (or purposely) screwing up the network.

So, a fair answer to our original question is that network management is a collection of processes and policies used for maintaining the health and efficiency of a computer network, regardless of the network's size or the type of work performed upon it.

System and Network Management

We've talked about network management. Another term that you probably have heard is system management. Although these terms are often used as if they refer to the same concepts, they are not interchangeable. They do, however, have some overlap in their definitions, and that is usually the source of confusion. Both types of management involve collecting data from devices, such as routers, servers, and workstations; however, they differ in how the data is used.

System management is the process of monitoring and maintaining individual devices, either configured as stand-alone units or connected to other devices as a network. System management activities include installing new and updated software, making backups, monitoring free disk space and power levels, configuring user accounts, and installing and removing system services.

Network management, which we've looked at briefly, includes the collective functions used to monitor and maintain the health of a network at the device level. How the network is performing is based on the capacity and current level of operation of its devices. Functions performed by a device that do not impact the performance of the network, such as communicating with a local peripheral device, are typically of no concern to network management.

Both system and network management focus on the monitoring and control of devices. But system management is concerned with a device as an independent entity, or as a member within a logical group of related systems. Network management is concerned with a device as only a small part of the anatomy of a network. Another way to look at it is this: is your concern for the health of only a set of specific devices, or is it for the health of an entire network?

The overlap in these concepts is where one leaves off and the other begins. You should be able to see how performing system management functions, such as backing up a large amount of data on a server or updating a router with buggy firmware, can affect a network. And network management functions, such as restricting the amount of network traffic that can be routed, can certainly affect individual systems on a network.

To get a basic idea of how, why, where, and when network management is performed, we need to have a look at one possible model of managing a computer network.

Types of Nodes

The basic model of network management groups all nodes on a network in the following categories:

Each managed node will run an agent process that services requests for management information made to the managed node by management nodes. When a request is received, it is checked to see if the sender is authorized to make the request. If so, the agent collects the request information from the node and returns the information to the management node in the form of a response.

A management node is typically a workstation operating a network management system in the form of a software application with an interactive menu-driven or graphical user interface. Management nodes may also be automated software processes called remote monitoring (RMON) probes, whose only purpose is to collect management information from managed nodes.

A node can be both a managed node and a management node at the same time--for example, a workstation that is running both an agent process and a network management system. Such a node is referred to as a bilevel entity.

The picture of distributed management becomes clearer if you imagine that most devices on a network are capable of collecting information on their performance and operational status, and then presenting that information in a standardized way. The management information is collected and processed using network management software and is organized into a useful picture of the overall state and health of the network.

Local vs. Remote Management

Manufacturers typically design network devices so that they may operate without any form of network management; however, usually some form of local management, such as a front panel or dumb terminal interface, is required to configure the device. Network management may be added later on as an upgrade of the device's firmware, or as an additional hardware assembly that is attached to the device.

SNMP's Own Terminology

At this point, you have probably recognized SNMP's parallel to the client/server information systems model. SNMP does not use overloaded and overused terms such as "client," "server," and "database," and instead either defines its own terms or uses those existing terms defined by OSI network management practices. Using specific terminology helps avoid the misinterpretation of SNMP concepts by people who have differing views and opinions of precisely what things "client" or "database" represent.

Not all network elements contain useful information about their physical or logical corner of the network. In fact, many network devices do not use the network to perform their primary functions at all, and many are not even aware that they are attached to any kind of a network. Consider a device that converts data signals from one format to another. Let's say you attach an optical fiber to the device's input interface, and a pair of copper wires to its output interface. The device is only aware of a few things: the signals it receives from the fiber, the process it uses to convert the signals from one data format to another, and the converted signals it transmits on the copper lines. Such a device will probably have a front panel with a few lights to indicate its present state, a few buttons used to enter data, a digital readout to display information, and possibly a simple menu. A serial interface might also be supported that is used to attach an asynchronous serial (dumb) terminal to access local device management information in the form of character-based menus. Controlling a device using its physical interface is called local management.

Now imagine that you had thousands of these devices spread out all over a city, state, or continent. As we discussed briefly in Chapter 1, Introduction to SNMP, you would find it very costly, in terms of both time and money, to travel to the location of each device to modify its configuration and monitor its performance. You would need some form of remote management that would allow you to access all of the devices in the field from a single point.

How would such remote management work? Working with the device you currently have, you could easily attach a modem to the device's serial port and allow administration personnel to call in remotely to monitor the device. The only problem with this plan is that you must have one modem per device; you would therefore tie up one phone line for as long as you were connected to the device. An expensive prospect, especially if you have hundreds of devices and you need to monitor them all constantly!

Let's see if we can improve this plan. The next thing to consider is some type of management proxy server. This would be a computer that contains specialized software designed to allow the remote management of your devices. The server would have a direct serial connection to each device and would support several dial-up modem connections. All a manager would need to do is dial up and connect to the server and then request management information from a specific device. The server would then either collect the device information that you requested (and format it nicely for you to browse) or simply pass on the management menus already present in the device's firmware.

This is a better solution in that you do not require one modem per device, although you do need a server that can handle many serial connections. There is also the added expense of the server itself and the cost to write and maintain the server's specialized management software.

An alternative to the centralized management server is a distributed form of management, where each device exists as a peer on a network, and can be queried by management systems that have network access (sound familiar?). The network could be based on the data that is being processed by the device. Special management commands could be included in the actual data being processed (in-band management), or the device could support some other type of network that is only used to convey management information (out-of-band management).

Functional Areas of Network Management

Network management is both a framework and a set of processes for planning, implementing, and maintaining computer networks (a network management paradigm, if you will). There are many different network management standards groups, each with its own concept of how networks should be managed, and even what the definition of the term "network management" is.

All models of network management have the same central themes, such as security and configuration, performance, and fault monitoring. The more complex network management models also include network administration functions, such as planning, support, asset records, and accounting and cost management.

Many people believe that network protocols themselves are network management frameworks; they think that if a device supports a management protocol, then it must therefore support a management framework. However, this is certainly not the case. Although many system and network management protocols do contain specific information on device configuration and provisioning, performance monitoring, and alarm reporting, the protocol itself is only a tool used to provide a structure for interpreting the management information. The protocol is not the management framework itself.

Rather than discuss a specific network management paradigm (there are many books written on the topic of network management that already do this), this section briefly presents some functional areas that are commonly found in most network management philosophies. Each of these areas is applicable to platforms ranging from the largest and most complex network to the simplest, non-networked workstation.

Configuration Management

The configuration of a network is determined by the types of devices that populate the network and their current operational parameters. Configuration management is therefore primarily concerned with the physical and logical connections of routers, bridges, hubs, and hosts, and with how each of these types of devices is configured to operate. There are actually three separate aspects of configuration management:

You can see all three of these aspects of configuration management in the CMOS setup program of a typical PC. The inventory of all hardware components includes disk drives, video and storage adapters, peripheral ports, and network interface controllers. The read-only data associated with each device, such as manufacturer's name, model and serial number, and firmware revision, is all part of the inventory information.

The configuration is a map of how all items in the inventory are connected together. For a network configuration, this map shows how each network node is physically and logically connected to all other nodes on the network. For device configuration in a network, this map indicates which drives are controlled by which adapter and which cards are plugged into which type of bus. The configuration will also indicate whether features such as Advanced Power Management (APM) and Desktop Management Interface (DMI) are present and active.

The provisioning is all the variable parameters that indicate how the node is to functionally perform. Provisioning items for a workstation include the time and date, capacity of the floppy and hard disk drives, memory cache settings, hard disk addressing features, and settings of all hardware peripheral ports. The controlling parameters for the APM and DMI features are also provisioned information.

A system or network management framework provides a single interface that may be used to read, compare, and change the configuration, inventory, and provisioning of many networked devices. This framework includes a database of all possible settings in the form of manuals, online help files, or successive calls to technical support. Unfortunately, there is no single management application that can manage the configuration of all devices. This makes a typical network management system a collection of many different software applications for managing many different types of devices.

Fault Management

When something unexpected happens on a network, some sort of signal might be raised, or you might observe a change in the operational condition of a device. Both of these events may indicate that the network has experienced a problem. If the problem has a negative effect on the service of the network, then it is considered a "fault." The detection, identification, isolation, reporting, and correction of both problems and faults is the concern of fault management.

Fault management is the most important form of system or network management. The ability to quickly detect a service-affecting problem, report it to a management device, and possibly apply corrective action is a mechanism that typically takes precedence over all other forms of management.

Network faults may be detected reactively or proactively. Reactive fault detection occurs when a fault is already present in the network. For example, a router detects that a network device has stopped responding, or that two devices are using the same network address. The router will then send out a reactive notification (called an alarm or alert), which signals that a fault has been detected. Much reactive management occurs in the form of users calling the network administrator with problem reports.

Proactive fault detection involves identifying an existing condition as the source or symptom of a problem that may eventually affect the service of the network. A server with a hard disk that has filled to more than 90% of its capacity may be an indication of a potential fault (the fault actually occurs if the disk is filled to 100% of its capacity). A network device that is reporting that more than 5% of the packets it has received are damaged may not be considered a fault at the moment, but it is an indication that a problem currently exists and a fault is likely to occur.

Just what is considered to be a problem? Usually, any event that is unintentional and service-affecting is a problem that requires immediate attention. Devices that have lost power and broken network connections are the most common, immediate, and service-affecting types of faults. Problems created by bugs in software or firmware, or a device provisioned with incorrect information, are also common sources of problems.

To predict when and where a fault might occur requires the added expense of extra monitoring equipment, detailed information of the operation of the network, and the additional network bandwidth required by the proactive fault detection processes. Because of the added development time and costs involved, you are likely to find significant proactive fault detection built into the management systems for only the largest types of networks.

Performance Management

A network is said to be performing well if there is at least a minimal acceptable level of available bandwidth present, and if the nodes are able to process network traffic within their workload capacity--in other words, there is lots of room to move around and nobody is overworked or overloaded.

Performance management involves monitoring network performance and tuning the network as necessary. What type of data provides a measure of performance depends upon the type of network. The most common type of performance data is usually at the packet level, and includes the following:

A significant number of bad packets or bad packet transmissions usually indicates some type of problem. Devices or communications links that are unexpectedly removed from service and routers that have insufficient memory to handle their work load are also factors that hurt performance.

Some network devices are able to gather statistics about the network at the signal level. The attenuation (decrease in power of a signal) or margin loss of the electromagnetic signal itself may indicate that a specific segment of a network requires a repeater, or perhaps that a section of cable is damaged or degrading.

Performance monitoring involves observing not only a device's current statistics, but also a history of its performance. Observing the history of a performance indicator will give an idea of what has been happening with the device in the past few hours or days, and helps to determine if the system has been, or will be, experiencing problems. For example:

Other Functional Areas

Many other forms of management may be in use in a particular network management framework, including the following types:

To Network or Not To Network . . .

By now you may be asking, "Why isn't network management a part of every device?" Network management is a common option on most network routing devices. And thanks to popular operating systems, such as UNIX, Novell NetWare, and Microsoft Windows, and protocol suites such as IPX/SPX and TCP/IP, it is fairly easy to add network management to most file servers and workstations that are network hosts.

But there are still many devices that do not directly support network management, or even a standard form of management by a proxy. For a manufacturer to even consider the expense of adding network management to a device, the following criteria must be met:

The management interface must be standardized and extensible
The management interface is the presentation of management data to other devices on the network. Obviously, all devices sharing a common form of management must have the same management interface. And when such an interface has been ratified as an international standard by one or more standards organizations and widely adopted by industry, then the credibility of the management interface is greatly increased.

The management interface must be extensible
Networks rarely contain only devices that are completely homogeneous and compatible. In fact, anything from a supercomputer to a kitchen appliance may be directly attached to a network, or indirectly attached using a proxy. For this reason, a management interface must be extensible enough to be able to support any type of information necessary to monitor and control any networked device.

The management interface must be portable
If you manufacture many different types of network devices, or if you support a wide variety of network technologies, then cost considerations are very important. You must try to reuse as many of the hardware and software components that you develop as possible. Be sure to use a network management protocol that can be supported by a wide variety of devices and that can be implemented as a single software package that has been ported to many different operating systems.

The management mechanism must be inexpensive
While a perfect, all-purpose, drop-in, plug-and-play network management solution does not exist, nor will ever exist, the fundamental management mechanism can be generic enough to be included in an unmodified state in a wide variety of devices. If this is the case, then only the specific code needed to manage a particular device needs to be developed, integrated, and supported by the device's manufacturer.

The management mechanism must be implemented as software only
If a management system requires that a specific management hardware device be integrated into every managed system, then a manufacturer is not likely to adopt it, citing a poor cost versus benefit ratio as the reason. And there are so many types of network devices that can be managed that constructing common management hardware devices for all of them would be an enormous design and standardization effort that would require many years to complete. Such an effort would likely end up being cost-prohibitive.

Other manufacturers must support the management mechanism
A standard management system is of no interest if no one is using it. On the other hand, if manufacturers within an industry look around and realize that most of their competitors' products support a popular form of network management, then you can bet that they'll be rushing to include it as well.

Customers must want and even demand the management mechanism
Above all, give the customers what they want, but also give them what they need. Network management is often present on a customer's "must have" list of features when purchasing a network system or device, but few customers will have a network management framework in place, or even a plan for deploying a system of network management. The network management solution you offer must be standardized, useful, and, above all, simple.

Network Management Using SNMP

SNMP fits perfectly into the model of network management that we have just discussed. SNMP is designed around a distributed network management framework. Each network node collects management information that describes its past and present state, and makes this data available to management systems also residing on the network.

The SNMP Management Model

SNMP defines two types of management entities: managers and agents. You may also think of these entities as "those who manage" and "those who are managed." You probably already have personal experience with this model (but note that SNMP has yet to incorporate cubicles, status reports, and 9:00 a.m. Monday morning staff meetings as part of its managerial requirements).

A network management station (NMS) is typically a computer that is used to run one or more network management system (also, confusingly, NMS) applications. Medium- to large-scale network management systems are usually built on top of a third-party software platform called a network management suite (you guessed it--NMS), such as HP OpenView and IBM NetView. The management station is used by the human manager to issue requests for management information from managed nodes. The station receives the requested information and then displays the management data in a useful way.

The role of a management agent is to monitor one or more network nodes, collect data on their operation (management information), and report this data to the management system when it is requested. Most of the work in SNMP management is performed by the management applications running on a management station. Why? Because a manager's computer and its resources are typically dedicated to the task of management, while a managed node usually has more important things to do.

A node is typically a host to either a management system or a management agent; if this were always the case, the SNMP management model could be simple indeed. But SNMP entities may also have one or more operational variations:

It is possible for a node to contain both a network management system and a management agent. A very good example is a Windows NT workstation running the SNMP service and an SNMP network management application. In fact, it is likely that all SNMP management nodes will also contain an SNMP management agent so they may be recognized and identified by other management systems.

Remember there may be at least two versions and several flavors of SNMP in use on a network. A node that supports both SNMPv1 and SNMPv2 is said to be "bilingual," and it is more likely that the management systems will be the bilingual nodes on a network.

An SNMP proxy agent is a network node that performs management services on behalf of another device that does not (or can not) support an SNMP agent. Peripherals and test equipment that may not actually reside on the network can be proxied, as can processes running in an operating system.

Many other system and network management protocols exist. If a node supporting a non-SNMP management protocol can be proxied by a multi-lingual SNMP agent that is able to translate requests into a form the node can process, then the node may reside within the SNMP management model.

Devices that cannot supply any form of management data at all are not part of the SNMP model.

Community Names

SNMPv1 defines a community-based administration framework used to manage SNMP elements. Each SNMP community is a group that contains at least one agent and one management system. The logical name assigned to such a group is called the community name. The community name is physically encoded into the SNMP messages sent by each member of the group, and in this form it is referred to as a "community string." The community string is used by the message receiver to identify the community for which the message intended.

A managed node indicates that it belongs to a specific community by accepting or rejecting requests containing a specific community string. For example, if an SNMP agent accepts all requests containing the community string "public," then the agent is asserting that it belongs to the "public" SNMP community. If the same agent rejects SNMP requests containing the community string "private," then the agent does not consider itself to be a member of the "private" community. All management nodes belong to SNMP communities for the purpose of interacting with managed nodes. A management node belongs to a particular SNMP community if it sends SNMP messages that contain the name of the community.

The assignment of acceptable community names to managed nodes is performed by the human network managers, and may be on many things, such as function (the PRINTER community), location (the "Engineering Lab" community), user (the "Software Group" community), or device manufacturer (the "PairGain Technologies" community). And community names will usually not be modified unless there is a significant change in the administrative configuration of the network.

If an SNMP agent is not provisioned with any community names, then it will typically accept and process SNMP requests containing any community string. Such a node effectively belongs to all SNMP communities on a network.

Figure 3-1 shows a map of several SNMP communities in a local area network. All of the nodes depicted support an SNMP management agent. Most nodes exist in only one community, but some exist in two or three. For example, the router is assigned to both the "Engineering Lab" and "campus" communities. And the printer server belongs to the "campus," "PRINTER," and "public" communities. The community labeled "All Communities" includes all of the SNMP-managed nodes that are currently not assigned a community name, so they effectively belong to all SNMP communities. And because a network management application may typically send SNMP messages to any community with a known community name, most management nodes will fit into the "All Communities" community as well.

Figure 3-1. SNMP communities

 

SNMP Proxy Agents

I mentioned earlier in this chapter that a proxy agent, or simply "a proxy," is a network node that performs management services on behalf of another device. An SNMP proxy allows a device that does not support SNMP protocol requests (or even network communication itself) to be monitored and controlled using SNMP.

A proxy agent allows SNMP to be used to do the following things:

To support an SNMP agent, a device must have enough memory capacity and CPU horsepower to support at least a small operating system and a network protocol stack. Many special-purpose devices, such as telephones, fax machines, printers, and modems, are not designed to support any type of network management, or even a network interface. The network management of such devices must therefore be accomplished by using a proxy.

The proxy agent itself is an SNMP agent process running on a network device. The device monitors the non-SNMP devices for specific management information, which is stored and made available to SNMP management nodes. The device may be monitored directly by the agent, such as using the AT command set to communicate with a modem, or indirectly using sensors to collect temperature, voltage, and signal strength data of the device. A proxy agent may also be running on the device that is being managed, but the device is unaware of the agent process.

The Microsoft SNMP service is itself a proxy agent for any manageable devices accessible by a Windows workstation, such as modems, printers, and network interface controllers. A proxy can also be used to manage software processes that are running in the Windows operating system without the processes explicitly supporting SNMP.

SNMP Gateway Agents

A proxy may also act as a gateway that translates management requests from one management protocol to another. The proxy does not actually perform management operations, but only acts as an intermediary between management systems and devices that use incompatible network management protocols.

For example, the message formats used by the two versions of SNMP are sufficiently different that a device supporting SNMPv1 cannot interpret requests made by an SNMPv2 management system and vice versa. A proxy therefore must be used to translate the SNMPv2 requests to SMNPv1 for the managed device to process, and the SNMPv1 responses from the device must be translated to the equivalent SNMPv2 messages for the management system to correctly interpret.[1]

The device that is being proxied may reside on the same network as the proxy agent (such as a group of workstations) or be physically attached to the proxy (such as a bank of modem cards plugged into a motherboard) or be remotely attached (such as a cable or infrared connection to a printer). It is only important that intelligible management information somehow be conveyed between the managed device and the proxy.

A proxy may be designed as a gateway to allow several SNMP-manageable devices to be accessed using a single network address. Requests for management information would be made by SNMP to the proxy, and the proxy would pass the request on to the appropriate managed device. The response would then be returned from the device to the proxy and then passed on to the NMS. The proxy gateway could also function as a single trap destination for multiple agents, with the proxy being responsible for forwarding the traps to their proper final destinations.

A proxy gateway may also act as a firewall and provide a single point that performs all UDP validation (packet filtering) and PDU authentication (application filtering). Address checks could be made to verify that an SNMP message originated at an address listed as authorized to make Get or Set requests. Invalid and unauthentic requests are discarded by the gateway.

Proxy agents may seem to solve a number of problems. However, in some cases, the use of a proxy agent is only a short-term, stopgap measure. All too often, it is tempting to write a proxy "translator" rather than building full management support into a device that is capable of supporting a management agent. Table 3-1 summarizes the pros and cons of proxies.

Table 3-1: Pros and Cons of Management Proxy Agents

Proxy Pros

Proxy Cons

Adds pseudo-SNMP management to devices that would not otherwise be SNMP-accessible.

 

Isolates proprietary and arcane management protocols from the public network.

 

Allows network elements to support multiple protocols. Consolidates multiple agents to a central access address.

 

Potentially quicker implementation than a full protocol stack and SNMP agent.

 

Used as a (possibly) quick way to make a non-SNMP node accessible via SNMP.

Often difficult to design and implement.

 

May not make use of available full management capabilities of device.

 

Requires additional network elements or processes.

 

Adds an extra level of complexity to debugging.

 

Design may make troubleshooting of network more difficult.

 

Implementers may believe (dangerously) that a short-term, stopgap proxy measure is a good, long-term solution.

1. Note that in this case, using bilingual management systems or agents would remove the need for the proxy.

Back to: Windows NT SNMP

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
 International | About O'Reilly | Affiliated Companies

© 2001, O'Reilly & Associates, Inc.
webmaster@oreilly.com