At the last moment, the president of your company has decided to have a videoconference the next day. You need to configure the network so his presentation goes off without a hitch. Sure, you have SNMP-compliant equipment and a systems-management package that cost a bundle, but you still have to reconfigure each server and router manually. That's a ton of work in a short span of time. But help is on the way.
A new technology emerging from the snmpconf (Configuration Management with SNMP) working group will let network administrators change network behavior from a central location using a single interface. The heart of the snmpconf is the policy MIB module. And there's good news on the vendor side, too: Gold Wire Technology, IPOptical, NAI Labs at Network Associates, RedCreek Communications, Riverstone Networks, Sitara Networks, SNMP Research International and other vendors have already begun work to support the snmpconf technology. The working group expects to complete all work planned for the policy MIB module around the time of this month's IETF meeting.
Work in the IETF snmpconf will make it possible to cost-effectively develop and deploy easy-to-use management applications that can ignore many of the details of variation from one vendor to the next. This approach has a number of benefits:
Experts on the configuration of routers and servers are expensive and in short supply. Snmpconf lets these experts create configuration templates that nonexperts can use to correctly configure systems. This can free up the experts for more productive duties.
The ability to deploy new systems and configurations more effectively allows for faster implementation of services. This reduces the length of time from the request stage until the new service is actually in place and can generate revenue.
Configuration information will be transferred more efficiently. With snmpconf, templates of the configuration information are sent to each system that's applied locally, as opposed to the current practice of sending the value for every configuration parameter. With snmpconf, instructions could be sent telling the system to configure all interfaces to allow customers that have paid for premium service to receive priority forwarding.
Because all information is SNMP-based, tying configuration changes to faults and utilization counters will be easier. This will enhance the ability to perform fault, capacity and performance management.
Existing SNMP-based code will be reused, enabling vendor and user familiarity with the technology.
When used with SNMP version 3, a fully fleshed-out security system will be provided. SNMPv3 has a security infrastructure that lets you protect information from unauthorized disclosure and controls who can perform certain functions.
Policy-based reporting of faults and SLAs (service-level agreements) will help both network operators and their customers.
Extensibility will let you support a multivendor network with different models and releases.
Network failures do occur. The snmpconf work coexists with models that require both CLI (command-line interface)- and SNMP-based access for authorized users from a number of places in the network.
A comprehensive set of standard-configuration objects may be tied to an extensive number of already-defined SNMP MIB objects. This commonality should help vendors create more useful and flexible applications.
Equipment vendors also are interested in this approach; it leverages significant investments already made in their products' CLI- and SNMP-based infrastructures and the management applications that support them. The snmpconf work gives vendors a way to address customer concerns about the complexity and scale of CLI-based configuration and control systems. CLI-based configuration control, along with the transfer of configuration files, is currently the primary method used to configure systems. Since it can co-exist with both, snmpconf gives administrators the best mix of flexibility and security.
Why SNMPConf Now?
A number of factors make the snmpconf work possible:
The security system in SNMPv3 is now available from several vendors. It has the flexibility to meet the requirements of even complex environments, and can improve the level of security for configuration operations desired in many situations.
Few people know how to use CLIs effectively, and configuration operations are becoming more difficult as networks offer new and more complex services, such as VoIP (voice over IP) and videoconferencing. For many networks, this scarcity of talent is hampering growth.
The IETF's Policy Framework working group has discussed the concept of management information at different levels. The snmpconf working group is addressing both policy-based and general areas of configuration management with SNMP, since all configuration information is related.
Operators have been performing policy-based management for years. Recently developed, however, are a set of terms to express it and a way to standardize operations that can greatly leverage the scarce, highly skilled resources necessary to run a network infrastructure.
Many different concepts are attached to the term "policy," creating some confusion. The snmpconf working group provides a common-sense definition: A policy is the practice of applying management operations globally on all managed objects that share certain attributes. For example: All model-X routers from a particular vendor should run version 1.2 of that vendor's OS.
Policies can also be quite complex, they can be abstractly stated, and they can mean quite a lot of implementation work. For example: All VoIP traffic should receive service equivalent to regular phone service in quality.
The ability to express policies at higher levels of abstraction and have computers map them to lower levels enables the creation of management applications that are effective and easy to use. Input from local network operations experts makes this mapping possible.
Four levels of abstraction can be used in a policy-enabled SNMP management system. These levels map well to current operational models:
Domains -- Areas of technology, such as service quality or security. Sales- and businesspeople commonly think in these terms. People often discuss these domains keeping in mind technology- or application-specific areas, such as IPsec (IP security) and DiffServ (Differentiated Services).
Mechanisms -- Technologies used within a domain. For example, in the DiffServ domain, RED (Random Early Detection) might be used as one of the mechanisms that devices employ to support DiffServ. The experts map from the domain to mechanism- and implementation-specific levels. This enables more effective use of these scarce resources, while making it possible for the businesspeople to have new services turned on more rapidly.
Implementation-specific -- Describes special capabilities to basic mechanisms that differentiate vendors. These differences often result from the implementation approach used for the product. For instance, if a vendor produces an interface card with capabilities beyond what is standard, the vendor might create a private MIB module that exposes these parameters. If the vendor wanted to simultaneously configure many of the interfaces based on a set of selection criteria, it would create an implementation-specific MIB module into which these defaults could be placed.
Instance-level information -- Refers to parameter values that have been associated with a specific instance in a managed element. It is impossible to have an implementation- or mechanism-specific MIB module without an underlying instance-specific MIB module.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
2009 IT Salary Survey: Meager Raises, Solid Prospects
Though raises are notably smaller than a year ago, and job security’s shrinking, IT careers are looking safer than many others in this economic downturn. Get all the findings in InformationWeek's 2009 IT Salary Survey. Available FREE for a limited time.
REPORTS
ANALYTICS
Follow 
