Transcript MIB - SNMP Research

SNMP Update
Jeff Case
Founder and CTO
SNMP Research, Inc.
+1 865 573 1434
[email protected]
Topics:
 Introduction
 Differences
between SNMPv1, SNMPv2c, and
SNMPv3


Advantages of SNMPv3 over SNMPv1 and SNMPv2c
Disadvantages of SNMPv3
2
Topics (Continued):
 Recent

SNMP-based Configuration Management





and Ongoing IETF Work Items
Policy MIB Module
EOS Working Group: Evolution of SNMP
SMIng Working Group: Evolution of the Structure of
Management Information
Distributed Management Working Group (DISMAN)
MIB Definitions
3
Topics (Continued):
A



brief look at SNMP/MIB vis-à-vis
DMI/MIFs
CIM/MOFs
COPS/PIBs
 Conclusions
4
The SNMP-based
Internet Standard Management Framework
has Evolved:
SNMPv1, SNMPv2c, and SNMPv3
SNMP: The Right Architecture, in
part, for the Wrong Reason
 Multiple
competing efforts circa 1987 - early 1988
with duplication of effort slowing progress and
discouraging product development and
deployment
 The time of GOSIP
 Blue-ribbon panel develops direction statement
 SNMP was to be the “short-term interim” standard
 Protocol independent SMI-based MIB
 MIB independent SMI-based protocol
 SMI “glue”
6
Protocol Versions:
Summary Picture
Simple-Based Management
SNMPv1
SNMPv3
Party-based
SNMPv2
SNMPv2*
Common
SNMPv2
SNMPv2c
SNMPv2u
Management Information Definitions (MIB Documents)
RFC
1155
Format
RFC
1212/1215
Format
RFC
1442-4
Format
7
RFC
1902-4
Format
RFC
2578-80
Format
SNMP: The Right Architecture, in
part, for the Wrong Reason
 This
architecture which was designed to ease the
shortening of the life of SNMP has actually
allowed it to age gracefully and to evolve, thereby
extending its useful life
 People have been predicting the demise of SNMP
for a decade and it just keeps going and growing
while “replacements” appear and then disappear
8
The SNMP-based Internet-Standard
Management Framework
 Based
on the Simple Network Management
Protocol, but more than merely a protocol for data
movement, but a complete framework:
1. A data definition language

The Internet-standard Structure of Management
Information (SMI)
2. Definitions of management information

Instrumentation described in the [Internet-standard]
Management Information Base (MIB)
3. Protocol definition

The Simple Network Management Protocol
9
Structure of Management
Information (SMI) Evolution
Modular (3 part) specification architecture:
1. A data definition language

The Internet-standard Structure of Management
Information (SMI)
1st Generation (1988-1991): RFC 1155
 2nd Generation (1991-1993): RFC 1212 and 1215
 3rd Generation (1993-present): SMIv2
RFCs 2578-2580
 4th Generation: SMIng: a new work in progress

10
Advantages of SMIv2 over SMIv1
 After
about 1995, all information modules (MIB
definitions) should be written in SMIv2 format
 Benefits:

New Data Types
Counter64
 BITS



Table indexing more clear and concise
Improved set operations for row create/delete
(important for configuration/control)
11
Advantages of SMIv2 over SMIv1
 Pragmatic
Reality
Most management stations and applications will load
SMIv2 format whereas a few still require SMIv1 format
so you need both
 Information in SMIv2 formatted documents is a
superset of the information in an SMIv1 formatted
document
 If you have SMIv2 format, SMIv1 format can be
generated automatically by throwing away information
and reformatting via an automatic tool
 If you have SMIv1 format, the tool is vi, emacs, etc plus
human input

12
MIB Grammar Versions and
Protocol Versions -- Decoupled
 In
general, there is no need for the version of the
protocol to match the version number of the
format of a MIB document
 With few exceptions, can use any MIB object,
