Printer Friendly

Managing SNMP LANs.

SNMP, the Simple Network Management Protocol, is the basis of the network management architecture for Ethernet networks. Its open architecture is intended to allow equipment from many vendors to operate in the same network, served by a single network management system.

Further, the network management system can be provided by any of a number of companies providing fully compliant SNMP NMSs (Network Management Systems).

MIB diversity and NMS

In practice, the system works somewhat differently. Vendors of Ethernet equipment have adopted MIB-2 (Management Information Base) that complies with the basic core functionality requirements of the SNMP protocol architecture and gives each device its personality. However, most vendors also have additional functions they include in their MIBs as proprietary extensions. For specific types of equipment like bridges, routers, and intelligent 10Base-T wiring hubs, those extensions allow the units to gather information and perform functions over and above the minimum SNMP MIB-2 requirements.

Obviously, the manufacturers want to differentiate their products by adding superior functionality and richness of feature sets to enhance their products' positions in the marketplace while still maintaining the basic SNMP compatibility required by the market.

While the diversity of feature sets between vendors' routers, for instance, is a healthy thing, it does require that the customer's SNMP NMS, regardless of its source, be able to request the full range of information from each type of equipment in the network, and properly interpret that information from each equipment type for the network operator. As a result, that diversity of proprietary extension imposes a flexibility requirement on the NMS to handle a wide range of possible MIBs in the network, so the NMS does not become a limiting factor in future company decisions to add new equipment types to the network.

The SNMP architecture actually has two functional areas which are of day-to-day importance to the network operations community. A third area of daily involvement lies in the protocol stack used by the network, but is not a direct function of the SNMP environment.

SNMP alarm traps

Certain events like the loss of connection and the presence of certain types of faulty packets can be detected by the MIB-2 agents in Ethernet LAN (SNMP) devices and an out-of-tolerance threshold can cause an alarm.

The alarm or "trap" that results is a message, containing alarm information which is dispatched over the Ethernet environment of a preselected address. That address is, of course, the NMS.

Often in larger systems, that alarm trap travels through an array of gateways, routers, segments, and wide area network channels to reach the NMS. The alarm message is interpreted by the NMS and the information presented on the screen.

The presentation is based on the sending agent address and the alarm information contained in the trap.

Alarm traps are initiated by an SNMP device at its own discretion when it observes a critical condition that falls outside of the acceptable limits defined by the user. They constitute a "cry for help" system which does not use polling of the covered entities for alarm information.

The inherent collision protection furnished by the Ethernet physical layer services assures simultaneously occurring random alarm trap messages are not lost in the network.

SNMP information retrieval

SNMP MIBs also look at and record many other types of information including the number of packets on the network segment, faulty packets, packets to and from that device, and many others.

This information can be gathered by the NMS through a polling process. It is often used in troubleshooting problems and building longer term information bases for network loading and capacity planning analysis, billing, and many other functions.

The NMS and, through it, the network operators determine the information gathered from the network entities, which entities are asked for information, what data is requested, and the timing of the requests.

Protocol stack operation

The two areas of SNMP operation take care of alarms, troubleshooting, and information gathering from SNMP entities on the Ethernet network. However, that does not completely cover the problems that can occur on a network.

Networks with multiple protocol stacks riding on an Ethernet physical layer are proliferating.

PCs using a TCP/IP stack today are mixing with DECnet applications and SNA terminal distribution support on the same physical system. Networks, both simple and complex, suffer from protocol problems. Such problems require troubleshooting information which is often at higher layers, and beyond the visibility of SNMP systems.

In these instances, the network as seen from the SNMP entities seems to be operating properly, but user reports indicate bad response time or outright outages.

Protocol problems require remote test equipment for fast troubleshooting and fault isolation. The Sniff Server from Network General and the Net Probe from H-P are examples of remotable testers that can be located throughout the network to identify protocol problems and other malfunctions across the system.

The use of multiple units at critical network locations can allow operations to quickly locate problems that might otherwise require days of troubleshooting.

Eliminating downtime

Downtime in a network can best be eliminated by making the necessary network status information available to the network operator in real time. The best ways to do that are these:

First, use an advanced SNMP NMS that is capable of sensing and displaying problem information for all network entities quickly. If it further has the ability to analyze information and offer suggestions about trouble locations and causes, so much the better.

Second, maintain an active program of modeling network performance for each of the protocol stacks and for the Ethernet level. Use the models to predict network overloading in advance to avoid problems and outages.

When problems do occur, the information base provides a baseline of normal network operation against which to compare the results of the present troubled operation. Differences will often point to the network problems.

Third, use remotable network diagnostic systems like H-P and Network General devices throughout the network to gain visibility of all aspects of network operation in the troubleshooting process.

Fourth, be sure that service support is contracted for each component of the network, and that the response time paid for by the company matches the criticality of the outage caused by failure of the device.

SNMP Ethernet systems can operate smoothly, with availability levels near those of WANs with the same device counts, provided they are managed carefully and the proper steps are taken to assure problems can be identified and cleared quickly when they do occur.
COPYRIGHT 1991 Nelson Publishing
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1991 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Local Area Networks; simple network management protocol
Author:Pruitt, James
Publication:Communications News
Article Type:Tutorial
Date:Nov 1, 1991
Previous Article:Smith College network lets students, staff communicate everywhere.
Next Article:Dual-loop token ring checks out at Roses Stores.

Related Articles
The race is on for leadership in network management.
National Westminster Bancorp triples response time with reorganized network.
How and why to re-engineer your network.
IBM frees users from master-slave strictures of SNA.
Controlling microwave links in wireless networks.
Controlling microwave links m wireless networks
How to secure switches and routers: security-in-depth philosophy marries traditional network security technologies with implementations. (Special...
Potential wi-fi security risks.

Terms of use | Copyright © 2016 Farlex, Inc. | Feedback | For webmasters