1 / 65

SNMPv2

In the Name of the Most High. SNMPv2. by Behzad Akbari Fall 2011. These slides are based in parts upon slides of Prof. Dssouli (Concordia university ). Overview. SNMPv1 was developed as an interim solution to an eventual adoption of OSI.

mmaxine
Télécharger la présentation

SNMPv2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. In the Name of the Most High SNMPv2 by BehzadAkbari Fall 2011 These slides are based in parts upon slides of Prof. Dssouli (Concordia university)

  2. Overview • SNMPv1 was developed as an interim solution to an eventual adoption of OSI. • This never came about: OSI was not as widely adopted as originally hoped. • SNMPv2, released in 1996, was basically major revisions added to SNMP.

  3. SNMPv1 • SNMPv1 Protocol • RFC 1157 – Simple Network Management Protocol • SMIv1 Data Definition Language • Full Standards: • RFC 1155 - Structure of Management Information • RFC 1212 - Concise MIB Definitions • Informational: • RFC 1215 - A Convention for Defining Traps • SMIv1 MIB Modules • Full Standards: • RFC 1213 - Management Information Base II • RFC 1643 - Ethernet-Like Interface Types MIB

  4. SNMPv2 SMIv2 Data Definition Language Full Standards: RFC 2578 - Structure of Management Information RFC 2579 - Textual Conventions RFC 2580 - Conformance Statements SMIv2 MIB Modules Full Standards: RFC 2819 - Remote Network Monitoring MIB RFC 3411 - SNMP Framework MIB RFC 3412 - SNMPv3 MPD MIB RFC 3413 - SNMP Applications MIBs RFC 3414 - SNMPv3 USM MIB RFC 3415 - SNMP VACM MIB RFC 3418 - SNMP MIB

  5. Bulk data transfer Request and receive bulk data using the get-bulk message Manager-to-manager message Enhances interoperability and allows for managing large distributed networks Enhancements to SMI: SMIv2 Module definitions: MODULE-IDENTITY macro Object definitions: OBJECT-TYPE macro (same as before) Trap definitions: NOTIFICATION-TYPE macro Textual conventions: define new data types Conformance statements Help customers compare features of various products Keeps vendors open to their product’s compatibility with SNMP Major Changes

  6. Row creation and deletion in table A table can also be expanded by augmenting another table MIB enhancements Two new subgroups: security and snmpV2 Transport mappings UDP remains the preferred transport protocol; however, other protocols can also be used with SNMPv2 Security features, originally to be in SNMPv2 moved to SNMPv3 SNMPv2 is community-based administrative framework Major Changes Internet {1 3 6 1} SNMPv2 directory mgmt experimental private security snmpv2 (1) (2) (3) (4) (5) (6) SNMPv2 Internet Group

  7. SNMPv2 System Architecture SNMP Manager SNMP Manager SNMP Agent Application Application PDU SNMP Manager SNMP Manager SNMP Agent PDU Application Application Application snmpV2-trap snmpV2-trap snmpV2-trap get-next-request get-next-request set-request get-bulk-request set-request get-next-request get-bulk-request set-request response response response get-request get-request get-request inform-request inform-request get-bulk-request SNMP SNMP PDU SNMP SNMP SNMP PDU UDP UDP UDP IP IP IP DLC DLC DLC PHY PHY PHY Physical Medium Physical Medium

  8. inform-request manager-to-manager message The receiving manager responds with a response message Enhances interoperability get-bulk-request transfer of large data, e.g. retrieval of table data SNMPv2-trap Similar to trap messages in SNMPv1 Additional Messages

  9. SMIv2- Modules Definitions Defines and describe semantics of an information module (info. related to network management) added to provide administrative information regarding the informational module and the revision history MODULE-IDENTITY macro defines the module definitions

  10. SMIv2- Object Definitions OBJECT IDENTIFIER, OBJECT-IDENTITY, OBJECT-TYPE OBJECT IDENTIFIERdefines the administrative identification of a node in the MIB OBJECT-IDENTITY macro (defines info. about OID) assigns an object identifier to a class of managed objects in the MIB (e.g., defining a class of routers!) The object itself is not managed OBJECT-TYPE macro defines the type of a managed object (e.g., a specific router type) Focuses on the details of implementation NOTE: OBJECT-IDENTITY is high level description OBJECT-TYPE details description needed for implementation

  11. OBJECT-TYPE OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart "MAX-ACCESS" Access "STATUS" Status "DESCRIPTION" Text ReferPart IndexPart DefValPart VALUE NOTATION ::= value(VALUE ObjectName)

  12. "SYNTAX" Syntax Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}“ NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")“ -- number is nonnegative

  13. (Example) SYNTAX BITS protocolDirType OBJECT-TYPE SYNTAX BITS { extensible(0), addressRecognitionCapable(1) } MAX-ACCESS read-only STATUS current DESCRIPTION “…” ::= { protocolDirEntry 5 }

  14. UnitsPart: UNITS UnitsPart ::= "UNITS" Text | empty hrDiskStorageCapacity OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total size for this long-term storage device. If the media is removable and is currently removed, this value should be zero." ::= { hrDiskStorageEntry 4 } Back to OBJECT-TYPE

  15. "MAX-ACCESS" Access Access ::= "not-accessible" | "accessible-for-notify" | "read-only" | "read-write" | "read-create" ordered from least to greatest: "not-accessible": indicates an auxiliary object "accessible-for-notify": accessible only via a notification "read-only": read only "read-write": read and write, but create does not. "read-create": read, write and create

  16. "STATUS" Status Status ::= "current" | "deprecated" | "obsolete" “current”: the definition is current and valid. “deprecated”: indicates an obsolete definition, it permits new/continued implementation. “obsolete”: the definition is obsolete and should not be implemented.

  17. ReferPart ReferPart ::= "REFERENCE" Text | empty ipForwardTable OBJECT-TYPE SYNTAX SEQUENCE OF IpForwardEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "This entity's IP Routing table." REFERENCE "RFC 1213 Section 6.6, The IP Group“ ::= { ipForward 2 }

  18. Object Definitions, example NOTE: A specific instance of routerIsi123 could be identified by its IP address 10.1.2.3

  19. Table Definition Static Tables Tables completely controlled by the agent. Access is read-only, and read-write These are useful when the number of rows corresponds to a fixed attribute (e.g., # physical interfaces) or a quantity controlled only by agent Dynamic Table Allows row creation/deletion by a manager Access includes also read, write and create privileges A table can be initialized with no rows and expanded as needed SNMPv2: Augmentation of a table (dependent table) Adds additional columns to an existing table (base table) Number of rows is not affected INDEX of the second table is the same as the first table One to one correspondence between rows of two tables

  20. Augmentation of Tables Conceptual rows: 1. T1.E1.C1.1 2. T1.E1.C1.2 3. T1.E1.C1.3 4. T1.E1.C1.4 Table 2 Table 1 Base table Augmented table table1 table 2 (T1) (T2) table1Entry table2Entry (E1) (E2) T1.E1.C1.1 T1.E1.C2.1 T1.E1.C3.1 T2.E2.C4.1 T2.E2.C5.1 T1.E1.C1.2 T1.E1.C2.2 T1.E1.C3.2 T2.E2.C4.2 T2.E2.C5.2 T1.E1.C1.3 T1.E1.C2.3 T1.E1.C3.3 T2.E2.C4.3 T2.E2.C5.3 T1.E1.C1.4 T1.E1.C2.4 T.E1.C3.4 T2.E2.C4.4 T2.E2.C5.4 Example Columnar object:T2.E2.C4 Index: T1.E1.C1.2 Value: T2.E2.C4.2 Index: First columnar object in Table 1

  21. Augmentation of Tables Example: a vendor can easily specify vendor-specific objects as extensions to standard MIB table. It should be easier for applications to access these objects than if they were defined as new, separate table A clause used to increase the number of columns in a table w/out rewriting the table definition --Conceptual row extension The resulting table is therefore treated the same way as if it was defined in a single table definition

  22. Row Creation A new feature in SMIv2 2 methods Create a row and make it active (or available) Create a row and make it available at a later time  definition of the status of a row Used by agent to send responses to a manager Used by manager for row creation/deletion

  23. Row Creation 2 states for RowStatus: createAndGo, createAndWait table1 entry1 status.1 index.1 data.1 status.2 index.2 data.2 status.3 index.3 data.3 Row to be created/deleted

  24. Create and Go Manager initiates a SetRequest-PDU to create a new row status = 4, i.e., create and go Agent interacts with the management entity and successfully create an instance; subsequently a response is transmitted to the manager status = 1, indicates that the row is active SetRequest ( status.3 =4, index.3 = 3, Create Instance data.3 = DefData ) Instance Created Response ( status.3 = 1, index.3 = 3, data.3 = DefData ) Manager Agent Managed Process Process Entity

  25. Create and Wait SetRequest ( status.3 = 5, Create and wait, no default data specified index.3 = 3 ) Response ( Agent responds with “notReady” (no default value) status.3 = 3, index.3 = 3 ) Get the data for the row GetRequest ( data.3 ) Response ( Data value is missing data.3 = noSuchInstance) SetRequest ( Value of data is sent data.3 = DefData ) Response ( status.3 = 2 Agent responds with notInServcie data.3 = DefData ) SetRequest ( Manager requests to activate the row status.3 = 1 ) Response ( Row activated status.3 = 1 ) Manager Agent Process Process

  26. Row Deletion Manager Agent Managed Process Process Entity SetRequest ( status.3 = 6 ) Delete Instance Instance Deleted Response ( status.3 = 6 )

  27. Textual Conventions 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 SNMPv2 SNMPv1 A string of up to 255 characters (refer to table 6.2 for more rules)

  28. Textual Conventions-Macro TEXTUAL-CONVENTION MACRO ::= BEGIN TYPE NOTATION ::= DisplayPart "STATUS" Status "DESCRIPTION" Text ReferPart "SYNTAX" Syntax VALUE NOTATION ::= value(VALUE Syntax) DisplayPart ::= "DISPLAY-HINT" Text | empty Status ::= "current" | "deprecated" | "obsolete“ ReferPart ::= "REFERENCE" Text | empty ……………………….. END Example: Hundredths ::= TEXTUAL-CONVENTION DISPLAY-HINT “d-2” ... SYNTAX INTEGER (0..10000) suggests that a Hundredths value of 1234 be rendered as "12.34"

  29. Textual Conventions- example RowStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The RowStatus textual convention is used to manage the …” SYNTAX INTEGER { -- the following two values are states: -- these values may be read or written active(1), notInService(2), -- the following value is a state: -- this value may be read, but not written notReady(3), -- the following three values are -- actions: these values may be written, -- but are never read createAndGo(4), createAndWait(5), destroy(6) }

  30. SNMPv2 Protocol Overall, 8 messages with almost common message format to improve the efficiency and performance Significant improvement is that trap message has the same format PDU Error Error VarBind 1 VarBind 1 VarBind n VarBind n RequestID ... Status Type Index name value name value SNMPv2 PDU Indicate the type of PDU (e.g., Request-PDU, etc) identifies the first variable binding in the variable-binding list that caused the error Indicate the status of the error (e.g., noError, tooBig, etc.) • NOTE: • SNMPv1 operations (e.g., GET-REQUEST) are atomic: • either all values are returned or none! • In SNMPv2: a binding list (with corresponding values) is prepared even if one variable cannot be returned  an (error-status), (error-index) are returned in the case of anomaly.

  31. SNMPv2 Protocol Error index is set to “0” if there is no error; otherwise, it identifies the first variable binding in the variable binding list that caused the error

  32. SNMPv2 Protocol GetBulkRequest enables the retrieval of data in bulk Uses the same selection principle as GetNexRequest (i.e., next object instance) Retrieval of multiple rows of data from table (constrained by the max. message size) Error status field replaced by Non-repeaters Non-repeaters indicates the number of non repetitive (scalar) field values requested Error index field replaced by Max repetitions Max repetitionsdesignates the maximum number of table rows requested to be returned in the response message NOTE 1: value depends on the size of the SNMP message and buffer size in implementation NOTE 2: no one to one relationship between the VarBindList of request and response messages PDU Non- Max VarBind 1 VarBind 1 VarBind n VarBind n RequestID ... Type Repeaters Repetitions name value name value SNMPv2 GetBulkRequest PDU

  33. GetBulkRequest-PDU Operation A A B T Z B E T 2.1 3.1 1.1 E 2.2 3.2 1.2 T.E.1.1 T.E.2.1 T.E.3.1 T.E.1.2 T.E.2.2 T.E.3.2 2.3 3.3 1.3 T.E.1.3 T.E.2.3 T.E.3.3 2.4 3.4 1.4 T.E.1.4 T.E.2.4 T.E.3.4 Z

  34. GetBulkRequest-PDU Operation GetRequest ( A,B ) Manager Agent GetResponse (A,B) Process Process GetNextRequest (T.E.1,T.E.2,T.E.3) GetResponse (T.E.1.1,T.E.2.1,T.E.3.1) GetNextRequest (T.E.1.1,T.E.2.1,T.E.3.1) GetResponse (T.E.1.2,T.E.2.2,T.E.3.2) GetNextRequest (T.E.1.2,T.E.2.2,T.E.3.2) GetResponse (T.E.1.3,T.E.2.3,T.E.3.3) GetNextRequest (T.E.1.3,T.E.2.3,T.E.3.3) GetResponse (T.E.1.4,T.E.2.4,T.E.3.4) GetNextRequest (T.E.1.4,T.E.2.4,T.E.3.4) GetResponse (T.E.2.1,T.E.3.1,Z)

  35. GetBulkRequest-PDU Operation A 2 non repetitive objects (A, B) B 3 repetitive instances Of the columnar object T.E.1, T.E.2, T.E.3 T GetBulkRequest ( 2,3, E A,B,T.E.1, T.E.2, T.E.3 ) Response ( A, B, T.E.1.1, T.E.2.1, T.E.3.1 T.E.1.1 T.E.2.1 T.E.3.1 T.E.1.2, T.E.2.2, T.E.3.2 T.E.1.3, T.E.2.3, T.E.3.3 ) GetBulkRequest ( 0,3, T.E.1.2 T.E.2.2 T.E.3.2 T.E.1.3, T.E.2.3, T.E.3.3 ) T.E.1.3 T.E.2.3 T.E.3.3 Response ( T.E.1.4, T.E.2.4, T.E.3.4, Z , " endOfMibView" ) T.E.1.4 T.E.2.4 T.E.3.4 Z Manager Agent Process Process 3 more rows Z is next in the lexicographic order

  36. GetBulkRequest-PDU Operation

  37. SNMPv2 Trap PDU Addition of NOTIFICATION-TYPE macro Positions 1 and 2 in VarBindList are sysUpTime and snmpTrapOID Inform-Request behaves as trap in that the message goes from one manager to another unsolicited The receiving manager sends response to the sending manager PDU Error Error VarBind1 VarBind1 VarBind2 VarBind 2 RequestID ... snmpTrapOID Status Type Index sysUpTime value value

  38. Conformance Statements for SMIv2 (RFC 2580)

  39. MIB MODULE IMPORTS EXPORTS MODULE-IDENTITY TEXTUAL-CONVENTION OBJECT IDENTIFIER Application Data Types OBJECT-TYPE NOTIFICATION-TYPE OBJECT-GROUP NOTIFICATION-GROUP MODULE-COMPLIANCE I E MI TCs OIs OTs NTs OGs NGs MCs

  40. NG OG OG NT OT OT OT NT NT OT OT OT OT NG NT NT OI OI data types TC E data types TC MI I MC OG OG NG NG MC

  41. Four Macros in SNMPv2-CONF • OBJECT-GROUP macro • NOTIFICATION-GROUP macro • MODULE-COMPLIANCE macro • AGENT-CAPABILITIES macro

  42. 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

  43. OBJECT-GROUP OBJECT-GROUP MACRO ::= BEGIN TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) ObjectsPart ::= "OBJECTS" "{" Objects "}" Objects ::= Object | Objects "," Object Object ::= value(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= value(IA5String) END

  44. OBJECT-GROUP Example hrSWRunGroup OBJECT-GROUP OBJECTS { hrSWOSIndex, hrSWRunIndex, hrSWRunName, hrSWRunID, hrSWRunPath, hrSWRunParameters, hrSWRunType, hrSWRunStatus } STATUS current DESCRIPTION "The Host Resources Running Software Group." ::= { hrMIBGroups 4 }

  45. 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

  46. NOTIFICATION-GROUP NOTIFICATION-GROUP MACRO ::= BEGIN TYPE NOTATION ::= NotificationsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) NotificationsPart ::= "NOTIFICATIONS" "{" Notifications "}" Notifications ::= Notification | Notifications "," Notification Notification ::= value(NotificationName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= value(IA5String) END

  47. NOTIFICATION-GROUP Example linkUpDownNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { linkUp, linkDown } STATUS current DESCRIPTION "The notifications which indicate specific changes in the value of ifOperStatus." ::= { ifGroups 14 }

  48. Compliance • Compliance has two classes of groups • MANDATORY-GROUPS ... Required • GROUP …Optional

  49. MODULE-COMPLIANCE MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart ModulePart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) MODULE-COMPLIANCE

  50. ModulePart ModulePart ::= Modules Modules ::= Module | Modules Module Module ::= "MODULE" ModuleName MandatoryPart CompliancePart ModuleName ::= identifier ModuleIdentifier | empty ModuleIdentifier ::= value(OBJECT IDENTIFIER) | empty MandatoryPart ::= "MANDATORY-GROUPS" "{" Groups "}“ | empty Groups ::= Group | Groups "," Group Group ::= value(OBJECT IDENTIFIER)

More Related