regardless of the version of the grammar of the
MIB document, with any version of the protocol
 The only noteworthy exception is MIB documents
containing MIB objects with a datatype of
Counter64 (this datatype is not supported by
version 1 of the protocol)
13
Protocol Versions:
Summary Picture
Simple-Based Management
SNMPv1
SNMPv3
Party-based
SNMPv2
SNMPv2*
Common
SNMPv2
SNMPv2c
SNMPv2u
Management Information Definitions (MIB Documents)
RFC
1155
Format
RFC
1212/1215
Format
RFC
1442-4
Format
14
RFC
1902-4
Format
RFC
2578-80
Format
Management Information Base
(MIB) Evolution
Modular (3 part) specification architecture:
2. Definitions of management information





Standard or non-standard
Protocol independent
Instrumentation described in the [Internet-standard]
Management Information Base (MIB)
Has undergone constant revision (mostly expansion)
since first defined in 1988
A wide variety of technologies covered by standard
MIB definitions and others through vendor-specific
extensions
15
Management Information Base
(MIB) Evolution
 In
the beginning (1988), there was MIB-I: basic to
all managed systems
 Next (early ‘90s) came MIB-2: a superset of MIB-I
 When MIB-2 reached Full Standard status (Mar
‘91), MIB-I became historic
 Change in strategy: a distributed approach of
multiple committees with differentiated staffing
producing many mini-MIB documents
 Lost benefit of input from almost all current
operators and administrators
16
Management Information Base
(MIB) Evolution (Continued)
 Many
of MIB documents are on the standards
track at various levels of standardization maturity
and market acceptance/demand


Most are adequate for monitoring
Many must be supplemented for configuration and
control
More standardization work needed
 Enterprise-specific extensions in the absence of standards

17
Management Information Base
(MIB) Evolution (Continued)
 Expanded
scope of MIB reflective of expanded
application of the Internet-Standard Management
Framework, the basis for seamless Internet
management:





traditional network management
system management
application management
service management
proxy management of legacy devices
18
MIB Documents:
Network Management
ADSL
ATM
AppleTalk
BGPv4
Bridge
Character Stream
CLNS
DECnet Phase IV
DOCSIS Cable Modem
RFC 2662
Multiple
RFC 1742
RFC 1657
RFC 1493
RFC 1658
RFC 1238
RFC 1559
Multiple
19
MIB Documents:
Network Management (Continued)
DS0, DS1/E1, DS3/E3 Interfaces
Entity
FDDI
Frame Relay
IEEE 802.3
IEEE 802.5
IEEE 802.12
Integrated Services
ISDN
20
Multiple
RFC 2737
Multiple
Multiple
Multiple
Multiple
Multiple
Multiple
Multiple
MIB Documents:
Network Management (Continued)
MIB-2
Modem
PPP
RMON
Routing
RS-232-Like
SNA technology
Sonet/SDH
X.25 technology
RFC 1213
RFC 1696
Multiple
Multiple
Multiple
RFC 1659
Multiple
RFC 1595
Multiple
21
MIB Documents:
Service Management
 Frame
Relay Service
RFC 1604
RFC 2720
RFC 1694
 Meter
 SMDS
SIP
22
MIB Documents: System and
Applications Management
Application
RFC 2564
Diffie-Helman USM Key Management RFC 2786
DISMAN Scheduling
RFC 2591
DISMAN Scripting
RFC 2592
Domain Name System
Multiple
Host Resources
RFC 2790
Identification
RFC 1414
Mail Monitoring
RFC 2249
Network Services Monitoring
RFC 2788
23
MIB Documents: System and
Applications Management (Cont.)
Parallel Printer
Printer
Radius
Relational Database Server
System Application
TN3270
UPS
WWW Server
X.500 Directory Services Monitoring
24
RFC 1660
RFC 1759
Multiple
RFC 1697
RFC 2287
Multiple
RFC 1628
RFC 2594
RFC 2605
The SNMP-based Management
Framework Is Not Just For Networks
 The







