Internet Draft SNMP CONFIGURATION May 3 2000
M. MacFaden
Riverstone Networks, Inc
J. Saperia
JDS Consulting, Inc
Configuring Networks and Devices with SNMP
draft-ietf-snmpconf-bcp-01.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.
1. Introduction
Data networks have grown greatly in size and complexity over
the past decade. Configuration (provisioning) of network
elements has grown correspondingly more complex. Complexity in
MacFaden/Saperia Expires September 10th 2000 [Page 1]
Internet Draft SNMP CONFIGURATION May 3 2000
the context of this document means specifically:
1) Scale - data networks consist of more devices than ever
2) Functionality - network devices increasingly perform more
functions
3) Convergence - more devices involved and different levels
of the stack are affected during configuration changes causing
lost connectivity for some period of time
The SNMP framework can and has been used to develop
configuration management systems. This document describes Best
Current Practices that SHOULD be used when designing and
effective SNMP-based management system that includes
configuration functions, or is an SNMP-based system that has
only configuration functions.
Configuration is a broad subject and recently a great deal of
attention has been placed on policy based configuration
management. This document includes recommendations for that
type of configuration. Policy based configuration management
is a set of configuration operations to potentially many
network elements with the goal of achieving some consistent
network behavior over some autonomous system.
Recommendations for the application of SNMP to what has
commonly be thought of as device-specific configuration
operations, such as assignment of an IP address to an
interface or set up of routing protocols on a router are also
included.
This document draws on first-hand experience provisioning 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. Some of this software
is in the public domain and much has been developed in the
private sector.
1.1. Document Organization
This document presents the goals of configuration management,
the needs of operators, and the needs of implementors.
Realistic expectations must be set for users and rules of
MacFaden/Saperia Expires September 10th 2000 [Page 2]
Internet Draft SNMP CONFIGURATION May 3 2000
thumb must provide implementors with proper use of the SNMP
framework for configuration of data networks.
This document is organized as follows: The background section
describes how configuration of TCP/IP networks is currently
practiced by experienced network operations staff and the
management interfaces used to perform these operations.
The requirements section enumerates the goals and fundamental
assumptions of configuration.
Section 2 describes terminology as used in this document.
Section 3 and 4 describe agent and management development
using the Internet standard SNMP framework. Section 5
describes relationship of Policy Management to SNMP framework.
Section 6 discusses agent and management system deployment
issues and Section 7 reviews security issues related to the
models described here.
1.2. Background
Data network devices are configured using many methods,
however two methods remain the most common: SNMP and Command
Line Interface (CLI). Layered on top of these methods are
operational methods for deploying changes to networks in a
cautious and incremental manner.
Experienced Network Operations staff make changes to network
configurations and firmware with careful planning and well
documented procedures such as:
A. Pass one: LAB tryout to verify reliability and
interoperability with prior versions.
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.
1. Apply change first via cli to memory and watch
device/network carefully over some time period
2. After some time, write changes to persistent storage
3. Expand changes to a few more like devices
4. Keep mixed versions to prevent total loss of network
5. Watch for new unkown defaults
6. Watch for unknown side effects of changes
MacFaden/Saperia Expires September 10th 2000 [Page 3]
Internet Draft SNMP CONFIGURATION May 3 2000
7. update configurations in revision control system
A diagnostic mode is often present to deal with implementation
issues of the above. Often this is done via syslog or output
to some serial or telnet interface.
1.3. Requirements
This section defines realistic requirements for what we want
to accomplish with SNMP Configuration.
What are the goals and assumptions needed achieve state of the
art configuration on network elements.
Show that SNMP can be used to achieve these goals and that the
assumptions are practical.
The following presents a set fundamental assumptions:
1.3.1. Fundamental Tenets of configuration
1) A loss of connectivity can occur at any point in time
between the configurator and the device being configured.
There is no conceivable protocol or sufficient voltage that
can negate this assumption.
2) Device state and configuration SHOULD be understood by a
"mere mortal" with the following assumptions:
1) trained in the fundamentals of data communication
(bridging, routing)
2) understands the vendor implementation
3) Operators MUST have the ability to validate proper
operation of a device before and after configuration changes.
4) The expected behavioral change exhibited by an individual
device under configuration is not as readily apparent as it
once was. Devices are more complex as they acquire more
capabilities. Interactions between capabilities are not always
well defined during configuration sequences up and down a
protocol stack. This leads to the next tenent:
MacFaden/Saperia Expires September 10th 2000 [Page 4]
Internet Draft SNMP CONFIGURATION May 3 2000
5) Configuration affects network stability and network
stability affects configuration. For example, noncritical
changes to a facility such as BGP or spanning tree SHOULD NOT
cause convergence to be lost.
6) Achieving convergence in an autonomous system is not an
absolute given when configuration changes are made. While
simulations can be made, keeping track of all state data is
growing harder as basic networking features become more
dynamic. Witness protocols like GVRP/GARP as well as time of
day configuration capabilities found in RFC 2591.
Here then are requirements for a modern configuration
protocol:
1) Any modern configuration protocol or process MUST be
mindful of connectivity loss between manager and manged device
and take appropriate measures to leave the network device or
devices in a consistent/recognizable state.
2) Support for testing configurations incrementally MUST be
included.
3) Diagnostic routines SHOULD be provided to verify proper
operation of complex protocols. Debugging is an integral part
of the configuration process.
4) Impact on convergence SHOULD be specified. For example, any
configuration change that causes loss of convergence should be
noted in a description clause.
2. Terminology
Transaction
A finite group of changes that taken as a whole can be applied
or rolled back in one operation.
Device-Local Configuration
Configuration data that is specific to a particular network
device. This is the finest level of granularity for
MacFaden/Saperia Expires September 10th 2000 [Page 5]
Internet Draft SNMP CONFIGURATION May 3 2000
configuring network devices. Per draft-ops-mumble-
conf_management
Network-Wide Configuration
Configuration data that 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. Per draft-ops-mumble-conf_management
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. Per
draft-ops-mumble-conf_management
Denial of Service Attack (DOS)
Any situation where access to resources by authorized
consumers is diminished by overt or inadvertant abuse of
network layer mechanisms.
3. Agent Software Development
3.1. MIB Module Implementation and Design
This section describes how to design and implement a read-
write MIB properly. It reviews some key SNMP requirements such
as rollback of sets in a given PDU. Most Agent software
development focuses n Device-Local configuration aspects.
There are however network wide aspects to agent development
such as setting the Autonomous System in router.
To begin with, let's consider a set pdu with one varbind using
MacFaden/Saperia Expires September 10th 2000 [Page 6]
Internet Draft SNMP CONFIGURATION May 3 2000
the managed object docsIfDownChannelFrequency from DOCS-IF-
MIB, RFC 2670, and enumerate potential outcomes to see which
are conformant with SNMP Framework:
Here is the definition of this object:
docsIfDownChannelFrequency OBJECT-TYPE
SYNTAX Integer32 (0..1000000000)
UNITS "hertz"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The center of the downstream frequency associated with
this channel. This object will return the current tuner
frequency. If a CMTS provides IF output, this object
will return 0, unless this CMTS is in control of the
final downstream RF frequency. See the associated
compliance object for a description of valid frequencies
that may be written to this object."
REFERENCE
"DOCSIS Radio Frequency Interface Specification,
Section 4.3.3."
::= { docsIfDownstreamChannelEntry 2 }
Scenario 0: most common usage model value is 200000 at time 0.
set to value 4400000 at time 1, read at time 2 returns 4400000
Scenario 1: read-write object is overloaded to return state +
set state) value is 20000 at time 0, set to value 4400000 at
time 1. read at time 2 returns 20000, and a subsequent read at
time 3 returns 4400000
Scenario 2: value is 200000 at time 0, set to value 4400000 at
time 1 and the snmp agent returns and error received by
manager application
Scenario 3: value is 200000 at time 0, set to value 4400000 at
time 1 and the snmp agent returns and error which is not
received by manager/network failure due to either set change,
device crashes, or manager crashes.
Another typical scenario is the granularity of counter
updates, 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 Expires September 10th 2000 [Page 7]
Internet Draft SNMP CONFIGURATION May 3 2000
3.1.1. Reporting Errors for SET operations
MIB Design for configuration SHOULD use objects to track
application level state. Management applications that are
unable to decode why "badValue" errors are received should be
able to obtain error strings or enumerated values to help log
problems from specific MIB objects.
Failure to provide detailed diagnostic information leads to
management applications that end up reporting insuficient
error information.
3.1.2. Duplication of objects considered harmful
One SHOULD NOT duplicate configuration objects across mibs.
While it may appear as a convienience, such as providing
different indexing schemes, the side effects may not be easily
discernable.
For example, RFC 1493 BRIDGE-MIB duplicates functionality
found in RFC 1213 interfaces group and its successor
RFC2233/IF-MIB as follows:
The BRIDGE-MIB defines the managed object:
dot1dStpPortEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The enabled/disabled status of the port."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 4 }
which is indexed by dot1dBasePortNumber, while the IF-MIB
defines this managed object by ifIndex.
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
MacFaden/Saperia Expires September 10th 2000 [Page 8]
Internet Draft SNMP CONFIGURATION May 3 2000
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3)
state indicates that no operational packets can be
passed. When a managed system initializes, all
interfaces start with ifAdminStatus in the down(2)
state. As a result of either explicit management
action or per configuration information retained by
the managed system, ifAdminStatus is then changed to
either the up(1) or testing(3) states (or remains in
the down(2) state)."
::= { ifEntry 7 }
If a port is set to testing in the IF-MIB, what should be reported
in the BRIDGE-MIB? These kinds of issues should be avoided if at
all possible and especially when mibs are as interrelated as the
above.
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.
3.1.3. Use Textual Conventions for enumerations
Standard's track MIBS SHOULD define textual conventions such
that later standard MIBs would be able to use them.
Textual convetions that have even the slighest chance of being
reused in other MIBS SHOULD also be defined in a separate MIB
to facilitate sharing of such objects.
Often in practice, dragging in an entire MIB definition in
order to reuse one Textual convention may lead to
computational excessiveness.
For example, take the ifAdminStatus object:
MacFaden/Saperia Expires September 10th 2000 [Page 9]
Internet Draft SNMP CONFIGURATION May 3 2000
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
Had this used a Textual convention, other mibs could import
the same semantic. Instead there there are now many more
"admin" style objects in other mibs that use the same
enumerations such as RFC 2668/MAU-MIB:
ifMauAutoNegAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
Often a situation may arise where a Textual convention defines
an enumeration of values. Should an implementation chose not
to implement all the enumarations, then it SHOULD document
this in an agent capabilities macro for the particular
revision.
In some cases, the use of capabilities bits can alievate this
as defined in RFC 2674, dot1dDeviceCapabilities can define
some preset level of capability.
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.
3.1.4. Rules for implementing RowStatus
Probably one of the most important areas of configuration with
SNMP is the ability to add and delete conceptual rows from
tables using the RowStatus textual convention.
Proper implementation requires the following:
First consider the default state of each object in the table
MacFaden/Saperia Expires September 10th 2000 [Page 10]
Internet Draft SNMP CONFIGURATION May 3 2000
when a row is created via one simple createAndWait(5).
operation. If defval's are not appropriate, then return
noSuchName for any object in that table not yet set by
managment application. One SHOULD NOT return some
implementation byproduct.
Second, consider the state of a row following a simple PDU
containing a createAndWait(5). Either notInService(2) or
notReady(3) are the two states the row can exist in. In the
latter case, one SHOULD define in the DESCRIPTION clause the
mandatory objects required to change the row state from
notReady(3) to notInService(2).
A conforming table SHOULD set rowStatus to notReady if any
mandatory object in the row has not yet been set be set by a
manager or if there is potentially some other implementation
constrictions such as being out of capacity to advance to
active(1) state.
Not doing this may lead a manager to assume falsely that a
transition to active(1) state will succeed without futher
action.
Not overloading the semantics of notReady vs notInService can
be done if mib defines error state objects an application can
query to determine the state of configuration.
Otherwise control rows in SNMP table may all activated but the
intended effect is not achieved and there is no object an
agent can provide to help diagnose the problem simply.
This is typical with existing RMON2 implementatons where a
typical example is configuring a host top N control row.
Both the agent and the manager application must be needlessly
*some would argue extremely* flexible in handling
configuration of hostTopNControlTable.
Control rows can be activated in the hostTopNControlTable
regardless of whether the hostTopNHostIndex actually exists in
the hostIndex of the hostTable. As such, the ability for an
agent to communicate any diagnostic information is limited.
Lastly, description clauses for any object in a table
MacFaden/Saperia Expires September 10th 2000 [Page 11]
Internet Draft SNMP CONFIGURATION May 3 2000
containing a RowStatus object SHOULD define the semantics of
what changes are valid when a row is in active(1) state.
As an example, RFC 1757 RMON-MIB used the following
description:
This object may not be modified if the associated
alarmStatus object is equal to valid(1)
is extremely useful and all new tables SHOULD follow this best
current practice.
3.1.5. Ownership issues
In many tables, ownership of a control row has been considered
in context of multiple managers as well as for diagnostic
information. As found in RMON-MIB
-- OwnerString ::= DisplayString
-- This data type is used to model an administratively
-- assigned name of the owner of a resource. This
-- information is taken from the NVT ASCII character
-- set. It is suggested that this name contain one or
-- more of the following: IP address, management station
-- name, network manager's name, location, or phone
-- number.
-- In some cases the agent itself will be the owner of
-- an entry. In these cases, this string shall be set
-- to a string starting with 'monitor'.
One MAY decide to make the agent responsible for tracking what
it knows of a manager setting up a row. Often it is useful to the operator
to know who is acessing the device and when as well as The IP Address is known
in SNMPv1 and additional user info is known in SNMPv3.
OwnerStrings are discussed further in the Multiple Manager section.
3.1.6. rowStatus and activation of configuration
Often configuration changes are activated in a device as soon
as a rowStatus is set to active(1). This is not always the
best way and often the implementation complexity may be great
if there are a set of interrelated tables. An alternate design
MacFaden/Saperia Expires September 10th 2000 [Page 12]
Internet Draft SNMP CONFIGURATION May 3 2000
to specify objects to activate all changes once all
configuration changes are made. In this way master on/off
changes can be effected in a two stage method. A two stage
configuration method often works well when changes affect
convergence.
Many rows can be setup and when all rows are activated, some
scalar object is touched to load the new changes.
3.1.7. Include a master on/off switch
As mentioned above, a master on/off switch for a given
subsystem SHOULD be provided. Often, these switches are useful
for diagnostics such as to help locate unstable subsystems as
well as for a common configuration sequence where a feature is
taken offline, reconfigured then put back online.
ospfAdminStat OBJECT-TYPE
SYNTAX Status
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The administrative status of OSPF in the
router. The value 'enabled' denotes that the
OSPF Process is active on at least one inter-
face; 'disabled' disables it on all inter-
faces."
::= { ospfGeneralGroup 2 }
When these master switches are not provided such as in the
BRIDGE-MIB which does not provide a to enable/disable
Spanning tree on a device nor a way to turn off spanning tree on
a per port basis requires managers to learn indirectly
the state of the subsystem.
3.1.8. Summary Status objects help configuration
Creating summary status objects "dummy lights" to provide a
quick means to determine overall status of a subystem.
Checksums could also be computed over a configuration so that
an application can reasonably identify an entier configuration
instead of having to poll many TableLastChange objects or have
MacFaden/Saperia Expires September 10th 2000 [Page 13]
Internet Draft SNMP CONFIGURATION May 3 2000
to use TimeFilter style indexing to achive highly efficient
polling.
ifOperStatus as it existed in RFC 1213, provids a template:
up/down/testing and "fault" would provide simple means to know
if changes have keep the overall subsystem up.
3.1.9. Indexing Issues
This section describes uses for Associative indexing, multiple
tables to support different indexing schemes, and other such
issues as it affects configuration.
3.1.10. Notifications
Proper use of notifications based on application development
needs. It is hard for agent developer to know at first when
agent should use notifications is being built and even harder
if designer is not familiar with the feature being
instrumented.
Even so, there is one key rule of thumb:
1) The more frequent the event, 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
frDLCIStatusChange defined in RFC 2115. In this case when
interfaces are taken down administratively, no
frDLCIStatusChange will be sent.
Rate Limiting trap emission will be vital in the future world
where hundreds of ports that do layer 1/2/3/4/n bridging and
routing and load balancing exist in a given device. RFC 2115
includes the object frTrapMaxRate.
3.1.11. Extending Standard notifications permissible
Vendor extensions to existing standard notifications are not
explicitly disallowed or allowed in SMIv2. For example, linkUp
MacFaden/Saperia Expires September 10th 2000 [Page 14]
Internet Draft SNMP CONFIGURATION May 3 2000
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 }
A implementor MAY add additional varbind objects to standard
notifications. However, an implementation SHOULD make any extensions
be not enabled by default and when enabled. An implemetation
SHOULD append to the varbind list any extensions.
3.1.12. Changed Configuration Alerts
Any change to a managed device or application's configuration
SHOULD be reported to an accounting authority. Notifications
provide such an ability and MAY be also logged on the device.
Any notification should include details on what management
interface, user, sysuptime, and what was changed.
3.1.13. RFC Module Compliance
There are a number of RFC MIB Modules today and new IETF
standard MIB modules written MUST contain compliance macros
per RFC 2579.
A vendor MAY provide additions to the existing MIB Objects,
they MAY also if necessary duplicate standard objects in their
vendor name space.
They MUST not use this duplication as an alternative to
standard objects found in standards track RFCs.
A vendor SHOULD write compliance macros for enterprise
specific MIB modules as this helps document changes over time.
MacFaden/Saperia Expires September 10th 2000 [Page 15]
Internet Draft SNMP CONFIGURATION May 3 2000
A vendor SHOULD also implement agent capability MIB modules to
define any variations in implementation. If an object in a mib
is made optionally read write and the implementation does not
implement the object to its fullest max access clause, the
variations clause SHOULD still be made explicit.
For example, RFC 2674 Q-BRIDGE-MIB defines
OBJECT dot1qPortAcceptableFrameTypes
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required as this is an optional
capability in IEEE 802.1Q."
An agent that implements this object as read-only SHOULD
include the following:
SUPPORTS Q-BRIDGE-MIB
INCLUDES { -- all Mandatory groups
qBridgeBaseGroup,
qBridgeVlanGroup,
qBridgeVlanStaticGroup,
qBridgePortGroup,
qBridgeFdbUnicastGroup,
qBridgeFdbMulticastGroup,
qBridgeServiceRequirementsGroup
}
-- qBridgePortGroup:
VARIATION dot1qPortAcceptableFrameTypes
ACCESS read-only
DEFVAL { disabled }
DESCRIPTION "Firmware Version 3.1 does not support GVRP/GARP."
3.2. 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 managemement software
SHOULD follow the current STATUS of MIB objects.
MacFaden/Saperia Expires September 10th 2000 [Page 16]
Internet Draft SNMP CONFIGURATION May 3 2000
3.3. Implementing MIBs - Coverage
The SNMP based instrumentation SHOULD provide complete
coverage of the managed element to facility integrated
management.
Using module compliance macros to guide implementation, all
mandatory conformance groups MUST be implemented.
3.4. Lifecycle considerations
This section presents one proposed lifecycle of a MIB based on
best current practices.
3.4.1. MIB Module
TBD
3.4.2. Agent
Agents, especially SNMPv1 agents require community strings to
be defined. A managed device SHOULD support read only as as
well as read-write community strings. Community strings should
specify the min length of at least 8 characters and be less
than 255 characters.
Agents should not define default community strings except
where to bootstrap devices that do not have secondary
management interfaces.
Practices include setting the read-write string to public or
to one of the mac addresses on ethernet bridges often lead to
security problems.
3.4.3. Default state of RFC 1215 Authentication traps
In the "Notifications" section earlier, the issue of
throttling traps was raised. For SNMPv1 agents, Any
MacFaden/Saperia Expires September 10th 2000 [Page 17]
Internet Draft SNMP CONFIGURATION May 3 2000
unsolicited packet to a device that causes another packet to
be created and sent in response in a one for one sequence can
be considered a denial of service attack. authTrap is one such
object that should be carefully limited so as to create a
denial of service attack or at least a diversion attack.
3.5. Vendor Extensions
Describe here how to relate vendor MIBs to ietf MIBs. Fate
sharing of MIB tables such as a MIB to create some layer that
then shows up in ifTable...
3.6. Supporting More than one Management Interface
Details how to relate data in one management interface to
another and to make the data consistent.
Only one data path to base information SHOULD exist in a
device. There may exist multiple names for a given data
object though. ifIndex defines some logical entity used by
SNMP manager applications, yet ifName provides mapping to CLI.
3.6.1. Configuration State
This will describe how to track current configuration state.
At what level are changes reported as errors, per table or per
object. Is there a need for specific objects to support
changes other than RowStatus?
To being with, it is important to track changes to a device
and to sync the changes with some specific configuration
respository.
Tracking changes to configuration has been done well for
command line interface via three reporting mechanisms:
syslog, tacacs+, and radius.
Tracking changes via SNMP has been done via enterprise traps
and notifications. The notification may contain either direct
or indirect references to what has changed or no varbinds.
However, it should indicate when and who made a change.
MacFaden/Saperia Expires September 10th 2000 [Page 18]
Internet Draft SNMP CONFIGURATION May 3 2000
3.6.2. Rollback
This section describes how SNMP can be used to maintain a
consistent state in the event of errors. Some discussion of
how this can work with large changes across tables.
3.6.3. Incremental Changes (sequencing issues)
Varbinds can come in any order in a pdu.
Per the spec, all sets must appear to occur at the same time.
The flexibility of a set pdu is very great, yet this feature
is infrequently used by management applications. Multiple
tables can be configured in one set with varbinds intermixed.
This puts a large implementation effort on the agent to sort
out the proper order of varbinds in order to make a given set
pdu succeed.
While it may be the cast that being liberal in what you accept
and conservative in what you send is the general case, it
definitely case computantional consequences when it comes to
handling set requests. MIB designers SHOULD be allowed to
specify the order by which objects are created.
3.6.4. Supporting Large Changes
Describe here how to implement support where changes are made
with massive configuration files such as thousands of lines of
access control lists.
3.7. When should changes made become effective
When should changes be realized in the device? Simple devices
like bridges performed simple set operations without
consideration for storage type, etc.
In addition, the need for near real time changes must be
understood.
MacFaden/Saperia Expires September 10th 2000 [Page 19]
Internet Draft SNMP CONFIGURATION May 3 2000
While most MIB objects can be polled or set in as little as
one second intervals, most agents may require more time for
more complex operations. Agent implementations SHOULD provide
some indication of time interval needed for set completion or
retrieval of managed objects.
3.8. Devices that use SNMP as Primary Interface
Describe this model of operation and interactions that should
be followed to stop race conditions for changes from two
interfaces.
3.9. Devices that use SNMP as Secondary Interface
Describe this model of operation and interactions that should
be followed to stop race conditions for changes from two
interfaces.
4. 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.
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
MacFaden/Saperia Expires September 10th 2000 [Page 20]
Internet Draft SNMP CONFIGURATION May 3 2000
4.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.
4.1.1. 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 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
MacFaden/Saperia Expires September 10th 2000 [Page 21]
Internet Draft SNMP CONFIGURATION May 3 2000
other factors.
4.1.2. Configuration Transactions
There are several types of configuration transactions that can
be supported by SNMP-based configuration applications. They
include transactions on a 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.
4.1.3. 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 attempted 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.
MacFaden/Saperia Expires September 10th 2000 [Page 22]
Internet Draft SNMP CONFIGURATION May 3 2000
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 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.
4.2. 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 a security issues.
4.3. Network Topology
Topology plays a critical row when what is being configured
are devices that implement network topology such as an
internet backbone router.
4.4. Topology/connectivity factors
4.4.1. In band
4.4.2. Out of band
4.4.3. Rules of thumb
MacFaden/Saperia Expires September 10th 2000 [Page 23]
Internet Draft SNMP CONFIGURATION May 3 2000
4.5. Device memory/Capability factors
This section describes how to design configuration models
when device memory and capability are constrained and when
these factors are not constrained.
4.6. Persistence expectations
Explicit persistence of set requests has always 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 an
implementor can make visible the level of persistance 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.
MacFaden/Saperia Expires September 10th 2000 [Page 24]
Internet Draft SNMP CONFIGURATION May 3 2000
4.7. 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.
4.8. Handling Multiple Managers
Devices are often modified by multiple management entities.
These managment 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 mangagement
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 locally such as a default or locally specified
configuration made through an alternate managment 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
implementer 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 encompasing lock can be used such as RFC 1907
snmpSetSerialNo object.
An application SHOULD use this object if there is no specific
TestAndIncr object.
MacFaden/Saperia Expires September 10th 2000 [Page 25]
Internet Draft SNMP CONFIGURATION May 3 2000
and RMON2-MIB, RFC 2021, Section 3.1 further that refined
them.
Practice has shown that the use of the string "monitor" to
identify configuration set by an agent/local management has
been useful. The flexibility of the OwnerString convention has
been left to general application interpretation and as such
has seen either good or bad implementation. As a whole, owner
strings have shown the SHOULD be used to identify the owner of
the configuration.
In addtion, if needed, the use of objects to track when
control rows are installed/activated are also recommneded. An
example is the ipCidrRouteAge which tracks routing prefixes
installed into a IP Forwarding table, RFC 2096.
TimeStamps can who made a change to the system are useful
example in addition to tracking which manager made the change.
For example, in the DOCS-IF-MIB:
docsIfCmtsServiceCreateTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this entry was created."
::= { docsIfCmtsServiceEntry 5 }
The syntax of such objects SHOULD be consistent.
One final thought of best current practice is to use
authorization/accounting protcools such as RADIUS or TACACS+
to track changes to devices. Often these protocls can help
identify conflicting changes that cause as well as what
the changes were made from. From within the SNMPv3 framework
much of what has traditionally been done with these
protocols can now also be done through the use of informs
backed by some level of persistence.
4.9. Diagnostics and Configuation
This section describes in detail the kinds of diagnostics
needed to help support proper provisioning models.
MacFaden/Saperia Expires September 10th 2000 [Page 26]
Internet Draft SNMP CONFIGURATION May 3 2000
5. Policy Based Management
Provides an overview of configuration "in the large" and how
to scale configuration to include many devices in a safe and
sane manner.
5.1. Policy Modules
TBD..
5.2. Transaction Latency
5.3. Requirements
TBD...
5.4. Capability Module
TBD...
5.5. Integration with 'device specific' module
TBD...
6. Deployment
6.1. Agent Deployment and Configuration Issues
6.2. Management System Deployment Considerations
MacFaden/Saperia Expires September 10th 2000 [Page 27]
Internet Draft SNMP CONFIGURATION May 3 2000
7. Security Considerations
TBD... More specific Text about security goes here. Could add
bits about snooping wire and sending.
SNMPv1 by itself is not a secure environment. Even if the
network itself is secure (for example by using IPSec), even
then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB.
It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically,
the use of the User-based Security Model RFC 2574 [12] and the
View-based Access Control Model RFC 2575 [15] is recommended.
It is then a customer/user responsibility to ensure that the
SNMP entity giving access to an instance of this MIB, is
properly configured to give access to the objects only to
those principals (users) that have legitimate rights to indeed
GET or SET (change/create/delete) them.
MacFaden/Saperia Expires September 10th 2000 [Page 28]
Internet Draft SNMP CONFIGURATION May 3 2000
8. References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[2] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-based
Internets", STD 16, RFC 1155, May 1990.
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"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.
MacFaden/Saperia Expires September 10th 2000 [Page 29]
Internet Draft SNMP CONFIGURATION May 3 2000
[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
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.
9. Intellectual Property
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result
MacFaden/Saperia Expires September 10th 2000 [Page 30]
Internet Draft SNMP CONFIGURATION May 3 2000
of an attempt made to obtain a general license or permission
for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard. Please address the
information to the IETF Executive Director.
10. 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
11. 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
MacFaden/Saperia Expires September 10th 2000 [Page 31]
Internet Draft SNMP CONFIGURATION May 3 2000
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 Expires September 10th 2000 [Page 32]
Internet Draft SNMP CONFIGURATION May 3 2000
Table of Contents
1 Introduction .......................................... 1
1.1 Document Organization ............................... 2
1.2 Background .......................................... 3
1.3 Requirements ........................................ 4
1.3.1 Fundamental Tenets of configuration ............... 4
2 Terminology ........................................... 5
3 Agent Software Development ............................ 6
3.1 MIB Module Implementation and Design ................ 6
3.1.1 Reporting Errors for SET operations ............... 8
3.1.2 Duplication of objects considered harmful ......... 8
3.1.3 Use Textual Conventions for enumerations .......... 9
3.1.4 Rules for implementing RowStatus .................. 10
3.1.5 Ownership issues .................................. 12
3.1.6 rowStatus and activation of configuration ......... 12
3.1.7 Include a master on/off switch .................... 13
3.1.8 Summary Status objects help configuration ......... 13
3.1.9 Indexing Issues ................................... 14
3.1.10 Notifications .................................... 14
3.1.11 Extending Standard notifications permissible ..... 14
3.1.12 Changed Configuration Alerts ..................... 15
3.1.13 RFC Module Compliance ............................ 15
3.2 Currency with RFC MIB Module Standards .............. 16
3.3 Implementing MIBs - Coverage ........................ 17
3.4 Lifecycle considerations ............................ 17
3.4.1 MIB Module ........................................ 17
3.4.2 Agent ............................................. 17
3.4.3 Default state of RFC 1215 Authentication traps
.................................................... 17
3.5 Vendor Extensions ................................... 18
3.6 Supporting More than one Management Interface ....... 18
3.6.1 Configuration State ............................... 18
3.6.2 Rollback .......................................... 19
3.6.3 Incremental Changes (sequencing issues) ........... 19
3.6.4 Supporting Large Changes .......................... 19
3.7 When should changes made become effective ........... 19
3.8 Devices that use SNMP as Primary Interface .......... 20
3.9 Devices that use SNMP as Secondary Interface ........ 20
4 Management Software Development ....................... 20
4.1 Protocol Operations ................................. 21
4.1.1 SET Operations .................................... 21
4.1.2 Configuration Transactions ........................ 22
4.1.3 Notifications ..................................... 22
MacFaden/Saperia Expires September 10th 2000 [Page 33]
Internet Draft SNMP CONFIGURATION May 3 2000
4.2 Scale of the Management Software .................... 23
4.3 Network Topology .................................... 23
4.4 Topology/connectivity factors ....................... 23
4.4.1 In band ........................................... 23
4.4.2 Out of band ....................................... 23
4.4.3 Rules of thumb .................................... 23
4.5 Device memory/Capability factors .................... 24
4.6 Persistence expectations ............................ 24
4.7 Rate and Volume of Changes to Device ................ 25
4.8 Handling Multiple Managers .......................... 25
4.9 Diagnostics and Configuation ........................ 26
5 Policy Based Management ............................... 27
5.1 Policy Modules ...................................... 27
5.2 Transaction Latency ................................. 27
5.3 Requirements ........................................ 27
5.4 Capability Module ................................... 27
5.5 Integration with 'device specific' module ........... 27
6 Deployment ............................................ 27
6.1 Agent Deployment and Configuration Issues ........... 27
6.2 Management System Deployment Considerations ......... 27
7 Security Considerations ............................... 28
8 References ............................................ 29
9 Intellectual Property ................................. 30
10 Editors' Addresses ................................... 31
11 Full Copyright Statement ............................. 31
MacFaden/Saperia Expires September 10th 2000 [Page 34]
