INTERNET-DRAFT SNMP CONFIGURATION July 2000
M. MacFaden
Riverstone Networks, Inc
J. Saperia
JDS Consulting, Inc
CONFIGURING NETWORKS AND DEVICES WITH SNMP
draft-ietf-snmpconf-bcp-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document is intended for vendors building equipment using the
Internet Standard Management Framework as well as for users of such
equipment. General guidelines for configuration are presented from
MacFaden/Saperia January 2000 [Page 1]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
which specific current best practices using the Internet Standard
Management Framework are derived.
NOTE: this work is very much a draft in progress. Reviewer comments,
questions and criticisms welcome on the snmpconf mailing list.
Table of Contents
Copyright Notice .................................................... 1
Abstract ........................................................... 1
1. Introduction ..................................................... 3
2. Document Organization ............................................ 4
3. Background - Practicing Configuration ............................ 4
4. Requirements ..................................................... 5
4.1 Fundamental Tenets of configuration ............................. 5
4.2 Requirements of configuration .................................. 6
4.3 Agent Software Development .................................... 7
4.3.1 Define read-write objects at the "right" level of abstraction.. 7
4.3.2 Separate out configuration sets from activation of configuration
sets ................................................................ 9
4.3.3 Employ summary objects so managers can track overall state of
configuration easily and efficiently ................................ 9
4.3.4 Handle activation latency early in the design of read-write
objects ............................................................ 9
4.3.5 Do not rely on the SNMP to report application layer errors for
SET operations ......................................................12
4.3.6 Do not create read-write objects that overlap in capability or
activate potentially the same instance...............................12
4.3.7 Use common Textual Conventions whenever possible, especially
when defining enumerations ..........................................13
4.3.8 Distinguishing which enumeration's an agent can support should
be done in an Agent Capability MIB or by designing the MIB to indicate
required basic capabilities ........................................ 14
4.3.9 RowStatus objects should return notReady(3) value if one or more
mandatory objects in a given row have not been set ..................14
4.3.10 For objects contained in a table, specify semantics of changing
a value when the row is in active(1) stat e ........................ 15
4.3.11 Extending IETF standard notifications is considered permissible.
15
4.3.13 Octet strings should not be used to aggregate multiple objects.
16
4.3.14 Design in an upper limit on the number of notifications (or
traps) that can be sent in response to a given event ............... 16
4.3.15 Currency with RFC MIB Module Standards 17
MacFaden/Saperia January 2000 [Page 2]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
4.3.16 Do not ship a device with a community string "public" or
"private" .......................................................... 17
4.3.17 The default state of RFC 1215 Authentication traps should be
off ................................................................ 17
4.3.18 Persistence expectations of sets should be well defined ..... 18
4.3.19 If a MIB object contains sensitive information, then specify so
in DESCRIPTION clause the need for encryption ...................... 18
4.3.20 Using OwnerString to represent row ownership can be a useful
diagnostic tool .................................................... 19
4.3.21 Using a TimeStamp in read-create tables to show when it was
activated is a useful diagnostic tool .............................. 19
5.0 Management Software Development ............................... 19
5.1 Protocol Operations ........................................... 20
5.2 SET Operations ................................................ 20
5.3 Configuration Transactions .................................... 21
5.4 Notifications ................................................. 21
5.5 Scale of the Management Software .............................. 22
5.6 Rate and Volume of Changes to Device .......................... 22
5.7 Handling Multiple Managers .................................... 22
5.8 Diagnostics and Configuration ................................. 23
6.0 Policy Based Management ........................................ 23
6.1 Introduction and Definition of Terms ........................... 23
6.2 Information Related to Policy Configuration .................... 25
6.3 Policy, Mechanism/Implementation and Instance Specific Modules
26
6.4 Schedule and Time Issues ....................................... 26
6.5 Conflict Detection, Resolution and Error Reporting ............. 27
6.6 Policy Precedence and Grouping ................................. 28
6.7 Changes to configuration outside of the policy system .......... 28
6.6 Use of Contexts ................................................ 28
6.8 Policy distribution applications ............................... 28
6.9 Notifications in a Policy System ............................... 28
7.0 Glossary ....................................................... 29
8.0 Example MIB .................................................... 29
9.0 References ..................................................... 37
10.0 Editors' Addresses ............................................ 39
11.0 Full Copyright Statement ...................................... 40
1. Introduction
Data networks have grown greatly in size and complexity over the
past decade. Configuration, also called provisioning of network
elements, has grown correspondingly more complex in a number of
aspects:
Scale - data networks consist of more devices than ever before.
Functionality - network devices increasingly perform more functions.
MacFaden/Saperia January 2000 [Page 3]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
Convergence - more protocols and network layers are involved than
ever before.
The SNMP framework continues to be used successfully to develop
configuration management systems for a broad range of devices. This
document describes Best Current Practices that should be used when
designing an effective SNMP-based element management system.
In addition to element management, the SNMP can be used to configure
groups of devices on a more abstract layer. Recently a great deal of
attention has been placed on policy based configuration management.
This document also includes recommendations for policy based
configuration. This document defines "Policy based configuration
management" as a set of configuration operations distributed to
potentially many network elements with the goal of achieving
consistent network behavior throughout a given autonomous system
[21].
This document draws on experience provisioning public and private
data networks over the past ten years. Over that same time-period,
significant experience has been gained in the development and
deployment of SNMP based management software, some of which also
performs configuration functions.
2. Document Organization
The background section describes how experienced operations staff
generally practices configuration of TCP/IP networks.
The first through fourht section on requirements enumerates the
goals and fundamental assumptions of configuration. Section 2 and 3
describe agent and management best current practices using the
Internet standard SNMP framework. Section 6 describes relationship
of Policy Management to SNMP framework. Section 8 presents a sample
MIB from which many examples are based.
3. Background - Practicing Configuration
The purpose of this section is to provide a sample configuration
sequence for evaluating many of the requirements in further sections
of this BCP.
Data network devices are configured using many mechanisms, however
two methods remain the most common: SNMP and Command
Line Interface (CLI).
MacFaden/Saperia January 2000 [Page 4]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
Layered on top of these mechanisms are operational methods for
deploying changes to networks in a cautious and incremental manner.
Experienced Network Operations staff makes changes to network
configurations and firmware with careful planning and well
documented procedures. Here is one model in detail:
A. Pass one: LAB tryout to verify reliability and interoperability
with prior versions of system code.
B. Pass two: select an edge of network during non-critical/off hours
to effect the change and plan for fall back should changes fail.
C. Apply change first via CLI to memory and watch device/network
carefully over some time period
D. After some time, write changes to persistent storage
E. Expand changes to a few more like devices
F. Keep mixed versions to prevent total loss of network
G. Watch for new unknown defaults
H. Watch for unknown side effects of changes
I. Update configurations in revision control system
Often, a diagnostic mode is present to deal with specific
implementation issues above and beyond the standard set of
instrumentation.
4. Requirements
This section describes basic realities affecting a configuration
management system from which specific requirements will be derived.
4.1 Fundamental Tenets of configuration
A "mere mortal" trained in the operation of a given technology
SHOULD be able to understand a device's state or some logical view
of that state. The configuration mechanism must not be more complex
than what is generally being configured so as to obscure what is
being configured.
Operators MUST have the ability to validate proper operation of a
device before and after configuration changes regardless of latency.
Put another way, the operator should have an integrated view of
configuration, status, and diagnostic information. Ideally there are
a series of tests the operator runs before and after a change is
MacFaden/Saperia January 2000 [Page 5]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
made to an operational network to ensure service remains intact. A
configuration subsystem should provide tools to facilitate such
tests. For example, when configuring a DNS system, the tool nslookup
is often used with a script to verify key database entries are
present and return the expected values.
Configuration can affect network stability and network stability can
affect configuration procedures. Achieving convergence (stability)
in an autonomous system is not an absolute given when configuration
changes are made. For example, if changes are made to
ospfIfHelloInterval and ospfIfRtrDeadInterval [22] timers in the
OSPF routing protocol such that both are set to the same value, two
routers may form an adjacency but then begin to cycle: lose
adjacency, form adjacency and so on never reach a converged (stable)
state.
Systems under configuration should be able to cope with unexpected
loss of control due to lost communications. Any modern configuration
protocol or process should be able to cope with a connectivity loss
between manager and managed device. Network elements must take
appropriate measures to leave the configuration in a
consistent/recognizable state by either rolling back to a previously
valid state or changing to a default state.
Here then are requirements for a modern configuration protocol.
4.2 Requirements of configuration
Diagnostic routines should be provided to verify proper operation of
complex protocols. Debugging is an integral part of the
configuration process. Subsystems should provide self-tests that
verify internal state as well as tests to verify external states.
Inclusion of debug/diagnostic tests that are exposed through a MIB
interface improve the chance configuration errors can be identified
and localized. The sequence test, set, test then becomes a normal
method if change control in a production environment.
Impact on convergence of an existing network should be specified in
the configuration MIB interface. For example, any configuration
change that causes loss of convergence should be noted in a
description clause. Should an implementation fail to meet the
convergence properties for a given object, notes can be made in an
agent-capabilities MIB variations clause. A similar requirement is
stated in "Requirements for IP Version 4 Routers" [20], section
1.3.4:
A vendor needs to provide adequate documentation on all
configuration parameters, their limits and effects.
MacFaden/Saperia January 2000 [Page 6]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
Any modern configuration protocol or process must be mindful of
connectivity loss between manager and managed device and take
appropriate measures to leave the network device or devices in a
consistent/recognizable state.
4.3. Agent Software Development
This chapter will enumerate a number of best current practices by
drawing upon a fictional MIB called ACME-HOUSECTRL-MIB. This MIB can
control familiar facilities found in a modern home and is defined in
Section 8.0 along with a sample agent capabilities definition. Along
the way, the BCP also reviews key capabilities in the SNMP such as
transactions, security, and error handling in the context of
configuration.
4.3.1 Define read-write objects at the "right" level of abstraction.
Metrics that can be employed during MIB design include number of
objects needed to configure a given system, the relations among
objects in the system, and the frequency at which they change state.
If a MIB used for configuration contains "too many" objects to
provision a given facility, then it is likely an abstraction
problem. If there are overlapping objects with similar capabilities,
then the abstraction may be to blame as well (See BCP6).
For example, consider the configuration request to turn on all
lights in a house. There may be tens of light circuits in a given
single family home. The MIB Designer might be tempted to create a
table with an instance for each lighting group controlled by one
more switches and have an object to turn that light group on/off.
Yet it considering the request, this would force the application
developer to issue sets with tens of objects. The MIB Designer might
solve this in at least two ways. First, specify an enumeration with
specific operations:
acmeGlobalHouseOperations OBJECT-TYPE
SYNTAX INTEGER {
turnOffAllLights (1),
turnOnAllLights(2)
dimAllLights(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
MacFaden/Saperia January 2000 [Page 7]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
"Actions to apply to all Lights in a house."
::= { acmeLightGlobals 2 }
The ease of adding such an object though has he drawback that the
relations to other read-create tables for which individual lights
suddenly become more complicated. What should happens to read-write
objects when all lights are turned using the above object is not
clearly spelled out. Exception cases then are created and an
application would have to poll all objects correctly to obtain the
current state of lights.
The second approach is to make the general command more powerful.
acmeLightGlobalHouseAction OBJECT-TYPE
SYNTAX INTEGER {
turnOn(1),
turnOff(2),
dim(3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Actions to apply to the lights enumerated in
acmeLightGlobalHouseArgument."
::= { acmeLightEntry 2 }
acmeLightGlobalHouseArgument OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A bitwise encoding of indexes into the
light Table for which a given Action
will be applied to."
::= { acmeLightEntry 3 }
This solution makes interpreting what the original request was much
easier, but not what the current state of all the light-groups
currently are. If a history is needed of what commands were sent,
this table can record this aspect as well.
DISCUSION NOTE: Retrieving a consistent configuration remains
problematic from most SNMP agents that implement a wide range of
MIBs. There is no generic way to retrieve a configuration with out
a-priori knowing what objects to get. A solution that records every
object using the powerful getnext operator does not scale.
MacFaden/Saperia January 2000 [Page 8]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
4.3.2 Separate out configuration sets from activation of configuration
sets.
(ospfAdminStat, schedAdminStatus)
Any complex configuration should have a master on/off switch as well
as strategically placed on/off switches to control the employment of
configuration data. These controls play a pivotal role during the
configuration process as well as during diagnostics. Generally a
series of set operations should not cause an agent to act on each
object causing convergence/stability to be lost on each and every
set. Ideally a series of Set PDUs would install the configuration
and a final set series of PDUs would activate the changes.
During diagnostic situations, certain on/off switches can be set to
localize the perceived error instead of having to remove the
configuration.
DISCUSSION NOTE: ifAdminStatus effects on ifOperStatus, helps in one
case where one doesn't poll ifAdminStatus along with ifOperStatus,
but hurts in another as in trying to know if the link would be up
operationally without actually setting ifAdminStatus to up(1).
A master on/off switch for a given subsystem SHOULD be provided.
Often, these switches are useful for diagnostics such as to help
locate which subsystem is unstable as well as for a common
configuration sequence where a feature is taken off-line,
reconfigured then put back online.
Lastly, one should not overload RowStatus objects to control
activation/deactivation of a configuration. While RowStatus looks
ideally suited for such a purpose since a management application can
set a row to active(1), then set it to notInService(2) to disable it
then make it active(1) again, there is no guarantee that the agent
won't discard the row while it is in the notInService state.
For an example see RFC 2591 schedAdminStatus.
4.3.3 Employ summary objects so managers can track overall state of
configuration easily and efficiently.
It is generally important to track changes to a device and to sync
the changes with some specific configuration repository.
Creating summary status objects "dummy lights" to provide simple and
quick means to determine overall configuration-state of a subsystem.
MacFaden/Saperia January 2000 [Page 9]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
For example, checksums or configuration version ids could also be
computed over a configuration so that an application can reasonably
identify an entire configuration instead of having to poll many
"LastChange" objects or have to use TimeFilter style indexing to
achieve highly efficient polling of large tables.
The ACME-HOUSECTL-MIB contains the following definitions:
AcmeCfgVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that starts at 0 and increases monotonically
until the max value is reached at which point the value
returns to 0."
SYNTAX Gauge32
acmeSysActiveConfigId OBJECT-TYPE
SYNTAX AcmeCfgVersion
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current value of configuration information. This value
remains persistent across reboots and increases when
configuration changes are made to any object in this MIB."
::= { acmeHouseGlobals 3 }
If configuration changes are very frequent in the order of seconds
then the abstraction for configuration is probably wrong, see BCP1.
If polling would not scale, consider using Notifications for
reporting the old and new checksum objects.
Notifications should most always report objects that are readily
accessible to a manager station via polling.
4.3.4 Handle activation latency early in the design of read-write
objects.
(doscsIfDownChannelFrequency)
Many MIBs both standard and enterprise often make the mistake of
assuming an agent can activate a set operation as fast as it takes
the agent to reply to the manager for a given set PDU. When there is
anticipated latency in activating the results of a set operation a
MIB designer SHOULD either:
Define state machine to support the intermediate states
Separate out read state of the object from read-write state of the
object.
MacFaden/Saperia January 2000 [Page 10]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
For example, if the ACME-HOUSE-MIB had implemented the garage door
with a single object as follows:
acmePortGarageDoor OBJECT-TYPE
SYNTAX INTEGER { unknown(0), closed(1), open(2)}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current state of the garage door.
Most garage doors open completely within 12 seconds."
::= { acmePortGarageEntry 2 }
Manger Time 0
GetPDU acmePortGarageDoor.1.1
Agent Time 1
ResponsePDU error-index 0 error-code 0
acmePortGarageDoor.1.1 = open(2)
Manger Time 2
SetPDU acmePortGarageDoor.1.1 = closed(1)
Agent Time 3
ResponsePDU error-index 0 error-code 0
acmePortGarageDoor.1.1 = closed(1)
Manger Time 4
GetPDU acmePortGarageDoor.1.1
Agent Time 5
ResponsePDU error-index 0 error-code 0
acmePortGarageDoor.1.1 = open(2)
Manger Time 5+N (some seconds later...)
GetPDU acmePortGarageDoor.1.1
Agent Time N+4
ResponsePDU error-index 0 error-code 0
acmePortGarageDoor.1.1 = closed(1)
But the Manager expected the value of closed(1) since it had just
set that value! Repeated polling of the object will eventually
return the state value of closed(1) assuming nothing prevented the
door from returning to the open state.
Another variation on latency is the granularity of counter updates.
Mangers some devices can't update counters as fast as it may be
polled. One SHOULD indicate in the agent capability MIB for the
device what the minimum polling interval is.
MacFaden/Saperia January 2000 [Page 11]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
4.3.5 Do not rely on the SNMP to report application layer errors for
SET operations.
MIB Design for configuration SHOULD use objects to track application
level state. Management applications to date do not handle errors
gracefully from the SNMP. When designing a MIB for configuration, do
not rely on the SNMP error command set for application level state.
Even if the SNMP will catch a "badValue" error, the application
should report additional application level error-state that an
application can obtain from an agent and decode.
Failure to provide detailed diagnostic information leads to
management applications that end up reporting insufficient error
information.
acmeSysDeviceLastErr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A description of the last error that occurred in this MIB
due to configuration errors or status error presentable to
user interface."
::= { acmeHouseGlobals 7 }
4.3.6 Do not create read-write objects that overlap in capability or
activate potentially the same instance.
(dot1dStpPortEnable)
One SHOULD NOT duplicate configuration objects across MIBs.
While it may appear as a convenience, such as providing different
indexing schemes, the side effects may not be easily discernible.
For example, in the ACME-HOUSECTL-MIB, a designer might have
designed the following two objects at different times:
acmeWaterHeaterPilot OBJECT-TYPE
SYNTAX INTEGER {
off(1),
on(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
MacFaden/Saperia January 2000 [Page 12]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
"The current state of the pilot light."
::= { acmeWaterHeaderEntry 4 }
in one table indexed by instances of water heaters in a house and
then in another section of another MIB that adds a third state.
-- The state of all gas pilots
acmeGasPilotsStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1), -- ready to pass gas
disabled(2),
primed(3) -- in some prime mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Gas Pilots have three states, initial state is disabled, then
primed which properly heats thermocouple and activates safety
valves, then enabled."
::= { acmeGasPilotsEntry 7 }
If a port is set to primed(3) via the acmeGasPilotsStatus what
should be reported in reported in acmeWaterHeaterPilot for the same
instance?
Fate sharing of the indexing should also be specified if possible
using SMI constructs such as AUGMENTS. If the relationship between
tables can not be defined using SMIv2 macros, then the DESCRIPTION
clause should define what should happen.
4.3.7 Use common Textual Conventions whenever possible, especially
when defining enumerations.
Textual conventions that have even the slightest chance of being
reused in other MIBs SHOULD also be defined in a separate MIB to
facilitate sharing of such objects.
For example, the state of an object can often be described using a
TruthValue textual convention instead of inventing yet another
Boolean condition.
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
MacFaden/Saperia January 2000 [Page 13]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
Would better expressed as follows:
AcmePatioLightsEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
4.3.8 Distinguishing which enumeration's an agent can support should
be done in an Agent Capability MIB or by designing the MIB to indicate
required basic capabilities.
(dot1dDeviceCapabilities)
In some cases, the use of capability bits can alleviate this as
defined in RFC 2674 dot1dDeviceCapabilities can define some preset
levels of capability.
Example: can one subset a RowStatus implementation by just doing
createAndGo instead of createAndWait and still call it RowStatus?
When implementing a MIB object with the syntax of RowStatus, failure
to implement the entire state machine MUST not be done. There is no
VARIANT clause that allows one to implement only createAndGo and
destroy and any such implementation is NOT compliant with the SMI.
4.3.9 RowStatus objects should return notReady(3) value if one or more
mandatory objects in a given row have not been set.
When designing read-create objects in a table containing a RowStatus
object, first consider the default state of each object in the table
when a row is created via one simple createAndWait(5) PDU. If no
default state is applicable but the object must be set to some
value, the DESCRIPTION clause should specify this object as
mandatory. In addtion, an snmp get of such an object then should
return noSuchName if the object has not yet been set. The RowStatus
object should return notReady until all mandatory objects have been
specified.
MacFaden/Saperia January 2000 [Page 14]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
Should a given implementation require more objects to be set than
what is specified in a MIB, an Agent capabilities MIB can be used to
define the additional objects using the CREATION-REQUIRES clause.
Not implementing the above may result in a manager being mislead
that a transition to active(1) state will succeed without further
action by only polling the rowStatus object and receiving the
notInService(2) value from an agent.
4.3.10 For objects contained in a table, specify semantics of changing
a value when the row is in active(1) state.
It is an advantage for an agent developer to know when an object can
and can not change value. Some operations may require an extended
period of time to run with a given set of parameters. To change
those parameters in mid step would necessitate the restarting of the
whole operation.
4.3.11 Extending IETF standard notifications is considered permissible.
Vendor extensions to existing standard notifications are not
explicitly disallowed or allowed in SMIv2. For example, linkUp and
linkDown traps are defined as follows in IF-MIB, rfc 2233.
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 entity,
acting in an agent role, has detected that the
ifOperStatus object for one of its communication
links is about to enter the down state from some
other state (but not from the notPresent state).
This other state is indicated by the included
value of ifOperStatus."
::= { snmpTraps 3 }
An implementation MAY add additional varbind objects to standard
notifications. However, an implementation SHOULD make any extensions
be not enabled by default and when enabled. An implementation SHOULD
append to the varbind list any extensions.
4.3.12 Do not use OCTET STRINGS to transport data that differs by
memory architecture or implementation.
MacFaden/Saperia January 2000 [Page 15]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
(PortList)
A MIB designer SHOULD NOT use octet strings to transport data that
differs by memory architecture or implementation. Only a well-
specified generic model should be used such as the above example.
4.3.13 Octet strings should not be used to aggregate multiple objects.
Separate objects should be specified in separate MIB objects.
Octet string is by definition limited to 256 bytes. If the object
being modeled is larger than this size, one should abstract the
information or reorganize the data to fit within this size boundary
which helps keep configuration working in the face of abnormally
behaving networks.
4.3.14 Design in an upper limit on the number of notifications (or
traps) that can be sent in response to a given event.
The more frequent the event which causes the notification to be
sent, the greater the need for internal aggregation or throttling in
the agent.
There can be cases where it is not useful to send notifications for
a given notification such as in frDLCIStatusChange defined in RFC
2115. In this case when interfaces are taken down administratively,
no frDLCIStatusChange will be sent.
At other times, rate limiting notifications sent should be
considered as in frTrapMaxRate.
acmeHouseCtlDeviceLost NOTIFICATION-TYPE
OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey,
acmeHouseInvenAdminStatus,
acmeHouseInvenOperStatus}
STATUS current
DESCRIPTION
"This notification is generated whenever
the invocation of a scheduled action fails.
If there is a failure of many devices
such that sending single notifications would be
resource and time prohibitive,
send the acmeHouseCtrlManyDevicesLost
notification."
MacFaden/Saperia January 2000 [Page 16]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
::= { acmeHouseCtlGlobalErrs 1 }
acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE
OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors }
STATUS current
DESCRIPTION
"This notification is generated whenever
the invocation of a
scheduled action fails. If there is a failure
of many devices such that sending single
notifications would be resource and time
prohibitive, send acmeHouseCtrlManyDevicesLost
notification."
::= { acmeHouseCtlGlobalErrs 2 }
4.3.15 Currency with RFC MIB Module Standards
Vendors SHOULD make every attempt to keep their implementations
current with the standards versions of MIB Modules. In particular,
agents and management software SHOULD follow the current STATUS of
MIB objects.
4.3.16 Do not ship a device with a community string "public" or
"private."
Agents should not define default community strings except where to
bootstrap devices that do not have secondary management interfaces.
These lead to security issues.
A managed device SHOULD support read only as well as read-write
community strings.
4.3.17 The default state of RFC 1215 Authentication traps should be
off.
In the "Notifications" section earlier, the issue of throttling
traps was raised. For SNMPv1 agents, any unsolicited packet to a
device that causes one ore more trap packets to be created and sent
to management stations in response. If these traps flow on links
that are shared, the community string from the trap may be used to
gain access to the device.
MacFaden/Saperia January 2000 [Page 17]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
4.3.18 Persistence expectations of sets should be well defined.
Explicit persistence of set requests has generally been assumed in
SNMP sets. New textual conventions such as StorageType allow for
alternative configuration models.
A MIB designer SHOULD make explicit indications as to how
implementers can make visible the level of persistence any read
write object can and should have.
For example, RFC 2591 defines the object schedStorageType of syntax
StorageType. New mibs SHOULD either define in
DESCRIPTION macros how a table should exist or use this type
to allow for varied persistence.
For instance: RFC 2674 also defines explicitly the 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 }
Best current practice in network elements is a dual persistence
model where: 1) a volatile memory configuration can be
retrieved/updated and 2) persistent boot configuration.
Single persistence systems suffer the ability to rollback changes
that cause lost connectivity and hence are not often found in
backbone wide area networks operated over remote connections.
4.3.19 If a MIB object contains sensitive information, then specify so
in DESCRIPTION clause the need for encryption.
(Bert)
There are MIB objects that may contain keys, passwords and other
such sensitive information and hence must be protected from
unauthorized access.
MacFaden/Saperia January 2000 [Page 18]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
A DESCRIPTION clause and for IETF MIB RFCS, the Security
Considerations section should make it clear how and why these
specific objects are sensitive and that a user should only make them
accessible for encrypted SNMP access.
If an implementation does not support DES, then the customer should
not allow access to these objects, which is easy to specify in VACM.
When writing standards track MIBs, one must operate on the basis of
the "must implement" properties are of the various standards-track
specifications.
Confidentiality is not a must-implement portion of the SNMPv3
specification.
4.3.20 Using OwnerString to represent row ownership can be a useful
diagnostic tool.
Practice has shown that the use of the string "monitor" to identify
configuration set by an agent/local management has been useful.
4.3.21 Using a TimeStamp in read-create tables to show when it was
activated is a useful diagnostic tool.
(ipCidrRouteAge, docsIfCmtsServiceCreateTime)
When tracking down errors in configuration sequences, having a
TimeStamp object in a row can help order sort out the order of
configuration without having to revert to write trace and protocol
decoders.
5.0 Management Software Development
This section focuses on general issues related to the development of
SNMP based applications that configure one or more network elements.
Special considerations for what has come to be known as policy-based
management with SNMP are discussed in the following section.
Effective software for the configuration of one or many network
elements requires some up front design work before starting
implementation. This is true regardless of the technology used to
represent and transfer the configuration information. For SNMP-based
configuration applications, here are some of the design parameters
that should be investigated before starting implementation.
MacFaden/Saperia January 2000 [Page 19]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
1. SNMP protocol operations
2. Scale of the Management
Software
3. Security considerations
4. Network topologies
5. Synchronization of management software and device views
6. Data storage and coexistence with other management applications
7. Device capabilities and differences
8. Persistence of configuration information
9. Multiple management systems
10. Support for diagnostic activities
5.1 Protocol Operations
There are three basic areas to evaluate relevant to SNMP protocol
operations and configuration: _ Set and configuration activation
operations _ Notifications from the device _ Data retrieval and
collection The design of the system should not assume that the
objects in a device that represent configuration data will remain
unchanged over time.
As standard MIB modules evolve and vendors add private extensions,
the specific configuration parameters for a given operation are
likely to change over time. Even in the case of a configuration
application that is designed for a single vendor, the designer
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. Management software SHOULD
verify the support in the devices it is intended to manage and
report any unexpected deviations to the operator. This approach is
particularly valuable when developing applications that are intended
to support equipment or software from multiple vendors.
5.2 SET Operations
Management software SHOULD adapt its SET operations to the type of
device and specific MIB objects included in the SET PDU.
Specifically, it SHOULD attempt to move the configuration
information as efficiently to the managed device as possible. There
are many ways to achieve efficiency and some are specific to
devices. One general case example that all management software
SHOULD employ is to reduce to the smallest reasonable number, the
MacFaden/Saperia January 2000 [Page 20]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
number of SET PDU exchanges between the managed device and the
management software. 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.
5.3 Configuration Transactions
There are several types of configuration transactions that can be
supported by SNMP-based configuration applications. They include
transactions on a single table, transactions across several tables
in a managed device and transactions across many devices. The
managers ability to support these different transactions is partly
dependent on the design of the MIB objects within the scope of the
configuration operation.
Management software that conforms with the BCP MUST be aware
of the information in the MIB Modules that it is to configure so
that it can effectively utilize row status 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.
5.4 Notifications
As described in the section on Agent Software Development, agents
SHOULD provide the capability for notifications to be sent to their
configured management systems whenever a configuration operation is
atttempted or completed. See that section for details on the control
of such notifications. The management application MUST be prepared
to accept these notifications so that it knows the current
configured state of the devices it has been deployed to control.
Some configuration management applications may consume data from the
managed devices that reflects configuration, operational and
utilization state information. The GetBulkRequest-PDU MUST be used
MacFaden/Saperia January 2000 [Page 21]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
whenever supported by the managed device. For the purposes of
backward compatibility, the management station SHOULD also support
the GetNextRequest-PDU. Management systems SHOULD also provide
configuration options with defaults for users that tend to retrieve
the smallest amount of data to achieve the particular goal of the
application.
5.5 Scale of the Management Software
Efficient data retrieval described above is only part of the
dimension of scale that application developers should consider when
developing configuration applications.
Deploying configuration software requires proper thought on how
configuration to a network will be done. There are basic
connectivity issues as well as security issues.
This section should include BCP for these if possible or dropped
upon further discussion.
5.6. Rate and Volume of Changes to Device
Describe different models from store and forward to real time
changes and how this relates to the volume of changes needed to
effect a feature change.
5.7. Handling Multiple Managers
Devices are often modified by multiple management entities.
These management entities may be in the same organization or may be
in different organizations interior or exterior to a given
autonomous system.
There are many aspects to view this model from. First is
coordinating the changes between two or more management applications
issuing SET protocol operations. Race conditions should be easily
detectable when two entities provision exactly the same object or
within a transaction a group of objects.
Second, A device SHOULD be able to report configuration as set by
different entities as well as distinguish configuration defined
MacFaden/Saperia January 2000 [Page 22]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
locally such as a default or locally specified configuration made
through an alternate management interfaces like command line
interface.
The SMIv2 defines the Textual convention TestAndIncr often called a
SpinLock to solve race conditions. As with most of the SNMP
framework, much flexibility is left to the implementers to "do the
right thing."
Unless a MIB explicitly defines the use mandatory use of
synchronization primitives, an agent MUST not enforce their
use. An object of syntax TestAndIncr SHOULD be well defined as to
what it is being covered. However the use of a general all
encompassing lock can be used such as RFC 1907 snmpSetSerialNo
object.
An application SHOULD use this object if there is no specific
TestAndIncr object.
5.8 Diagnostics and Configuration
This section describes in detail the kinds of diagnostics needed to
help support proper provisioning models.
6.0 Policy Based Management
Since policy based management with SNMP is a relatively new concept,
this section does not document established practice with regard to
policy-enabled SNMP management systems. It gives some background and
defines terms that are relevant to this field and describes
recommended deployment approaches.
Issues that one should consider when deploying an SNMP-enabled
policy management system are also discussed.
6.1 Introduction and Definition of Terms
A primary goal of policy based management is to represent
configuration information at higher levels of abstraction to make it
easier for some operators to configure elements without knowing the
details of each device.
MacFaden/Saperia January 2000 [Page 23]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
Part of the function of the management station software and software
the executes inside the network elements is to transform these
different levels of abstractness into a form the equipment can use.
The following are some terms that refer to the different levels of
abstraction.
Domain-Specific. A domain is a general area of technology such as
service quality or security. Services, or service level agreements,
may span several domains, each of them potentially including many
policies. As a general rule, people will not discuss these domains
in the abstract. They will most often be discussed with technology
or application-specific examples. Examples of technical domains
include, IPSec and Differentiated Services. When expressed in terms
specific to a particular domain, a policy is said to be at the
Domain Specific level of detail.
Mechanism-Specific. Mechanisms are technologies used within a
particular domain. For example, in the differentiated services
domain, RED (Random Early Detection) or WRED (Weighted Random Early
Detection) might be used as one of the mechanisms that devices
employ to support differentiated services and the applications on
which they rely. Policy descriptions that include the details
associated with a particular mechanism, are said to be mechanism-
specific.
Implementation-Specific. Implementation-specific details are those
parameters that a particular vendor might use in an implementation
that augment a standard set of mechanism-specific parameters.
Vendors often add special capabilities to basic mechanisms as a way
of meeting special customer requirements or differentiating
themselves from their competitors.
These special capabilities are often a result of the implementation
approach that a vendor has used for the product, thus the term,
implementation-specific. For example, if a router vendor implemented
a particular routing protocol, they would have the mechanism-
specific parameters that control the behavior of that software. The
vendor might have chosen to run several instances of that routing
protocol, perhaps on different processors, for performance reasons.
The parameters that are used to control the distribution of work on
the different processors for that protocol would be implementation-
specific.
Instance-Specific. Network operators are most familiar and
comfortable with information of this type. Instance-specific
information refers to parameter values that have been associated
with a specific instance in a managed element. For example, The
Border Gateway Protocol is a routing protocol that has a number of
parameters that describe information about a particular router1s
view of other routers that it is sharing information with, peer
MacFaden/Saperia January 2000 [Page 24]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
routers. One such parameter defined in the BGP MIB Module [BGP MIB]
is the desired connection retry interval for a peer,
bgpPeerConnectRetryInterval. An example value would be 120
(seconds). When expressed with this level of specificity, one would
say that this is mechanism-specific data. If we were to see a value
of bgpPeerConnectRetryInterval.10.0.0.1 = 120 we would be looking at
the retry interval of the peer router found at IP address 10.0.0.1.
The value for this instance is 120 seconds, instance-specific data.
6.2 Information Related to Policy Configuration
In order for effective policy management to take place, a range of
information about the network elements is needed to avoid making
poor policy decisions. An effective policy management system will
include the following information about each network element before
sending policies for execution:
The operational state of network elements that are to be configured.
In particular, care should be taken to determine if the sub
components to be configured are available for use. In some cases the
elements may not be available. The policy configuration software
should determine if this is a prerequisite to policy download or if
the condition is acceptable. In those cases where policy is
distributed when the sub component such as an interface or disk is
not available, the managed system should send a notification to the
designated management station when the policy is to become active if
the resource is still not available.
The capabilities of the devices in the network. A capability can be
almost any unit of work a network element can perform. These
include, routing protocols supported, Web Server and OS versions,
queuing mechanisms supported on each interface that can be used to
support different qualities of service, and many others. this
information can be obtained from the capabilities table of the
Policy MIB Module.
The capacity of the devices to perform the desired work. Capability
is an ability to perform the desired work while a capacity is a
measure of how much of that capability the system has. The policy
configuration application should wherever possible, evaluate the
capacity of the network element to perform the work identified by
the policy. In some systems it will not be possible to directly
obtain the capacity of the managed elements to perform the desired
work, even though it may be possible to monitor the amount of work
the element performs. In these cases, the management application may
MacFaden/Saperia January 2000 [Page 25]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
benefit from pre-configured information about the capacity of
different network elements so that evaluations of the resources
available can be made before distributing new policies.
Utilization refers to how much capacity for a particular capability
has been consumed. For devices that have been under policy
configuration control for any period of time, a certain percentage
of the available capacity of the managed elements will be used.
Policies should not be distributed to systems that do not have the
resources to carry out the policy for a reasonable period of time.
6.3 Policy, Mechanism/Implementation and Instance Specific Modules
A conformant system could implement the policy module without any
mechanism or implementation-specific modules though it is thought
that will not be a likely scenario. For complicated configuration
areas such as Differentiated Services, Web servers, routing
protocols, etc., mechanism and frequently implementation-specific
MIB Modules will be required.
If a vendor implements a standard set of instance-specific MIB
objects and an RFC has not yet been defined for a mechanism-specific
set of objects to control the policy based configuration of these
instance-specific objects, the vendor should create such a module
allowing for the fact that an RFC might be issued later for the
mechanism-specific module. To the extent a vendor creates instance-
specific extensions to standard instance-specific MIB Modules, they
should also create implementation-specific MIB Modules if they
intent the box to be configured with policy-based management.
Many vendors create proprietary functions and the instrumentation to
manage them. To enable these features to be integrated into an SNMP-
based policy management system, both instance and implementation-
specific MIB objects should be created.
6.4 Schedule and Time Issues
In large networks it may be necessary to coordinate the application
of policies across time zones. Wherever possible, the network
elements should support time information that includes local time
zone information. Some deployed systems do not store complex notions
of local time and thus may not be able to properly process policy
MacFaden/Saperia January 2000 [Page 26]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
directives that contain time zone relevant data. For this reason,
policy management applications should have the ability to ascertain
the time keeping abilities of the managed system and make
adjustments to the policy for those systems that are time-zone
challenged.
6.5 Conflict Detection, Resolution and Error Reporting
Sophisticated conflict detection and resolution is not realistically
achievable in the short-term. Using a hierarchical approach to this
problem can achieve significant benefits. Each 'layer' policy
management system should be able to check for some errors and report
them. The responsibilities for each layer are:
Instance-specific. Conflict detection has been performed in a
limited way for some time in software that realizes instance-
specific MIB objects. This detection is independent of policy
however. They types of 'conflicts' that are usually processed
related are to resource availability and validity of the set
operations. In a policy enabled system, there are not additional
requirements for this software assuming that good error detection
and reporting appropriate to this level had already been
implemented.
Mechanism and implementation-specific. For software that realizes
mechanism and/or implementation-specific objects, failures should be
reported such that the specific policy that has been impacted can be
related with the specific element that failed. Beyond this basic
reporting which is does not perform any policy conflict detection,
there are not requirements.
Mechanism and implementation-independent. The software that
implements the mechanism and implementation-independent function
will most often be a realization of the policy module. This software
does assume some limited role in conflict detection. Specifically
this software should verify that no two policies with the same
precedence are allowed on the system. The policy system should also
report events where one policy overrides another or when an element
under policy control has been modified outside the policy system as
would be the case of CLI modifications to elements under policy
control.
MacFaden/Saperia January 2000 [Page 27]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
6.6 Policy Precedence and Grouping
6.7 Changes to configuration outside of the policy system
A goal of SNMP-based policy management is to coexist with other
forms what have historically been instance based management. The
best example is command line interface. Here are some guidelines for
handling these changes.
A notification should be sent whenever an out of policy control
change is made to an element that is under the control of policy.
This notification should include the policy that was changed, the
instance of the element that was changed and the object and value
that it was changed to.
More on contexts later.
An element under the control of policy that has been changed remains
a member of the policy group until the attributes in the Role table
that caused it to match the policy in the first place are modified.
An element that has been modified by a an out of policy mechanism,
while remaining a member of the policy does not get overridden by a
policy until its value is made the same as the extant policy with
the highest precedence for this element, and by implication then
returned to policy control. A notification should be sent when this
action is taken.
6.7 Use of Contexts
TBD
6.8 Policy distribution applications
TBD
6.9 Notifications in a Policy System
TBD.
MacFaden/Saperia January 2000 [Page 28]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
7.0 Glossary
Transaction
A finite group of changes that taken as a whole can be applied
or rolled back in one operation. For example, a single SNMP SET PDU
represents a transaction for which the state before the set is
returned should any individual element in the variable-bindings list
fail to be applied thus returning the device to exactly the same
state before the SET was executed.
Device-Local Configuration
Device-local configuration data is specific to a particular network
device. This is the finest level of granularity for configuring
network devices.
Network-Wide Configuration
Network-wide configuration data is not specific to any particular
network device and from which multiple device-local configurations
can be derived. Network-wide configuration provides a level of
abstraction above device-local configurations.
Configuration Data Translator
A function that transforms Configuration Management Data (high-level
policies) or Network-wide configuration data (middle-level policies)
into device local configurations (low-level policies) based on the
generic capabilities of network devices. This function can be
performed either by devices themselves or by some intermediate
entity.
Denial of Service (DOS)
Any situation where access to resources by authorized consumers is
diminished by overt or inadvertent abuse of network layer mechanisms
8.0 Example MIB
ACME-HOUSECTL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY, Counter32, Gauge32,
OBJECT-TYPE, TimeTicks, Integer32, NOTIFICATION-TYPE
MacFaden/Saperia January 2000 [Page 29]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TruthValue, TEXTUAL-CONVENTION, TimeStamp
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
acmeHouseCtlMIB MODULE-IDENTITY
LAST-UPDATED "200007090000Z"
ORGANIZATION "Acme, Inc"
CONTACT-INFO
"Acme, Inc
1 Main Street
Anytown, Anywhere"
DESCRIPTION
"This mib module defines a sample mib module
that contains status, configuration and diagnostic
management objects for items in a single family home."
REVISION "200007090000Z"
DESCRIPTION
"Initial version of ACME-HOUSECTRL-MIB."
::= { XXX 1 }
--
-- Textual Conventions
--
AcmeCfgVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that starts at 0 and increases monotonically
until the Max value is reached at which point the value
returns to 0."
SYNTAX Gauge32
AcmeDeviceAdminStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The operational state of a device. Setting a device to
testing invokes diagnostic routines which may or may not
bring a device out of service."
SYNTAX INTEGER {
up(1),
down(2),
testing(3)
}
MacFaden/Saperia January 2000 [Page 30]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
AcmeDeviceOperStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The current general state of the device. A failed state
indicates the device is not responding to management
control"
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
failed(4)
}
--
-- Top level delegations
--
acmeHouseInventory OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Inventory of the controls in the home over which
operations can be made."
::= { acmeHouseCtlMIB 1 }
acmeHouseGlobals OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Objects of global scope over a given home."
::= { acmeHouseCtlMIB 2 }
acmeHouseConfig OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Configuration of devices managed by this MIB
or subsidiary MIBs."
::= { acmeHouseCtlMIB 3 }
acmeHouseCtlExceptions OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Exceptions of global scope to this mib defined here."
::= { acmeHouseCtlMIB 9 }
acmeHouseCtlConformance OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Conformance details kept here for this MIB."
MacFaden/Saperia January 2000 [Page 31]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
::= { acmeHouseCtlMIB 10 }
--
-- Inventory Group
--
acmeHouseInvenLastUpdated OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Timestamp when inventory report was last updated. A value of
zero indicates never."
::= { acmeHouseInventory 1 }
acmeHouseInvenNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of rows in acmeHouseInvenTable."
::= { acmeHouseInventory 2 }
acmeHouseInvenTable OBJECT-TYPE
SYNTAX SEQUENCE OF AcmeHouseInvenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table presents a list of devices found
in a given home.
Rows are added and deleted by the agent. "
::= { acmeHouseInventory 3 }
acmeHouseInvenEntry OBJECT-TYPE
SYNTAX AcmeHouseInvenEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a particular device managed
by this agent."
INDEX { acmeHouseInvenId }
::= { acmeHouseInvenTable 1 }
AcmeHouseInvenEntry ::= SEQUENCE {
acmeHouseInvenId SnmpAdminString,
acmeHouseInvenDevice OBJECT IDENTIFIER,
acmeHouseInvenKey Integer32,
acmeHouseInvenAdminStatus AcmeDeviceAdminStatus,
acmeHouseInvenOperStatus AcmeDeviceOperStatus,
acmeHouseInvenLastContact TimeStamp
MacFaden/Saperia January 2000 [Page 32]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
}
acmeHouseInvenId OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A persistent identifier that identifies
a device uniquely within a single domain."
::= { acmeHouseInvenEntry 1 }
acmeHouseInvenDevice OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The object identifier that uniquely identifies
the type of device. A registration mib maintains
the mappings to text."
::= { acmeHouseInvenEntry 2 }
acmeHouseInvenKey OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A unique value within a given set of device
with the same acmeHouseInvenDevice object identifier.
Can be used for a short-hand indexing
to other tables and notifications."
::= { acmeHouseInvenEntry 3 }
acmeHouseInvenAdminStatus OBJECT-TYPE
SYNTAX AcmeDeviceAdminStatus
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired administrative status of this device.
Setting the value to down(2) has the effect of
changing acmeHouseInvenOperStatus to down(2) as well."
::= { acmeHouseInvenEntry 4 }
acmeHouseInvenOperStatus OBJECT-TYPE
SYNTAX AcmeDeviceOperStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The curent operational state of the device."
MacFaden/Saperia January 2000 [Page 33]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
::= { acmeHouseInvenEntry 5 }
acmeHouseInvenLastContact OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the device last responded
to any management request or last poll."
::= { acmeHouseInvenEntry 6 }
--
-- Configuration Globals Group
--
acmeHouseGlobalSysActive OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"State of house control system. A value of true(1) represents
the system is actively monitoring state and will
accept valid configuration requests. A value of false(2)
indicates this the master system is not maintaining
state of systems found in
the inventory component."
::= { acmeHouseGlobals 1 }
acmeSysActiveLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"sysUpTime when acmeHouseGlobalSysActive last changed state."
::= { acmeHouseGlobals 2 }
acmeSysActiveConfigId OBJECT-TYPE
SYNTAX AcmeCfgVersion
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current value of configuration information. This value remains
persistent across reboots and increases when configuration
changes are made to any object in this MIB."
::= { acmeHouseGlobals 3 }
acmeSysDevicesActive OBJECT-TYPE
SYNTAX Gauge32
MacFaden/Saperia January 2000 [Page 34]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Number of active devices in the system according to last poll."
::= { acmeHouseGlobals 4 }
acmeSysDevicesLastFailed OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"sysUpTime when last device failed poll or admin request."
::= { acmeHouseGlobals 5 }
acmeSysDeviceErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Number of devices that this manager lost contact, timed out
with."
::= { acmeHouseGlobals 6 }
acmeSysDeviceLastErr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A description of the last error that occured in this mib due
to configuration errors or status error presentable to user
interface."
::= { acmeHouseGlobals 7 }
--
-- Notification Section
--
acmeHouseCtlGlobalErrs OBJECT IDENTIFIER ::= {
acmeHouseCtlExceptions 0}
acmeHouseCtlDeviceLost NOTIFICATION-TYPE
OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey,
acmeHouseInvenAdminStatus,
acmeHouseInvenOperStatus}
STATUS current
DESCRIPTION
"This notification is generated whenever the invocation
of a scheduled action fails. If there is a failure of
many devices such that sending single notifications
would be resource and time prohibitive, send the
MacFaden/Saperia January 2000 [Page 35]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
acmeHouseCtrlManyDevicesLost notification."
::= { acmeHouseCtlGlobalErrs 1 }
acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE
OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors }
STATUS current
DESCRIPTION
"This notification is generated whenever the invocation
of a scheduled action fails. If there is a failure of
many devices such that sending single notifications
would be resource and time prohibitive, send the
acmeHouseCtrlManyDevicesLost notification."
::= { acmeHouseCtlGlobalErrs 2 }
--
-- Compliance Section
--
acmeHouseCtlGroups OBJECT IDENTIFIER
::= { acmeHouseCtlConformance 1 }
acmeHouseCtlCompliances OBJECT IDENTIFIER
::= { acmeHouseCtlConformance 2 }
acmeHouseInventoryGroup OBJECT-GROUP
OBJECTS {
acmeHouseInvenLastUpdated,
acmeHouseInvenNumber,
acmeHouseInvenDevice,
acmeHouseInvenKey,
acmeHouseInvenAdminStatus,
acmeHouseInvenOperStatus,
acmeHouseInvenLastContact
}
STATUS current
DESCRIPTION
"A collection of objects providing
inventory and general status of all home objects controlled
by this MIB."
::= { acmeHouseCtlGroups 1 }
acmeHouseGlobalsGroup OBJECT-GROUP
OBJECTS {
acmeHouseGlobalSysActive,
acmeSysActiveLastChanged,
acmeSysActiveConfigId,
acmeSysDevicesActive,
acmeSysDevicesLastFailed,
acmeSysDeviceErrors,
MacFaden/Saperia January 2000 [Page 36]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
acmeSysDeviceLastErr
}
STATUS current
DESCRIPTION
"A collection of objects providing
overall feature configuration state status."
::= { acmeHouseCtlGroups 2 }
acmeHouseCtlNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
acmeHouseCtlDeviceLost,
acmeHouseCtlManyDevicesLost
}
STATUS current
DESCRIPTION
"The notifications used by this MIB to denote
exceptional conditions."
::= { acmeHouseCtlGroups 3 }
acmeHouseCtrlMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The set of groups that make up the mandatory
and optional groups
required for MIB implementation."
MODULE
MANDATORY-GROUPS { acmeHouseInventoryGroup,
acmeHouseGlobalsGroup }
::= { acmeHouseCtlCompliances 1 }
END
9.0 References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[2] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-based
Internets", STD 16, RFC 1155, May 1990.
MacFaden/Saperia January 2000 [Page 37]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[11] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, April
1999.
[12] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
MacFaden/Saperia January 2000 [Page 38]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
Management Protocol (SNMP)", RFC 2575, April 1999.
[16] McCloghrie, K. and M. Rose, Editors, "Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems,
Performance Systems International, March 1991.
[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software,
November 1997.
[18] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[19] Brown, C., and F. Baker, "Management Information Base for
Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.
[20] Baker, F, "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[21] Hawkinson, J, "Guidelines for creation, selection, and
registration of an Autonomous System (AS)", RFC 1930,
March 1996.
[22] Baker, F, "OSPF Version 2 Management Information Base", RFC
1850, November 1995.
10.0 Editors' Addresses
Michael R. MacFaden
Riverstone Networks, Inc
5200 Great America Parkway
Santa Clara, CA 95054
phone - +1 408 878 6500
email - mrm@riverstonenet.com
Jon Saperia
JDS Consulting
174 Chapman Street
Watertown, MA 02472
email - saperia@mediaone.net
MacFaden/Saperia January 2000 [Page 39]
INTERNET-DRAFT SNMP CONFIGURATION July 2000
11.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
MacFaden/Saperia January 2000 [Page 40]