only
relatively complete
open
multi-vendor
multi-platform
interoperable
standards-based management framework
for seamless integrated management of networks,
systems, applications, and services
25
Importance of Seamlessness
 Sharing:
Among cooperating management
applications
 Showing: User interfaces and reports
 Crunching: Converting data to information and
information to data
 Telling: SNMP-based movement of management
data
 Knowing: SMI-based instrumentation
26
Importance of Seamlessness
 No
single application or set of applications can
meet all requirements
 Sharing is essential



Single naming scheme
Consistent data definitions
Standard information semantics
 Mapping

functions do not work well
Every time you convert you lose
 Example:
event correlation for network, system,
and application management with point solutions
and proprietary database formats
27
Protocol Versions:
Summary Picture
Simple-Based Management
SNMPv1
SNMPv3
Party-based
SNMPv2
SNMPv2*
Common
SNMPv2
SNMPv2c
SNMPv2u
Management Information Definitions (MIB Documents)
RFC
1155
Format
RFC
1212/1215
Format
RFC
1442-4
Format
28
RFC
1902-4
Format
RFC
2578-80
Format
Evolution of the SNMP Protocol Portion of
Internet-Standard Management Framework
Modular (3 part) specification architecture:
3. Protocol definition


MIB independent
The Simple Network Management Protocol
Protocol operations
 Transport mappings
 Security and administration




First defined in RFC 1157 (SNMPv1)
Separate documents beginning in SNMPv2
Security and administration completed in SNMPv3
29
Protocol Evolution
Generation
Protocol
Operations
Transport
Mappings
1st
RFC 1157
(1988–1993)
2nd
RFC 1905
(1993- )
RFC 1906
(1993- )
3rd
Security &
Administration
Communitybased
Party-based
RFC 1445-47
(1993-1995)
User-based
RFC 2570-76
(1998- )
SNMP EOS
(new work)
30
New Features of SNMPv2c
 Expanded
data types: 64-bit counters
 Improved efficiency and performance: get-bulk
operator
 Confirmed event notifications: inform operator
 Richer error handling: errors and exceptions
 Improved sets: especially row creation/deletion
 Transport independence: IP, Appletalk, IPX, ...
 Etc.
31
New Features of SNMPv3
 New
features inherited from SNMPv2c, plus
 Security and Administration
32
New Features of SNMPv3 Inherited
from SNMPv2c
 The







list we just saw …
Expanded data types: 64-bit counters
Improved efficiency and performance: get-bulk
operator
Confirmed event notifications: inform operator
Richer error handling: errors and exceptions
Improved sets: especially row creation/deletion
Transport independence: IP, AppleTalk, IPX, ...
Etc.
 Plus
...
33
Features of SNMPv3: Security and
Administrative Framework
 Security
authentication
 privacy

 Administration







Authorization and view-based access control
Logical contexts
Naming of entities, identities, and information
People and policies
Usernames and key management
Notification destinations and proxy relationships
Remotely configurable via SNMP operations
34
Security Threats and Mechanisms
 Threats
protected against by SNMPv3:
1. Masquerade/data origin authentication: interloper
assumes the identity of a sender to gain its privileges.
2. Modification of information/data integrity: alteration
of in-transit messages.
3. Message stream modification: messages are reordered, delayed, or replayed
4. Disclosure/data confidentiality: privileged
information is obtained via eavesdropping on
messages.
35
Security Mechanisms
 SNMPv3
uses MD5 and DES as “symmetric,” i.e.,
private key mechanisms
(MD5 = Message Digest Algorithm 5,
RFC 1321)
(DES = Data Encryption Standard)
36
SNMPv3 User-based Authentication
Mechanism
 Based

