RFC 3512 - Configuring Networks and Devices with Simple Network Management Protocol (SNMP)
(Formats: TXT)
Network Working Group M. MacFaden
Request for Comments: 3512 Riverstone Networks, Inc.
Category: Informational D. Partain
Ericsson
J. Saperia
JDS Consulting, Inc.
W. Tackabury
Gold Wire Technology, Inc.
April 2003
|
Configuring Networks and Devices with
Simple Network Management Protocol (SNMP)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document is written for readers interested in the Internet
Standard Management Framework and its protocol, the Simple Network
Management Protocol (SNMP). In particular, it offers guidance in the
effective use of SNMP for configuration management. This information
is relevant to vendors that build network elements, management
application developers, and those that acquire and deploy this
technology in their networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Internet Standard Management Framework. . . . . . . . 3
1.2. Configuration and the Internet Standard Management
Frame-work. . . . . . . . . . . . . . . . . . . . . . . . 4
2. Using SNMP as a Configuration Mechanism. . . . . . . . . . . . 5
2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . . 6
2.2. Practical Requirements for Transactional Control. . . . . 6
2.3. Practices in Configuration--Verification. . . . . . . . . 7
3. Designing a MIB Module . . . . . . . . . . . . . . . . . . . . 9
3.1. MIB Module Design - General Issues. . . . . . . . . . . . 10
3.2. Naming MIB modules and Managed Objects. . . . . . . . . . 11
3.3. Transaction Control And State Tracking. . . . . . . . . . 12
MacFaden, et al. Informational [Page 1]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
3.3.1. Conceptual Table Row Modification Practices. . . . 12
3.3.2. Fate sharing with multiple tables. . . . . . . . . 13
3.3.3. Transaction Control MIB Objects. . . . . . . . . . 14
3.3.4. Creating And Activating New Table Rows . . . . . . 15
3.3.5. Summary Objects and State Tracking . . . . . . . . 15
3.3.6. Optimizing Configuration Data Transfer . . . . . . 18
3.4. More Index Design Issues. . . . . . . . . . . . . . . . . 22
3.4.1. Simple Integer Indexing. . . . . . . . . . . . . . 23
3.4.2. Indexing with Network Addresses. . . . . . . . . . 23
3.5. Conflicting Controls. . . . . . . . . . . . . . . . . . . 24
3.6. Textual Convention Usage. . . . . . . . . . . . . . . . . 25
3.7. Persistent Configuration. . . . . . . . . . . . . . . . . 26
3.8. Configuration Sets and Activation . . . . . . . . . . . . 28
3.8.1. Operational Activation Considerations. . . . . . . 28
3.8.2. RowStatus and Deactivation . . . . . . . . . . . . 30
3.9. SET Operation Latency . . . . . . . . . . . . . . . . . . 31
3.9.1. Subsystem Latency, Persistence Latency,
and Activation Latency . . . . . . . . . . . . . . 33
3.10. Notifications and Error Reporting. . . . . . . . . . . . 33
3.10.1. Identifying Source of Configuration Changes . . . 34
3.10.2. Limiting Unnecessary Transmission of
Notifications . . . . . . . . . . . . . . . . . . 34
3.10.3. Control of Notification Subsystem . . . . . . . . 36
3.11 Application Error Reporting . . . . . . . . . . . . . . . 36
3.12 Designing MIB Modules for Multiple Managers . . . . . . . 37
3.13 Other MIB Module Design Issues. . . . . . . . . . . . . . 39
3.13.1. Octet String Aggregations . . . . . . . . . . . . 39
3.13.2 Supporting multiple instances of a MIB Module. . . 40
3.13.3 Use of Special Optional Clauses. . . . . . . . . . 41
4. Implementing SNMP Configuration Agents . . . . . . . . . . . . 41
4.1. Operational Consistency . . . . . . . . . . . . . . . . . 41
4.2. Handling Multiple Managers. . . . . . . . . . . . . . . . 43
4.3. Specifying Row Modifiability. . . . . . . . . . . . . . . 44
4.4. Implementing Write-only Access Objects. . . . . . . . . . 44
5. Designing Configuration Management Software. . . . . . . . . . 44
5.1. Configuration Application Interactions
with Managed Systems. . . . . . . . . . . . . . . . . . . 45
5.1.1. SET Operations . . . . . . . . . . . . . . . . . . 46
5.1.2. Configuration Transactions . . . . . . . . . . . . 46
5.1.3. Tracking Configuration Changes . . . . . . . . . . 47
5.1.4. Scalability of Data Retrieval. . . . . . . . . . . 48
6. Deployment and Security Issues . . . . . . . . . . . . . . . . 48
6.1. Basic assumptions about Configuration . . . . . . . . . . 48
6.2. Secure Agent Considerations . . . . . . . . . . . . . . . 49
6.3. Authentication Notifications. . . . . . . . . . . . . . . 49
6.4. Sensitive Information Handling. . . . . . . . . . . . . . 50
7. Policy-based Management. . . . . . . . . . . . . . . . . . . . 51
7.1. What Is the Meaning of 'Policy-based' . . . . . . . . . . 51
MacFaden, et al. Informational [Page 2]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
7.2. Organization of Data in an SNMP-Based Policy System . . . 53
7.3. Information Related to Policy-based Configuration . . . . 54
7.4. Schedule and Time Issues. . . . . . . . . . . . . . . . . 56
7.5. Conflict Detection, Resolution and Error Reporting. . . . 56
7.5.1. Changes to Configuration Outside of the
Policy System. . . . . . . . . . . . . . . . . . . 57
7.6. More about Notifications in a Policy System . . . . . . . 57
7.7. Using Policy to Move Less Configuration Data. . . . . . . 57
8. Example MIB Module With Template-based Data. . . . . . . . . . 58
8.1. MIB Module Definition. . . . . . . . . . . . . . . . . . 61
8.2. Notes on MIB Module with Template-based Data. . . . . . . 73
8.3. Examples of Usage of the MIB . . . . . . .. . . . . . . . 74
9. Security Considerations . . . . . . . . . . .. . . . . . . . . 77
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 78
11. Normative References. . . . . . . . . . . . . . . . . . . . . 78
12. Informative References. . . . . . . . . . . . . . . . . . . . 79
13. Intellectual Property . . . . . . . . . . . . . . . . . . . . 81
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 82
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 83
1. Introduction
1.1. The Internet Standard Management Framework
The Internet Standard Management Framework has many components. The
purpose of this document is to describe effective ways of applying
those components to the problems of configuration management.
For reference purposes, the Internet Standard Management Framework
presently consists of five major components:
o An overall architecture, described in RFC 3411 [1].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC 1155 [15], STD 16, RFC 1212 [16] and RFC 1215 [17]. The
second version, called SMIv2, is described in STD 58, RFC 2578
[2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [18]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [19]. The
third version of the message protocol is called SNMPv3 and
described in RFC 3417 [5], RFC 3412 [6] and RFC 3414 [7].
MacFaden, et al. Informational [Page 3]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [18]. A second set of protocol
operations and associated PDU formats is described in RFC 3416
[8].
o A set of fundamental applications described in RFC 3413 [9] and
the view-based access control mechanism described in RFC 3415
[10].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 3410 [12].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
1.2. Configuration and the Internet Standard Management Framework
Data networks have grown significantly over the past decade. This
growth can be seen in terms of:
Scale - Networks have more network elements, and the network
elements are larger and place more demands on the systems managing
them. For example, consider a typical number and speed of
interfaces in a modern core network element. A managed
metropolitan area network switch can have a port density much
greater than the port density built into the expectations of the
management systems that predated it. There are also many more
interrelationships within and between devices and device
functions.
Functionality - network devices perform more functions.
More protocols and network layers are required for the successful
deployment of network services which depend on them.
Rate of Change - the nature of modern network services
causes updates, additions, and deletions of device configuration
information more often than in the past. No longer can it be
assumed that a configuration will be specified once and then be
updated rarely. On the contrary, the trend has been towards much
more frequent changes of configuration information.
Correct configuration of network elements that make up data networks
is a prerequisite to the successful deployment of the services on
them. The growth in size and complexity of modern networks increases
the need for a standard configuration mechanism that is tightly
integrated with performance and fault management systems.
MacFaden, et al. Informational [Page 4]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
The Internet Standard Management Framework has been used successfully
to develop configuration management systems for a broad range of
devices and networks. A standard configuration mechanism that
tightly integrates with performance and fault systems is needed not
only to help reduce the complexity of management, but also to enable
verification of configuration activities that create revenue-
producing services.
This document describes Current Practices that have been used when
designing effective configuration management systems using the
Internet Standard Management Framework (colloquially known as SNMP).
It covers many basic practices as well as more complex agent and
manager design issues that are raised by configuration management.
We are not endeavoring to present a comprehensive how-to document for
generalized SNMP agent, MIB module, or management application design
and development. We will, however, cover points of generalized SNMP
software design and implementation practice, where the practice has
been seen to benefit configuration management software. So, for
example, the requirement for management applications to be aware of
agent limitations is discussed in the context of configuration
operations, but many issues that a management application developer
should consider with regard to manager-agent interactions are left
for other documents and resources.
Significant experience has been gained over the past ten years in
configuring public and private data networks with SNMP. During this
time, networks have grown significantly as described above. A
response to this explosive growth has been the development of
policy-based configuration management. Policy-Based Configuration
Management is a methodology wherein configuration information is
derived from rules and network-wide objectives, and is distributed to
potentially many network elements with the goal of achieving
consistent network behavior throughout an administrative domain.
This document presents lessons learned from these experiences and
applies them to both conventional and policy-based configuration
systems based on SNMP.
2. Using SNMP as a Configuration Mechanism
Configuration activity causes one or more state changes in an
element. While it often takes an arbitrary number of commands and
amount of data to make up configuration change, it is critical that
the configuration system treat the overall change operation
atomically so that the number of states into which an element
transitions is minimized. The goal is for a change request either to
be completely executed or not at all. This is called transactional
integrity. Transactional integrity makes it possible to develop
MacFaden, et al. Informational [Page 5]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
reliable configuration systems that can invoke transactions and keep
track of an element's 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 instance or in very large aggregations
that could include many object instances located in many tables on a
managed device. For this reason, reliance on transactional integrity
only at the SNMP protocol level is insufficient.
2.2. Practical Requirements for Transactional Control
A well-designed and deployed configuration system should have the
following 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 alternately one small
attribute may be changed.
2) The transaction control component should work at and understand a
notion of the kind of multi-level "defaulting" as described in
Section 7.1. 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) A configuration management system should provide time-indexed
transaction control. For effective rollback control, the
configuration transactions and their successful or unsuccessful
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 by the system recording the change.
MacFaden, et al. Informational [Page 6]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
5) The managed system must support transactional security. This
means that depending on who is making the configuration request
and where it is being made, it may be accepted or denied based on
security policy that is in effect in the managed element.
Effective transactional control is a responsibility shared between
design, implementation, and operational practice. Transaction
control techniques for MIB module design are discussed in Section
3.3. Transaction control considerations for the agent implementation
are discussed in Section 5.2.2.
2.3. Practices in Configuration--Verification
Verification of expected behavior subsequent to the commitment of
change 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 and wait for convergence
(system or network stability)
re-test - verify once again that the system is working properly
This procedure is commonly used to verify configuration changes to
critical systems such as the domain name system (DNS). DNS software
kits provide diagnostic tools that allow automatic test
procedures/scripts to be conducted.
A planned configuration sequence can be aborted if the pre-
configuration test result shows the state of the system as unstable.
Debugging the unintended effects of two sets of changes in large
systems is often more challenging than an analysis of the effects of
a single set after test termination.
Networks and devices under SNMP configuration readily support this
change management procedure since the SNMP provides integrated
monitoring, configuration and diagnostic capabilities. The key is
the sequencing of SNMP protocol operations to effect an integrated
change procedure like the one described above. This is usually a
well-bounded affair for changes within a single network element or
node. However, there are times when configuration of a given element
can impact other 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 (convergence) of the network the device is connected
to.
MacFaden, et al. Informational [Page 7]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
An integrated view of configuration and monitoring provides an ideal
platform from which to evaluate such changes. For example, the MIB
module governing IEEE 802.1D Spanning Tree (RFC 1493 [24]) 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.
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 above object types are good examples of a means of facilitating
the principles described in Section 2.3. That is, one needs to
understand the behavior of a subsystem before configuration change,
then be able to use the same means to retest and verify proper
operation subsequent to configuration change.
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" [22], Section 1.3.4:
A vendor needs to provide adequate documentation on all
configuration parameters, their limits and effects.
MacFaden, et al. Informational [Page 8]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
Adherence to the above model is not fail-safe, especially when
configuration errors are masked by long latencies or when
configuration errors lead to oscillations in network stability. For
example, consider the situation of loading a new software version on
a device, which leads to small, slow, cumulative memory leaks brought
on by a certain traffic pattern that was not caught during vendor and
customer test lab trials.
In a network-based example, convergence in an autonomous system
cannot be guaranteed when configuration changes are made since there
are factors beyond the control of the operator, such as the state of
other network elements. Problems affecting this convergence may not
be detected for a significant period of time after the configuration
change. Even for factors within the operator's control, there is
often little verification done to prevent mis-configuration (as shown
in the following example).
Consider a change made to ospfIfHelloInterval and
ospfIfRtrDeadInterval [24] 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 described at the beginning of this section been employed,
this particular situation would have been discovered without
impacting the production network.
The important point to remember from this discussion is that
configuration systems should be designed and implemented with
verification tests in mind.
3. Designing a MIB Module
Carefully considered MIB module designs are crucial to practical
configuration with SNMP. As we have just seen, MIB objects designed
for configuration can be very effective since they can be associated
with integrated diagnostic, monitoring, and fault objects. MIB
modules for configuration also scale when they expose their notion of
template object types. Template objects can represent information at
a higher level of abstraction than instance-level ones. This has the
benefit of reducing the amount of instance-level data to move from
management application to the agent on the managed element, when that
instance-level data is brought about by applying a template object on
the agent. Taken together, all of these objects can provide a robust
configuration subsystem.
The remainder of this section provides specific practices used in MIB
module design with SMIv2 and SNMPv3.
MacFaden, et al. Informational [Page 9]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
3.1. MIB Module Design - General Issues
One of the first tasks in defining a MIB module is the creation of a
model that reflects the scope and organization of the management
information an agent will expose.
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. However, it is important to
include only those aspects of a subsystem that are proven to be
operationally useful.
In 1993, one of most widely deployed MIB modules supporting
configuration was published, RFC 1493, which contained the BRIDGE-
MIB. It defined the criteria 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 (sic) of objects.
(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.
Over the past eight years additional experience has shown a need to
expand these criteria as follows:
(7) Before designing a MIB module, identify goals and objectives for
the MIB module. How much of the underlying system will be
exposed depends on these goals.
MacFaden, et al. Informational [Page 10]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
(8) Minimizing the total number of objects is not an explicit goal,
but usability is. Be sure to consider deployment and usability
requirements.
(9) During configuration, consider supporting explicit error state,
capability and capacity objects.
(10) When evaluating rule (5) above, consider the impact on a
management application. If an object can help reduce a
management application's complexity, consider defining objects
that can be derived.
3.2. Naming MIB modules and Managed Objects
Naming of MIB modules and objects informally follows a set of best
practices. 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
identifiers [2]) defined in standard MIB modules should be unique
across all MIB modules. 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 descriptors of object types
such as ifTable, ifStackTable and so forth.
MIB module object type descriptors can include an abbreviation for
the function they perform. For example the objects that control
configuration in the example MIB module in Section 8 include "Cfg" as
part of the object descriptor, as in bldgHVACCfgDesiredTemp.
This is more fully realized when the object descriptors that include
the fault, configuration, accounting, performance and security [33]
abbreviations are combined with an organized OID assignment approach.
For example, a vendor could create a configuration branch in their
private enterprises area. In some cases this might be best done on a
per product basis. Whatever the approach used, "Cfg" might be
included in every object descriptor in the configuration branch.
This has two operational benefits. First, for those that do look at
instances of MIB objects, descriptors as seen through MIB browsers or
other command line tools assist in conveying the meaning of the
object type. Secondly, management applications can be pointed at
specific subtrees for fault or configuration, causing a more
efficient retrieval of data and a simpler management application with
potentially better performance.
MacFaden, et al. Informational [Page 11]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
3.3. Transaction Control And State Tracking
Transactions and keeping track of their state is an important
consideration when performing any type of configuration activity
regardless of the protocol. Here are a few areas to consider when
designing transaction support into an SNMP-based configuration
system.
3.3.1. Conceptual Table Row Modification Practices
Any discussion of transaction control as it pertains to MIB module
design often begins with how the creation or modification of object
instances in a conceptual row in the MIB module is controlled.
RowStatus [3] is a standard textual convention for the management of
conceptual rows in a table. Specifically, the RowStatus textual
convention that is used for the SYNTAX value of a single column in a
table controls the creation, deletion, activation, and deactivation
of conceptual rows of the table. When a table has been defined with
a RowStatus object as one of its columns, changing an instance of the
object to 'active' causes the row in which that object instance
appears to become 'committed'.
In a multi-table scenario where the 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.
The RowStatus textual convention specifies that, when used in a
conceptual row, a description must define what can be modified.
While the description of the conceptual row and its columnar object
types is the correct place to derive this information on instance
modifiability, it is often wrongly assumed in some implementations
that:
1) objects either must all be presently set or none need be set to
make a conceptual RowStatus object transition to active(1)
2) objects in a conceptual row cannot be modified once a RowStatus
object is active(1). Restricting instance modifiability like
this, so that after a RowStatus object is set to active(1) is in
fact a reasonable limitation, since such a set of RowStatus may
have agent system side-effects which depend on committed columnar
MacFaden, et al. Informational [Page 12]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
object instance values. However, where this restriction exists on
an object, it should be made clear in a DESCRIPTION clause such as
the following:
protocolDirDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the protocol encapsulation.
A probe may choose to describe only a subset of the
entire encapsulation (e.g., only the highest layer).
This object is intended for human consumption only.
This object may not be modified if the associated
protocolDirStatus object is equal to active(1)."
::= { protocolDirEntry 4 }
Any such restrictions on columnar object instance modification while
a row's RowStatus object instance is set to active(1) should appear
in the DESCRIPTION clause of the RowStatus columnar OBJECT-TYPE as
well.
3.3.2. Fate sharing with multiple tables
An important principle associated with transaction control is fate
sharing of rows in different tables. Consider the case where a
relationship has been specified between two conceptual tables of a
MIB module (or tables in two different MIB modules). In this
context, fate sharing means that when a row of a table is deleted,
the corresponding row in the other table is also deleted. Fate
sharing in a transaction control context can also be used with the
activation of very large configuration changes. If we have two
tables that hold a set of configuration information, a row in one
table might have to be put in the 'ready' state before the second can
be put in the 'ready' state. When that second table can be placed in
the 'ready' state, then the entire transaction can be considered to
have been 'committed'.
Fate sharing of SNMP table data should be explicitly defined where
possible using the SMI index qualifier AUGMENTS. If the relationship
between tables cannot be defined using SMIv2 macros, then the
DESCRIPTION clause of the object types which particularly effect the
cross-table relationship should define what should happen when rows
in related tables are added or deleted.
MacFaden, et al. Informational [Page 13]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
Consider the relationship between the dot1dBasePortTable and the
ifTable. These tables 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? A number of acceptable
design and practice techniques can provide the answer to these
questions, so it is important for the MIB module designer to provide
the guidance to guarantee consistency and interoperability.
To this end, when two tables are related in such a way, ambiguities
such as this should be avoided by having the DESCRIPTION clauses of
the pertinent row object types define the fate sharing of entries in
the respective tables.
3.3.3. Transaction Control MIB Objects
When a MIB module is defined that includes configuration object
types, consider providing transaction control objects. These objects
can be used to cause a large transaction to be committed. For
example, we might have several tables that define the configuration
of a portion of a system. In order to avoid churn in the operational
state of the system we might create a single scalar object that, when
set to a particular value, will cause the activation of the rows in
all the necessary tables. Here are some examples of further usage
for such object types:
o Control objects that are the 'write' or 'commit' objects.
Such objects can cause all pending transactions (change MIB object
values as a result of SET operations) to be committed to a
permanent 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 are the
levels of granularity that make sense in practice. For example,
in the routing area, would changes be allowed on a per protocol
basis such as BGP? If allowed at the BGP level, are sub-levels
permitted such as per autonomous system? The design of these
control objects will be impacted by the underlying software
design. RowStatus (see Section 3.3.1) also has important
relevance as a general transaction control object.
MacFaden, et al. Informational [Page 14]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
3.3.4. Creating And Activating New Table Rows
When designing read-create objects in a table, a MIB module designer
should first consider the default state of each object in the table
when a row is created. Should an implementation of a standard MIB
module vary in terms of the objects that need to be set in order to
create an instance of a given row, an agent capabilities statement
should be used to name the additional objects in that table using the
CREATION-REQUIRES clause.
It is useful when configuring new rows to use the notReady status to
indicate row activation cannot proceed.
When creating a row instance of a conceptual table, one should
consider the state of instances of required columnar objects in the
row. The DESCRIPTION clause of such a required columnar object
should specify it as such.
During the period of time when a management application is attempting
to create a row, there may be a period of time when not all of these
required (and non-defaultable) columnar object instances have been
set. Throughout this time, an agent should return a noSuchInstance
error for a GET of any object instance of the row until such time
that all of these required instance values are set. The exception is
the RowStatus object instance, for which a notReady(3) value should
be returned during this period.
One need only be concerned with the notReady value return for a
RowStatus object when the row under creation does not yet have all of
the required, non-defaultable instance values for the row. One
approach to simplifying in-row configuration transactions when
designing MIB modules is to construct table rows that have no more
instance data for columnar objects than will fit inside a single SET
PDU. In this case, the createAndWait() value for the RowStatus
columnar object is not required. It is possible to use createAndGo()
in the same SET PDU, thus simplifying transactional management.
3.3.5. Summary Objects and State Tracking
Before beginning a new set of configuration transactions, a
management application might want to checkpoint the state of the
managed devices whose configuration it is about to change. There are
a number of techniques that a MIB module designer can provide to
assist in the (re-)synchronization of the managed systems. These
objects can also be used to verify that the management application's
notion of the managed system state is the same as that of the managed
device.
MacFaden, et al. Informational [Page 15]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
These techniques include:
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 message (InformRequests are preferable) to
deliver configuration change.
By providing an object containing the number of rows in a table,
management applications can decide how best to retrieve a given
table's data and may choose different retrieval strategies depending
on table size. Note that the availability of and application
monitoring of such an object is not sufficient for determining the
presence of table data change over a checkpointed duration since an
equal number of row creates and deletes over that duration would
reflect no change in the object instance value. Additionally, table
data change which does not change the number of rows in the table
would not be reflected through simple monitoring of such an object
instance.
Instead, the change in the value of any table object instance data
can be tracked through an object that monitors table change state as
a function of time. An example is found in RFC 2790, Host Resources
MIB:
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, RFC 2737 [34], provides the following
object:
entLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp
MacFaden, et al. Informational [Page 16]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
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. There tend to be small
differences in what a table's LastChanged object reflects. IF-MIB
(RFC 2863 [20]) 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 modifies a row with an SNMP SET on ifAdminStatus, the
value of ifTableLastChange will not be updated. It is important to
be specific about what can cause an object to update so that
management applications will be able to detect and more properly act
on these changes.
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 relatively low or polling a cache object is not
desired, consider defining a notification that can be used to report
all configuration change details.
When doing so, the option is available to an SNMPv3 (or SNMPv2c)
agent to deliver the notification using either a trap or an inform.
The decision as to which PDU to deliver to the recipient is generally
a matter of local configuration. Vendors should recommend the use of
informs over traps for NOTIFICATION-TYPE data since the agent can use
the presence or absence of a response to help know whether it needs
MacFaden, et al. Informational [Page 17]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
to retransmit or not. Overall, it is preferable to use an inform
instead of a trap so that changes have a higher likelihood of
confirmed end-to-end delivery.
As a matter of MIB module design, when practical, the NOTIFICATION-
TYPE should include in the PDU all of the modified columnar objects
in a row of a table. This makes it easier for the management
application receiving the notification to keep track of what has
changed in the row of a table and perform addition analysis on the
state of the managed elements.
However, the use of notifications to communicate the state of a
rapidly changing object may not be ideal either. This leads us back
to the MIB module design question of what is the right level of
granularity to expose.
Finally, having to poll many "LastChange" objects does not scale
well. Consider providing a global LastChange type object to
represent overall configuration in a given agent implementation.
3.3.6. Optimizing Configuration Data Transfer
Configuration management software should keep track of the current
configuration of all devices under its control. It should ensure
that the result is a consistent view of the configuration of the
network, which can help reduce inadvertent configuration errors.
In devices that have very large amounts of configuration data, it can
be costly to both the agent and the manager to have the manager
periodically poll the entire contents of these configuration tables
for synchronization purposes. A benefit of good synchronization
between the manager and the agent is that the manager can determine
the smallest and most effective set of data to send to managed
devices when configuration changes are required. Depending on the
table organization in the managed device and the agent
implementation, this practice can reduce the burden on the managed
device for activation of these configuration changes.
In the previous section, we discussed the "LastChange" style of
object. When viewed against the requirements just described, the
LastChange object is insufficient for large amounts of data.
There are three design options that can be used to assist with the
synchronization of the configuration data found in the managed device
with the manager:
MacFaden, et al. Informational [Page 18]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
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 based
on what an application will use the table for
2) Use a time-based indexing technique
3) Define a control MIB module that manages a separate data delivery
protocol
3.3.6.1. 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.
Many tables in standard MIB modules follow one of two indexing
models:
- Indexing based upon increasing Integer32 or Unsigned32 values of
the kind one might find in an array.
- Associative indexing, which refers to the technique of using
potentially sparse indices based upon a "key" of the sort one
would use for a hash table.
When tables grow to a very large number of rows, using an associative
indexing scheme offers the useful ability to efficiently retrieve
only the rows of interest.
For example, if an SNMP entity exposes a copy of the default-free
Internet routing table as defined in the ipCidrRouteTable, it will
presently contain around 100,000 rows.
Associative indexing is used in the ipCidrRouteTable and allows one
to retrieve, for example, all routes for a given IPv4 destination
192.0.2/24.
Yet, if the goal is to extract a copy of the table, the associative
indexing reduces the throughput and potentially the performance of
retrieval. This is because each of the index objects are appended to
the object identifiers for every object instance returned.
ipCidrRouteEntry OBJECT-TYPE
SYNTAX IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular route to a particular destination,
MacFaden, et al. Informational [Page 19]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
under a particular policy."
INDEX {
ipCidrRouteDest,
ipCidrRouteMask,
ipCidrRouteTos,
ipCidrRouteNextHop
}
A simple array-like index works efficiently since it minimizes the
index size and complexity while increasing the number of rows that
can be sent in a PDU. If the indexing is not sparse, concurrency can
be gained by sending multiple asynchronous non-overlapping collection
requests as is explained in RFC 2819 [32], Page 41 (in the section
pertaining to Host Group indexing).
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 [20] and the
ifInvStackTable RFC 2864 [33]. 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 }
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 }
MacFaden, et al. Informational [Page 20]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
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 [32], demonstrates a very
useful technique 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 practice for command generators to encode the ifIndex
into this simple integer to provide associative lookup capability.
The RMON hostTable and hostTimeTable represent dependent tables that
contain the results indexed by the hostControlTable entry.
The hostTable is further indexed by the MAC address which provides
the ability to reasonably search for a collection, such as the
Organizationally Unique Identifier (OUI), 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
hostControlLastDeleteTime.
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 }
3.3.6.2. Time Based Indexing
The TimeFilter as defined in RFC 2021 [44] and used in RMON2-MIB and
Q-BRIDGE-MIB (RFC 2674 [26]) provides a way to obtain only those rows
that have changed on or after some specified period of time has
passed.
MacFaden, et al. Informational [Page 21]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
One drawback to TimeFilter index tables is that a given row can
appear at many points in time, which artificially inflates the size
of the table when performing standard getNext or getBulk data
retrieval.
3.3.6.3. Alternate Data Delivery Mechanisms
If the amount of data to transfer is larger than current SNMP design
restrictions permit, as in the case of OCTET STRINGS (64k minus
overhead of IP/UDP header plus SNMP header plus varbind list plus
varbind encoding), consider delivery of the data via an alternate
method, such as FTP and use a MIB module to control that data
delivery process. In many cases, this problem can be avoided via
effective MIB design. In other words, object types requiring this
kind of transfer size should be used judiciously, if at all.
There are many enterprise MIB modules that provide control of the
TFTP or FTP protocol. Often the SNMP part defines what to send where
and setting an object initiates the operation (for an example, refer
to the CISCO-FTP-CLIENT-MIB, discussed in [38]).
Various approaches exist for allowing a local agent process running
within the managed node to take a template for an object instance
(for example for a set of interfaces), and adapt and apply it to all
of the actual instances within the node. This is an architecture for
one form of policy-based configuration (see [36], for example). Such
an architecture, which must be designed into the agent and some
portions of the MIB module, affords the efficiency of specifying many
copies of instance data only once, along with the execution
efficiency of distributing the application of the instance data to
the agent.
Other work is currently underway to improve efficiency for bulk SNMP
transfer operations [37]. The objective of these efforts is simply
the conveyance of more information with less overhead.
3.4. More Index Design Issues
Section 3.3.5 described considerations for table row index design as
it pertains to the synchronization of changes within sizable table
rows. This section simply considers how to specify this syntactically
and how to manage indices semantically.
In many respects, the design issues associated with indices in a MIB
module are similar to those in a database. Care must be taken during
the design phase to determine how often and what kind of information
must be set or retrieved. The next few points provide some guidance.
MacFaden, et al. Informational [Page 22]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
3.4.1. Simple Integer Indexing
When indexing tables using simple Integer32 or Unsigned32, start with
one (1) and specify 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 [2], Section 7.7, page 28 states the following: 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 type should be avoided, except in
special cases. Consider the provisions afforded by the following
textual convention from the Interfaces Group MIB module [33]:
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
InterfaceIndex convention. The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system. This extension permits the
additional value of zero. the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax. Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced."
SYNTAX Integer32 (0..2147483647)
3.4.2. 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 [14] IP-
MIB. This limits the usefulness of the MIB module to IPv4. To avoid
such limitations, use the addressing textual conventions INET-
ADDRESS-MIB [13] (or updates to that MIB module), which provides a
generic way to represent addresses for Internet Protocols. In using
the InetAddress textual convention in this MIB, however, pay heed to
the following advisory found in its description clause:
When this textual convention is used as the syntax of an index
object, there may be issues with the limit of 128 sub-identifiers
specified in SMIv2, STD 58. In this case, the OBJECT-TYPE
declaration MUST include a 'SIZE' clause to limit the number of
potential instance sub-identifiers.
MacFaden, et al. Informational [Page 23]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
One should consider the SMI limitation on the 128 sub-identifier
specification when using certain kinds of network address index
types. The most likely practical liability encountered in practice
has been with DNS names, which can in fact be in excess of 128 bytes.
The problem can be, of course, compounded when multiple indices of
this type are specified for a table.
3.5. 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:
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
MacFaden, et al. Informational [Page 24]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
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. Without clarification on how
these two objects interact, management implementations will have to
monitor both objects if bridging is detected and correlate behavior.
The dot1dStpPortEnable object type could have been written with more
information about the behavior of this object when values of
ifAdminStatus which impact it change. For example, text could be
added that described proper return values for the dot1dStpPortEnable
object instance for each of the possible values of ifAdminStatus.
In those cases where overlap between objects is unavoidable, then as
we have just described, care should be taken in the description of
each of the objects to describe their possible interactions. In the
case of an object type defined after an incumbent object type, it is
necessary to include in the DESCRIPTION of this later object type the
details of these interactions.
3.6. Textual Convention Usage
Textual conventions should be used whenever possible to create a
consistent semantic for an oft-recurring datatype.
MIB modules often define a binary state object such as enable/disable
or on/off. Current practice is to use existing Textual Conventions
and define the read-write object in terms of a TruthValue from
SNMPv2-TC [3]. For example, the Q-BRIDGE-MIB [26] defines:
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 }
Textual conventions that have a reasonable chance of being reused in
other MIB modules ideally should also be defined in a separate MIB
module to facilitate sharing of such object types. For example, all
ATM MIB modules draw on the ATM-TC-MIB [39] to reference and utilize
common definitions for addressing, service class values, and the
like.
MacFaden, et al. Informational [Page 25]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
To simplify management, it is recommended that existing SNMPv2-TC
based definitions be used when possible. For example, consider the
following object definition:
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
This could be defined as follows using existing SNMPv2-TC TruthValue.
acmePatioLightsOn OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRI2096PTION
"Current status of outdoor lighting. When set to true (1),
this means that the lights are enabled and turned on.
When set to false (2), the lights are turned off."
::= { acmeOutDoorElectricalEntry 3 }
3.7. Persistent Configuration
Many network devices have two levels of persistence with regard to
configuration data. In the first case, the configuration data sent
to the device is persistent only until changed with a subsequent
configuration operation, or the system is reinitialized. The second
level is where the data is made persistent as an inherent part of the
acceptance of the configuration information. Some configuration
shares both these properties, that is, that on acceptance of new
configuration data it is saved permanently and in memory. Neither of
these necessarily means that the data is used by the operational
code. Sometimes separate objects are required to activate this new
configuration data for use by the operational code.
However, many SNMP agents presently implement simple persistence
models, which do not reflect all the relationships of the
configuration data to the actual persistence model as described
above. Some SNMP set requests against MIB objects with MAX-ACCESS
read-write are written automatically to a persistent store. In other
cases, they are not. In some of the latter cases, enterprise MIB
MacFaden, et al. Informational [Page 26]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
objects are required in order to get standard configuration stored,
thus making it difficult for a generic application to have a
consistent effect.
There are standard conventions for saving configuration data. The
first method uses the Textual Convention known as StorageType [3]
which explicitly defines a given row's persistence requirement.
Examples include the RFC 3231 [25] 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 [10].
A second method for persistence simply uses the DESCRIPTION clause to
define how instance data should persist. RFC 2674 [26] explicitly
defines Dot1qVlanStaticEntry data persistence as follows:
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 }
The current practice is a dual persistence model where one can make
changes to run-time configuration as well as to a non-volatile
configuration read at device initialization. The DISMAN-SCHEDULE-MIB
module [25] provides an example of this practice. A row entry of its
SchedTable specifies the parameters by which an agent MIB variable
instance can be set to a specific value at some point in time and
governed by other constraints and directives. One of those is:
schedStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether this scheduled action is kept
in volatile storage and lost upon reboot or if this row is
backed up by non-volatile or permanent storage.
Conceptual rows having the value `permanent' must allow
write access to the columnar objects schedDescr,
schedInterval, schedContextName, schedVariable, schedValue,
and schedAdminStatus. If an implementation supports the
MacFaden, et al. Informational [Page 27]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
schedCalendarGroup, write access must be also allowed to
the columnar objects schedWeekDay, schedMonth, schedDay,
schedHour, schedMinute."
DEFVAL { volatile }
::= { schedEntry 19 }
It is important, however, to reiterate that the persistence is
ultimately controlled by the capabilities and features (with respect
to the storage model of management data) of the underlying system on
which the MIB Module agent is being implemented. This falls into
very much the same kind of issue set as, for example, the situation
where the size of data storage in the system for a Counter object
type is not the same as that in the corresponding MIB Object Type.
To generalize, the final word on the "when" and "how" of storage of
persistent data is dictated by the system and the implementor of the
agent on the system.
3.8. Configuration Sets and Activation
An essential notion for configuration of network elements with SNMP
is awareness of the difference between the set of one or more
configuration objects from the activation of those configuration
changes in the actual subsystem. That is, it often only makes sense
to activate a group of objects as a single 'transaction'.
3.8.1. Operational Activation Considerations
A MIB module design must consider the implications of the preceding
in the context of changes that will occur throughout a subsystem when
changes are activated. This is particularly true for configuration
changes that are complex. This complexity can be in terms of
configuration data or the operational ramifications of the activation
of the changes in the managed subsystem. A practical technique to
accommodate this kind of activation is the partitioning of contained
configuration sets, as it pertains to their being activated as
changes. Any complex configuration should have a master on/off
switch (MIB object type) as well as strategically placed on/off
switches that partition the activation of configuration data in the
managed subsystem. These controls play a pivotal role during the
configuration process as well as during subsequent diagnostics.
Generally, a series of set operations should not cause an agent to
activate each object, causing operational instability to be
introduced with every changed object instance. To avoid this
liability, ideally a series of Set PDUs can install the configuration
and a final set series of PDUs can activate the changes.
MacFaden, et al. Informational [Page 28]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
During diagnostic situations, certain on/off switches can be set to
localize the perceived error instead of having to remove the
configuration.
An example of such an object from the OSPF Version 2 MIB [29] is the
global ospfAdminStat:
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 interface;
'disabled' disables it on all interfaces."
::= { ospfGeneralGroup 2 }
Elsewhere in the OSPF MIB, the semantics of setting ospfAdminStat to
enabled(2) are clearly spelled out.
The Scheduling MIB [25] exposes such an object on each entry in the
scheduled actions table, along with the corresponding stats object
type (with read-only ACCESS) on the scheduled actions row instance.
This reflects a recurring basic design pattern which brings about
semantic clarity in the object type usage. A table can expose one
columnar object type which is strictly for administrative control.
When read, an instance of this object type will reflect its last set
or defaulted value. A companion operational columnar object type,
with MAX-ACCESS of read-only, provides the current state of
activation or deactivation resulting from the last set of the
administrative columnar instance. It is fully expected that these
administrative and operational columnar instances may reflect
different values over some period of time of activation latency,
which is why they are separate. Further sections display some of the
problems which can result from attempting to combine the operational
and administrative row columns into a single object type.
Note that all of this is independent of the RowStatus columnar
object, and the notion of 'activation' as it pertains to RowStatus.
A defined RowStatus object type should be strictly concerned with the
management of the table row itself (with 'activation' indicating "the
conceptual row is available for use by the managed device" [3], and
not to be confused with any operational activation semantics).
MacFaden, et al. Informational [Page 29]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
In the following example, schedAdminStatus controls activation of the
scheduled action, and schedOperStatus reports on its operational
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 }
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 }
3.8.2. RowStatus and Deactivation
RowStatus objects should not be used 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. RFC
2579 [3], page 15 states:
MacFaden, et al. Informational [Page 30]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
The agent must detect conceptual rows that have been in either
state for an abnormally long period of time and remove them. It
is the responsibility of the DESCRIPTION clause of the status
column to indicate what an abnormally long period of time would
be.
The DISMAN-SCHEDULE-MIB's managed object schedAdminStatus
demonstrates how to separate row control from row activation.
Setting the schedAdminStatus to disabled(2) does not cause the row to
be aged out/removed from the table.
Finally, a reasonable agent implementation must consider how many
rows will be allowed to be created in the notReady/notInService state
such that resources are not exhausted by an errant application.
3.9. 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 application.
Consider the subtle operational shortcomings in the following object.
It both reports the current state and allows a SET operation to
change to a possibly new state.
wheelRotationState OBJECT-TYPE
SYNTAX INTEGER { unknown(0),
idle(1),
spinClockwise(2),
spinCounterClockwise(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current state of a wheel."
::= { XXX 2 }
MacFaden, et al. Informational [Page 31]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
With the object defined, the following example represents one possible
transaction.
Time Command Generator --------> <--- Command Responder
----- ----------------- -----------------
|
A GetPDU(wheelRotationState.1.1)
|
| ResponsePDU(error-index 0,
| error-code 0)
|
B wheelRotationState.1.1 == spinClockwise(2)
|
C SetPDU(wheelRotationState.1.1 =
| spinCounterClockwise(3)
|
| ResponsePDU(error-index 0,
| error-code 0)
|
D wheelRotationState.1.1
== spinCounterClockwise(3)
|
E GetPDU(wheelRotationState.1.1)
|
F ResponsePDU(error-index 0,
| error-code 0)
|
V wheelRotationState.1.1 == spinClockwise(2)
....some time, perhaps seconds, later....
|
G GetPDU(wheelRotationState.1.1)
|
H ResponsePDU(error-index 0,
| error-code 0)
| wheelRotationState.1.1
V == spinCounterClockwise(3)
The response to the GET request at time E will often confuse
management applications that assume the state of the object should be
spinCounterClockwise(3). In reality, the wheel is slowing down in
order to come to the idle state then begin spinning counter
clockwise.
This possibility of confusing and paradoxical interactions of
administrative and operational state is inevitable when a single
object type is used to control and report on both types of state.
One common practice which we have already seen is to separate out the
MacFaden, et al. Informational [Page 32]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
desired (settable) state from current state. The objects
ifAdminStatus and ifOperStatus from RFC 2863 [20] provide such an
example of the separation of objects into desired and current state.
3.9.1. Subsystem Latency, Persistence Latency, and Activation Latency
A second way latency can be introduced in SET operations is caused by
delay in agent implementations that must interact with loosely
coupled subsystems. The time it takes the instrumented system to
accept the new configuration information from the SNMP agent, process
it and 'install' the updated configuration in the system or otherwise
process the directives can often be longer than the SNMP response
timeout.
In these cases, it is desirable to provide a "current state" object
type which can be polled by the management application to determine
the state of control of the loosely coupled subsystem which was
affected by its configuration update.
More generally, some MIB objects may have high latencies associated
with changes to their values. This could be either a function of
saving the changed value to a persistent storage type, and/or
activating a subsystem that inherently has high latency as discussed
above. When defining such MIB objects, it might be wise to have the
agent process set operations in the managed subsystem as soon as the
Set PDU has been processed, and then update appropriate status
objects when the save-to- persistent storage and (if applicable)
activation has succeeded or is otherwise complete. Another approach
would be to cause a notification to be sent that indicates that the
operation has been completed.
When you describe an activation object, the DESCRIPTION clauses for
these objects should give a hint about the likely latency for the
completion of the operation. Keep in mind that from a management
software perspective (as presented in the example of schedAdminStatus
in Section 3.8.1), the combined latency of saving-to-persistence and
activation are not distinguishable when they are part of a single
operation.
3.10. Notifications and Error Reporting
For the purpose of this section, a 'notification' is as described in
the SMIv2, RFC 2578 [2], by the NOTIFICATION-TYPE macro.
Notifications can be sent in either SNMPv2c [19] or SNMPv3 TRAP or
InformRequest PDUs. Given the sensitivity of configuration
information, it is recommended that configuration operations always
be performed using SNMPv3 due to its enhanced security capabilities.
InformRequest PDUs should be used in preference to TRAP PDUs since
MacFaden, et al. Informational [Page 33]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
the recipient of the InformRequest PDUs responds with a Response PDU.
This acknowledgment can be used to avoid unnecessary retransmission
of NOTIFICATION-TYPE information when retransmissions are in fact
required. The use of InformRequest PDUs (as opposed to TRAPs) is not
at the control of the MIB module designer or agent implementor. The
determination as to whether or not a TRAP or InformRequest PDU is
sent from an SNMPv2c or SNMPv3 agent is generally a function of the
agent's local configuration (but can be controlled with MIB objects
in SNMPv3). To the extent notification timeout and retry values are
determined by local configuration parameters, care should be taken to
avoid unnecessary retransmission of InformRequest PDUs.
Configuration change and error information conveyed in InformRequest
PDUs can be an important part of an effective SNMP-based management
system. They also have the potential to be overused. This section
offers some guidance for effective definition of NOTIFICATION-TYPE
information about configuration changes that can be carried in
InformRequest PDUs. Notifications can also play a key role for all
kinds of error reporting from hardware failures to configuration and
general policy errors. These types of notifications should be
designed as described in Section 3.11 (Application Error Reporting).
3.10.1. Identifying Source of Configuration Changes
A NOTIFICATION-TYPE designed to report configuration changes should
report the identity of the management entity initiating the
configuration change. Specifically, if the entity is known to be a
SNMP command generator, the transport address and SNMP parameters as
found in table snmpTargetParamsTable from RFC 3413 SNMP-TARGET-MIB
should be reported where possible. For reporting of configuration
changes outside of the SNMP domain, the applicable change mechanism
(for example, CLI vs. HTTP-based management client access) should be
reported, along with whatever notion of "user ID" of the change
initiator is applicable and available.
3.10.2. Limiting Unnecessary Transmission of Notifications
The design of event-driven synchronization models, essential to
configuration management, can use notifications as an important
enabling technique. Proper usage of notifications allows the
manager's view of the managed element's configuration to be in close
synchronization with the actual state of the configuration of the
managed element.
When designing new NOTIFICATION-TYPEs, consider how to limit the
number of notifications PDUs that will be sent with the notification
information defined in the NOTIFICATION-TYPE in response to a
configuration change or error event.
MacFaden, et al. Informational [Page 34]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
InformRequest PDUs, when compared to TRAP PDUs, have an inherent
advantage when the concern is the reduction of unnecessary messages
from the system generating the NOTIFICATION-TYPE data, when in fact
retransmission of this data is required. That is, an InformRequest
PDU is acknowledged by the receiving entity with a Response PDU. The
receipt of this response allows the entity which generated the
InformRequest PDU to verify (and record an audit entry, where such
facilities exist on the agent system) that the message was received.
As a matter of notification protocol, this receipt guarantee is not
available when using TRAP PDUs, and if it is required, must be
accomplished by the agent using some mechanism out of band to SNMP,
and usually requiring the penalty of polling.
Regardless of the specific PDUs used to convey them, one way to limit
the unnecessary generation of notifications is to include in the
NOTIFICATION-TYPE definition situations where it need not be sent. A
good example is the frDLCIStatusChange defined in FRAME-RELAY-DTE-
MIB, RFC 2115 [21].
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 }
There are a number of other techniques which can be used to reduce
the unwanted generation of NOTIFICATION-TYPE information. When
defining notifications, the designer can specify a number of temporal
limitations on the generation of specific instances of a
NOTIFICATION-TYPE. For example, a definition could specify that
messages will not be sent more frequently than once every 60 seconds
while the condition which led to the generation of the notification
persists. Alternately, a NOTIFICATION-TYPE DESCRIPTION clause could
provide a fixed limit on the number of messages sent over the
duration of the condition leading to sending the notification.
If NOTIFICATION-TYPE transmission is "aggregated" in some way -
bounded either temporally or by absolute system state change as
described above - the optimal design technique is to have the data
delivered with the notification reference the actual number of
underlying managed element transitions which brought about the
notification. No matter which threshold is chosen to govern the
MacFaden, et al. Informational [Page 35]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
actual transmission of NOTIFICATION-TYPEs, the idea is to describe an
aggregated event or related set of events in as few PDUs as possible.
3.10.3. 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 filtering of notifications.
In the past, agents did not have a standard means to configure a
notification generator. With the availability of the SNMP-
NOTIFICATION-MIB module in RFC 3413 [9], it is strongly recommended
that the filtering functions of this MIB module be used. This MIB
facilitates the mapping of given NOTIFICATION-TYPEs and their
intended recipients.
If the mechanisms of the SNMP-NOTIFICATION-MIB are not suitable for
this application, a explanation of why they are not suitable should
be included in the DESCRIPTION clause of any replacement control
objects.
3.11. Application Error Reporting
MIB module designers should not rely on the SNMP protocol error
reporting mechanisms alone to report application layer error state
for objects that accept SET operations.
Most MIB modules that exist today provide very little detail as to
why a configuration request has failed. Often the only information
provided is via SNMP protocol errors which generally does not provide
enough information about why an agent rejected a set request.
Typically, there is an incumbent and sizable burden on the
configuration application to determine if the configuration request
failure is the result of a resource issue, a security issue, or an
application error.
Ideally, when a "badValue" error occurs for a given set request, an
application can query the agent for more details on the error. 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 diagnosing conditions in the integrated
system.
MacFaden, et al. Informational [Page 36]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
Consider the requirement of conveying error information about a MIB
expression 'object' set within the DISMAN-EXPRESSION-MIB [40] that
occurs when the expression is evaluated. Clearly, none of the
available protocol errors are relevant when reporting an error
condition that occurs when an expression is evaluated. Instead, the
DISMAN-EXPRESSION-MIB provides objects to report such errors (the
expErrorTable). Instead, the expErrorTable maintains information
about errors that occur at evaluation time:
expErrorEntry OBJECT-TYPE
SYNTAX ExpErrorEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about errors in processing an expression.
Entries appear in this table only when there is a matching
expExpressionEntry and then only when there has been an
error for that expression as reflected by the error codes
defined for expErrorCode."
INDEX { expExpressionOwner, expExpressionName }
More specifically, a MIB module can provide configuration
applications with information about errors on the managed device by
creating columnar object types in log tables that contain error
information particular to errors that occur on row activation.
Notifications with detailed failure information objects can also be
used to signal configuration failures. If this approach is used, the
configuration of destinations for NOTIFICATION-TYPE data generated
from configuration failures should be considered independently of the
those for other NOTIFICATION-TYPEs which are generated for other
operational reasons. In other words, in many management
environments, the network operators interested in NOTIFICATION-TYPEs
generated from configuration failures may not completely overlap with
the community of network operators interested in NOTIFICATION-TYPEs
generated from, for example, network interface failures.
3.12. Designing MIB Modules for Multiple Managers
When designing a MIB module for configuration, there are several
pertinent considerations to provide support for multiple managers.
The first 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 [3] defines TestAndIncr,
often called a spinlock, which is used to avoid race conditions.
MacFaden, et al. Informational [Page 37]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
A MIB module designer may explicitly define a synchronization object
of syntax TestAndIncr or may choose to rely on snmpSetSerialNo (a
global 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
command generator applications to coordinate their
use of the SNMP 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 }
Another prominent TestAndIncr example can be found in the SNMP-
TARGET- MIB [9], snmpTargetSpinLock.
Secondly, an agent should be able to report configuration as set by
different entities as distinguishable from configuration defined
external to the SNMP domain, such as application of a default or
through an alternate management interface like a command line
interface. Section 3.10.1 describes considerations for this practice
when designing NOTIFICATION-TYPEs. The OwnerString textual
convention from RMON-MIB RFC 2819 [32] has been used successfully for
this purpose. More recently, RFC 3411 [1] introduced the
SnmpAdminString which has been designed as a UTF8 string. This is
more suitable for representing names in many languages.
Experience has shown that usage of OwnerString to represent row
ownership 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 prevalent and useful in applications.
Thirdly, consider whether there is a need for multiple managers to
configure 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, at least at the level of
securityName or groupName provided. RFC 3231 [25], Section 6
presents this technique in detail. This technique does add
complexity to the managed device and to the configuration management
application since the manager will need to be aware of these
additional columnar objects in configuration tables and act
appropriately to set them. Additionally, the agent must be
MacFaden, et al. Informational [Page 38]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
configured to provide the appropriate instance-level restrictions on
the modifiability of the instances.
3.13. Other MIB Module Design Issues
3.13.1. Octet String Aggregations
The OCTET STRING syntax can be used as 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[2].
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 3418 SNMPv2-MIB [11].
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 }
Such informational object types have come to be colloquially known as
"scratch pad objects". While often useful, 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 definition of the
contents of the OCTET STRING is needed, since the actual format of an
instance for such an object is unstructured. Hence, alternatively,
dividing the object type into several object type definitions can
provide the required additional structural detail.
When using OCTET STRINGS, avoid platform dependent data formats.
Also avoid using OCTET STRINGS where a more precise SMI syntax such
as SnmpAdminString 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. For example, the PortList syntax as defined in the
Q-BRIDGE-MIB (RFC 2674 [26]) is defined as follows:
MacFaden, et al. Informational [Page 39]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
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 compact representation saves on data transfer but has some
limitations. Such complex instance information is difficult to
reference outside of the object or use as an index to a table.
Additionally, with this approach, if a value within the aggregate
requires change, the entire aggregated object instance must be
written.
Providing an SNMP table to represent aggregate data avoids the
limitations of encoding data into OCTET STRINGs and is thus the
better general practice.
Finally, as previously mentioned in Section 3.3.6.3, one should
consider the practical ramifications of instance transfer for object
types of SYNTAX OCTET STRING where they have typical instance data
requirements close to the upper boundary of SMIv2 OCTET STRING
instance encoding. Where such object types are truly necessary at
all, SNMP/UDP may not be a very scalable means of transfer and
alternatives should be explored.
3.13.2. Supporting multiple instances of a MIB Module
When defining new MIB modules, one should consider if there could
ever be multiple instances of this MIB module in a single SNMP
entity.
MIB modules exist that assume a one to many relationship, such as
MIBs for routing protocols which can accommodate multiple "processes"
of the underlying protocol and its administrative framework.
However, the majority of MIB modules assume a one-to-one relationship
between the objects found in the MIB module and how many instances
will exist on a given SNMP agent. The OSPF-MIB, IP-MIB, BRIDGE-MIB
are all examples that are defined for a single instance of the
technology.
MacFaden, et al. Informational [Page 40]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
It is clear that single instancing of these MIB modules limits
implementations that might support multiple instances of OSPF, IP
stacks or logical bridges.
In such cases, the ENTITY-MIB [RFC2737] can provide a means for
supporting the one-to-many relationship through naming scopes using
the entLogicalTable. Keep in mind, however, that there are some
drawbacks to this approach.
1) One cannot issue a PDU request that spans naming scopes. For
example, 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) Reliance on this technique creates a dependency on the Entity MIB
for an application to be able to access multiple instances of
information.
Alternately, completely independently of the Entity MIB, multiple MIB
module instances can be scoped by different SNMP contexts. This
does, however, require the coordination of this technique with the
administrative establishment of contexts in the configured agent
system.
3.13.3. Use of Special Optional Clauses
When defining integer-based objects for read-create, read-write and
read-only semantics, using the UNITS clause is recommended in
addition to specification in the DESCRIPTION clause of any particular
details of how UNITs are to be interpreted.
The REFERENCE clause is also recommended as a way to help an
implementer track down related information on a given object. By
adding a REFERENCE clause to the specific underlying technology
document, multiple separate implementations will be more likely to
interoperate.
4. Implementing SNMP Configuration Agents
4.1. Operational Consistency
Successful deployment of SNMP configuration systems depends on
understanding the roles of MIB module design and agent design.
MacFaden, et al. Informational [Page 41]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
Both module and agent design need to be undertaken with an
understanding of how UDP/IP-based SNMP behaves. A current practice
in MIB design is to consider the idempotency of settable objects.
Idempotency basically means being able to invoke the same set
operation repeatedly but resulting in only a single activation.
Here is an example 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)
Manager receives OK
Had object A been defined in a stateful way, the set operation might
have caused the Set2 operation to fail as a result of interaction
with Set1. If the agent implementation is not aware of such a
possible situation on the second request, the agent may behave poorly
by performing the set request again rather than doing nothing.
The example above shows that all of the software that runs on a
managed element and in managed applications should be designed in
concert when possible. Particular emphasis should be placed at the
logical boundaries of the management system components in order to
ensure correct operation.
1. The first interface is between SNMP agents in managed devices and
the management applications themselves. The MIB document is a
contract between these two entities that defines expected behavior
- it is a type of API.
2. The second interface is between 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 in order to minimize the impact of management on the
primary subsystems.
Additionally, while the SNMP protocol-level and MIB module-level
modeling of configuration operations may be idempotent and stateless
from one set operation to another, it may not be that way in the
MacFaden, et al. Informational [Page 42]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
underlying subsystem. It is possible that an agent may need to
manage this state in these subsystem architectures explicitly when it
has placed the underlying subsystem into an "intermediate" state at a
point in processing a series of SET PDUs. Alternatively, depending
on the underlying subsystem in question, the agent may be able to
buffer all of the configuration set operations prior to activating
them in the subsystem all at once (to accommodate the nature of the
subsystem).
As an example, it would be reasonable to define a MIB module to
control Virtual Private Network (VPN) forwarding, in which a
management station could set a set of ingress/egress IP addresses for
the VPN gateway. Perhaps the MIB module presumes that the level of
transactionality is the establishment of a single row in a table
defining the address of the ingress/egress gateway, along with some
prefix information to assist in routing at the VPN layer to that
gateway. However, it would be conceivable that in an underlying
Layer 2 VPN subsystem instrumentation, the requirement is that all
existing gateways for a VPN be deleted before a new one can be
defined--that, in other words, in order to add a new gateway, g(n),
to a VPN, gateways g(1)..g(n-1) need to be removed, and then all n
gateways reestablished with the VPN forwarding service. In this
case, one could imagine an agent which has some sort of timer to
establish a bounded window for receipt of SETs for new VPN gateways,
and to activate them in this removal-then-reestablishment of existing
and new gateways at the end of this window.
4.2. Handling Multiple Managers
Devices are often modified by multiple management entities and with
different management techniques. It is sometimes the case that an
element is managed by different organizations such as 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(s) and the
managed elements.
An agent should report configuration changes performed by different
entities. It should also distinguish configuration defined locally
such as a default or locally specified configuration made through an
alternate management interface such as a command line interface.
When a change has been made to the system via SNMP, CLI, or other
method, a managed element should send an notification to the
manager(s) configured as recipients of these applicable
notifications. These management applications should update their
MacFaden, et al. Informational [Page 43]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
local configuration repositories and then take whatever additional
action is appropriate. This approach can also be an early warning of
undesired configuration changes.
Managers should also develop mechanisms to ensure that they are
synchronized with each other.
4.3. Specifying Row Modifiability
Once a RowStatus value is active(1) for a given row, the management
application should be able to determine what the semantics are for
making additional changes to a row. The RMON 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 observe.
4.4. Implementing Write-only Access Objects
The second version of the SNMP SMI dropped direct support for a
write-only object. It is therefore necessary to return something when
reading an object that you may have wished to have write-only
semantics. Such objects should have a DESCRIPTION clause that
details what the return values should be. However, regardless of the
approach, the value returned when reading the object instance should
be meaningful in the context of the object's semantics.
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 using SNMP. Functions all configuration management
software should provide, regardless of the method used to convey
configuration information to the managed systems are backup, fail-
over, 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.
MacFaden, et al. Informational [Page 44]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
2. A method for saving back up versions of the configuration data in
case of hardware or software failure.
3. A method of providing fail-over 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 of
configuration.
These three capabilities are of course important for other types of
management that are not the focus of this BCP.
5.1. Configuration Application Interactions with Managed Systems
From the point of view of the design of the management application,
there are three basic requirements to evaluate relevant to SNMP
protocol operations and configuration:
o Set and configuration activation operations
o Notifications from the device
o Data retrieval and collection
Depending on the requirements of the specific services being
configured, many other requirements may, and probably will, also be
present.
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 configuration 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 expected 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.
MacFaden, et al. Informational [Page 45]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
5.1.1. SET Operations
Management software should be mindful of the environment in which SET
operations are being deployed. The intent here is to move
configuration information as efficiently as possible to the managed
device. There are many ways to achieve efficiency and some are
specific to given devices. One general case that all management
software should employ is to reduce the number of SET PDU exchanges
between the managed device and the management 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 bindings to be
sent in a particular PDU will be influenced by the device, the
specific MIB objects and other factors.
Maximizing the number of variable bindings in a SET PDU also has
benefits in the area of management application transaction
initiation, as we will discuss in the following section.
There are, though, agents that may have implementation limitations on
the number and order of varbinds they can handle in a single SET PDU.
In this case, sending fewer varbinds will be necessary.
As stated at the outset of this section, the management application
software designer must be sensitive to the design of the SNMP
software in the managed device. For example, the software in the
managed device may require that all that all related configuration
information for an operation be conveyed in a single PDU because it
has no concept of a transaction beyond a single SNMP PDU. Another
example has to do with the RowStatus textual convention. Some SNMP
agents implement a subset of the features available and as such the
management application must avoid using features that may not be
supported in a specific table implementation (such as createAndWait).
5.1.2. Configuration Transactions
There are several types of configuration transactions that can be
supported by SNMP-based configuration applications. They include
transactions on a scalar object, transactions in a single table
(within and across row instances), 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 used in the configuration
operation.
To make use of any kind of transaction semantics effectively, SNMP
management software must be aware of the information in the MIB
modules that it is to configure so that it can effectively utilize
MacFaden, et al. Informational [Page 46]
RFC 3512 Configuring Networks and Devices with SNMP April 2003
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
provide 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 that support
management application level transactions. One was mentioned in the
preceding section, that transactions can be optimized by including
the maximum number of SET variable bindings possible in a single PDU
sent to the agent.
There is an important refinement to this. The set of read-create row
data objects for tables should be sent in a single PDU, and only
placed across multiple PDUs if absolutely necessary. The succe |
