Better tools for a harder job - SNMP-compliant systems are better than proprietary ones - Special Focus: Network Management - Technology Information - Cover Story

Communications News, Sept, 1997 by M. Michael Drummer

As networks combine functions that were created as separate pieces, network management has become more and more com-plicated. No matter whether you came from the data or voice side of the new network equation, something is going to be unfamiliar to you.

If you were used to dealing with servers, workstations, NIC cards, Category 5 wiring, bridges, and routers, now you're adding phone systems, DSU/CSUs or channel banks, and phone lines.

Then you have to make sure that voice traffic, leased line data traffic, dial-up data traffic, fax traffic, Internet access, and the software, device drivers, and protocol stacks all function smoothly together. Users don't understand (or care) that these devices and programs were never originally meant to go together. All they want is faster, more, and zero downtime.

Your bosses have business concerns that lead them to expect that you will manage all this with fewer resources, less training, and less time.

Equipment is becoming more interoperable. Vendors work together in standards committees to develop technology guidelines that will be common to all equipment supporting that standard.

Multifunction switches and integrated access devices combined with standardized testing protocols are pointing the way to simplified, more effective network management relatively soon, if not as soon as we'd like.

Managed equipment is more expensive -- about a 25% premium for the managed hub over the "dumb" one-but the savings in time over the long run will more than make up the difference.

Today there are really three different approaches to network monitoring and management. The first is a particular vendor's proprietary protocol. Practically any vendor will offer his own version of real-time queries of his product, as well as some batch performance data, perhaps with an equally proprietary reporting scheme.

Having to have a monitoring station for each vendor's equipment, and learning the vendors' different software schemes and commands, is time-consuming and inefficient.

IBM's Netview has a quasi-standard status. It will show you much about your IBM, IBM-compatible, and Netview-compatible equipment. Unfortunately, there is a ton of equipment available today that does not support a Netview monitoring scheme at all. The same is true of Hewlett Packard's Openview, Sun Microsystems' SunNet Manager, Computer Associates' Unicenter, and so on.

The industry is settling on a standard that comes from the world of Ethernet and the Internet and TCP/IP: SNMP (Simple Network Management Protocol). Most vendors are making their equipment SNMP-compliant, which means that consoles will be able to read what is going on all through the network -- not only the NIC cards, hubs, repeaters, bridges, routers, switches, servers, DSU/CSUs, but the network topology itself

SNMP-compliant devices and objects have three components: the SNMP agent, the SNMP MIB (Management Information Base), and perhaps SNMP traps. Agents collect the appropriate data that they have been told to collect, store this data in a MIB, respond to queries from the SNMP management console, and manage commands (such as resets and restarts) from the console.

MIBs keep track of IP addresses, active TCP connections, etc. The list of things to monitor and keep track of is really enormous. The trick for the network administrator is choosing what is necessary to monitor and what would just be nice to keep track of

Traps tell the management station that some resource is at a critical value. Traps can be set up so that the trap messages are sent immediately to the management console (a real-time warning). Or they can be set up so that messages are sent to the device's MIB to be sent to the management console when requested (polled).

SNMP gives a lot of control to the network manager, who decides which agents, MIBs, and traps are set up. Ultimately, a network using SNMP will enable a thorough documentation of what goes on in the network -- critical information for analysis and planning.

All the planning tools are useless if your capacity planner cannot correlate organizational work load parameters (credit card transactions, orders placed, product units shipped) with network resources (bandwidth, processor cycles, disk space).

Network managers can no longer stop at technical knowledge. The network is a business-critical resource that requires an understanding of the industry it serves. The equivalent business tool to SNMP for the network manager is the Service Level Agreement (SLA). The correctly negotiated SLA allows a networking group to rise above a purely reactive help desk level.

Good SLAs reflect what the users of the network need to get their work done. Does the data entry clerk need subsecond response time? That is the same question as: Will the organization pay for the network infrastructure and network expertise to ensure it some percent of the time? It's not magic; it's business.