on:
MD5 message digest algorithm in HMAC
indirectly provides data origin authentication
 directly defends against data modification attacks
 uses private key known by both sender and receiver
 16 byte key
 128 bit digest (truncated to 96 bits)



SHA an optional alternative algorithm
Loosely synchronized monotonically increasing time
indicator values

defends against certain message stream modification
attacks
37
SNMPv3 User-based Privacy
Mechanism
 Based


on:
Symmetric encryption used
Data Encryption Standard (DES) Cipher Block
Chaining (CBC) mode
provides privacy / protection against disclosure
 uses encryption
 subject to export and use restrictions in many
jurisdictions



16 byte key (8 bytes DES key, 8 byte DES initialization
vector)
Multiple levels of compliance with respect to DES due
to problems associated with international use
38
Secret Rules
 Note
that both of these mechanisms depend on
private keys




Secrets must be kept secret
No postem notes, no world readable files
Initial keys must be loaded out-of-band
Note that key management is a requirement for a
secure infrastructure because without a standardized
key distribution mechanism, proper key hygiene will
not be practiced
39
Remote Configuration MIB
Modules
 Each
document in the set of SNMPv3
specifications has appropriate Information
Modules which define appropriate MIB
instrumentation
 Includes key management for proper key hygiene
 User-friendly string-based naming
 UTF8 for international use
40
HTTP and IPSEC are not alternatives
because they do only part of the job
 They
provide authentication and privacy, but do
not help with the other parts of the problem:



authorization and view-based access control
multiple logical contexts and information naming
MIB module for standards-based remote configuration
of
security parameters including key management
 notification destinations, etc

 HTTP
over SSL has the additional problem of
connection-orientation which rules it out for use
in fault management
41
Mechanisms: Configurability
 Can



have:
no authentication / no privacy
authentication / no privacy
authentication / privacy
 Configured



at choice of network administrator
with the user deciding how much to “spend” on
security,
selecting the correct level of protection,
potentially on a transaction-by-transaction basis
42
Mechanisms: Configurability
(Continued)
 Most
administrators are expected to use the three
securityLevel choices as follows:



Monitoring: no authentication / no privacy
Control: authentication / no privacy
Downloading secrets: authentication / privacy
 Privacy

use may possibly be limited by:
Vendor reluctance to ship cryptographic technology
Multiple versions, extra paperwork, etc
 FUD
 DOTFWHAS: We should not confuse excuses for reasons


Usage restrictions in some jurisdictions
43
Multi-Lingual Implementations for
Coexistence and Transition
 Cannot
upgrade all systems at once
 Some systems will never be upgraded
 Virtually all products expected to be multilingual with simultaneous support for SNMPv1
and SNMPv3, perhaps including SNMPv2c,
maybe including Web-based management
 Old agent, old packet, old rules, old response;
New agent, new packet, new rules, new response
 Modular SNMPv3 architecture allows view-based
access control to be applied to any/all of these
paths
44
Advantages of SNMPv3
So What?
Who Cares?
Good Things Operators and
Administrators will like in SNMPv3
 Able




to practice safe sets
Configuration / Control / Provisioning
No longer mere monitoring
Able to augment or replace proprietary CLI over Telnet
Via standards-based solutions providing
Commercial-grade industrial strength security
 Authentication and Privacy

46
Good Things Operators and Administrators
will like in SNMPv3 (Cont’d)
 Now
able to distribute management out to
intelligent agents and mid-level managers



Important for scalability
Keep local management traffic local
Shorter feedback loops with lower latency
47
Good Things Operators and
Administrators will like in SNMPv3
 View-based

Access Control
Various groups can have differentiated:
levels of access, e.g. staff versus customers
 access to different information, e.g., customer 1 versus 2


Example:

Some groups of users might be allowed:
Read-write access to
 Read-write access to
 Read-only access to
 Read-only access to
all
of the MIB data
subsets of the MIB data
all
of the MIB data
subsets of the MIB data


