|
|
|
|
Simplifying SNMPv3
|
 |
|
September 18, 2003
By Bruce Boardman
|
|
Sometimes simple can be complicated. The Simple Network Management Protocol's new modular architecture and secure-management features in version 3 make adding onto the protocol easier, plus the protocol now encrypts management traffic so that SNMP can be used when you configure devices on the network. It's even backward-compatible with earlier versions of the protocol, so you can use it to manage SNMPv1- and v2-based devices. But SNMPv3 hasn't caught on yet in enterprise networks.
The major sticking point is that you can't use SNMP commands to set up the initial user ID and password for securing a managed device with SNMPv3. That means you must configure the user ID and password on your routers and switches with a manual or scripted CLI. For management applications, you'll have to input, store and maintain synchronized user ID and password pairs for all network devices to be managed.
|
|
Version 3's shortcomings haven't stopped some key vendors from supporting the protocol in their products. All the major router and switch vendors have supported it for several years. Cisco, for instance, has had full SNMPv3 support since IOS 12.0. On the management platform side, Aprisma's Spectrum, BMC Software's Patrol, Computer Associates' Unicenter, Hewlett-Packard's OpenView, IBM's Tivoli and Smarts' InCharge all support v3. Even Castle Rock Computing's SNMPc and MG-Soft's MIB Browser include SNMPv3 support. These management packages store a user ID and password in their database so they can securely communicate with, and manage, an SNMPv3-capable device. SNMPv3 is slowly catching on with cable broadband providers, too; Cox Cable and Time Warner, for instance, use SNMPv3 for securely managing their cable modem networks, and they've expanded on the spec with stronger encryption.
Entities and Engines
SNMPv3 has incorporated and extended earlier versions of the protocol so you can add new functions as modules without having to rewrite the protocol altogether. So if a new access model were developed for v3, for example, it would replace the existing one without affecting the rest of the protocol.
That's good news for network managers, because it means your existing SNMP software won't require a complete rewrite, and your new v3 software will work with previous versions. Although SNMPv1 and v2 rely on plain-text community strings and can't use v3 authentication and encryption, for example, you can still manage your v1 and v2 devices with v3. And vendors will be able to reuse code and upgrade functionality without overhauling their management software.
SNMPv3 doesn't use the traditional SNMP terms agent and manager. Devices and management components are entities in SNMPv3 parlance. One entity (formerly known as the agent) sits on a router, and the other entity (formerly known as the manager) handles application polling. The names may have changed, but the functions have not. Each entity has an SNMP engine and application (see "Start Your Engine,"). The SNMP engine has four functions--access control, security, message processor and dispatcher. Both the message processor and dispatcher modules come with SNMPv1 and v2 functions, such as processing sets and gets and formatting the SNMP data units, or PDUs (protocol data units).
Here's how the SNMPv3 engine works: The dispatcher is the gatekeeper for SNMPv3, and all message I/O goes through it. When an SNMP message is processed, the dispatcher determines the SNMP version of the message and sends it on to the message-processor module for parsing. If the dispatcher can't determine the version due to a malformed or illegal packet, for instance, it logs an error.
The message processor passes the message to the security subsystem or to the access-control subsystem, and then back to the dispatcher, which hands the message off to the SNMP applications. These applications are not conventional transaction-processing or database-query applications, for instance, but merely functions for initiating or responding to SNMP requests. Network-management applications issue command-generator applications to get information from routers, switches and hosts.
The command-responder application is the reverse side of the generator: It resides on routers, switches and host and responds to a get command, for instance. The notification originator and receiver applications send and receive traps and the proxy forwarder moves SNMP messages between management and managed entities when direct SNMP support isn't available.
|
|
|
|
|
|
|
|
RSS
