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
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
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 RFC3411 [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, RFC1155 [15], STD 16, RFC1212 [16] and RFC1215 [17]. The
second version, called SMIv2, is described in STD 58, RFC2578
[2], STD 58, RFC2579 [3] and STD 58, RFC2580 [4].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [18]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [19]. The
third version of the message protocol is called SNMPv3 and
described in RFC3417 [5], RFC3412 [6] and RFC3414 [7].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [18]. A second set of protocol
operations and associated PDU formats is described in RFC3416
[8].
o A set of fundamental applications described in RFC3413 [9] and
the view-based access control mechanism described in RFC3415
[10].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC3410 [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.
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
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.
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.
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 (RFC1493 [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.
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.
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, RFC1493, 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.
(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 RFCnames.
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.
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
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.
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.
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.
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 RFC2790, 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, RFC2737 [34], provides the following
object:
entLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time a conceptual row is
created, modified, or deleted in any of these tables:
- entPhysicalTable
- entLogicalTable
- entLPMappingTable
- entAliasMappingTable
- entPhysicalContainsTable"
::= { entityGeneral 1 }
This convention is not formalized. There tend to be small
differences in what a table's LastChanged object reflects. IF-MIB
(RFC2863 [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
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:
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,
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 RFC2819 [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 RFC2863 [20] and the
ifInvStackTable RFC2864 [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 }
Second, table designs that can factor data into multiple tables with
well-defined relationships can help reduce overall data transfer
requirements. The RMON-MIB, RFC2819 [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