All others get no access
48
Good Things Operators and Administrators
will like in SNMPv3 (Cont’d)
 Better

Notifications:
Traps
Spray and pray
 The only option in SNMPv1


Informs
Send, wait for acknowledgement
 Retry count and retry interval
 Added in SNMPv2c but with problems
 Problems fixed in SNMPv3



Standard MIB objects to configure
Source-side notification suppression
49
Good Things Operators and Administrators
will like in SNMPv3 (Cont’d)
 Source

Side Notification Suppression
Too many resources spent on uninteresting notification
messages, e.g., unwanted traps and informs
Notification generation
 Notification transmission and delivery
 Notification logging
 Notification filtering



SNMPv3 allows you to use a standard MIB and
standards-based tools to turn unwanted notifications
off at the source
You will really like this
50
Good Things Operators and Administrators
will like in SNMPv3 (Cont’d)
 Standards-based
applications enabled through
standard MIB definitions for ease of
administration




User names and keys
Authorization and access control rights
Notification destinations (traps and informs)
Also management of SNMPv1 and SNMPv2c
parameters such as community strings
51
Good Things Operators and Administrators
will like in SNMPv3 (Cont’d)
 Better

performance
The Awesome getBulk operator works better with
SNMPv3
Less latency and lower overhead through a smaller
number of larger packets
 One to three orders of magnitude faster than SNMPv1
getNext operator (typically two)
 Negotiates maximum message size correctly


Counter64

 New

No need to poll as often
features eliminate need for “gross hacks”
e.g., logical contexts
52
Good Things Operators and Administrators
will like in SNMPv3 (Cont’d)
 Better

error handling:
In a Get Request with 10 items requested and one is
unavailable:
In SNMPv1, returns in an error with no partial results
 In SNMPv2/3, results in 9/10 good values and one
exception


In a Set Request, if something fails:
In SNMPv1, results in a “No”
 In SNMPv2/3, results in a “No-because”

53
Disadvantages of SNMPv3
 Security

is expensive
More to configure and administer
Unlocked doors are more convenient to use
 Community strings were relatively easy to administer
 Off-the-shelf tools help


More overhead
Message headers longer and more complex
 Cryptographic calculations can increase CPU load
approximately 20-ish percent
 It will run slower, it will run much slower if softwarebased DES is used, especially if implemented in Java


Some machines do not have the hardware assets, but
almost all do: NO EXCUSES
54
Disadvantages of SNMPv3 (Cont’d)
 Export
and international usage considerations
 Incomplete product support

Some vendors claim customers (i.e., you) don’t care
about security


Agents better than manager stations and applications
SNMPv3 code often less mature and shaken out
55
Conclusion:
What is SNMPv3?
 Newest
version of the Internet-standard
Management Framework
 What SNMPv2 should have been - builds on the
good
 Compatible with the SMI and MIB you use now
 Important enabling technology for configuration
and control: adds security and administration for
safe sets
 Security: authentication and privacy
 Administration: logical contexts, view-based
access control, remote configuration
 Available now
56
Conclusions about SNMPv3
 There
is a lot to like
 But we are not done yet -- there is more to be done
57
The SNMP-based
Internet Standard Management Framework
is Still Evolving:
Recent and Ongoing IETF Work Items
The SNMP-based Management Framework
is Evolved and Evolving
 Not
the same old SNMP your mother used in 1988
 Many positive advancements already
standardized, implemented, and deployed
 Some more are nearly done and ready for
implementation and deployment:

SNMP-based configuration
Policy-based Management MIB
 Provisioning MIB for DiffServ

 Some


standardization work is just getting started:
SMIng
Evolution of SNMP: SNMP EOS
59
Recent and Ongoing IETF Work Items:
Topics
 SNMP-based

Configuration Management
Policy MIB Module
 EOS
Working Group: Evolution of SNMP
 SMIng Working Group: Evolution of the
