Transcript Standardization Status of SNMP
SNMP Update Jeff Case Founder and CTO SNMP Research, Inc.
+1 865 573 1434 [email protected]
Please see www.snmp.com/jdctutorial.ppt for slides
Topics:
Introduction
Differences between SNMPv1, SNMPv2c, and SNMPv3
Advantages of SNMPv3 over SNMPv1 and SNMPv2c
Disadvantages of SNMPv3
2
Topics (Continued):
Recent and Ongoing IETF Work Items
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
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 Party-based SNMPv2 Common SNMPv2
*
SNMPv2 SNMPv2c SNMPv2u SNMPv3 Management Information Definitions (MIB Documents) RFC 1155 Format RFC 1212/1215 Format RFC 1442-4 Format RFC 1902-4 Format RFC 2578-80 Format
7
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 Party-based SNMPv2 Common SNMPv2
*
SNMPv2 SNMPv2c SNMPv2u SNMPv3 Management Information Definitions (MIB Documents) RFC 1155 Format RFC 1212/1215 Format RFC 1442-4 Format RFC 1902-4 Format RFC 2578-80 Format
14
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
19
RFC 2662 Multiple RFC 1742 RFC 1657 RFC 1493 RFC 1658 RFC 1238 RFC 1559 Multiple
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 Multiple RFC 2737 Multiple Multiple Multiple Multiple Multiple Multiple Multiple
20
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
Meter
SMDS SIP RFC 1604 RFC 2720 RFC 1694
22
MIB Documents: System and Applications Management Application RFC 2564 Diffie-Helman USM Key Management RFC 2786 DISMAN Scheduling DISMAN Scripting RFC 2591 RFC 2592 Domain Name System Host Resources Identification Mail Monitoring Network Services Monitoring Multiple RFC 2790 RFC 1414 RFC 2249 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 RFC 1660 RFC 1759 Multiple RFC 1697 RFC 2287 Multiple RFC 1628 RFC 2594 RFC 2605
24
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 Party-based SNMPv2 Common SNMPv2
*
SNMPv2 SNMPv2c SNMPv2u SNMPv3 Management Information Definitions (MIB Documents) RFC 1155 Format RFC 1212/1215 Format RFC 1442-4 Format RFC 1902-4 Format RFC 2578-80 Format
28
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 1 st 2 3 nd rd Protocol Operations RFC 1905 (1993- ) SNMP EOS (new work) Transport Mappings RFC 1157 (1988–1993) Security & Administration Community based RFC 1906 (1993- ) Party-based RFC 1445-47 (1993-1995) User-based RFC 2570-76 (1998- )
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 re ordered, 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 multi lingual 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 all of the MIB data
Read-write access to
Read-only access to
Read-only access to 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
No need to poll as often
New 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 software based 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
Deliverable: BCP document Make it easier to do it
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 policy based configuration of standard and vendor specific 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 Off Trunk ATM Gold 45Mb Trunk Ethernet Autonegotiate Off Access Ethernet Gold 10Mb Access Ethernet 10Mb Access Frame Silver 512Kb Trunk Ethernet Silver Autonegotiate Off Access Frame 128Kb Access Ethernet Gold 100Mb Access Ethernet Bronze 10Mb Trunk Frame 45Mb Access Ethernet Gold 10Mb 68 Access Ethernet Silver 10Mb Access Frame Gold 512Kb
A Conceptual Policy Ethernet AND Access AND Gold:
Trunk Ethernet Gold 100Mb Trunk ATM Gold 45Mb Trunk Ethernet 100Mb Access Ethernet Gold DSCP = 5 Access Ethernet 10Mb Access Frame Silver 512Kb Trunk Ethernet Silver 100Mb .
Access Frame 128Kb Access Ethernet Gold DSCP = 5 Access Ethernet Bronze 10Mb 69 Trunk Frame 45Mb Access Ethernet Gold DSCP = 5 Access Ethernet Silver 10Mb Access Frame Gold 512Kb Access Ethernet Gold
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)
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 resolution
Uses a precedence tree to find best policy in conflicts Error 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