福州大学：《计算机网络管理》课程PPT教学课件（英文）Chapter 6 SNMP Management-SNMPv2

Chapter 6:SNMP Management:SNMPv2 6.1 Major Changes in SNMPv2 Several significant Changes were introduced in SNMPv2.One of the most significant changes was to provide the security functions that SNMPy1 lacked. Unfortunately,after significant effort there was a lack of consensus,so the security feature was dropped from the final specifications.The security function continued to be implemented on an administrative framework based on community name,and the same administrative framework as in SNMPv1 was adopted for SNMPv2.The SNMPv2 Working Group has presented a summary of the community-based Administrative Framework for the SNMPv2 framework,and referred to it as SNMPv2C

Chapter 6: SNMP Management: SNMPv2 6.1 Major Changes in SNMPv2 Several significant Changes were introduced in SNMPv2. One of the most significant changes was to provide the security functions that SNMPv1 lacked. Unfortunately,after significant effort there was a lack of consensus, so the security feature was dropped from the final specifications. The security function continued to be implemented on an administrative framework based on community name, and the same administrative framework as in SNMPv1 was adopted for SNMPv2. The SNMPv2 Working Group has presented a summary of the community-based Administrative Framework for the SNMPv2 framework, and referred to it as SNMPv2C

Chapter 6:SNMP Management:SNMPv2 There are significant differences between the two versions of SNMP,and unfortunately version 2 is not backward-compatible with version 1.RFC 1908 presents implementation schemes for the coexistence of the two versions. The basic components of network management in SNMPv2 are the same as in version 1.They are agent and manager,both performing the same functions. The manager-to-manager communication,shown in Figure 4.8,is formalized in version 2 by adding an additional message.Thus,the organizational model in version 2 remains essentially the same.In spite of the lack of security enhancements,major improvements to the architecture have been made in SNMPv2

Chapter 6: SNMP Management: SNMPv2 There are significant differences between the two versions of SNMP, and unfortunately version 2 is not backward-compatible with version 1. RFC 1908 presents implementation schemes for the coexistence of the two versions. The basic components of network management in SNMPv2 are the same as in version 1. They are agent and manager, both performing the same functions. The manager-to-manager communication, shown in Figure 4.8, is formalized in version 2 by adding an additional message. Thus, the organizational model in version 2 remains essentially the same. In spite of the lack of security enhancements, major improvements to the architecture have been made in SNMPv2

Chapter 6:SNMP Management:SNMPv2 Bulk Data Transfer Message:Two significant messages were added.The first is the ability to request and receive bulk data using the get-bulk message.This speeds up the get-next-request process and is especially useful to retrieve data from tables. Manager-to-Manager Message: The second additional message deals with interoperability of two network management systems.This message extends the communication of management messages between management systems and thus makes network management systems interoperable. Structure of Management Information (SMD): SMI have been consolidated and rewritten in RFCs 1902 through 1904 in SNMPy2

Chapter 6: SNMP Management: SNMPv2 Bulk Data Transfer Message: Two significant messages were added. The first is the ability to request and receive bulk data using the get-bulk message. This speeds up the get-next-request process and is especially useful to retrieve data from tables. Manager-to-Manager Message: The second additional message deals with interoperability of two network management systems. This message extends the communication of management messages between management systems and thus makes network management systems interoperable. Structure of Management Information (SMI): SMI have been consolidated and rewritten in RFCs 1902 through 1904 in SNMPv2

SMIv2 is divided into three parts: module definitions,object definitions,and trap definitions. An ASN.1 macro,MODULE-IDENTITY,is used to define an information module.It concisely conveys the semantics of the information module.OBJECT- TYPE macro defines the syntax and semantics of a managed object.Trap is also termed notification and defined by NOTIFICATION-TYPE macro. Textual Conventions are designed to help define new data types.They are also intended to make the semantics consistent and clear to the human reader. Although new data types could have been created using new ASN.I classes and tags,the decision was made to use the existing defined class types and apply restrictions to them

SMIv2 is divided into three parts: module definitions, object definitions, and trap definitions. An ASN.1 macro, MODULE-IDENTITY, is used to define an information module. It concisely conveys the semantics of the information module. OBJECT￾TYPE macro defines the syntax and semantics of a managed object. Trap is also termed notification and defined by NOTIFICATION-TYPE macro. Textual Conventions are designed to help define new data types. They are also intended to make the semantics consistent and clear to the human reader. Although new data types could have been created using new ASN. 1 classes and tags, the decision was made to use the existing defined class types and apply restrictions to them

Intemet 1361 SNMPV2 rectory mgmt experimental rivate security snmpv2 ②) 3 ④ (5) (6) Figure6.1 SNMPV2 Internet Group