Structure of Management Information
 Distributed Management Working Group
(DISMAN)
 MIB Definitions
60
Significant Market Drivers
 Growth
and scale
 Dearth of expert personnel
 The need for seamlessness
 The need for security
 Standards and enabling technology
 Driver du jour:
secure policy-based configuration of policy, e.g.,
secure policy-based configuration of security policy
 important to note multiple meanings of security and
policy

61
Multiple Meanings of Policy
 Policy-based
distribution of configurations
(targets selected according to a policy, e.g.,
every system which run Solaris and an Apache
Web server)
 Policy-based application of configuration rules
within a system (targets selected according to
roles), e.g., for each interface on a switch, apply
configuration A on every backbone interface and
configuration B on all other interfaces
 Configuration of policy, e.g.,
QoS policy or Security policy
62
SNMP-based Configuration Management
 IETF
SNMPCONF Working Group
 Goals

Show best practices regarding how to do it


Make it easier to do it


Deliverable: BCP document
Deliverable: Policy MIB Module
Provide a worked out example while addressing
pressing immediate needs
DOTFWHAS: One example is worth two books
 Provisioning of DiffServ QoS Policy

63
SNMP-based Configuration Management
Policy MIB Module
 Challenges

Configure multiple parameters with many instances
while, to the extent possible, being
Vendor independent (unlike CLI)
 Technology independent (ATM versus DiffServ)
 Instance independent (at a higher level of abstraction)


Integration of configuration management with fault
management, performance monitoring, etc
64
SNMP-based Configuration Management
Policy MIB Module
 The
PM MIB uses structured scripts to do policybased configuration of standard and vendorspecific MIB objects
 A policy in the PM MIB is a pairing of a filter rule
and an action (simple or complex)
 The filter rule selects the applicable elements, i.e.,

if (an element has certain characteristics) then
(apply operation to that element)
 Alternately:
if (policyFilter) then (policyAction)
65
PolicyScript Language
 The
script language will look familiar to you if
you use C, Perl, C++, Tcl, Python, or Javascript
 A simple subset


No pointers, structures, typed variables, objects,
classes, etc.
Does contain expressions, variables, looping
66
The Policy-Based Management MIB
 PM
MIB Policies can be applied to any type of
manageable element






Interfaces
Circuits
Queues
Processes
Software
others...
67
A Conceptual Policy
Trunk AND Ethernet AND 100Mb:
Trunk
Ethernet
Gold
Autonegotiate
100Mb
Off
Access
Ethernet
10Mb
Access
Frame
Silver
512Kb
Trunk
ATM
Gold
45Mb
Trunk
Ethernet
Silver
Autonegotiate
100Mb
Off
Access
Frame
128Kb
Trunk
Ethernet
Access
Ethernet
Gold
10Mb
Access
Ethernet
Silver
10Mb
Access
Ethernet
Gold
100Mb
Trunk
Frame
Access
Frame
Gold
512Kb
Access
Ethernet
Bronze
10Mb
Access
Ethernet
Gold
10Mb
Autonegotiate
100Mb
Off
68
45Mb
A Conceptual Policy
Ethernet AND Access AND Gold:
Trunk
Ethernet
Gold
100Mb
Trunk
ATM
Gold
45Mb
Access
Ethernet
Trunk
Ethernet
Silver
100Mb
Access
Ethernet
Gold
100Mb
DSCP = 5
Access
Frame
Access
Ethernet
Bronze
10Mb
10Mb
Access
Frame
Silver
512Kb
128Kb
.
Trunk
Ethernet
100Mb
69
Access
Ethernet
Gold
10Mb= 5
DSCP
Trunk
Frame
45Mb
Access
Ethernet
Gold
10Mb= 5
DSCP
Access
Ethernet
Silver
10Mb
Access
Frame
Gold
512Kb
Access
Ethernet
Gold
10Mb
DSCP = 5
PM MIB Goals
 Leverage


