SNMPCONF Working Group M. MacFaden
Category: Best Current Practice Riverstone Networks, Inc
J. Saperia
JDS Consulting, Inc
W. Tackabury
Gold Wire Technology, Inc
Configuring Networks and Devices With SNMP
draft-ietf-snmpconf-bcp-04.txt
March 2, 2001
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document is for a variety of readers interested in the Internet
Standard Management Framework, the Simple Network Management Protocol
(SNMP).
In particular, it offers guidance in the effective use of SNMP in
configuration management. This information is relevant to vendors
Various Authors [Page 1]
RFC DRAFT Expires July 2001 March 2001
that build network elements, management application developers, and
those that acquire and deploy this technology in their networks.
1. INTRODUCTION
Data networks have grown greatly in size and complexity over the past
decade. This growth can be seen in terms of:
Scale - Data networks have grown in many dimensions:
they have more network elements, the network
elements perform a significantly wider range of tasks,
and there are many more interrelationships
within and between devices.
Functionality - network devices perform more functions.
More protocols and network layers are
required for the successful deployment of a wide array
of network services.
Time - changes to devices occur more often than in the
past. The need for dynamic configuration has grown faster than
set-and-forget style configuration.
Configuration of network elements that make up data networks is an
essential prerequisite to the deployment of services upon them. The
growth in size and complexity of modern networks increases the need for
a standard configuration mechanism that is tightly integrated with per-
formance and fault management systems.
The Internet Standard Management Framework, SNMP, is used successfully
to develop configuration management systems for a broad range of devices
and networks. A standard configuration mechanism that tightly inte-
grates with performance and fault systems is needed not only to help
reduce the complexity of management, but to enable verification of con-
figuration activities that create billable services.
This document describes Best Current Practices that have been used when
designing effective configuration management systems using the Internet
Standard Management +Framework (or, more colloquially, SNMP). It covers
many basic practices as well as more complex agent and manager design
issues that are raised in configuration management.
Significant experience has been gained over the past ten years in con-
figuring public and private data networks with SNMP. Policy Based Con-
figuration Management, PBCM, is a methodology of configuration dis-
tributed to potentially many network elements with the goal of achieving
consistent network behavior throughout an administrative domain.
Various Authors [Page 2]
RFC DRAFT Expires July 2001 March 2001
This document presents lessons learned from these experiences and
applies them to both conventional and policy based configuration systems
based on SNMP.
1.1. Document Organization
This document is divided into eight sections:
Section 1 - Introduction and document organization
Section 2 - Using SNMP as a configuration mechanism
Section 3 - Designing a MIB Module
Section 4 - Implementing a configuration agent
Section 5 - Designing and implementing configuration management
applications
Section 6 - Deployment and Security Issues
Section 7 - Policy Management
Section 8 - Example MIB Module for configuration
2. USING SNMP AS A CONFIGURATION MECHANISM
Configuration causes a discrete change in an element from one state to
another. While it often takes an arbitrary amount of commands and data
to make up configuration change, it is critical that the configuration
system treat the overall change operation atomically so the number of
states an element can transition to is minimized. A change request is
either completely executed not at all. This is called transactional
integrity. Transactional integrity makes it possible to develop reliable
configuration systems that can invoke transactions and keep track of an
elements overall state and work in the presence of error states.
2.1. Transactions and SNMP
Transactions can logically take place at very fine-grained levels such
as an individual object or in very large aggregations such as an entire
configuration file. For this reason, reliance on transactional integrity
only at the protocol level is insufficient.
MIB Module design plays a significant role in how well SNMP transaction
integrity will work. For example, The Structure of Management Informa-
tion Version 2 (SMIv2), RFC 2579, defines textual conventions which help
support configuration. The RowStatus object which defines a standard
object for the management of conceptual rows in a table is one example.
A RowStatus object can be used in many ways to help with transaction
control. For example, a single row activation where a single row is
equivalent to the level of transaction. When a RowStatus object is moved
to the active state, the entire row is 'committed'.
Various Authors [Page 3]
RFC DRAFT Expires July 2001 March 2001
In a multi-table scenario where the amount of configuration data must be
spread over many columnar objects, a RowStatus object in one table can
be used to cause the entire set of data to be put in operation or stored
based on the definition of the objects.
In some cases, very large amounts of data may need to be 'committed' all
at once. In these cases, another approach is to configure all of the
rows in all the tables required and have an "activate" object that has a
set method that commits all the modified rows.
It is possible for an SNMP-based management system to address all of
these issues effectively. Transactional control is an essential property
of a configuration management system.
2.2. Practical Requirements for Transactional Control
A well designed and deployed configuration system should have the fol-
lowing features with regard to transactions and transactional integrity.
1) Provide for flexible transaction control at many different levels of
granularity. At one extreme, an entire configuration may be delivered
and installed on an element or one small attribute may be changed. The
effects of a change should be commensurate with the change request. Very
granular changes should invoke behavior according to the change being
made. This is often termed "no surprises."
2) The transaction control component should work at any of the levels of
abstraction defined in section 8. The key point here is that it may
make most sense to configure systems at an abstract level rather than on
an individual instance by instance basis as has been commonly practiced.
In some cases it is more effective to send a configuration command to a
system that contains a set of 'defaults' to be applied to instances that
meet certain criteria.
3) An effective configuration management system must allow flexibility
in the definition of a successful transaction. This cannot be done at
the protocol level alone, but rather must be provided for throughout the
application and the information that is being managed. In the case of
SNMP, the information would be in properly defined MIB modules.
4) Time-indexed transaction control A configuration management system
should provide time-indexed transaction control. For effective rollback
control, the configuration transactions and their successful or unsuc-
cessful completion status must be reported by the managed elements and
stored in a repository that supports such time indexing and can record
the user that made the change, even if the change was not carried out
the system recording the change.
Various Authors [Page 4]
RFC DRAFT Expires July 2001 March 2001
5) The managed system must support transactional security. This means
that depending on where and who is making the configuration request, it
may be accepted or denied based on security policy that is in effect in
the managed element.
2.3. Best Practices in Configuration
Debugging is an integral part of the configuration process. To reduce
the chance of making simple errors in configuration, many organizations
employ the following change management procedure:
pre-test - verify that the system is presently working properly
change - make configuration changes/wait for convergence
re-test - verify once again that the system is working properly
This procedure is commonly used to verify configuration changes to crit-
ical systems such as the domain name system (DNS). DNS software kits
provide a diagnostic tools provided that allow automatic test procedures
to be defined. Strict adherence to this procedure ensures service
remains intact since any failure of the test detected after the change
can be rolled back to the prior state.
Likewise, a planned configuration sequence can be aborted if pre-config-
uration test results show the state of the system as unstable. Debugging
two sets of changes in large systems is often more challenging than one.
Networks and devices under SNMP configuration readily support this
change management procedure since the SNMP provides integrated monitor-
ing, configuration and diagnostic capabilities. For example, the Ether-
Like-MIB, RFC 2665, defines diagnostic tests as follows:
Various Authors [Page 5]
RFC DRAFT Expires July 2001 March 2001
dot3TestLoopBack OBJECT-IDENTITY
STATUS current
DESCRIPTION "This test configures the MAC chip and executes
an internal loopback test of memory, data paths,
and the MAC chip logic. This loopback test can
only be executed if the interface is offline.
Once the test has completed, the MAC chip should
be reinitialized for network operation, but it
should remain offline.
If an error occurs during a test, the
appropriate test result object will be set
to indicate a failure. The two OBJECT
IDENTIFIER values dot3ErrorInitError and
dot3ErrorLoopbackError may be used to provided
more information as values for an appropriate
test result code object."
::= { dot3Tests 2 }
There are times when configuration of a given element can impact other
network elements in a network. Configuring network protocols such as
IEEE 802.1D Spanning Tree or OSPF is especially challenging since the
impact of a configuration change can directly affect stability (conver-
gence) of the network the device is connected to.
An integrated view of configuration and monitoring provides an ideal
platform from which to evaluate such changes. For IEEE 802.1D Spanning
Tree, RFC 1493 provides the following object to monitor stability per
logical bridge.
dot1dStpTopChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of topology changes detected by
this bridge since the management entity was last
reset or initialized."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 4 }
Likewise, the OSPF MIB module provides a similar metric for stability
per OSPF area.
Various Authors [Page 6]
RFC DRAFT Expires July 2001 March 2001
ospfSpfRuns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the intra-area route
table has been calculated using this area's
link-state database. This is typically done
using Dijkstra's algorithm."
::= { ospfAreaEntry 4 }
The operational effects of a given implementation often differ from one
to another for any given standard configuration object. The impact of a
change to stability of systems such as OSPF should be documented in an
agent-capabilities statement which is consistent with "Requirements for
IP Version 4 Routers" [20], section 1.3.4:
A vendor needs to provide adequate documentation on all
configuration parameters, their limits and effects.
The above model is not fail safe, especially when configuration errors
are masked by long latencies or when configuration errors lead to oscil-
lations in network stability. For example, consider the situation where
loading a new software version on a device leads to a small, slow memory
leak brought on by a certain traffic pattern that went uncaught during
vendor and customer test lab trials.
Also, convergence in an autonomous system cannot be guaranteed when con-
figuration changes are made since there are factors beyond control of
the operator. And even for factors within the operator's control there
is little verification done to prevent misconfiguration such as in the
following example.
Consider a change made to ospfIfHelloInterval and ospfIfRtrDeadInterval
[22] timers in the OSPF routing protocol such that both are set to the
same value. Two routers may form an adjacency but then begin to cycle in
and out of adjacency, and thus never reach a stable (converged) state.
Had the configuration process defined above been employed, this particu-
lar situation would have been discovered without impact on the produc-
tion network.
3. DESIGNING A MIB MODULE
Well-thought out MIB module design is crucial for practical configura-
tion with SNMP. MIB Modules for configuration can and do scale and when
integrated with diagnostic, monitoring, and policy objects. Policy
objects represent information at an aggregate, or higher level of
Various Authors [Page 7]
RFC DRAFT Expires July 2001 March 2001
abstraction, than instance level ones. Taken together these all of these
objects can for a robust configuration subsystem.
This section provides specific practices used in MIB module design.
3.1. MIB Module design
This section describes specific design practices by drawing upon a fic-
tional MIB module called BLDG-HVAC-MIB as defined in Section 8. This MIB
module provides a means to control the heating/cooling system found in a
modern building.
3.1.1. Consistency in Modeling
One of the first tasks in defining a MIB module is the creation of a
model which reflects the scope of the management information.
3.1.2. Designing Configuration Objects
MIB modules can be thought of as logical models providing one or more
aspects/views of a subsystem. The objective for all MIB modules should
be to serve one or more operational requirements such as accounting
information collection, configuration of one or more parts of a system,
or fault identification.
Choosing only those aspects of a subsystem that are proven to be opera-
tionally useful.
In 1993, one of most widely deployed MIB modules supporting configura-
tion was published, RFC 1493, or the BRIDGE-MIB. It defined the crite-
ria used to develop the MIB module as follows:
To be consistent with IAB directives and good engineering
practice, an explicit attempt was made to keep this MIB as
simple as possible. This was accomplished by applying the
following criteria to objects proposed for inclusion:
(1) Start with a small set of essential objects and add only
as further objects are needed.
(2) Require objects be essential for either fault or
configuration management.
(3) Consider evidence of current use and/or utility.
(4) Limit the total of objects.
Various Authors [Page 8]
RFC DRAFT Expires July 2001 March 2001
(5) Exclude objects which are simply derivable from others in
this or other MIBs.
(6) Avoid causing critical sections to be heavily
instrumented. The guideline that was followed is one
counter per critical section per layer.
During the past eight years, additional experience has shown a need to
refine these criteria as follows:
1. Before MIB Module design, identify goals and objectives
for the MIB module.
2. 2. Minimalization is not explicit goal, but usability is. Be sure
to consider deployment requirements.
3. During configuration, consider supporting explicit
error state, capability and capacity objects.
4. When considering rule (5) above, consider the impact on
a management application. When deployment or modeling
experience shows that objects that can be derived are
useful for the management application, consider defining them rather
than requiring that they be derived.
3.1.3. Naming MIB modules and Managed Objects
Naming of MIB modules and objects generally follows a set of best prac-
tices. Originally, standards track MIB modules used RFC names. As the
MIB modules evolved, the practice changed to using more descriptive
names. Presently, Standards Track MIB modules define a given area of
technology such as ATM-MIB, and vendors then extend such MIB modules by
prefixing the company name to a given MIB Module as in ACME-ATM-MIB.
Object descriptors (the "human readable names" assigned to object iden-
tifiers) defined in standard MIB modules should be unique across all MIB
modules. However, MIB Modules do not define a naming scope. Generally,
a prefix is added to each managed object that can help reference the MIB
module it was defined in. For example, the IF-MIB uses "if" prefix for
objects such as ifTable, ifStackTable and so forth.
The names for MIB objects can include an abbreviation for the function
they perform. For example the objects that control configuration in the
example MIB Module in section 8 might include Cfg as part of the name.
The bldgHVACDesiredTemp object might have been better named bldgHVAC-
CfgDesiredTemp. These longer names were left out of the example in the
interest of simplify. Some have adopted this approach with good results.
The power of this approach is more fully realized when the names that
include the fault, configuration, accounting, performance and security
[34] abbreviations are combined with an organized OID assignment
approach. For example a vendor could create a configuration branch in
Various Authors [Page 9]
RFC DRAFT Expires July 2001 March 2001
their private enterprises area. In some cases this might be best done on
a per product basis. Which ever approach is used, Cfg might be included
in every object in the configuration branch. This has two operational
benefits. First for those that do look at MIB Object names through MIB
Browsers or other simple command line tools, the name can more com-
pletely convey the meaning of that object. Secondly, management applica-
tions can be pointed at specific sub trees for fault or configuration,
causing a more efficient retrieval of data and a simpler management
application with potentially better performance.
3.1.4. Using Summary Objects and State Tracking
Prior to making a configuration change, management software generally
will synchronize with agents and backup existing configuration.
The three factors that influence this process are:
1. Amount of configuration data to transfer
2. Frequency of change to the data
3. Accessibility of the data
To make this process simple and efficient, consider using the following
techniques in a MIB module.
1. Provide an object that reports the number of rows in a table
2. Provide an object that flags when data in the table
was last modified.
3. Send a notification (inform) to deliver configuration change
details which can be seen in Section 8
By providing an object containing the number of rows in a table, manage-
ment applications can decide how best to retrieve a given table's data
and may choose different access strategies depending on table size.
Once a table has been synchronized, keeping it synchronized requires an
object to monitor table state. An example is found in RFC 2790, Host
Resources MIB:
Various Authors [Page 10]
RFC DRAFT Expires July 2001 March 2001
hrSWInstalledLastUpdateTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the hrSWInstalledTable
was last completely updated. Because caching of this
data will be a popular implementation strategy,
retrieval of this object allows a management station
to obtain a guarantee that no data in this table is
older than the indicated time."
::= { hrSWInstalled 2 }
A similar convention found in many standards track MIB modules is the
"LastChange" type object.
For example, the ENTITY-MIB RFC2737 provides the following object:
entLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time a conceptual row is
created, modified, or deleted in any of these tables:
- entPhysicalTable
- entLogicalTable
- entLPMappingTable
- entAliasMappingTable
- entPhysicalContainsTable"
::= { entityGeneral 1 }
This convention is not formalized, and there tend to be small differ-
ences in what a table's LastChanged object reflects. IF-MIB, RFC2863,
[31] defines the following:
ifTableLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
creation or deletion of an entry in the ifTable. If
the number of entries has been unchanged since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { ifMIBObjects 5 }
So, if an agent performs a row modification via an SNMP SET on ifAdmin-
Status, the value of ifTableLastChange will not be updated.
Various Authors [Page 11]
RFC DRAFT Expires July 2001 March 2001
The final way to keep distributed configuration data consistent is to
use an event-driven model, where configuration changes are communicated
as they occur. When the frequency of change to configuration is rela-
tively low or polling a cache object is not desired, consider defining a
notification that will report all configuration change details.
Use an inform instead of a trap notification so that changes are reli-
ably communicated.
The use of notifications to communicate the state of a rapidly changing
object may not be ideal either. This leads back to the object design
question of what is the right level of granularity is.
Finally, having to poll many "LastChange" objects does not scale reason-
ably. Consider using some global LastChange type object to represent
overall configuration in a given implementation.
3.1.5. Advanced Synchronization Considerations
For very large tables or for tables whose data changes frequently, a row
count and LastChange-like object as described in the previous section
caching a whole table's contents may not work.
There are three design choices to consider: 1) Design multiple indices
to partition
the data in a table logically or break a table into
a set of tables to partition the data 2) Use a time-based indexing
technique 3) Define a control MIB module that manages
a separate data delivery protocol
Index Design
Index design has a major impact on the amount of
data that must be transferred between SNMP entities
and can help to mitigate scaling issues with large
tables.
Most tables in standard MIB modules follow one of two
indexing models: associative indexing or
positional/array-like indexing that can start from one (1).
When tables get to a very large number of rows,
using an associative indexing scheme offers the
capacity to retrieve only the rows of interest.
For example, if an SNMP entity contains a copy
of the default-free Internet routing table as
defined in RFC 2096, the ipCidrRouteTable
Various Authors [Page 12]
RFC DRAFT Expires July 2001 March 2001
will presently contain around 100,000 rows.
Since associative indexing is used and the nature of
the data in this table is partitionable,
synchronizing with a subset is possible. If this
table contained a simple index, there would have
to be at least one complete scan of the table.
ipCidrRouteEntry OBJECT-TYPE
SYNTAX IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular route to a particular destina-
tion, under a particular policy."
INDEX {
ipCidrRouteDest,
ipCidrRouteMask,
ipCidrRouteTos,
ipCidrRouteNextHop
}
If copying a large table is required, a simple positional index can
potentially increase the number of rows that can be sent in a PDU and if
the indexing is not sparse, concurrency can be gained by sending multi-
ple asynchronous non-overlapping collection requests.
Should requirements dictate new methods of access, multiple indices can
be defined such that both associative and simple indexing can coexist to
access a single logical table.
Two examples follow.
First, consider the ifStackTable found in RFC 2863 [31] and the ifInvS-
tackTable RFC 2864 [32]. They are logical equivalents with the order of
the auxiliary (index) objects simply reversed.
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer runs on
'top' of the other sub-layer. Each sub-layer
corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
Various Authors [Page 13]
RFC DRAFT Expires July 2001 March 2001
ifInvStackEntry OBJECT-TYPE
SYNTAX IfInvStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer runs underneath the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX { ifStackLowerLayer, ifStackHigherLayer }
::= { ifInvStackTable 1 }
Second, table designs that can factor data into multiple tables with
well-defined relationships can help reduce overall data transfer
requirements. The RMON-MIB, RFC 2819, demonstrates a very useful tech-
nique of organizing tables into control and data components. Control
tables contain those objects that are configured and change infrequently
and the data tables contain information to be collected that can be
large and may change quite frequently.
As an example, the RMON hostControlTable provides a way to specify how
to collect MAC addresses learned as a source or destination from a given
port that provides transparent bridging of ethernet packets.
Configuration is accomplished using the hostControlTable. It is indexed
by a simple integer. While this may seem to be array-like, it is common
use for command generators to encode the ifIndex into this simple inte-
ger to provide associative lookup capability.
The RMON hostTable and hostTimeTable represent dependent tables that
contains the results indexed by the hostControlTable entry.
The hostTable table is further indexed by the MAC address which provides
the ability to reasonably search a collection such as the Organization-
ally Unique Identifier (OUI) which is the first three octets of the MAC
address.
The hostTimeTable is designed explicitly for fast transfer of bulk RMON
data. It demonstrates how to handle collecting large number of rows in
the face of deletions and insertions by providing hostControlLastDelete-
Time.
Various Authors [Page 14]
RFC DRAFT Expires July 2001 March 2001
hostControlLastDeleteTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the last entry
was deleted from the portion of the hostTable
associated with this hostControlEntry. If no
deletions have occurred, this value shall be zero."
::= { hostControlEntry 4 }
2) Time Based Indexing The TimeFilter as defined and used in RFC 2021 as
well as in RFC2674 provide a way to obtain only those rows that have
changed on or after some specified time since the SNMP entity was
started (sysUpTime).
Since TimeFilter introduces rows based on time based indexing, a given
row can appear at many points in time which artificially inflates the
size of the table when performing classical getNext or getBulk data
retrieval.
3) Divide the Work If the amount of data to transfer is larger than cur-
rent SNMP design restrictions such as OCTET STRINGS or PDU sizes and
well as being overly volatile, consider deliver the data via separate
protocol and use a MIB module to control that data delivery process.
3.1.6. Octet String Aggregations
The OCTET STRING syntax is an extremely flexible and useful datatype
when defining managed objects that allow SET operation. An octet string
is capable of modeling many things and is limited in size to 65535
octets by SMIv2[5].
Since OCTET STRINGS are very flexible, the need to make them useful to
applications requires careful definition. Otherwise, applications will
at most simply be able to display and set them.
Consider the following object from RFC 1907 SNMPv2-MIB.
For example:
Various Authors [Page 15]
RFC DRAFT Expires July 2001 March 2001
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The physical location of this node (e.g., `telephone
closet, 3rd floor'). If the location is unknown, the value
is the zero-length string."
::= { system 6 }
Should an application be required to do more with this information than
be able to read and set the value of this object, a more precise defini-
tion of the contents of the OCTET STRING is needed.
When using OCTET STRINGS, avoid platform dependent data formats. Also
avoid using OCTET STRINGS where a more precise SMI syntax such as Inte-
ger32 or BITS would work.
There are many MIB modules that attempt to optimize the amount of data
sent/received in a SET/GET PDU by packing octet strings with aggregate
data. Example, the PortList TC in RFC 2674 is defined as follows:
PortList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Each octet within this value specifies a set of eight
ports, with the first octet specifying ports 1 through
8, the second octet specifying ports 9 through 16, etc.
Within each octet, the most significant bit represents
the lowest numbered port, and the least significant bit
represents the highest numbered port. Thus, each port
of the bridge is represented by a single bit within the
value of this object. If that bit has a value of '1'
then that port is included in the set of ports; the port
is not included if its bit has a value of '0'."
SYNTAX OCTET STRING
This saves on data transfer but has some limitations. Any changes in
object specification or version control is made more difficult, given
that the granularity of control in SMIv2 is a managed object. Any
change such as delete or add to the number of elements
Any change such as delete or add to the number elements encoded within
the object would deprecate the entire object.
Complex instance information is difficult to reference in particular
data kept in a managed object that is contained in an aggregate.
Various Authors [Page 16]
RFC DRAFT Expires July 2001 March 2001
Providing an SNMP Table to represent aggregate data does not have as
many limitations as encoding data into OCTET STRINGS and is the better
common practice.
3.1.7. Simple Integer Indexing
When indexing tables using simple Integers, start with one (1) and spec-
ify the maximum range of the value.
Since Object Identifiers are unsigned long values, a question that
arises is why not index from zero (0) instead of one(1)?
RFC 2578, Section 7.7, page 28 states: Instances identified by use of
integer-valued objects should be numbered starting from one (i.e., not
from zero). The use of zero as a value for an integer-valued index
object should be avoided, except in special cases.
Indexing from one simplifies implementation on the management applica-
tion side. Consider the following sequence
request expected response
sysUpTime -> sysUpTime.0
ifInOctets.0 -> ifInOctets.1
ifInOctets.1 -> ifInOctets.2
ifInOctets.2 -> ifInOctets.3
which allows simple management application iteration:
for (i = 0; i < something; i++ ) {
action(i);
}
whereas if one allows
a .0 instance to exist, a management application must
consider the following sequence:
request expected response
------- -----------------
sysUpTime -> sysUpTime.0
ifInOctets -> ifInOctets.0 <---
ifInOctets.0 -> ifInOctets.1
ifInOctets.1 -> ifInOctets.2
ifInOctets.2 -> ifInOctets.3
for (i = 0; i < something; i++ ) {
if (is_leaf(i) action();
}
Various Authors [Page 17]
RFC DRAFT Expires July 2001 March 2001
3.1.8. Indexing with Network Addresses
There are many objects that use IPv4 addresses (SYNTAX IpAddress) as
indexes. One such table is the ipAddrTable from RFC 2011 IP-MIB. This
limits the usefulness of the MIB module to IPv4. To avoid such limita-
tions, use the INET-ADDRESS-MIB, which provides a generic way to repre-
sent addresses for Internet Protocols.
3.1.9. Fate sharing with multiple tables
Fate sharing of SNMP tables should be explicitly defined where possible
using SMI macros such as AUGMENTS. If the relationship between tables
cannot be defined using SMIv2 macros, then the DESCRIPTION clause should
define what should happen when rows in related tables are added or
deleted.
Consider the relationship between the dot1dBasePortTable and the
ifTable, which have a sparse relationship. If a given ifEntry supports
802.1D bridging then there is a dot1dBasePortEntry that has a pointer to
it via dot1dBasePortIfIndex.
Now what should happen if an ifEntry that can bridge is deleted? Should
the object dot1dBasePortIfIndex simply be set to 0 or should the
dot1dBasePortEntry be deleted as well?
When two tables are related, the DESCRIPTION clauses should define the
fate sharing of entries in the respective tables.
3.1.10. Conflicting Controls
MIB module designers should avoid specifying read-write objects that
overlap in function partly or completely.
Consider the following situation where two read-write objects partially
overlap when a dot1dBasePortEntry has a corresponding ifEntry.
The BRIDGE-MIB defines the following managed object:
Various Authors [Page 18]
RFC DRAFT Expires July 2001 March 2001
dot1dStpPortEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The enabled/disabled status of the port."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 4 }
The IF-MIB defines a similar managed object:
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3) state
indicates that no operational packets can be passed. When a
managed system initializes, all interfaces start with
ifAdminStatus in the down(2) state. As a result of either
explicit management action or per configuration information
retained by the managed system, ifAdminStatus is then
changed to either the up(1) or testing(3) states (or remains
in the down(2) state)."
::= { ifEntry 7 }
if ifAdminStatus is set to testing(3), the value to be returned for
dot1dStpPortEnable is not defined, or, even worse, an agent returns a
misleading value. Without clarification on how these two objects inter-
act, management implementations will have to monitor both objects if
bridging is detected and correlate behavior.
When this situation has been detected, one of the two objects should
have the STATUS set to deprecated from future use.
3.1.11. Textual Convention Usage
Textual conventions should be used whenever possible to create a consis-
tent semantic for an oft-recurring practice.
Various Authors [Page 19]
RFC DRAFT Expires July 2001 March 2001
Textual conventions that have even the slightest chance of being reused
in other MIB modules ideally should also be defined in a separate MIB
module to facilitate sharing of such objects. For example, all ATM MIB
modules draw on the ATM-TC-MIB to define common definitions.
To simplify management applications use of a given set of managed
objects, consider using SNMPv2-TC based definitions:
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
Would better expressed as follows:
AcmePatioLightsEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
3.1.12. Persistent Configuration
Many SNMP agents implement simple persistence models. SNMP set requests
against MIB objects with MAX-ACCESS read-write are typically written
automatically to a persistent store.
There are methods to support explicit storage of configuration data. The
first method uses the Textual Convention known as StorageType [6] which
explicitly defines a given row's persistence requirement.
Examples include the RFC 2591 [23] definition for the schedTable row
object schedStorageType of syntax StorageType, as well as similar row
objects for virtually all of the tables of the SNMP View-based Access
Control Model MIB [15].
A second method for persistence simply uses the DESCRIPTION macros to
define how instance data should persist. RFC 2674 [24] defines explic-
itly Dot1qVlanStaticEntry data persistence as follows:
Various Authors [Page 20]
RFC DRAFT Expires July 2001 March 2001
dot1qVlanStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qVlanStaticEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing static configuration information
for each VLAN configured into the device by (local
or network) management. All entries are permanent
and will be restored after the device is reset."
::= { dot1qVlan 3 }
Best current practice is a dual persistence model where: 1) a volatile
memory configuration can be retrieved/updated 2) persistent boot config-
uration which is updatable and non-volatile.
3.1.13. Configuration Sets and Activation
An essential notion for configuration of network elements is awareness
of the difference between the set of one or more configuration objects
from the activation of those configuration changes in the actual subsys-
tem.
The document "Requirements for IP Version 4 Routers" [20], section 1.3.4
states:
A vendor needs to provide adequate documentation on all
configuration parameters, their limits and effects.
Any complex configuration should have a master on/off switch as well as
strategically placed on/off switches to control the sectional employment
of configuration data. These controls play a pivotal role during the
configuration process as well as during subsequent diagnostics. Gener-
ally a series of set operations should not cause an agent to act on each
object causing convergence/stability possibly to be lost on each and
every set. Ideally a series of Set PDUs would install the configuration
and a final set series of PDUs would activate the changes.
During diagnostic situations, certain on/off switches can be set to
localize the perceived error instead of having to remove the configura-
tion.
An example of such an object from the OSPF Version 2 MIB [27] is the
global ospfAdminStat:
Various Authors [Page 21]
RFC DRAFT Expires July 2001 March 2001
ospfAdminStat OBJECT-TYPE
SYNTAX Status
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The administrative status of OSPF in the
router. The value 'enabled' denotes that the
OSPF Process is active on at least one inter-
face; 'disabled' disables it on all inter-
faces."
::= { ospfGeneralGroup 2 }
Elsewhere in the OSPF MIB, the semantics of setting ospfAdminStat to
enabled(2) are clearly spelled out.
The Scheduling MIB [23] exposes such an object on each entry in the
scheduled actions table, along with the corresponding read status object
on the entry status:
schedAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The desired state of the schedule."
DEFVAL { disabled }
::= { schedEntry 14 }
Various Authors [Page 22]
RFC DRAFT Expires July 2001 March 2001
schedOperStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
finished(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of this schedule. The state
enabled(1) indicates this entry is active and that the
scheduler will invoke actions at appropriate times. The
disabled(2) state indicates that this entry is currently
inactive and ignored by the scheduler. The finished(3)
state indicates that the schedule has ended. Schedules
in the finished(3) state are ignored by the scheduler.
A one-shot schedule enters the finished(3) state when it
deactivates itself."
::= { schedEntry 15 }
Finally, a MIB module designer should not always overload RowStatus
objects to control activation/deactivation of a configuration. While
RowStatus looks ideally suited for such a purpose since a management
application can set a row to active(1), then set it to notInService(2)
to disable it then make it active(1) again, there is no guarantee that
the agent won't discard the row while it is in the notInService(2)
state.
The DISMAN-SCHEDULE-MIB's managed object schedAdminStatus demonstrates
how to separate row control from row activation. Setting the schedAd-
minStatus to disabled(2) does not cause the row to be aged out/removed
from the table.
3.1.14. Usage of Row notReady Status
It is useful when configuring new rows to use the notReady status to
indicate row activation cannot proceed.
When designing read-create objects in a table containing a RowStatus
object, a MIB module designer should first consider the default state of
each object in the table when a row is created via one simple createAnd-
Wait(5) PDU. If no default state is applicable but the object must be
set to some value, the DESCRIPTION clause should specify this object as
mandatory. In addition, an SNMP get of such an object then should return
a noSuchName error if the object has not yet been set. A read of the
RowStatus columnar object should return notReady(3) until all such
mandatory and non-defaultable objects have been set with acceptable val-
ues.
Various Authors [Page 23]
RFC DRAFT Expires July 2001 March 2001
Should a given implementation require more objects to be set than is
specified in a MIB module, an agent capabilities statement can be used
to define the additional objects using the CREATION-REQUIRES clause. Not
implementing the above may result in a management application being mis-
led that a transition to active(1) state will succeed without further
action by only polling the RowStatus object and receiving the notInSer-
vice(2) value from an agent.
3.1.15. SET operation Latency
Many standards track and enterprise MIB modules that contain read-write
objects assume that an agent can complete a set operation as quickly as
an agent can send back the status of the set operation to the applica-
tion.
Consider the following object that both reports the state of a garage
door as well as allows a SET operation to change a garage door's state.
acmePortGarageDoor OBJECT-TYPE
SYNTAX INTEGER { unknown(0), closed(1), open(2)}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current state of the garage door.
Most garage doors change state within 12 seconds."
::= { acmePortGarageEntry 2 }
With the object defined, the following example represents
one possible transaction.
Time Command Generator --------> <--- Command Responder
----- ----------------- -----------------
|
A GetPDU(acmePortGarageDoor.1.1)
|
| ResponsePDU(error-index 0,
| error-code 0)
|
B acmePortGarageDoor.1.1 == open(2)
|
C SetPDU(acmePortGarageDoor.1.1 =
| closed(1))
|
| ResponsePDU(error-index 0,
| error-code 0)
|
D acmePortGarageDoor.1.1 == closed(1)
|
E GetPDU(acmePortGarageDoor.1.1)
Various Authors [Page 24]
RFC DRAFT Expires July 2001 March 2001
|
F ResponsePDU(error-index 0,
| error-code 0)
|
V acmePortGarageDoor.1.1 == open(2)
....some time, perhaps seconds, later....
|
G GetPDU(acmePortGarageDoor.1.1)
|
H ResponsePDU(error-index 0,
| error-code 0)
| acmePortGarageDoor.1.1 = closed(1)
V
The response to the GET request at time E will often confuse management
applications that assume the state of the object should be closed(1). In
reality, the garage door is somewhere between the states open and
closed.
Aother implementation may reasonably assume to return the unknown value
since it may detect that garage door is in neither open or closed state.
In both cases, the response is not what most would expect.
One solution to the above problem is to consider separating desired
(settable) state from current state. ifAdminStatus and ifOperStatus
from RFC 2863 provide such an example of the separation of objects into
desired and current state.
A second solution requires providing a more detailed state machine for
read-write object which can be done alone or in combination with a spe-
cific control object. In the example above the enumeration could be
expanded to include a full state machine with states for closing(3) and
opening(4) and possibly jammed(5).
A second way latency can be introduced in SET operations is the way an
agent interfaces to the instrumentation of the managed subsystem. This
latency is not the result of the time it takes to accomplish some opera-
tion as in the door example above. It comes from several potential
sources. First, the time it takes the operational code to accept the new
configuration information from the SNMP agent and process it and
'install' the commands in the system. An example of this is when config-
uration changes are made to a routing system that has a large routing
table and the configuration changes cause a re-computation of a large
number of routes. A second related source of delay in this context is
the 'naturalness' of the interface between the instrumentation in the
operational code and the sub-agent. In some cases the operational code
will have been written without an consideration of management other than
flat files. In these cases, the structures in the operational code may
Various Authors [Page 25]
RFC DRAFT Expires July 2001 March 2001
not be well suited to any sort of dynamic change and thus will be some-
what clunky and inefficient until re-written. This would be true regard-
less of the management technology used. In these conditions, the agent
software will have to adapt as well as possible, and the management
software should consider this latency (and cost) when making changes.
3.1.16. Application Error Reporting
MIB Module designers should not rely on the SNMP protocol error report-
ing mechanisms alone to report application layer error state for objects
that accept SET operations.
Most configuration applications provide poor error reporting when they
receive SNMP protocol errors. These protocol errors are important and
should be reported but they are not intended to provide application
layer information. That information should be 'built-in' to the design
the managed system just as well written code provides context specific
error information. In the case of SNMP, those error returns can be con-
veyed in MIB Objects.
When a "badValue" error occurs, an application can update the applica-
tion state so management application can collect, analyze and report the
failure. A badValue does not necessarily mean the command generator sent
bad data. An agent could be at fault. Additional detailed diagnostic
information may aid in debugging the integrated system.
As an example of tracking errors, consider the hrPrinterTable from the
HOST-RESOURCES-MIB, RFC 2790:
Various Authors [Page 26]
RFC DRAFT Expires July 2001 March 2001
hrPrinterDetectedErrorState OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object represents any error conditions detected
by the printer. The error conditions are encoded as
bits in an octet string, with the following
definitions:
Condition Bit #
lowPaper 0
noPaper 1
lowToner 2
noToner 3
doorOpen 4
jammed 5
offline 6
serviceRequested 7
inputTrayMissing 8
outputTrayMissing 9
markerSupplyMissing 10
outputNearFull 11
outputFull 12
inputTrayEmpty 13
overduePreventMaint 14
Bits are numbered starting with the most significant
bit of the first byte being bit 0, the least
significant bit of the first byte being bit 7, the
most significant bit of the second byte being bit 8,
and so on. A one bit encodes that the condition was
detected, while a zero bit encodes that the condition
was not detected.
This object is useful for alerting an operator to
specific warning or error conditions that may occur,
especially those requiring human intervention."
::= { hrPrinterEntry 2 }
Notifications can also be used to signal configuration failures with
detailed failure information objects.
3.1.17. Designing Notifications
Notifications can play an important role in configuration. With SNMPv2c
and SNMPv3, informs allow the design of reliable, event-driven
Various Authors [Page 27]
RFC DRAFT Expires July 2001 March 2001
synchronization models that can aid configuration.
When designing new notifications, consider how to limit on the number of
notifications (traps or informs) that can be sent in response to a given
event. RMON I[30] defines a generic trap capability in the alarmTable
and provides one of many ways to prevent the quantity of notifications
from overwhelming a management system.
Another way to limit the volume of a particular notification it to
define situations where it need not be sent. A good example is the
frDLCIStatusChange defined in FRAME-RELAY-DTE-MIB, RFC 2115 [19].
frDLCIStatusChange NOTIFICATION-TYPE
OBJECTS { frCircuitState }
STATUS current
DESCRIPTION
"This trap indicates that the indicated Virtual Circuit
has changed state. It has either been created or
invalidated, or has toggled between the active and
inactive states. If, however, the reason for the state
change is due to the DLCMI going down, per-DLCI traps
should not be generated."
::= { frameRelayTraps 1 }
3.1.18. Control of Notification Subsystem
There are standards track MIB modules that define objects that either
augment or overlap control of notifications. For instance, FRAME-RELAY-
DTE-MIB RFC 2115 defines frTrapMaxRate and DOCS-CABLE-DEVICE-MIB defines
a set of objects in docsDevEvent that provide for rate limiting and fil-
tering of notifications.
In the past, agents did not have a standard means to configure a notifi-
cation generator. With the availability of SNMP-NOTIFICATION-MIB in
RFC 2573 it is recommended that the filtering functions of this MIB mod-
ule be used.
3.1.19. Transaction Control MIB Objects
When a standard MIB module is defined that includes configuration opera-
tions, thought should be given to providing transaction control objects
in places where they may have value. Here are some examples:
o Control objects that are the 'write' or 'commit' objects.
Such objects will cause all pending transactions (change MIB object
Various Authors [Page 28]
RFC DRAFT Expires July 2001 March 2001
values as a result of SET operations) to be committed to a perma-
nent repository or operational memory as defined by the semantics
of the MIB objects.
o Control objects at different levels of configuration granularity.
One of the decisions for a MIB module designer is what levels of
granularity that make sense. For example, in the routing area,
would changes be allowed on a per protocol basis only or by proto-
col area such as BGP? If allowed at the BGP level, are sub-levels
permitted such as per autonomous system? The design of these con-
trol objects will be impacted by the underlying software design.
RowStatus also has important relevance as a general transaction
control object.
3.1.20. MIB Modules and Instance Indexing
When defining new MIB modules, one should consider if there could ever
be multiple instances of this MIB module in a single SNMP entity.
There are a few MIB modules that assume a one to many relationship, such
as the SYSAPPL-MIB [RFC2287]. However, the majority of MIB modules
assume a one-to-one relationship between the objects found in the MIB
module and a given SNMP agent. The OSPF-MIB, IP-MIB, BRIDGE-MIB are all
examples that are defined for a single instance of the technology.
It is clear that single instancing of these MIB modules was not adequate
to support devices that support multiple instances of a given technol-
ogy.
While the ENTITY-MIB [RFC2737] can provide a means for supporting the
one-to-many relationship through naming scopes using the entLogi-
calTable. There are some drawbacks to this approach: 1) cannot issue
PDU request that span naming scopes
Given two instances of BRIDGE-MIB active in a
single agent, one PDU cannot contain a
request for dot1dBaseNumPorts from
both the first and second instances.
2) creates a dependency on the entity MIB itself
3.1.21. Use of special optional clauses
When defining integer based objects for both read-write and read-only
semantics, using the UNITS clause is recommended in addition to
Various Authors [Page 29]
RFC DRAFT Expires July 2001 March 2001
specification in the DESCRIPTION clause of any particular details.
The REFERENCE clause is also recommended to help an implementer track
down related information on a given object.
3.1.22. Conceptual Table Modification Practices
The RowStatus textual convention does not define when objects in a con-
ceptual row can be modified. In fact, it is often wrongly assumed that
objects:
1) either must all be presently set or none need be to make
a conceptual RowStatus object transition to active(1)
2) that objects in a conceptual row cannot be modified once
a RowStatus object is active(1).
When it is not clear as to when an object in a conceptual row is modifi-
able, it should be stated explicitly as in RMON-MIB [RFC2819]:
filterPktDataOffset OBJECT-TYPE
SYNTAX Integer32
UNITS "Octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The offset from the beginning of each packet where
a match of packet data will be attempted. This offset
is measured from the point in the physical layer
packet after the framing bits, if any. For example,
in an Ethernet frame, this point is at the beginning of
the destination MAC address.
This object may not be modified if the associated
filterStatus object is equal to valid(1)."
DEFVAL { 0 }
::= { filterEntry 3 }
3.1.23. MIB Object and Practice Reuse
Experience has shown that MIB modules are easier to understand and sim-
pler to implement when common conventions are employed.
Often, MIB modules often define a binary state object such as
enable/disable or on/off. Best current practice is to use existing Tex-
tual Conventions and define the read-write object in terms of a Truth-
Value from SNMPv2-TC [RFC2579]. For example, the Q-BRIDGE-MIB [RFC2674]
defines :
Various Authors [Page 30]
RFC DRAFT Expires July 2001 March 2001
dot1dTrafficClassesEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value true(1) indicates that Traffic Classes are
enabled on this bridge. When false(2), the bridge
operates with a single priority level for all traffic."
DEFVAL { true }
::= { dot1dExtBase 2 }
4. IMPLEMENTING SNMP CONFIGURATION AGENT
4.1. Operational Consistency
Sucessful deployment of SNMP configuration depends on understanding the
roles MIB module design and agent design play.
Both components must have been designed with an understanding of how
UDP/IP based SNMP behaves. A best current practice in MIB design is to
consider the idempotency of settable objects. Idempotency basically
means being able to invoke the same set repeatedly with the effect of it
being felt only once.
Here is an eample of the idempotency in action:
Manager Agent
-------- ------
Set1 (Object A, Value B) ---> receives set ok and responds
X<-------- Response PDU(ok) is dropped by network
Manager times out
and sends again
Set2 (Object A, Value B) ---> receives set ok (does nothing), responds
<-------- with a Response PDU(ok) dropped by network
Manager receives OK
Had object A been defined in stateful way, the set operation may cause
Set2 operation to fail owing to interactions with the operation from
Set1. If the implementation of the agent on the second request is not
aware of such a situation, the agent may behave poorly by actually re-
implementing the set request instead of doing nothing.
Logic is needed at these boundaries to provide operational consistency.
1. Integration of management applications and
agents. The MIB document is a contract between these two
entities that defines their behavior.
Various Authors [Page 31]
RFC DRAFT Expires July 2001 March 2001
2. The agent and the instrumented subsystem. In some
cases the instrumented subsystem will require
modification to allow for the dynamic nature of
SNMP-based configuration, control and monitoring
operations. Agent implementors must also be sensitive to
the operational code and device approaches that minimize
the management impact on those operational elements.
4.2. Handling Multiple Managers
Devices are often modified by multiple management entities and with dif-
ferent management techniques. It is sometimes the case that an element
is managed by different organizations as is often the case when a device
sits between administrative domains.
There are a variety of approaches that management software can use to
ensure synchronization of information between the manager and the man-
aged elements.
A agent should report configuration changes set by different entities.
It should also distinguish configuration defined locally such as a
default or locally specified configuration made through an alternate
management interface like command line interface. When a change has been
made to the system via SNMP, CLI, or other method, a managed element
should send an inform to the manager(s) to which it has been assigned.
The managers should update there local configuration repositories. This
approach can also be an early warning of undesired configuration
changes.
Managers should also develop mechanisms to ensure that they are synchro-
nized with each other.
4.3. Designing MIB Modules for Multiple Managers
When designing a MIB Module for configuration, consider the following to
provide support for multiple managers.
The first consideration is to avoid any race conditions between two or
more authorized management applications issuing SET protocol operations
spanning over more than a single PDU.
The standard textual convention document [RFC2579] defines TestAndIncr,
often called a spinlock, which is used to avoid race conditions.
A MIB module designer may explicitly define a synchronization object of
syntax TestAndIncr or may choose to rely on snmpSetSerialNo (a global
Various Authors [Page 32]
RFC DRAFT Expires July 2001 March 2001
spinlock object) as defined in SNMPv2-MIB.
snmpSetSerialNo OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An advisory lock used to allow several cooperating SNMPv2
entities, all acting in a manager role, to coordinate their
use of the SNMPv2 set operation.
This object is used for coarse-grain coordination. To
achieve fine-grain coordination, one or more similar objects
might be defined within each MIB group, as appropriate."
::= { snmpSet 1 }
Second, an agent should be able to report configuration as set by dif-
ferent entities as well as distinguish configuration defined locally
such as a default or locally specified configuration made through an
alternate management interfaces like a command line interface. The Own-
erString textual convention from RMON-MIB RFC 2819 [30] has been used
successfully for this purpose.
Experience has shown that usage of OwnerString to represent row owner-
ship can be a useful diagnostic tool as well. Specifically, the use of
the string "monitor" to identify configuration set by an agent/local
management has been useful in applications.
Third, consider whether there is a need for multiple managers to config-
ure the same set of tables. If so, an "OwnerString" may be used as the
first component of a table's index to allow VACM to be used to protect
access to subsets of rows per manager. RFC 2591 section 6 presents this
technique in detail.
4.4. Exposure of Row Object Modifiability
Once a RowStatus value is active(1) for a given row, the management
application should be able to determine the semantics are for making
additional changes to a row. RMON I MIB control table objects spell out
explicitly what managed objects in a row can and cannot be changed once
a given RowStatus goes active.
As described earlier, some operations take some time to complete. Some
systems also require that they remain in a particular state for some
period before moving to another. In some cases a change to one value may
require re-initialization of the system. In all of these cases, the
DESCRIPTION clause should contain information about requirements of the
managed system and special restrictions that managers should observed.
Various Authors [Page 33]
RFC DRAFT Expires July 2001 March 2001
Transferring large amounts of configuration data via SNMP can be effi-
ciently performed with several of the techniques described in this docu-
ment. The policy section of this document shows how a very small amount
of information can be conveyed to a system under policy control that
reduces the need to move large amounts of configuration data between a
manager and a managed system. A common practice used to move large
amounts of data that some vendors use involves using SNMP as a control
channel in combination with other protocols defined for transporting
bulk data. This approach is sub-optimal since it raises a number of
security and other concerns.
5. DESIGNING CONFIGURATION MANAGEMENT SOFTWARE
In this section, we describe practices that should be used when creating
and deploying management software that configures one or more systems
with SNMP. One function all configuration management software should
provide, regardless of the method used to convey configuration informa-
tion to the managed systems is backup, failover and and restoration. A
management system should have the following features:
1. A method for restoring a previous configuration to one or
more devices. Ideally this restoration should be time indexed
so that a network can be restored to a configured state as of
a specific time and date.
2. A method for saving back up versions of the configured date
in case of hardware or software failure.
3. A method of providing failover to a secondary (management)
system in case of a primary failure. This capability should be
deployed in such a way that it does not cause duplicate
polling.
These three capabilities are of course important for other types of man-
agement that are not the focus of this BCP.
5.1. SNMP Configuration Management Sofware
This section focuses on general issues related to the development of
SNMP based applications (command generators) that configure one or more
network elements. Special consideration is give to what has come to be
known as policy-based management with SNMP. Effective software for the
configuration of one or many network elements requires thoughtful design
before starting implementation. This is true regardless of the technol-
ogy used to represent and transfer the configuration information. Two
general guiding principles in management application design are:
Various Authors [Page 34]
RFC DRAFT Expires July 2001 March 2001
- Ensure minimum movement of data
- Transaction control should be synchronized with remote system
5.2. Protocol Operations
There are three basic areas to evaluate relevant to SNMP protocol opera-
tions and configuration:
o Set and configuration activation operations
o Notifications from the device
o Data retrieval and collection
The design of the system should not assume that the objects in a device
that represent configuration data will remain unchanged over time.
As standard MIB modules evolve and vendors add private extensions, the
specific configuration parameters for a given operation are likely to
change over time. Even in the case of a configuration application that
is designed for a single vendor, the management application should allow
for variability in the MIB objects that will be used to configure the
device for a particular purpose. The best method to accomplish this is
by separating as much as possible the operational semantics of a config-
uration operation from the actual data. One way that some applications
achieve this is by having the specific configuration objects that are
associated with a particular device be table driven rather than hard
coded. Ideally, management software should verify the support in the
devices it is intended to manage and report any unexpected deviations to
the operator. This approach is particularly valuable when developing
applications that are intended to support equipment or software from
multiple vendors.
5.3. SET Operations
Management software should adapt its SET operations to the type of
device and specific MIB objects included in the SET PDU. The specific
intent here is to attempt to move the configuration information as effi-
ciently to the managed device as possible. There are many ways to
achieve efficiency and some are specific to given devices. One general
case example that all management software should employ is to reduce the
number of SET PDU exchanges between the managed device and the manage-
ment software to the smallest reasonable number. One approach to this is
to verify the largest number of variable bindings that can fit into a
SET PDU for a managed device. In some cases, the number of variable
Various Authors [Page 35]
RFC DRAFT Expires July 2001 March 2001
bindings to be sent in a particular PDU will be influenced by the
device, the specific MIB objects and other factors.
Maximizing SET variable bindings within a PDU has beneficial implica-
tions in the area of management application transaction initiation, as
well, as we will discuss in the following section.
5.4. Configuration Transactions
There are several types of configuration transactions that can be sup-
ported by SNMP-based configuration applications. They include transac-
tions on a single table, transactions across several tables in a managed
device and transactions across many devices. The manager's ability to
support these different transactions is partly dependent on the design
of the MIB objects within the scope of the configuration operation.
To make use of any kind of transaction semantics effectively, SNMP man-
agement software must be aware of the information in the MIB modules
that it is to configure so that it can effectively utilize RowStatus
objects for the control of transactions on one or more tables. Such
software must also be aware of control tables that the device supports
that are used to control the status of one or more other tables.
To the greatest extent possible, the management application should pro-
vide the facility to support transactions across multiple devices. This
means that if a configuration operation is desired across multiple
devices, the manager can coordinate these configuration operations such
that they become active as close to simultaneously as possible.
Several practical means are present in the SNMP model to effect this
management application transactional support. One was mentioned in the
preceding section. A transactional effect is optimized when the maximum
number of SET variable bindings are conveyed in a single PDU processed
on the agent.
There is an important refinement to this, however, for sets of table row
data objects. The set of read-create row data objects for the table
should be set in a single PDU or set of PDUs, and the verification of
their successful set through the response to the Set PDU or the subse-
quent polling of the row data objects to verify their setting in the
desired state. Only at the point of that verification should the set on
the applicable RowStatus object(s), to set the rows to active, be done.
This is the only effective means of affording an opportunity for per-row
rollback, particularly when the configuration change is across table row
instances on multiple managed devices.
Various Authors [Page 36]
RFC DRAFT Expires July 2001 March 2001
5.5. Notifications
As described throughout the section on Agent Software Development,
agents should provide the capability for notifications to be sent to
their configured management systems whenever a configuration operation
is attempted or completed. The management application MUST be prepared
to accept these notifications so that it knows the current configured
state of the devices it has been deployed to control. Some configura-
tion management applications may consume data from the managed devices
that reflects configuration, operational and utilization state informa-
tion. The GetBulkRequest-PDU is useful here whenever supported by the
managed device. For the purposes of backward compatibility, the manage-
ment station should also support and make use of the GetNextRequest-PDU
in these cases.
Management systems should also provide configuration options with
defaults for users that tend to retrieve the smallest amount of data to
achieve the particular goal of the application.
5.6. Scale of the Management Software
Efficient data retrieval described above is only part of the dimension
of scale that application developers should consider when developing
configuration applications. Management applications should provide for
distributed processing of the configuration operations. This also
extends to other management functions not the focus of this document.
This capability can also be used to provide resilience in the case of
network failures as well. An SNMP-based configuration management system
might be deployed in a distributed fashion where three systems in dif-
ferent locations keep each other synchronized. This synchronization can
be accomplished without additional polling of network devices through a
variety of techniques between each of the three managers. In the case of
a failure, a 'backup' system can take over the configuration responsi-
bilities of the failed manager without having to re-synchronize with the
managed elements since it will already be up to date.
6. DEPLOYMENT AND SECURITY ISSUES
Data network devices are configured using many mechanisms, however two
methods remain the most common: SNMP and Command Line Interface (CLI).
Effective use of these mechanisms involves an operational methodology
for deploying changes to networks in a cautious and incremental manner
with well-documented procedures. The collective intent of these proce-
dures is to guarantee that a configuration change to the network has the
intended effect on the affected network elements. Here is one such
Various Authors [Page 37]
RFC DRAFT Expires July 2001 March 2001
procedural model in detail:
Network Scope Input Procedural Step Output
------------------ ----- --------------- ------
Lab isolated from (1) Stage configuration Verify reliability
main network change with test of config change
device set and
(SNMP action: interoperability
determine distribution with prior system
of CLI and SNMP versions and
set actions for backwards
configuration change) compatibility
with prior
configuration
(2) Plan noncritical/ Fall back strategy
off hour window in case of change
(SNMP action: none) failure
Segmented edge of (1),(2) (3) Apply change to CLI Verified device
main network of network segment accept of
network elements configuration
(SNMP action: none) change
(1),(3) (4) Observation of Verified device
devices/networks over and network
time after change stability, proper
(SNMP action: effect of changes
monitor status of
SNMP read-only objects
which are companions
to SNMP set objects
for configuration
change)
(4) (5) Save changes to Verify integrity
persistent storage of changes after
of devices device restart
(SNMP action: SET
on controls to move
running config to
restart/persistent)
Expanded network (1),(2),(5) (6) Deploy changes, Verification of
Various Authors [Page 38]
RFC DRAFT Expires July 2001 March 2001
segments, iterative using CLI and SNMP. safety from any
to complete network Keep prior unanticipated
configuration on some SNMP defaulting
devices to allow behavior in mixed
fallback in case environment
of failure
(SNMP action: SET
on SNMP objects
determined in (1))
(4),(6) (7) Continue to Checkpointed
observe devices and verification
network for of anticipated
behavioral/service behavior
anomalies
(SNMP action:
same as (4) across
devices of expanded
network)
(7) (8) Expand deployment Checkpointed
and iteration to (6) verification
as called for of anticipated
(SNMP action: behavior
same as (6) across
expanded network)
Network revision (8) Update archived Change deployment
control system configurations, complete.
change log.
(SNMP action: none)
Procedures such as those above bring about a form of operational trans-
actionality, which works alongside (and employs) SNMP transactionality
as outlined in [SNMPTRANS]. The key goals throughout are
o Transactionality of configuration change deployment
o Persistence of configuration change which can be verified for
resulting stability, convergence, and realization of intended
effect of change.
Considerations for bringing about this verification are discussed
in the following section.
Various Authors [Page 39]
RFC DRAFT Expires July 2001 March 2001
6.1. Basic assumptions about Configuration
The following basic assumptions are made about real world configuration
models.
One, operations must understand and must be trained in the operation of
a given technology. No configuration system can prevent an untrained
operator from causing outages due to misconfiguration.
Two, systems undergoing configuration changes must be able to cope with
unexpected loss of communication at any time.
Network elements in conjunction with the configuration mechanism must
take appropriate measures to leave the configuration in a consis-
tent/recognizable state by either rolling back to a previously valid
state or changing to a well-defined or default state.
Three, configuration exists on a scale from relatively unchanging speci-
fications to high volume, high rate of configuration changes. The former
is often referred to as "set and forget" and the later "near real-time
change control." Design of configuration management must take into
account the rate and volume of change expected in a given configuration
subsystem.
6.2. Secure Agent Considerations
Vendors should not ship a device with a community string 'public' or
'private', and agents should not define default community strings except
where to bootstrap devices that do not have secondary management inter-
faces. Defaults lead to security issues, that have been recognized and
exploited. When using SNMPv1, supporting read-only community strings is
a common practice.
6.3. Authentication Traps
The default state of RFC 1215 [4] Authentication traps should be off.
In the "Notification" section of this document's discussion on MIB agent
design, issues and recommendations on throttling traps were raised.
Where notifications are sent in SNMPv1 trap PDUs, unsolicited packets to
a device can causes one ore more trap PDUs to be created and sent to
management stations. If these traps flow on shared access media and
links, the community string from the trap may be gleaned and exploited
to gain access to the device.
Various Authors [Page 40]
RFC DRAFT Expires July 2001 March 2001
6.4. Sensitive Information Handling
Some MIB modules contain objects that may contain data for keys, pass-
words and other such sensitive information and hence must be protected
from unauthorized access.
The DESCRIPTION clause for these and their defining MIB RFC Security
Considerations section should make it clear how and why these specific
objects are sensitive and that a user should only make them accessible
for encrypted SNMP access. Vendors should also throughly document senti-
tive objects in a similar fashion.
As noted in the section on Designing Configuration Objects, when writing
standards track MIB modules, one must implement those objects that part
are of the various standards-track specifications. Confidentiality is
not a must implement portion of the SNMPv3 management framework [11].
Prior to SNMPv3, providing customized views of MIB module data was dif-
ficult. This led to objects being defined such as the following.
docsDevNmAccessEntry OBJECT-TYPE
SYNTAX DocsDevNmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing access to SNMP objects by a
particular network management station. An entry in
this table is not readable unless the management station
has read-write permission (either implicit if the table
is empty, or explicit through an entry in this table.
Entries are ordered by docsDevNmAccessIndex. The first
matching entry (e.g. matching IP address and community
string) is used to derive access."
INDEX { docsDevNmAccessIndex }
::= { docsDevNmAccessTable 1 }
Organize your objects into groups such that VACM views can be defined to
properly scope what tables are visible to a given user and view. See the
prior section "Naming MIB modules and Managed Objects "
7. POLICY BASED MANAGEMENT
Policy based management with SNMP is a new concept. This section gives
background to and defines terms that are relevant to this field and
describes some deployment approaches.
Various Authors [Page 41]
RFC DRAFT Expires July 2001 March 2001
7.1. Organization of Data in an SNMP-Based Policy System
The number of configurable parameters and 'instances' such as interfaces
on network devices have increased as equipment has become larger and
more complex. At the same time there is a need to configure many of
these systems to operate in a coordinated fashion to deliver specialized
services that are valued by customers. These include the delivery of
virtual private networks and connections that guarantee specific service
levels.
This is an essential consideration both for the organization of configu-
ration data and for the efficient transfer of the per-element configura-
tion data to the management agent. As an example, a Bridge MIB [22]
agent which represents a massively sized VLAN across an administrative
domain could have some 65,000 (virtual) port entries. Configuring such
a VLAN would require the establishment of To configure such a VLAN, it
would require the establishment of dot1dStpPortTable and dot1DStat-
icTable entries for each such virtual port. Values for these aggregate
row entries should ideally be representable in a form which aggregates
the requirement for any individual SNMP sets to establish the columns
and rows for the port. Of equal importance for scalable operation, the
management environment should allow the iteration across the table for
row and column creation for each such port to be done on the agent,
rather than requiring the round trip of a PDU and response for each.
The way that configuration has been accomplished to now is with file
transfer, by setting individual MIB objects, or with many CLI commands.
This can work for a few machines configured by experts, but there is a
desire for a more scalable solution. Policy based management abstracts
the details above the instance level which means that fewer SET requests
are sent to a managed device.
Realization of such a policy-driven system requires agent capabilities
to interpret the management policy data and to execute its logical con-
figuration on the managed element. An environment with such capabili-
ties is described in [31]. For the purposes of the discussion here, we
shall focus on terms and concepts relevant to the application of arbi-
trary policy-based configuration supporting the criteria just discussed.
7.2. Layering
For this discussion, we will create a MIB Module called the Building
Heating Ventilation and Air Conditioning (HVAC) MIB Module as a way of
describing terms new to policy-based configuration management with SNMP.
Instance-Specific
Various Authors [Page 42]
RFC DRAFT Expires July 2001 March 2001
Instance-specific information refers to parameter values that have been
associated with a specific instance in a managed element. One example
would be the number of octets that were received over a particular
interface, ifInOctets. In our example MIB Module, we will have fan and
temperature settings for every control panel in the building. Imagine
how many there would be in a 50-story office building or multi-acre
office park. Network operators have the same problem, only with parame-
ters for many routers and interfaces that they contain which have an
ever-increasing number of values that must be configured to deliver spe-
cialized services such as Differentiated Services.
Implementation-Specific
Implementation-specific details are those parameters that a particular
vendor might use in an implementation that augment a standard set of
mechanism-specific parameters. Vendors often add special capabilities
to basic mechanisms as a way of meeting special customer requirements or
differentiating themselves from their competitors.
These special capabilities are often a result of the implementation
approach that a vendor has used for the product, thus the term "imple-
mentation-specific". For example, if a router vendor implemented a par-
ticular routing protocol, they might have mechanism-specific parameters
that control the behavior of that protocol implementation. In our HVAC
example, some vendors might extend the standard to include features that
distinguish their products from their competition. In our example MIB
module, the system is a sophisticated one and allows for the control of
the humidity, which is not part of the HVAC Standard MIB Module.
Mechanism-Specific
Mechanisms are technologies defined in standards that are used within a
particular domain (see domain description below). For example, in the
area (domain) of routing, BGP is a mechanism that is used that has many
parameters, including time-out values, that control the behavior of
routers in a BGP environment. Policy descriptions that include the
details associated with a particular mechanism are said to be mechanism-
specific. In our HVAC example, we have several mechanisms that are used
in the standard MIB module to control how fast a fan is to turn and what
position a switch is to be in for heating or cooling.
Domain-Specific
A domain is a general area of technology such as service quality or
security, or HVAC. Services, or service level agreements, may span sev-
eral domains, each of them potentially including many policies. To con-
tinue the building analogy, there might also be a lighting domain with
many mechanisms that control different aspects of the light. Both the
Various Authors [Page 43]
RFC DRAFT Expires July 2001 March 2001
lighting and the HVAC domains would be used in the lease the tenant
signs with the landlord in which the landlord promises to keep things
cool in the summer, warm in the winter and light at night. As a practi-
cal matter, people will not discuss these domains in the abstract. They
will most often be discussed with technology or application-specific
examples. Examples of technical domains include IPSec and Differentiated
Services. In our example MIB module we are describing information in the
HVAC (heating, ventilation, and air conditioning domain).
7.3. Information Related to Policy Configuration
In order for effective policy management to take place, a range of
information about the network elements is needed to avoid making poor
policy decisions. Even in those cases where policy-based configuration
is not in use, much of the information described in this section can be
a useful input to the decision-making process about what type of config-
uration operations to do.
For this discussion it is important to make distinctions between distri-
bution of policy to a system, activation of a policy in a system, and
changes/failures that take place during the time it is expected to be
active. For example, if an interface is down that is included in a pol-
icy that is distributed, there may not be an error since the policy may
not be scheduled for activation until a later time. On the other hand if
a policy is distributed and applied to an interface that should be oper-
ational and it is not, clearly this is a problem. With this as back-
ground, here are some areas to consider that are important to making
good policy configuration decisions and establishing when a policy has
'failed'.
o The operational state of network elements that are to be config-
ured.
In particular, care should be taken to determine if the sub compo-
nents to be configured are available for use. In some cases the
elements may not be available. The policy configuration software
should determine if this is a prerequisite to policy down-load or
if the condition is acceptable. In those cases where policy is dis-
tributed when the sub component such as an interface or disk is not
available, the managed system should send a notification to the
designated management station when the policy is to become active
if the resource is still not available.
o The capabilities of the devices in the network.
Various Authors [Page 44]
RFC DRAFT Expires July 2001 March 2001
A capability can be almost any unit of work a network element can
perform. These include, routing protocols supported, Web Server and
OS versions, queuing mechanisms supported on each interface that
can be used to support different qualities of service, and many
others. this information can be obtained from the capabilities
table of the Policy MIB module.
o The capacity of the devices to perform the desired work.
Capability is an ability to perform the desired work while a capac-
ity is a measure of how much of that capability the system has. The
policy configuration application should, wherever possible, evalu-
ate the capacity of the network element to perform the work identi-
fied by the policy. In some systems it will not be possible to
directly obtain the capacity of the managed elements to perform the
desired work, even though it may be possible to monitor the amount
of work the element performs. In these cases, the management appli-
cation may benefit from pre-configured information about the capac-
ity of different network elements so that evaluations of the
resources available can be made before distributing new policies.
Utilization refers to how much capacity for a particular capability
has been consumed. For devices that have been under policy configu-
ration control for any period of time, a certain percentage of the
available capacity of the managed elements will be used. Policies
should not be distributed to systems that do not have the resources
to carry out the policy for a reasonable period of time.
7.4. Policy, Mechanism/Implementation and Instance Specific Modules
A conformant agent could implement the policy module without any mecha-
nism or implementation-specific modules. For complicated configuration
areas such as Differentiated Services, Web servers, routing protocols,
etc., mechanism and frequently implementation-specific MIB modules will
be required.
If a vendor implements a standard set of instance-specific MIB objects
and an RFC has not yet been defined for a mechanism-specific set of
objects to control the policy based configuration of these instance-spe-
cific objects, the vendor should create such a module allowing for the
fact that an RFC might be issued later for the mechanism-specific mod-
ule. To the extent a vendor creates instance- specific extensions to
standard instance-specific MIB modules, they should also create imple-
mentation-specific MIB modules if the intend the box to be configured
with policy-based management. Many vendors create proprietary functions
and the instrumentation to manage them. To enable these features to be
integrated into an SNMP-based policy management system, both instance
Various Authors [Page 45]
RFC DRAFT Expires July 2001 March 2001
and implementation-specific MIB objects should be created.
7.5. Schedule and Time Issues
This section applies equally to systems that are not policy based as
well as policy-based systems, since configuration operations often need
to be synchronized across time zones. Wherever possible, the network
elements should support time information that includes local time zone
information. Some deployed systems do not store complex notions of local
time and thus may not be able to properly process policy directives that
contain time zone relevant data. For this reason, policy management
applications should have the ability to ascertain the time keeping abil-
ities of the managed system and make adjustments to the policy for those
systems that are time-zone challenged.
7.6. Conflict Detection, Resolution and Error Reporting
For many systems, sophisticated conflict detection and resolution is not
realistically achievable in the short-term. Using a hierarchical
approach to this problem can achieve significant benefits. Each 'layer'
policy management system should be able to check for some errors and
report them. This is conceptually identical to programs raising and
exception and passing that information on to software that can do some-
thing meaningful with it.
The responsibilities for each layer are: Instance-specific: Conflict
detection has been performed in a limited way for some time in software
that realizes instance- specific MIB objects. This detection is indepen-
dent of policy. The types of 'conflicts' usually evaluated are for
resource availability and validity of the set operations. In a policy
enabled system, there are no additional requirements for this software
assuming that good error detection and reporting appropriate to this
level have already been implemented.
Mechanism and implementation-specific: For software that realizes mecha-
nism and/or implementation-specific objects, failures should be reported
such that the specific policy that has been impacted can be related with
the specific element that failed. Beyond this basic reporting which is
does not perform any policy conflict detection, there are no require-
ments. See the Policy MIB Module document for additional information on
policy precedence and conflict detection.
Changes to configuration outside of the policy system:
A goal of SNMP-based policy management is to coexist with other forms of
management software have historically been instance based management.
Various Authors [Page 46]
RFC DRAFT Expires July 2001 March 2001
The best example is command line interface. Here are some guidelines for
handling these changes.
A notification should be sent whenever an out of policy control change
is made to an element that is under the control of policy. This notifi-
cation should include the policy that was changed, the instance of the
element that was changed and the object and value that it was changed
to.
An element under the control of policy that has been changed remains a
member of the policy group until the attributes in the Role table that
caused it to match the policy in the first place are modified. An ele-
ment that has been modified by a an out of policy mechanism, while
remaining a member of the policy does not get overridden by a policy
until its value is made the same as the extant policy with the highest
precedence for this element, and by implication then returned to policy
control. A notification should be sent when this action is taken.
7.7. Notifications in a Policy System
Notifications can be useful in determining a failure of a policy as a
result of an error in the policy or element(s) under policy control. As
with all notifications, they should be defined and controlled in such a
way that they do not add to a problem by sending more than are helpful
over a specific period of time. For example if a policy is controlling
1,000 interfaces and it fails, one notification rather than 1,000 may be
the better approach. In addition, such notifications should be defined
to include as much information as possible to aid in problem resolution.
7.8. Using Policy to Move Large Amounts of Data
One of the advantages of policy-based configuration with SNMP is that
many configuration operations can be conveyed with a small amount of
data. Changing a single configuration parameter for each of 100 inter-
faces on a system might require 100 CLI commands or 100 SNMP variable
bindings using conventional techniques.
Using policy-based configuration with SNMP, a single SET PDU can be sent
with the policy information necessary to apply a configuration change to
100 similar interfaces. This efficiency gain is the result of eliminat-
ing the need to send the value for each instance to be configured. The
'default' for each of the instances included in the policy is sent and
the rule for selection of the instances that the default is to be
applied can also be carried (see the Policy MIB Module).
To extend the example above, let's say that there are 10 parameters that
Various Authors [Page 47]
RFC DRAFT Expires July 2001 March 2001
need to change. Using conventional techniques, there would now be 1,000
variable bindings, one for each instance of each new value for each
interface. Using policy-based configuration with SNMP, it is still
likely that all the information can be conveyed in one SET PDU. The only
difference in this case is that there are ten parameters sent that will
be the 'template' used to create instances on the managed interfaces.
This efficiency gain not only applies to SET operations, but also to
those management operations that require configuration information.
Since the policy is also held in the pmPolicyTable, and entire policy
that potentially controls hundreds of rows of information can be
retrieved in a single GET request.
8. EXAMPLE MIB MODULE FOR POLICY-BASED MANAGEMENT
In this section, we define a 'standard' MIB Module that controls the
heating and air conditioning for a large building. This module contains
both configuration and counter objects that allow operators to see how
much cooling or heating a particular configuration has consumed. A pol-
icy table that represents the configuration information at a mechanism
specific level is also included. This table in combination with the pol-
icy MIB Module will allow operators to configure many rooms all at once,
change the configuration parameters based on time of day, and make a
number of other sophisticated decisions based on policy.
In this section, a vendor specific extension to 'standard' HVAC module
is also included to show how one would extend a standard with vendor
specific extensions and include those extensions in an SNMP-based policy
management system.
The design approach taken for policy configuration of this MIB module
that could be used for other similar MIB modules is to avoid redundant
or similar managed objects. In this case, this means using the objects
defined in the instance specific table to create templates, used to con-
figure one or more instances.
When multiple managed objects represent a single instance a template can
be used to active a complete configuration on the instance. The managed
objects used to represent the parameters of a managed instance will be
used for the provisioning of the configuration template.
The concept presented consists of three design steps:
Step 1: Design the managed objects for the instance level.
This is required in order to have the most accurate
representation of your managed device or application.
Various Authors [Page 48]
RFC DRAFT Expires July 2001 March 2001
These managed objects (for the example MIB module)
are:
bldgHVACFloor
bldgHVACOffice
bldgHVACOffType
bldgHVACHeatOrCool
bldgHVACFanSpeed
bldgHVACDesiredTemp
bldgHVACCurrentTemp
bldgHVACCoolOrHeatMins
Step 2: Separate the actual binding to the instance from the managed
objects.
The split of the managed objects (for the example MIB module)
would be:
- instance specific
bldgHVACFloor
bldgHVACOffice
bldgHVACButtonsPointer
- parameters
bldgHVACIndex -- a unique index needs to be added
bldgHVACOffType
bldgHVACHeatOrCool
bldgHVACFanSpeed
bldgHVACDesiredTemp
bldgHVACCurrentTemp
bldgHVACCoolOrHeatMins
bldgHVACOwner
bldgHVACStatus
Step 3: Define a binding between a template and the managed objects
representing the device. An extra table from which the
configuration template a defined needs to be added. Due to
the separation in step 2 we do not need to defined, since
we reuse the managed objects representing the parameters.
The following managed objects (for the example MIB module)
will be added.
bldgHVACPolicyId
bldgHVACPolicyDescr
bldgHVACPolicyConfiguration
bldgHVACPolicyOwner
bldgHVACPolicyStatus
BLDG-HVAC-MIB DEFINITIONS ::= BEGIN
IMPORTS
Various Authors [Page 49]
RFC DRAFT Expires July 2001 March 2001
-- NOTIFICATION-TYPE,
MODULE-IDENTITY, OBJECT-IDENTITY, Counter32,
Gauge32, OBJECT-TYPE, Integer32, experimental
FROM SNMPv2-SMI
-- MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
-- FROM SNMPv2-CONF
TEXTUAL-CONVENTION,
RowStatus, RowPointer
FROM SNMPv2-TC
OwnerString
FROM RMON-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
bldgHVACMIB MODULE-IDENTITY
LAST-UPDATED "200007090000Z"
ORGANIZATION "SNMPCONF working group"
CONTACT-INFO
"www.ietf.org"
DESCRIPTION
"This example MIB module defines a set of standard
management objects for heating ventilation and air
conditioning systems. It also includes a simple table
that can be used to create policies that are applied to
rooms based on a schedule."
REVISION "200101040900Z"
DESCRIPTION
"Initial version of BLDG-HVAC-MIB."
::= { experimental XXX }
--
-- Top level delegations
--
bldgHVACObjects OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Objects that configure and monitor HVAC in a building."
::= { bldgHVACMIB 1 }
--
-- Textual Conventions
--
Various Authors [Page 50]
RFC DRAFT Expires July 2001 March 2001
HvacOperation ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Operations supported by a Heating and cooling system.
A reference to underlying general systems would go here."
SYNTAX INTEGER {
heat(1),
cool(2)
}
--
-- HVAC Objects Group
--
bldgHVACTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This simple table is an example of objects that are at the
instance level of specificity. That is, they are indexed by a
specific floor and office number. The configuration
parameters and counters are for a specific location,
but these are defined with a 'bldgHVACButtonsTable'."
::= { bldgHVACObjects 1 }
bldgHVACEntry OBJECT-TYPE
SYNTAX BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a particular room, the desired HVAC
settings and usage information for that location since this
setting was initialized."
INDEX { bldgHVACFloor, bldgHVACOffice }
::= { bldgHVACTable 1 }
BldgHVACEntry ::= SEQUENCE {
bldgHVACFloor Integer32,
bldgHVACOffice Integer32,
bldgHVACButtons RowPointer
Various Authors [Page 51]
RFC DRAFT Expires July 2001 March 2001
}
bldgHVACFloor OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This portion of the index indicates the floor of the
building."
::= { bldgHVACEntry 1 }
bldgHVACOffice OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This second component of the index that specifies the office
number."
::= { bldgHVACEntry 2 }
bldgHVACButtons OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The pointer to an entry in the 'bldgHVACButtonsTable'.
The entry pointed to is a pre-made configuration that
represents the description of the bldgHVACPolicyDescr
object."
::= { bldgHVACEntry 3 }
bldgHVACButtonTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This simple table is an example of objects that are at the
Various Authors [Page 52]
RFC DRAFT Expires July 2001 March 2001
instance level of specificity. That is, they are indexed by a
specific floor and office number. The configuration
parameters and counters are for a specific location,
but these are defined with a 'bldgHVACButtonTable'."
::= { bldgHVACObjects 2 }
bldgHVACButtonEntry OBJECT-TYPE
SYNTAX BldgHVACButtonEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a particular room, the desired HVAC
settings and usage information for that location since this
setting was initialized."
INDEX { bldgHVACFloor, bldgHVACOffice }
::= { bldgHVACButtonTable 1 }
BldgHVACButtonEntry ::= SEQUENCE {
bldgHVACButtonIndex Integer32,
bldgHVACOffType INTEGER,
bldgHVACHeatOrCool INTEGER,
bldgHVACFanSpeed Gauge32,
bldgHVACDesiredTemp Gauge32,
bldgHVACCurrentTemp Gauge32,
bldgHVACCoolOrHeatMins Counter32,
bldgHVACOwner OwnerString,
bldgHVACStatus RowStatus
}
bldgHVACButtonIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An index that uniquely defines a set of buttons to be used
floor heating."
::= { bldgHVACButtonEntry 1 }
bldgHVACHeatOrCool OBJECT-TYPE
SYNTAX HvacOperation
Various Authors [Page 53]
RFC DRAFT Expires July 2001 March 2001
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This controls the heating and cooling mechanism and is
set-able by building maintenance."
::= { bldgHVACButtonEntry 2 }
bldgHVACFanSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Shows the revolutions per minute of the fan. Fan speed will
vary based on the difference between bldgHVACDesiredTemp and
bldgHVACurrentTemp."
::= { bldgHVACButtonEntry 3 }
bldgHVACDesiredTemp OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is the desired temperature setting. It might be changed
at different times of the day or based on seasonal
conditions. This is a good candidate parameter for control by
policy."
::= { bldgHVACButtonEntry 4 }
bldgHVACCurrentTemp OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current measured temperature in the office."
::= { bldgHVACButtonEntry 5 }
bldgHVACCoolOrHeatMins OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
Various Authors [Page 54]
RFC DRAFT Expires July 2001 March 2001
DESCRIPTION
"The total number of heating or cooling minutes that have
been consumed since the row was activated."
::= { bldgHVACEntry 6 }
bldgHVACOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity of the operator/system that last modified this
entry."
::= { bldgHVACEntry 7 }
bldgHVACStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row. This is a good example of latency
discussed earlier in this document. A row may be activated
with a particular temperature setting but it may take some
time before the current temperature is made equal to the
desired temperature. This time lag can even be effected by
where the sensor is in the office."
::= { bldgHVACEntry 8 }
--
-- The Policy Table to specify Mechanism-specific Parameters
--
bldgHVACPolicyTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACPolicyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Various Authors [Page 55]
RFC DRAFT Expires July 2001 March 2001
"This table can be used to set policy defaults that will be
placed on the specific offices that match the
pmPolicyFilter. See the policy MIB Module for more
information."
::= { bldgHVACObjects 3 }
bldgHVACPolicyEntry OBJECT-TYPE
SYNTAX BldgHVACPolicyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a single set of policy parameters that
can be applied to selected instances - in this case offices.
These policies will be turned on and off by the policy module
through its scheduling facilities."
INDEX { bldgHVACPolicyId }
::= { bldgHVACPolicyTable 1 }
BldgHVACPolicyEntry ::= SEQUENCE {
bldgHVACPolicyId Integer32,
bldgHVACPolicyDescr SnmpAdminString,
bldgHVACPolicyConfiguration RowPointer,
bldgHVACPolicyOwner OwnerString,
bldgHVACPolicyStatus RowStatus
}
bldgHVACPolicyId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each defined policy in this table. This
value be be pointed to from the Policy MIB Module."
::= { bldgHVACPolicyEntry 1 }
bldgHVACPolicyDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
Various Authors [Page 56]
RFC DRAFT Expires July 2001 March 2001
"A human readable textual convention for this HVAC
policy."
::= { bldgHVACPolicyEntry 2 }
bldgHVACPolicyConfiguration OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The pointer to a configuration template for floor
heating. This is a pointer to a specific row in
thebldgHVACButtonTable."
::= { bldgHVACPolicyEntry 3 }
bldgHVACPolicyOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity that created this row of the table."
::= { bldgHVACPolicyEntry 5 }
bldgHVACPolicyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row of the table."
::= { bldgHVACPolicyEntry 6 }
END
Implementation and Instance Extensions:
Just as with networking technologies, vendors may wish to add extensions
that can distinguish their products from the competition. If an HVAC
vendor also wanted to support humidity control, they could add that
Various Authors [Page 57]
RFC DRAFT Expires July 2001 March 2001
facility to their equipment and use AUGMENTS for the bldgHVACPolicyTable
with two objects, one that indicates the desired humidity and the other,
the actual. The bldgHVACPolicyTable could also be extended using this
same approach so that HVAC policies could easily be extended to support
this vendor.
9. GLOSSARY
Command Line Interface (CLI)
A means of interface to a configuration and management system for net-
work elements which involves a textual request/reply interface over a
terminal transport. In the province of data networking, there is no
standardized form of CLI, and hence a CLI is invariably specific to a
vendor implementation.
community string
A SNMP Version 1 access control mechanism. Logically, a community is a
simple string which associates some number of SNMP application entities,
and allows an agent to make access control decision on access requests
to given MIB objects and OID subtrees.
Device-Local Configuration
Device-local configuration data is specific to a particular network
device. This is the finest level of granularity for configuring network
devices.
Differentiated Services
A means of defining enterprise or cross-enterprise packet transmission
requirements for purposes of realizing service levels or other traffic
engineering requirements. As has been developed by the IETF, Differen-
tiated Services is realized by fields in IP packet headers and an
implied contract between cooperating packet processing nodes as to the
significance of certain values for those fields (in a traffic engineer-
ing sense).
Domain-specific
A term for a scope of configuration data, broad enough to encompass an
entire area of technology or generalized problem statement to which the
configuration activity is applied. Examples might include "routing",
"secure IP", or "layer 3 routing".
Various Authors [Page 58]
RFC DRAFT Expires July 2001 March 2001
Fate Sharing
A principle of Internet protocol resources and management data units
which specifies that there is an inherent unification between the state
of a relationship (for example, between two related table rows). If the
relationship between them becomes inoperable or invalidated, there will
be a predictable behavior for the removal of the relationship (and pos-
sibly, one or both of its parties in their entirety).
Implementation-specific
A term for a scope of configuration data, encompassing a technology or
feature set pertinent to the technologies or feature sets specific to a
vendor's implementation of the more generalized features constrained by
domain-specific or mechanism-specific containment.
Instance-specific
A term for a scope of configuration data, constrained to encompass all
parametric values as defined by the deployment of domain, mechanism, and
implementation specific containment, but further qualified with data
specific to a specific managed element or group of managed elements.
Instance-specific configuration data requires no further decomposition
for deployment from a network management software application perspec-
tive.
MIB module
The SNMP Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects, collectively
defined by the IETF or management administrative enterprises, are
defined in MIB modules. These MIB modules are logical subsets of the
total MIB data exposed by a running SNMP agent.
Network-Wide Configuration
Network-wide configuration data is not specific to any particular net-
work device and from which multiple device-local configurations can be
derived. Network-wide configuration provides a level of abstraction
above device-local configurations.
Octet string
A management data type, defined in the SMI, which denotes interpretation
as arbitrary binary or textual data.
OwnerString
Various Authors [Page 59]
RFC DRAFT Expires July 2001 March 2001
A textual convention, first defined in the RMON MIB, providing an infor-
mal means of access control over a resource. As specified in the TC
definition, an object instance of this type is specified on a table row
which is likely to be under incremental creation or update. The Owner-
String generally defines the IP address or other identifier for the cre-
ator of a row and hence the party using its resources.
Persistence
A property of management data that defines its permanence. Specifi-
cally, for the purposes of this document, persistence defines whether a
change in configuration on a managed element will have that change
reflected across power cycles (and associated operational configuration
data store re-initialization) of the managed element.
Policy-based configuration
Policy-based configuration is the practice of applying management opera-
tions for collective configuration action on managed objects that share
certain rule-based attributes.
RMON (remote monitoring)
The Remote Monitoring MIB module, defined in [30], contains a number of
objects and notification facilities useful in direct and delegated man-
agement of remote network devices. It contains a number of configurable
table rows to define targets managed elements for remote packet process-
ing analysis and thresholds for notification generation.
SMI
The Structure of Managed Information is the definition of a subset of
ASN.1 and the administrative values which constrain the expression and
encoding of data within the SNMP MIB and its modular extensions.
SNMP
The Simple Network Management Protocol. This comprises the Internet
Standard Management Framework.
textual convention (TC)
Textual conventions refer to new types defined for specific purposes
within SMI-compliant MIB modules. Textual conventions are defined using
an ASN.1 macro (TEXTUAL-CONVENTION), and synthesize new types with syn-
tactic similarity but greater semantic precision than the native SMI
types the textual conventions derive from.
Various Authors [Page 60]
RFC DRAFT Expires July 2001 March 2001
Time-indexed
For this document, this refers to data (and in particular, data describ-
ing events of configuration set or notification), which is tagged with
the agent or management station time of event occurrence. This is often
used in SNMP management systems to correlate events over an elapsed
indexed time sequence with each other for purposes of transactional
grouping.
TimeStamp
A textual convention containing a managed element sysUpTime value, gen-
erally to reflect the element-relative time of the occurrence of a given
associated event.
Transaction
A finite group of changes that taken as a whole can be applied or rolled
back in one operation. For example, a single SNMP SET PDU represents a
transaction for which the state before the set is returned should any
individual element in the variable-bindings list fail to be applied thus
returning the device to exactly the same state before the SET was exe-
cuted.
variable binding (VarBind)
Within a SNMP PDU, a VarBind is an in-PDU pairing of the identifier for
the instance of managed data with that instance's value.
10. ACKNOWLEDGEMENTS
This document was produced by the SNMPCONF Working Group:
Christopher Anderson
Andy Bierman
Dr Jeffrey Case
Chris Elliott
Joel Halpern
Pablo Halpern
Wes Hardaker
David Harrington
Harrie Hazewinkel
Art Mellor
David Partain
Randy Preshun
Dan Romanescu
Shawn Routhier
Robin Whitworth
Various Authors [Page 61]
RFC DRAFT Expires July 2001 March 2001
11. REFERENCES
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[2] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC
1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP",
RFC 1215, March 1991.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC
2579, April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduc-
tion to Community-based SNMPv2", RFC 1901, January 1996.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management Proto-
col (SNMP)", RFC 2572, April 1999.
[12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
Various Authors [Page 62]
RFC DRAFT Expires July 2001 March 2001
2574, April 1999.
[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Con-
trol Model (VACM) for the Simple Network Management Protocol (SNMP)",
RFC 2575, April 1999.
[16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, q(Management
Information Base for Version 2 of the Simple Network Management
Protocol (SNMPv2) q, RFC 1907, January 1996.
[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using
SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997.
[18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to
Version 3 of the Internet-standard Network Management Framework",
RFC 2570, April 1999.
[19] Brown, C., and F. Baker, "Management Information Base for Frame
Relay DTEs Using SMIv2", RFC 2115, September 1997.
[20] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June
1995.
[21] Hawkinson, J., and T. Bates, "Guidelines for Creation, Selection,
and Registration of an Autonomous System (AS)", RFC 1930,
March 1996.
[22] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie,
"Definitions of Managed Objects for Bridges", RFC 1493, July 1993.
[23] Levi, D., and J. Schoenwaelder "Definitions of Managed Objects for
Scheduling Management Operations", RFC 2591, May 1999.
[24] Bell, E., Smith, A., Langille, P., Rijsinghani, A., and K.
McCloghrie, "Definitions of Managed Objects for Bridges with
Traffic Classes,
Various Authors [Page 63]
RFC DRAFT Expires July 2001 March 2001
Multicast Filtering and Virtual LAN Extensions, RFC 2674, August
1999.
[25] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997.
[26] St. Johns, M., "Radio Frequency (RF) Interface Management Informa-
tion Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670,
August 1999.
[27] Baker, F., and R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1850, November 1995.
[28] Blake, S. Black, D., Carlson M., Davies E. Wang Z., Weiss W., "An
Architecture for Differentiated Services ", RFC 2475, December
1998.
[29] Willis, S. and J. Chu., "Definitions of Managed Objects for the
Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2",
RFC 1657, July 1994.
[30] Waldbusser, S."Remote Network Monitoring Management Information
Base", RFC 2819, May 2000.
[31] McCloghrie, K., and Kastenholz, F., "The Interfaces Group MIB",
RFC 2863, June 2000.
[32] McCloghrie, K., and Hanson, G., "The Inverted Stack Table Exten-
sion to the Interfaces Group MIB", RFC 2864, June 2000.
[33] McCloghrie, K. and Bierman, A., "Entity MIB (Version 2)", RFC
2737, December, 1999.
[34] ITU-T,, Recommendation M.3010.,
PRINCIPLES FOR ATELECOMMUNICATIONS MANAGEMENT NETWORK.
February, 2000.
12. EDITORS' ADDRESSES
Michael R. MacFaden
Riverstone Networks, Inc
5200 Great America Parkway
Santa Clara, CA 95054
email - mrm@riverstonenet.com
Various Authors [Page 64]
RFC DRAFT Expires July 2001 March 2001
Jon Saperia
JDS Consulting
174 Chapman Street
Watertown, MA 02472
email - saperia@mediaone.net
Wayne Tackabury
Gold Wire Technology
411 Waverley Oaks Rd.
Waltham, MA 02452
email - wayne@goldwiretech.com
13. INTELLECTUAL PROPERTY
The IETF takes no position regarding the validity or scope of any intel-
lectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document
or the extent to which any license under such rights might or might not
be available; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan-
dard. Please address the information to the IETF Executive Director.
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
Various Authors [Page 65]
RFC DRAFT Expires July 2001 March 2001
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or ref-
erences to the Internet Society or other Internet organizations, except
as needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.
Table of Contents
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Organization . . . . . . . . . . . . . . . . . . . . . 3
2. USING SNMP AS A CONFIGURATION MECHANISM . . . . . . . . . . . . . 3
2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . . . . . 3
2.2. Practical Requirements for Transactional Control . . . . . . . 4
2.3. Best Practices in Configuration . . . . . . . . . . . . . . . . 5
3. DESIGNING A MIB MODULE . . . . . . . . . . . . . . . . . . . . . 7
3.1. MIB Module design . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Consistency in Modeling . . . . . . . . . . . . . . . . . . . 8
3.1.2. Designing Configuration Objects . . . . . . . . . . . . . . . 8
3.1.3. Naming MIB modules and Managed Objects . . . . . . . . . . . 9
3.1.4. Using Summary Objects and State Tracking . . . . . . . . . . 10
3.1.5. Advanced Synchronization Considerations . . . . . . . . . . . 12
3.1.6. Octet String Aggregations . . . . . . . . . . . . . . . . . . 15
3.1.7. Simple Integer Indexing . . . . . . . . . . . . . . . . . . . 17
3.1.8. Indexing with Network Addresses . . . . . . . . . . . . . . . 18
3.1.9. Fate sharing with multiple tables . . . . . . . . . . . . . . 18
3.1.10. Conflicting Controls . . . . . . . . . . . . . . . . . . . . 18
3.1.11. Textual Convention Usage . . . . . . . . . . . . . . . . . . 19
3.1.12. Persistent Configuration . . . . . . . . . . . . . . . . . . 20
3.1.13. Configuration Sets and Activation . . . . . . . . . . . . . 21
3.1.14. Usage of Row notReady Status . . . . . . . . . . . . . . . . 23
Various Authors [Page 66]
RFC DRAFT Expires July 2001 March 2001
3.1.15. SET operation Latency . . . . . . . . . . . . . . . . . . . 24
3.1.16. Application Error Reporting . . . . . . . . . . . . . . . . 26
3.1.17. Designing Notifications . . . . . . . . . . . . . . . . . . 27
3.1.18. Control of Notification Subsystem . . . . . . . . . . . . . 28
3.1.19. Transaction Control MIB Objects . . . . . . . . . . . . . . 28
3.1.20. MIB Modules and Instance Indexing . . . . . . . . . . . . . 29
3.1.21. Use of special optional clauses . . . . . . . . . . . . . . 29
3.1.22. Conceptual Table Modification Practices . . . . . . . . . . 30
3.1.23. MIB Object and Practice Reuse . . . . . . . . . . . . . . . 30
4. IMPLEMENTING SNMP CONFIGURATION AGENT . . . . . . . . . . . . . . 31
4.1. Operational Consistency . . . . . . . . . . . . . . . . . . . . 31
4.2. Handling Multiple Managers . . . . . . . . . . . . . . . . . . 32
4.3. Designing MIB Modules for Multiple Managers . . . . . . . . . . 32
4.4. Exposure of Row Object Modifiability . . . . . . . . . . . . . 33
5. DESIGNING CONFIGURATION MANAGEMENT SOFTWARE . . . . . . . . . . . 34
5.1. SNMP Configuration Management Sofware . . . . . . . . . . . . . 34
5.2. Protocol Operations . . . . . . . . . . . . . . . . . . . . . . 35
5.3. SET Operations . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4. Configuration Transactions . . . . . . . . . . . . . . . . . . 36
5.5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6. Scale of the Management Software . . . . . . . . . . . . . . . 37
6. DEPLOYMENT AND SECURITY ISSUES . . . . . . . . . . . . . . . . . 37
6.1. Basic assumptions about Configuration . . . . . . . . . . . . . 40
6.2. Secure Agent Considerations . . . . . . . . . . . . . . . . . . 40
6.3. Authentication Traps . . . . . . . . . . . . . . . . . . . . . 40
6.4. Sensitive Information Handling . . . . . . . . . . . . . . . . 41
7. POLICY BASED MANAGEMENT . . . . . . . . . . . . . . . . . . . . . 41
7.1. Organization of Data in an SNMP-Based Policy System . . . . . . 42
7.2. Layering . . . . . . . . . . . . .. . . . . . .. . . . . . . . 42
7.3. Information Related to Policy Configuration . . . . . . . . . . 44
7.4. Policy, Mechanism/Implementation and Instance Specific Mod-
ules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.5. Schedule and Time Issues . . . . . . . . . . . . . . . . . . . 46
7.6. Conflict Detection, Resolution and Error Reporting . . . . . . 46
7.7. Notifications in a Policy System . . . . . . . . . . . . . . . 47
7.8. Using Policy to Move Large Amounts of Data . . . . . . . . . . 47
8. EXAMPLE MIB MODULE FOR POLICY-BASED MANAGEMENT . . . . . . . . . 48
Various Authors [Page 67]