710 likes | 1.23k Views
Chapter 6 SNMPv2. SNMPv2 References. RFC 3418 December 2002 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) Std 0062 RFC 2576 Jan 1996, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
E N D
Chapter 6 SNMPv2
SNMPv2 References • RFC 3418 December 2002 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) Std 0062 • RFC 2576 Jan 1996, Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework • RFC: June 2005 Management Information Base for the User Datagram Protocol (UDP)
Structure Of Management Information (Data Definition language • The Structure of Management Information (SMIV2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules • "Textual Conventions for SMIv2," defines an initial set of shorthand abbreviations, which are available for use within all MIB modules for the convenience of human readers and writers. • "Conformance Statements for SMIv2," defines the format for compliance statements, which are used for describing requirements for agent implementations and capability statements that can be used to document the characteristics of particular implementations.
SNMPv2 SNMPv2 is defined by these documents: - • STD 58, RFC 2578: Defines Version 2 of the Structure of Management Information (SMIv2) • STD 58, RFC 2579: Defines common MIB "Textual Conventions" • STD 58, RFC 2580: Defines Conformance Statements and requirements for defining agent and manager capabilities • RFC 1905 which defines the Protocol Operations used in processing : • RFC 1906 which defines the Transport Mappings used "on the wire" • RFC 1907 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580
SNMPv2 • SNMPv2 : Work finished, and standards released in 1996 • Community based admin framework as SNMPv1 • Was slated to provide security framework, lacking in SNMPv1, but this aspect was moved to SNMPv3, as there was lack of agreement
Major Changes • Bulk data transfer; addition of 2 message types (get-bulk, and receive-bulk messages) • Manager-to-manager message: Added a new message type • Enhancements to SMI: SMIv2 • Module definitions: MODULE-IDENTITY macro • Object definitions: OBJECT-TYPE macro • Trap definitions: NOTIFICATION-TYPE macro • Textual conventions
Major Changes • Conformance statements: allows a user to compare the features of the various management products • Table enhancements: • Row creation and deletion in table • MIB enhancements • Transport mappings: changes to communication model. Allows other transport protocols to be used. Mappings of SNMP layer over multiple transports • UDP is still preferred model
Major Changes: MIB Enhancements (cont’d) Internet 1.3.6.1 SNMPv2 directory (1) mgmnt (2) experimental (3) private (4) security (5) SNMPv2 (6) MIB (2) system (1) snmp (11) interfaces (2) transmission (10) at (3) cmot (9) ip (4) egp (8) icmp (5) udp (7) tcp (6) 1. Objects added to System group 2. Extensive modification of the SNMP group 3. Additional SNMPv2 group added 4. Security group is a placeholder
Major Changes(cont’d) • Security features, originally to be in SNMPv2 moved to SNMPv3 • SNMPv2, like SNMPv1, is community-based administrative framework
SNMPv2 NM Architecture (Cont’d) SNMP Manager Inform Request SNMP Manager Get SNMP Agent Get Request Get- Next Get- Next-Request Get- Bulk Get- Bulk-Request Set-Request Set-Request Response Response SNMPv2-trap SNMPv2-trap
SNMPv2 New Messages • inform-request • manager-to-manager message (major step in right direction for manager to manger communication) • get-bulk-request • transfer of large data • report • not used
SNMPv2 SMI • Several changes to SMI • Enhancements to SIMv2 over SIMv1 • SIMv2 divided into three parts • Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. • Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. • Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification. • SIMv2 formalizes the assignment of the object identifier
Information Model • Three kinds of information modules: • MIB modules • Compliance statements for modules • Capability statement for agent implementations • SNMPv2 uses already defined and new defined MIBS • Extensive mods made to SNMP group and System group
Major ChangesMIB Enhancements (cont’d) Internet 1.3.6.1 SNMPv2 directory (1) mgmnt (2) experimental (3) private (4) security (5) SNMPv2 (6) snmpDomains (1) snmpProxys (2) snmpModules (3) 1. Objects added to System group 2. Extensive modification of the SNMP group 3. Additional SNMPv2 group added 4. Security group is a placeholder
Internet MIB-2 Groups Internet {1 3 6 1} directory mgmt experimental private (1) (2) (3) (4) mib-2 (1) system (1) snmp (11) interfaces (2) transmission (10) at (3) cmot (9) ip (4) egp (8) icmp (5) udp (7) tcp (6) Figure 4.26 Internet MIB-II Group
Table Expansion • SMIv2 extends the concept table from an aggregate object from a single table to multiple tables • Augmentation of a table (dependent table) adds additional columns to an existing table (base table) • Dense table enables addition of more rows to base table • Sparse table supplements less rows to a base table
Augmentation of tables • This allows for augmentation of a table when columnar objects need to be increased, or columns need to be arranged in certain heirarchy • For this augmentation number of rows is same in both tables • Table 1 has index for both tables (Table 1 and table 2)
Example of Table Augmentation ipAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddrEntry MAX- ACCESS not-accessible STATUS current table …" DESCRIPTION "The ::= { ip 20} ipAddrEntry OBJECT-TYPE SYNTAX IpAddrEntry MAX- ACCESS not-accessible STATUS current D ESCRIPTION "The addressing information…” INDEX { ipAdEntAddr} ;;= { ipAddrTable 1} Figure 6.13 Example of Augmentation of Tables
Example of Augmentation Table continued ipAugAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAugAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The augmented table to IP address table defining board and port numbers" ::= { ipAug 1} ipAugAddrEntry OBJECT-TYPE SYNTAX IpAugAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The addressing information …" AUGMENTS { ipAddrEntry} ::= { ipAugAddrTable 1} Figure 6.13 Example of Augmentation of Tables
Textual Conventions SNMPv2 • Enables defining new data types • Makes semantics of data types consistent and human readable • Creates new data types using existing ones and applies restrictions to them • An important textual convention in SNMPv2, RowStatus creates and deletes rows
SNMPv1: Textual conventions Textual convention for defining Dsplay string in SNMPv1 is as follows (RFC 1213)
SNMPv2: Textual conventions The same example of dispay string in SNMPv2 is defined as follows:
SNMPv2: Textual conventions • In SNMPV2 “TEXTUALCONVENTION” is defined as data type. • It conveys the syntax and semantics of textual convention • The cluase ‘DISPLAY-HINT is optional and gives a hint as how the value of an instance of an object, with the syntax defined with textual convention may be displayed. • It is used when underlying primitive is either INTEGER or OCTET STRING In the example DIPLAY-HINT (255a), it hints that display string is an ASCII string with up to 255 characters
Creation of Row: RowStatus Status: A new column is added to the conceptual table SYNTAX of Status is RowStatus Value of RowStatus is Enumerated INTEGER
snmpMIBObjects MIB 1.3.6.1.6.3.1.1 Snmp modules SNMPv2 Snmp MIB
SNMPv2 MIB (Cont’d) • Security is a placeholder • System group: A table sysORTable added that lists resources that the agent controls; NMS configures NE through the agents. • Most of the objects in the SNMPv1 obsoleted • Object Groups and Notification Groups defined for conformance specifications
Conformance: OBJECT-GROUP • Conformance defined by • OBJECT-GROUP macro • NOTIFICATION-GROUP macro • OBJECT-GROUP • Compiled during implementation, not at run time • OBJECTS clause names each object • Every object belongs to an OBJECT-GROUP • Access defined by MAX-ACCESS, the maximum access privilege for the object
Conformance: NOTIFICATION-GROUP • NOTIFICATION-GROUP • Contains trap entities defined in SMIv1 • NOTIFICATIONS clause identifies the notifications in the group • NOTIFICATIONS-GROUP macro compiled during implementation, not at run time
Compliance • Compliance has two classes of groups • MANDATORY-GROUPS ... Required • GROUP …Optional
Compliance groupsManadatory • systemGroup • snmpSetGroup • snmpGroup • snmpBasicNotificationsGroup • snmpCommunityGroup • snmpMIBObjects: defines information on notifications
Agent Capabilities • AGENT-CAPABILITIES macro • SUPPORTS modules and includes groups • VARIATION identifies additional features
SNMPv2 PDU • Standardized format for all messages Error Status & Index: 0 or ignored (get-request, get-next-request, set) Status=0 for get-response