Moving from Proprietary Management to SNMP

There have been many false starts on the road to integrated network management. The problem of multiple management consoles became obvious in the mid-1980s as LANs grew.

Initially, vendors such as AT&T and IBM designed proprietary systems and tried to develop all the needed functions themselves. They jury-rigged existing applications into integrated suites and published proprietary APIs so that third parties could send information to their management consoles.

At that time, users were generally moving away from proprietary systems and toward industrywide standards. The ISO developed a suite of management specifications, dubbed CMIP (Common Management Information Protocol) and CMIS (Common Management Information System).

Unfortunately, these standards w ere too complex for vendors and users alike. They did find a niche, however, in large telecommunications networks from companies such as AT&T and Pacific Bell. And they may still eventually work their way into corporate networks.

The IETF (Internet Engineering Task Force), an ad hoc task force that handles common network problems, has had the most success in tackling management issues. The vendor-independent group's work is not considered proprietary.

Rather than creating an all-encompassing standard like CMIP or CMIS, the IETF aimed to keep its work simple; it even named its protocol SNMP--the Simple Network Management Protocol. The initial goal of SNMP was to ease physical network management (e.g., identifying a faulty wiring hub or router). To this end, the group outlined a series of common functions, such as running an error-checking test.

The IETF recognized the myriad of incompatible equipment. But rather than forcing conformity, SNMP allowed a central console to store management in formation in databases known as MIBs (Management Information Bases).

As the IETF completed its SNMP specification, network management platforms began to emerge. Rather than relying on proprietary protocols, vendors based their systems on SNMP, which quickly became a de facto standard.

But even though SNMP soon won widespread support, it wasn't perfect. SNMP was designed to work with TCP/IP, which meant that SNA (Systems Network Architecture) and DECnet users had to install separate TCP/IP lines to funnel information to central management stations. Also, SNMP's first iteration included no security features. Large companies with highly sensitive data found this a major limitation.

In response, in 1992 the IETF developed a second version of SNMP, dubbed SNMP 2. This version has moved along slowly. Only a handful of vendors have shipped SNMP 2-compliant packages, and few organizations are using them.

One strength of the original version was its automatic discover feature, which found a nd identified new network devices. That's incompatible with SNMP 2's security, which requires that a device supply a security clearance to be connected to a network.

Security administration is another problem area. To implement SNMP 2 security, a company must maintain and coordinate a handful of different databases; this adds significant overhead.

In June, Steven Waldbusser--manager of network development at Carnegie Mellon University (Pittsburgh, PA) and a leading SNMP architect--outlined a set of software conventions to ease security administration. Waldbusser wants to expand the use of SNMP 2 at Carnegie Mellon. Currently, the university, which has 7000 computers, relies on SNMP and Telenet for network management. SNMP gathers network fault information and then relays it to central consoles. Telenet configures remote devices.

Why two different products? SNMP isn't suited to remote configuration because it supports only one error code, while Telenet works with more error codes but lacks security. Consequently, an intruder with a protocol analyzer can pick off remote-device passwords and IDs. Waldbusser would like to use SNMP 2, which includes security features and supports 15 error codes, to handle both information gathering and remote configuration.

Because of such obvious benefits, observers expect a bevy of SNMP 2-compliant gear to appear soon. Cabletron, Cisco, and SynOptics have already demonstrated such products.

Even though SNMP 2 has encountered problems, SNMP is still clearly the protocol of choice, and vendors have expanded its scope beyond physical network management. Suppliers such as Hewlett-Packard and SunSoft have delivered packages that allow network technicians to monitor PCs and workstations. Work is also under way to enhance the protocol to oversee applications software and DBMSes.