existing infrastructure, tools, and MIBs
Resulting simplicity will accelerate time to market
Don’t start from scratch in our data models
 Flexibility

for real-world policy
Simple or complex filters and simple or complex actions
 Do
not underestimate the power of configuring by
reference versus by value:

Consider 5 configuration parameters for 500 interfaces is
2,500 operations. If these are common, then a single SET
PDU could change them all simultaneously
70
policyFilter PseudoCode
Pseudocode:
(is an ethernet
AND is operational
AND gets gold or silver service)
Scripted As:
((getvar(“ifType.$*”)== ethernet-csmacd)
&& (getvar(“ifOperStatus.$*”) == up)
&& (roleMatch("gold”)||roleMatch("silver")))
71
Execution Example
 Filter:
((getvar(“ifType.$*”)== ethernet-csmacd)
&& (getvar(“ifOperStatus.$*”) == up)
&& (roleMatch("gold”)||roleMatch("silver")))
 Action:
setvar(“ifAdminStatus.$*”, down(2),Integer)
Index
1
2
3
4
5
Type
Ethernet
Frame
Ethernet
Ethernet
Ethernet
Roles
Gold
Gold
Silver
Silver
AdminStatus
Up
Up
Up
Down
Up
Up
72
Features of PM MIB
 Scripting
Very flexible and understandable way to express policy
 IT Personnel like the power of scripting
 Much more flexible than string matching

 Policies


based on operational status
Capabilities, status of interface, utilization, etc.
Allows much more rich sets of policies than using
human-input strings
 Scheduling


Business calendars: “M-F 9-5” or “Last Friday of every
month”
Videoconference from 12PM to 1PM
73
Features of PM MIB
 Conflict

Uses a precedence tree to find best policy in conflicts
 Error

resolution
Recovery
Helps meet service level goals by having backup
policies on managed systems
Policies have precedence - pmPolicyPrecedence
 Notifications if a policy encounters errors

 Operational


aspects:
Ability to test a policy
Ability to disable a policy on an element so operator
can take back control (“limp-home mode”) until policy
is fixed
74
SNMP-based Configuration Management
Benefits of the PM MIB Module
 Configuration


tied to fault and performance:
Interface fails that has been configured with DiffServ
or IPSec
Statistics can be collected based on configuration - can
selectively optimize data collection
 Built
with existing infrastructure and tools
 Leverages existing MIBs
 A complete package, including operational
aspects
75
SNMP-based Configuration Management
Benefits of the PM MIB Module
 You
will like how the Policy MIB module works
to configure DiffServ via the DiffServ MIB and
DiffServ Provisioning MIB Modules
 The same approach can and will be used with
other areas of configuration such as



The secure policy-based configuration of security
policy
Routing
etc.
76
Evolution of SNMP
IETF EOS Working Group
 The
SNMP Protocol portion of the Internet
Standard Framework is in its 2nd generation
 The EOS Working Group is chartered to develop
and propose a 3rd generation
 Performance enhancements under consideration /
development




Efficiency through OID suppression and compression
Enhanced table manipulation
Improved row operations
Support for new data types
77
Evolution of the Structure of Management
Information: IETF SMIng Working Group
 The
SMIng Working Group is developing a new
proposal for a next generation data definition
language
 Currently compiling and winnowing
requirements
 Motivated to have a single protocol-independent
data definition language to eliminate wasteful
duplication between MIBs and PIBs
 Realistic requirements that can be supported by
the SNMP and COPS-PR protocols
78
Evolution of the Structure of Management
Information: IETF SMIng Working Group
 Best
hits album of SMIv2 and SPPI, plus (still
being decided):


General cleanup / housekeeping
Additional data types
Signed and unsigned 64 bit integers
 Floating point: Float32, Float64, and Float128 (# of bits)
 Unions and discriminated unions
 Arrays
 Aggregate data types


New C-like grammar / syntax

Language extensibility
79
Evolution of the Structure of Management
Information: IETF SMIng Working Group
…

Object Oriented Design Features
Classes
 Inheritance
 Containment
 Methods
 Procedures
 Constraints: existence constraints, attribute transaction
constraints, attribute value constraints, method
constraints
 Associations and association cardinalities

 Not
all of the proposals will make the cut
80
Distributed Management:
IETF DISMAN Working Group
 With
security, it is possible to have intelligent
agents or mid-level managers doing distributed
management





Intelligent requires configuration
Configuration requires security
or
Security enables configuration
Configuration enables intelligent
 Multiple
proprietary MIB modules for years
 IETF DISMAN adding standardization
81
Distributed Management:
IETF DISMAN Working Group
 IETF
DISMAN chartered to define MIB specs for
distributed network management applications
 Remotely configured as an SNMP agent, acts as a
distributed SNMP manager application
 Off-load polling, keeping local polling local
 Proximity yielding lower latency and shorter
feedback loops
 Important for scalability
82
Distributed Management:
IETF DISMAN Working Group
 Published





Work Products
Schedule MIB (RFC 2591): Time driven execution
Script MIB: (RFC 2592): Movement of scripts, not
standardizing language
Remote Operations MIB: (RFC 2925): ping, traceroute,
DNS lookup
Event MIB (RFC 2981): actions based upon threshholds
Notification Log MIB (RFC 3014)
 Works
in progress
 Alarm MIB, ITU Alarm MIB, SNMP Alarms
83
MIB Definitions
 Multiple
Standards-track Specifications
WWW MIB
 Application MIB
 System Application MIB
 Network Services Monitoring MIB
 Host Resources MIB

 You
can use these to monitor your and your
customers’ mission-critical servers and services
running on open systems



DNS
Web, e-commerce
etc
84
MIB Definitions
 Use
of a single paradigm allows integrated and
correlated data and operations
 Addresses frustration of multiple, independent,
incompatible databases
85
Conclusions
Conclusions: The SNMP-based
Management Framework is Sturdy
 Originally
“the short-term interim standard”
 According to the pundits, has been on its last legs
since 1988

To be eclipsed by a succession of replacements
 SNMP-based



management is still
growing
expanding scope
evolving
 While
“replacements” come and go
87
What ever happened to?
Pre 1989 Proprietary, e.g. IBM Netview, DEC NMCC
1989 CMIP over TCP/IP (CMOT)
1990 DCE RPC – based management
1991 Open Software Foundation Distributed
Management Environment (OSF DME)
1992 CMIP over LANs (CMOL)
88
What ever happened to?
1993 DMTF’s Distributed Management Interface
(DMI) Management Information File (MIF)
1994 OMNIPoint
1995 CORBA
1996 Web-based device management, Web
enabled management
1997 DMTF’s WBEM: HMMS, HMMP, HMOM,
etc
89
What ever happened to?
1998 JMAPI over Java and DEN/LDAP
1999 JDMK over Java and CIM
2000 COPS/PIBs
2001 XML
Beyond … more to come …
90
Conclusions:
 The
Internet-Standard Management Framework
based on SNMP is




Evolved
Not just for networks
Secure
Sturdy
 But




there is much more work to be done
Additional standards work
Better applications
Implementation
Deployment
91
Conclusions:
 SNMP-based
management is far from perfect, but
it continues to be the best game in town
 The architecture and vision are fine
 We need to execute to completion
 You do not yet get to live that vision, in part
because the vendors are not supplying complete
and compliant products
92
Conclusions:
 The
vendors are not fully implementing and
supplying products based on that vision, in part
because you are not insisting that they do so

Some vendors claim they see little market demand for
secure management
 There
is an alternative to scripts and proprietary
CLI over Telnet: the Internet Standard
Management Framework
93
Questions / Comments
Thank you for your participation