Chapter 6:SNMP Management:SNMPv2 6.2 SNNPv2 System Architecture The SNMPv2 system architecture looks essentially the same as that of version 1,shown in Figure 4.9. However,there are two significant enhancements in the SNMPv2 architecture.First,there are seven messages instead of five (compare Figure 4.9). Second,two manager applications can communicate with each other at peer level.Another message, report message,is missing from Figure 6.2 because, even though it has been defined as a message,the SNMPv2 Working Group did not specify its details. It is left for the implementers to generate the specifications.It is not currently being used

Chapter 6: SNMP Management: SNMPv2 6.2 SNNPv2 System Architecture The SNMPv2 system architecture looks essentially the same as that of version 1, shown in Figure 4.9. However, there are two significant enhancements in the SNMPv2 architecture. First, there are seven messages instead of five (compare Figure 4.9). Second, two manager applications can communicate with each other at peer level. Another message, report message, is missing from Figure 6.2 because, even though it has been defined as a message, the SNMPv2 Working Group did not specify its details. It is left for the implementers to generate the specifications. It is not currently being used

The messages get-request,get-next request,and set-request are the same as in version 1 and are generated by the manager application.The message response is also the same as get-response in version 1, and is now generated by both the agent and the manager applications.It is generated by the agent application in response to a get or set message from the manager application.It is also generated by the manager application in response to an inform-request message from another manager application. An inform-request message is generated by a manager application and transmitted to another manager application.The receiving manager application responds with a response message.This set of communication messages is a powerful enhancement in SNMPv2,because it makes two network management systems interoperable

The messages get-request, get-next request, and set-request are the same as in version 1 and are generated by the manager application. The message response is also the same as get-response in version 1, and is now generated by both the agent and the manager applications. It is generated by the agent application in response to a get or set message from the manager application. It is also generated by the manager application in response to an inform-request message from another manager application. An inform-request message is generated by a manager application and transmitted to another manager application. The receiving manager application responds with a response message. This set of communication messages is a powerful enhancement in SNMPv2, because it makes two network management systems interoperable

Chapter 6:SNMP Management:SNMPv2 The message get-bulk-request is generated by manager application.It is used to transfer large amounts of data from the agent to the manager, especially if it includes retrieval of table data.The retrieval is fast and efficient.The receiving entity generates and fills data for each entry in the request and transmits all the data as a response message to the originator of the request. An SNMPv2-trap event,known as trap in version 1,is generated and transmitted by an agent process when an exceptional situation occurs.The destination to which it is sent is implementation-dependent.The PDU structure has been modified to be consistent with other PDUs

Chapter 6: SNMP Management: SNMPv2 The message get-bulk-request is generated by a manager application. It is used to transfer large amounts of data from the agent to the manager, especially if it includes retrieval of table data. The retrieval is fast and efficient. The receiving entity generates and fills data for each entry in the request and transmits all the data as a response message to the originator of the request. An SNMPv2-trap event, known as trap in version 1, is generated and transmitted by an agent process when an exceptional situation occurs. The destination to which it is sent is implementation-dependent. The PDU structure has been modified to be consistent with other PDUs

6.3 SNMPv2 Structure of Management Information There are several changes to SMI in version 2,as well as enhancements to SMIv2 over that of SMIv1. The SMIv2 [RFC 1902]is divided into three parts: module definitions,object definitions, and notification definitions. The module definitions describe the semantics of an information module and are formally defined by an ASN.1 macro,MODULE-IDENTITY. The OBJECT-TYPE macro is used to define managed objects.OBJECT-TYPE conveys both syntax and semantics of a managed object. Notification in SMIv2 is equivalent to trap in SMIv1.In SMIv1,trap is formally specified by an ASN.1 macro,TRAP-TYPE.In SMIv2,notification is specified by an ASN.1 macro,NOTIFICATION- TYPE,and conveys both its syntax and semantics

6.3 SNMPv2 Structure of Management Information There are several changes to SMI in version 2, as well as enhancements to SMIv2 over that of SMIv1. The SMIv2 [RFC 1902] is divided into three parts: module definitions, object definitions, and notification definitions. The module definitions describe the semantics of an information module and are formally defined by an ASN.1 macro, MODULE-IDENTITY. The OBJECT-TYPE macro is used to define managed objects. OBJECT-TYPE conveys both syntax and semantics of a managed object. Notification in SMIv2 is equivalent to trap in SMIv1. In SMIv1, trap is formally specified by an ASN.1 macro, TRAP-TYPE. In SMIv2, notification is specified by an ASN. 1 macro, NOTIFICATION￾TYPE, and conveys both its syntax and semantics

SNMP Manager SNMP Agent SNMP Manager APDU SNMP Agent Application Application isenbe-ing-6 nbeJ-jes isenba-a6 senba-xeu-je6 isenba-ying-e6 isenba-jes den-dwus SNMP SNMP PDU SNMP UDP CLNS IP IP DLC DLC PHY PHY Physical Medium CLNS=Connectionless-Mode Network Service UDP User Datagram Protocol DLC Data Link Control igure 6.3 SNMPv2 Network Management Architecture on Multiple Transport Domains