Table Of Contents. Loading MIBs...34 Unloading MIBs...36 Parsing MIBs...37

Transcription

1

2 Table Of Contents ADVENTNET SNMP API.NET EDITION 4.0 PRODUCT DOCUMENTATION... 4 QUICK TOUR... 5 About AdventNet SNMP API... 6 AdventNet SNMP API Experience... 7 Related Products Contact Customer Support TECHNOLOGY OVERVIEW SNMP Overview Versions of SNMP SNMPv3 Overview MIB Overview RELEASE NOTES INSTALLATION GUIDE System Requirements Installing SNMP API.NET Edition Package Structure Installing Service Pack DEVELOPING MANAGEMENT APPLICATIONS Using MIBs in Applications Loading MIBs...34 Unloading MIBs...36 Parsing MIBs...37 Parsing Levels Checks for Various Parsing Levels Checks in Detail Accessing Node Information...52 Retrieving MIB Information...54 Exceptions and Error Messages...55 Macro Type Constructs...60 Configuring SNMP Agent Parameters AdventNet, Inc. 1

3 Handling Datatypes Overview...71 SMI Datatypes...75 Integer INTEGER (Enumerated) Unsigned Gauge Counter Timeticks OCTET STRING OBJECT IDENTIFIER IpAddress Opaque BITS Textual Conventions Overview DateAndTime MacAddress Data Retrieval Operations SNMP GET SNMP GETNEXT SNMP GETBULK Data Altering Operations SNMP SET Setting Values for Datatypes Traps and Notifications Receiving Notifications Sending Notifications Table Handling in Applications SNMP Table Basics Fetching Tables Getting Row Data Getting Column Data Modifying Table Data Adding a Row Deleting a Row Error Messages AdventNet, Inc. 2

4 Using Transport Providers SNMP Transport Provider Custom Transport Provider Deployment Instructions Examples Setting Up the Environment SNMP GET SNMP GETNEXT SNMP GETBULK SNMP Walk SNMP SET Send Trap Receive Trap Send Inform Receive Inform MIB Details Tutorials Tutorials: SNMP GET Tutorials: SNMP GETNEXT Tutorials: SNMP GETBULK Tutorials: SNMP SET Tutorials: Send Trap Tutorials: Receive Trap MIB Node Information Performance Metrics FAQS Beginners FAQs FAQs - General Advanced FAQs KNOWN ISSUES APIDOCS AdventNet, Inc. 3

5 AdventNet SNMP API.NET Edition 4.0 Product Documentation Welcome to AdventNet SNMP API.NET Edition, a comprehensive toolkit for rapid development of SNMP-based management applications that are reliable and scalable. With well-proven APIs enriched with customer experience and an integrated set of easy-to-use tools and features, AdventNet SNMP API caters to the complete development life cycle of network element management. Network management developers can leverage AdventNet SNMP library to build standalone and Web-based applications. The library provides many of the commonly used functions and components out-of-the-box to make the development simpler. The core of AdventNet SNMP API.NET Edition is a set of APIs that can be integrated in any application. Built using the best software design patterns and optimized performance, it is a powerful suite to secure APIs to build cross-platform, real-time application for monitoring and tracking the performance of network elements. Quick Tour Technology Overview Release Notes Installation Guide Developing Management Applications FAQs Known Issues and Limitations APIdocs AdventNet, Inc. 4

6 Quick Tour About AdventNet SNMP API AdventNet SNMP API Experience Related Products Contact Customer Support This section gives you an overview of AdventNet SNMP API and the technologies on which it is built. It also gives an overview of the features and the various modules of AdventNet SNMP API. AdventNet, Inc. 5

7 About AdventNet SNMP API Target Market Benefits Key Features AdventNet SNMP API can be used for building management applications for delivering superior solutions that are appropriate for specific needs in the spheres of Internet Infrastructure Management. This API can be used and integrated into any programming infrastructure that might require network management solution. Target Market AdventNet SNMP API is built to address the needs of the following: Equipment Vendors and ISVs can build device and network element management applications. In addition, applications for performance monitoring, configuration, and managing resources on the network can be developed easily. Enterprises can build applications for measuring utilization and throughput monitoring and deploy them in various ways. Service Providers can develop applications for monitoring utilization and throughput besides service availability and performance management. Benefits Customization - provides a rich set of interfaces to deliver a highly customizable solution. Scalability - fundamentally designed as a multi-tier system, based on widely used Internet technologies for highly scalable solutions. Flexibility - provides a hierarchy of.net library packages, which allow flexible selection of the level of library support desired. Therefore, you can access the detailed SNMP information by using API. Conformance to standards - AdventNet SNMP API conforms to the following Internet RFC specifications. SNMPv1 - RFC 1155 and RFC 1157 SNMPv2c - RFC 3416 Coexistence between SNMPv1, SNMPv2c, SNMPv3 - RFC 3584 Notification Filtering and Proxy Forwarding - RFC 3413 Key Features Multi-lingual support: Complete support for SNMPv1 and SNMPv2c Robust SMIv1 and SMIv2 MIB Parser: Seamlessly parses the MIB definitions from any OEM vendor. Offers various flavors of parsing based on the MIB definitions. SNMP Broadcasting: Broadcasts snmp packets across the network to auto-discover snmp devices in the network. Command line utilities: Perform SNMP operations such as, SNMP GET, SNMP GETNEXT, SNMP SET, SNMP BULK, SNMP WALK, etc. on remote agents. AdventNet, Inc. 6

8 AdventNet SNMP API Experience All SNMP management applications communicate with one or more SNMP agents to deliver their functionality. Both the management application and the agent always conform to the SNMP, MIB, and SMI specifications. Although the management applications are diverse in nature, they all share a minimal common characteristics. All the SNMP agents typically behave in a standard way - processing requests from the manager applications and sending traps. SNMP agents on a network only differ in the various versions of the SNMP they support, and the MIB or the managed objects they maintain. The SNMP management applications communicate with the agents to retrieve and collect the necessary information. The following are the various factors that need to be considered while developing a management application Accessing the Data from the MIBs Supported by the Agent Collecting Data from the Agent Communicating with SNMP Agent Table Handling Polling Displaying the Retrieved Data Receiving Unsolicited Messages from the Agent Version of SNMP to Be Supported Fig: SNMP API Architecture SNMP Core: Implements SNMP communication related classes developed in C# MIBS API: Implements all the MIB handling support, such as MIB loading, unloading, etc., developed using J# Accessing the Data from the MIBs Supported by the Agent The management applications typically request management data or properties from one or more SNMP-enabled nodes. The application needs to know the names and types of objects in the managed device. This is available in the Management Information Base (MIB) modules, which are usually provided with the managed devices. AdventNet, Inc. 7

9 The data supported by the agent are available in the form of MIB files and the manager applications make use of the information available in the MIB files while querying the agent. For example, RFC1213-MIB, also known as MIB-II, is a MIB module that is supported by all SNMP agents on TCP/IP-enabled devices. Apart from supporting MIB-II, each device has its own MIB, such as a printer MIB, a modem MIB, or a switch MIB. These MIBs can be used to access the associated data with it. Management applications should be able to Load and unload MIB modules Access the information on managed objects using MIB Resolve the textual labels to numerical OIDs Determine the type of data of the MIB object Simple management applications normally make a request by manually loading the MIB file, entering the OID, data type, and data value of the each variable binding. Advanced applications require loading multiple MIBs, storing the MIBs, logging the management requests, and so on. Collecting Data from the Agent The SNMP management applications communicate with the agents to retrieve the data. Applications normally retrieve the data by synchronous/asynchronous communication or by polling at regular intervals. The applications, while communicating through the synchronous mode, wait for the response of the previous request before sending a new request. In the case of asynchronous mode, the manager application can keep sending requests to the agent without waiting for the response. The responses are retrieved using the callback mechanism. Though using asynchronous mode appears to lead to improved performance, it can be used when the manager application knows the OID of the object it has to query. The synchronous operation is relevant while retrieving something like a tabular data, in which the instance of the OID to be queried next is got from the response of the previous request. The data retrieving functions of the manager applications can be classified as follows: Communicating with SNMP agent Table handling Polling Communicating with SNMP Agent Management applications normally retrieve the properties of the devices using SNMP GET, GETNEXT, or GETBULK request to the OIDs. The request may be simply to check whether the node is alive or to periodically retrieve the values of specific managed objects. The sections Data Retrieval Operations and Data Altering Operations discuss how the applications communicate with the agent to access the data and the various ways of accessing the data using the SNMP protocol. Table Handling Most of the MIBs are designed to handle large data in the form of tables. Management applications should be able to retrieve tables in a quick and efficient way. Intuitive table handling GUIs should become part of the management applications. Table Handling in Applications explains the various table-related operations that can be performed using AdventNet SNMP API. AdventNet, Inc. 8

10 Polling The retrieval of data for specific managed objects at periodic interval of time is called polling. Polling is normally used to monitor data that may change over time. Repeated polling of data is required when the object is a critical resource or when it is required to monitor the performance. Displaying the Retrieved Data After the necessary data is collected from the agent, the management application has the option of displaying the result in the form of UI or non-ui. In case of displaying the results in the form of UI, the users have to build their own UI components. Receiving Unsolicited Messages from the Agent Traps are unsolicited messages sent from an SNMP agent to one or more SNMP management applications. The generation of a trap by an agent indicates that some predefined event has occurred. When the agent detects the occurrence, trap messages are generated and sent to specific trap destinations. Management applications running in these trap destinations receive the traps. Trigger actions can be configured on receiving the trap. This could be a change in color, an alarm sound, a blinking LED, an alert, or a pager alert. Applications should also allow the trap data to be logged to determine what kind of event caused the agent to generate the trap. This is done by examining the data stored in the variable bindings of each trap message. The varbinds may contain the identity and values of MIB variables that provide information on the specific event. Many trap messages do not contain any variable bindings. This is because there may be no data associated with the event that triggered the generation of the trap, or the trap message itself conveys the necessary information. Receiving Unsolicited Messages discusses the trap-handling features that are available in AdventNet SNMP API. Version of SNMP to Be Supported The management applications should be able to support all the SNMP versions, so that it can communicate with diverse set of devices/systems. SNMPv1 and v2c versions are predominantly used for monitoring and performance management. SNMPv3 with its enhanced security features can be used for configuration, accounting, and fault management. AdventNet SNMP API supports SNMPv1 and SNMPv2c. Applications have the flexibility of selecting any desired versions. AdventNet, Inc. 9

11 Related Products AdventNet provides a comprehensive range of network management products that address all the network and system management needs of your organization. The following is our comprehensive portfolio of development tools. Visit our Web site for the latest information on our products. This section talks briefly about AdventNet products that are closely related to AdventNet SNMP API. Java SNMP API AdventNet SNMP API is a comprehensive development environment that comprises Java SNMP library and protocol stack for building SNMP management applications. It supports all three versions of SNMP:SNMPv1, SNMPv2c, and SNMPv3 in one common API. For a detailed product overview, please see the Java SNMP API product page on our Web site. Web NMS An open, standards-based, scalable network management platform that enables easy development of custom element management system (EMS) and network management system (NMS) applications. For a detailed product overview, please see the Web NMS product page on our Web site. CLI API AdventNet CLI API supports CLI protocols, such as SSH stack (SSH1 and SSH2), CLI telnet, and CLI transport provider (for custom protocols); offers CLI command set and functions, such as CLI parsing. For a detailed product overview, please see the CLI API product page on our Web site. TL1 API AdventNet TL1 API combines the power of TL1 protocol stack and TL1 message parser and contains TL1 tools, such as TL1 craft interface and TL1 message builder that help in rapid application development. For a detailed product overview, please see the TL1 API product page on our Web site. Agent Toolkit Java Edition The AdventNet Agent Toolkit Java Edition is a rapid prototyping and development tool used for building Java-based standalone SNMP and TL1 agents. For a detailed product overview, please see the Agent Toolkit Java Edition product page on our Web site. Agent Toolkit C Edition AdventNet Agent Toolkit C Edition is a rapid prototyping and development tool for building SNMP agents, TL1 agents, CLI agents, and multi-protocol agents in strict ANSI C language. For a detailed product overview, please see the Agent Toolkit C Edition product page on our Web site. AdventNet, Inc. 10

12 SNMP Utilities AdventNet SNMP Utilities consists of tools that enable SNMP management, which supports SNMPv1, SNMPv2c, and SNMPv3. MIB Browser is one such tool for browsing MIBs in the MIB tree. For a detailed product overview, please see the SNMP Utilities product page on our Web site. Simulation Toolkit The AdventNet Simulation Toolkit provides a comprehensive set of tools for creating a simulated environment. It not only supports setting up a simulated agent but also simulating an entire network in Windows, Linux, and Solaris. For a detailed product overview, please see the Simulation Toolkit product page on our Web site. AdventNet, Inc. 11

13 Contact Customer Support AdventNet, the Internet Management Infrastructure Company is the leading provider of open, scalable, extensible, and cross-platform management solutions for managing the Internet and e- commerce infrastructure. AdventNet's solutions range in scope from optical and core inter-networking management systems, cable modem, DSL, storage, security management to e-commerce application management. In each of these fast-growing markets, AdventNet is the leading provider of technology. During the evaluation phase, AdventNet provides support "at no cost". This support includes access to our product specialists for problem resolution, clarifications in documentation, and technical guidance. Please send in your queries. We guarantee to respond as quickly as possible to make your evaluation a success. AdventNet is eager to hear your comments, feedback, and suggestions that would help us improve our products. We give you the contact information of our Corporate Headquarters, Sales, and Technical support teams. Corporate Headquarters Web Site AdventNet Headquarters AdventNet Development Center AdventNet, Inc Gibraltar Drive Pleasanton, CA USA Phone : Fax : info@adventnet.com AdventNet Development Center (India) Private Limited Sree Narayana Complex 11, Sarathy Nagar Velachery, Chennai INDIA Phone : Fax : info@adventnet.com Sales For sales and product licensing inquiries, please use the contact information available in the following URL. You can also send to sales@adventnet.com at the AdventNet Headquarters main switchboard below. Phone: and request for Sales Fax: Technical Support For support and bug-report, please mail to snmp-support@adventnet.com. For those with support contracts, AdventNet provides priority support through with a reply usually within 24 hours. Please provide the following information while sending support mails. Release version of the product Operating System and version AdventNet, Inc. 12

14 Stack traces, if any Debug messages or hex dumps, if any CLASSPATH environment variable, if applicable Any other related information This would help us provide faster responses to your query. Feedback We welcome your feedback that will help us improve the APIs and provide future enhancements. Send your feedback to: AdventNet, Inc. 13

15 Technology Overview SNMP Overview Versions of SNMP SNMPv3 Overview MIB Overview This section gives an overview of SNMP and MIB basics. More Information If you would like to learn more about SNMP, we would recommend you taking a look at the following site for more information. SNMP FAQ available at AdventNet, Inc. 14

16 SNMP Overview A network provides ease of communication between computers. To use networks effectively, we need a set of rules by which all the networks should abide. The set of rules is called protocols. Simple Network Management Protocol (SNMP) is one among the various protocols that defines messages related to network management. In simple terms, SNMP is a primary protocol, used in the transfer of network management information between two or more network entities or nodes. Let us get to know more about SNMP and its features in the following sections. Need for SNMP Evolution Advantages Features Basic Operations Need for SNMP Network Management is all about keeping the network up and running, monitoring, and controlling network devices using conventional network technology. Local management and remote management are the two ways of managing a device connected to a network. Local management demands for a human manager where the managed object is situated. When the network devices are more and the network is widespread, management becomes tedious and impossible. Therefore, there arises the need to manage the network remotely. This is enhanced by SNMP. Using SNMP, one workstation running one or more management software applications can monitor management information collected by thousands of network devices. This information is used to establish the functioning of the network and also to identify the problems in the network. Evolution The ARPANET was the first research network sponsored by the United States Department of Defense (DOD), which connected many universities and government installations using leased telephone lines. When satellite and radio networks were added, trouble brewed and to resolve it, TCP/IP came into existence. This facilitated the connection of multiple networks in a seamless way. On Jan , TCP/IP became the only official protocol used by the DOD that marked a decline of the ARPANET. It was then Internet came into existence. Sometime in the mid-1980s, the growth of Internet was rapid, but there were no standardized network management models. Later, the three models were formulated: the High-Level Entity Management System (HEMS); the Common Management Information Protocol (CMIP) proposed by the Open Systems Interconnection (OSI), a group of International Standards Organization (ISO); and the Simple Gateway Monitoring Protocol (SGMP). CMIP over TCP was formed by the ISO as the actual network management protocol to be used for the Internet. In February 1988, the then Internet Architecture Board (IAB) convened an ad hoc committee to determine which of the three models should be used. It was then decided that CMOT would be a natural choice. The SGMP was the short-term solution before CMOT was distributed. For an effective transition of systems from SGMP to CMOT, a common network management framework had to be developed that would be used by both the models. This framework was named the Simple Network Management Protocol (SNMP). In April 1989, SNMP was promoted and given a recommended status as the de facto TCP/IP network management framework by the IAB. By then, AdventNet, Inc. 15

17 there were problems between CMOT and SNMP, which led to their independent developments. In May 1990, on reaching a consensus, IAB promoted SNMP as the standard network management protocol and a framework recommended for use on Internet and on all TCP/IP networks. Advantages As the name goes, the protocol is quite simple because it is easy to understand and the agent requires only minimal software. It is this simplicity that serves as a key reason for its widespread acceptance, besides being the chief Internet standard for network management. Implementing SNMP management in a networked device is far more straightforward than most other approaches to network management. Some of the benefits you derive on using SNMP are as follows. Standardized protocol: SNMP is the standard network management protocol for TCP/IP networks. Internet Protocols are open, nonproprietary standards developed through voluntary efforts by the Internet community, so is the SNMP that is actively maintained and all future enhancements to SNMP are based on existing protocol standards. Universal acceptance: All major vendors support SNMP. All SNMP-managed devices use the same type of management interface to support a common set of network management information. Portability: SNMP is independent of operating system and programming language. The functional design of SNMP is also portable and it defines a core set of operations that must function identically in all devices that support SNMP. Lightweight: SNMP facilitates the addition of management capability to a device without impacting the operation of the device or its performance. SNMP management may be added to a network device with very little increase in workload and demand on system resources. Extendibility: SNMP is a core set of operations that remain the same on all managed devices. SNMP has the capability of supporting any type of information on any type of device that may be part of any type of computer network. Widely deployed: SNMP is one of the most popular protocols in the protocol suite that every vendor is aware of. This popularity serves as one dominant factor for its wide deployment by the vendors. Features The three major components of the SNMP that form an integral part of its foundation are the network device, the agent and the manager. Network device: A network device or the Managed Object is a part of the network that requires some form of monitoring and management. Agent: An agent is a mediator between the manager and the device. The agent resides inside the network device. It collects the management information from the device and makes it available to the manager. It is to be understood that an agent is a program that resides in the device and is not a separate entity. A typical agent: Implements full SNMP protocol. Stores and retrieves management information as defined in the MIB. Collects and maintains information about its local environment. Asynchronously signals an event to the manager. Acts as a proxy for some non-snmp manageable network node. AdventNet, Inc. 16

18 Manager: A manager or management system is a separate entity that manages the agents from a remote place. This is typically a computer that is used to run one or more network management systems. Consider an organization having its branches in different geographical locations. Administration of all the computers present in different localities would be difficult. When the System Administrator s computer is installed with the manager and all other systems and devices across all the offices are installed with the agent, management becomes easier. The administrator has to just query the agent through its manger to know the functioning of the device. A typical manager: Implements the network management system. Implements full SNMP protocol. Queries agents, gets responses from agents, sets variables in agents, and acknowledges asynchronous events from agents. Communication Between the Manager and Agent: The communication between the manager and the agent in the network is enabled by means of Protocol Data Units (PDUs). These PDUs allow the manager to interact with the agent in the device. The extent of management possible depends on the data available to the manager from the agent. Before data can be transported across the network, it must be passed down the network mass and encapsulated. PDUs are encapsulated in the User Datagram Protocol (UDP). UDP is a connectionless transport protocol included in the TCP/IP suite and described in RFC 768. The SNMP network management is composed of three parts to which both the management applications and agents conform. They are: The protocol, which defines the functioning of the basic operations of SNMP and the format of the messages exchanged by management systems and agents. Structure of Management Information (SMI), which is a set of rules used to specify the format for defining managed objects or the devices that are accessed using SNMP. Management Information Base (MIB) is a collection of definitions, which define the properties of the managed object or the device. The MIB modules and the SMI are expressed using a text-based data description notation called as Abstract Syntax Notation One (ASN.1), which is an unambiguous description of data in an ASCII text format. The MIB data is conveyed across a network using SNMP messages, which are encoded using Basic Encoding Rules (BER). They are similar to SMI, but the messages are encoded in a binary format. Both the ASN.1 and BER are essential for the implementation of SNMP. Basic Operations SNMP is a request-and-response protocol. The basic SNMP operations performed are categorized as follows. Retrieving data Altering variables Receiving unsolicited messages Retrieving data: The manager sends a request to an agent to retrieve data by performing the following operations. GET: The GET operation is a request sent by the manager to the managed object. It is performed to retrieve one or more values from the managed objects. GETNEXT: This operation is similar to the GET operation. The significant difference is that the GETNEXT operation retrieves the value of the next OID in the tree. GETBULK: The GETBULK operation is used to retrieve voluminous data from large table. AdventNet, Inc. 17

19 Altering variables:at times,the manager might want to change the value of a variable. SET: This operation is used by the managers to modify the value of the network device. Receiving unsolicited messages: The agent, when faced by problems in the transmission of message, responds to the manager by sending unsolicited messages by using the TRAP operation. AdventNet, Inc. 18

20 Versions of SNMP Overview of the Versions SNMPv1 and SNMPv2c SNMPv1 and SMPv3 SNMPv1, SNMPv2c, and SNMPv3 Internet Engineering Task Force (IETF) publishes documents that are called Requests For Comments (RFCs). These documents specify standards, operational practices, opinions, humor, etc. for the Internet protocol suite. The different versions of SNMP are the SNMPv1, SNMPv2c, and SNMPv3. The following is a snippet of each version and it is followed by a detailed comparative overview of the versions. SNMPv1: This is the first version of the protocol, which is defined in RFCs 1155 and SNMPv2c: This is the revised protocol, which includes enhancements of SNMPv1 in the areas of protocol packet types, transport mappings, MIB structure elements but using the existing SNMPv1 administration structure ("community based" and hence SNMPv2c). It is defined in RFC 1901, RFC 1905, and RFC SNMPv3: SNMPv3 defines the secure version of the SNMP. SNMPv3 also facilitates remote configuration of the SNMP entities. It is defined by RFC 1905, RFC 1906, RFC 2571, RFC 2572, RFC 2574, and RFC The AdventNet SNMP API distribution supports all the three versions of the SNMP. The communication and MIB portions of the AdventNet SNMP API conform to the following Internet RFC specifications. SNMPv1 - RFC1155 and RFC1157 SNMPv2c - RFC1901 and RFC1907 SNMPv3 - RFC2571 and RFC2572 SNMPv3 USM - RFC2574 SNMPv3 VACM - RFC2575 Overview of SNMP Versions SNMPv1 was the standard version of SNMP. The SNMPv2 was created as an update of SNMPv1 with several features. The key enhancements of SNMPv2 are focused on the SMI, Manager-tomanager capability, and protocol operations. The SNMPv2c combined the community-based approach of SNMPv1 with the protocol operation of SNMPv2 and omitted all SNMPv2 security features. One notable deficiency in SNMP was the difficulty in monitoring networks, as opposed to nodes on networks. A substantial functional enhancement to SNMP was achieved by the definition of a set of standardized management objects referred to as the Remote Network Monitoring MIB (RMON MIB) objects. Another major deficiency in SNMP was the complete lack of security facilities. The development of SNMPv3 was based on the security issues. SNMPv3 defines two security-related capabilities, namely USM and VACM. SNMPv1 and SNMPv2c SNMPv2c provides several advantages over SNMPv1. SNMPv2c has expanded data types of 64-bit counter. It calls for improved efficiency and performance by introducing the GETBULK operation. Confirmed event notification is sought by the introduction of the Inform operator. Enhanced error AdventNet, Inc. 19

21 handling approach, improved sets, and a fine tuned Data Definition Language are some of the advantages of SNMPv2c over the SNMPv1. SNMPv1 and SNMPv3 The SNMPv1 framework distinguishes between application entities and protocol entities. In SNMPv3, these are renamed as applications and engines respectively. The SNMPv1 framework also introduces the concept of an authentication service supporting one or more authentication schemes. In SNMPv3, the concept of an authentication service is expanded to include other services, such as privacy. The SNMPv1 framework introduces access control based on a concept called an SNMP MIB view. The SNMPv3 framework specifies a fundamentally similar concept called view-based access control. SNMPv1, SNMPv2c, and SNMPv3 Both the versions v1 and v2c lack the following security-related features. Authentication Privacy Authorization and access control Remote configuration and administration capabilities SNMPv3 was formed mainly to address the deficiencies related to security and administration. AdventNet, Inc. 20

22 SNMPv3 Overview Comparative Overview of SNMPv3 with SNMPv1 and SNMPv2c SNMPv3 Message Format Due to lack of security with the use of SNMP, network administrators were using other means, such as telnet for configuration, accounting, and fault management. SNMPv3 addresses issues related to the large-scale deployment of SNMP, accounting, and fault management. Currently, SNMP is predominantly used for monitoring and performance management. SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the SNMP entities. Primary Goals of SNMPv3 1. To verify that each received SNMP message has not been modified during its transmission through the network. 2. To verify the identity of the user on whose behalf a received message claims to have been generated. 3. To detect received messages that contain management information, whose time of generation was not recent. 4. To assure that the contents of each received message are protected from disclosure. Comparative Overview of SNMPv3 with SNMPv1 and SNMPv2c SNMPv1 and SNMPv2c have a wide deployment base covering the following. A platform-independent data definition syntax - A subset of ASN.1 A platform-independent data transfer notation - BER Communication between the peer entities - SNMP communication protocol with message formats, message types, etc. o Message contains the SNMP version o Message contains the community string which is used to provide some security Guidelines for definition of management data - SMI Management data definition repository - The MIB files SNMPv3 provides a secure environment for the management of systems covering the following. Identification of SNMP entities to facilitate communication only between known SNMP entities - Each SNMP entity has an identifier called the SNMPEngineID, and SNMP communication is possible only if an SNMP entity knows the identity of its peer. Traps and Notifications are exceptions to this rule. Support for security models - A security model may define the security policy within an administrative domain or an intranet. SNMPv3 contains the specifications for USM. Definition of security goals where the goals of message authentication service include protection against the following. o Modification of Information - Protection against some unauthorized SNMP entity altering in-transit messages generated by an authorized principal. o Masquerade - Protection against attempting management operations not authorized for some principal by assuming the identity of another principal that has the appropriate authorizations. o Message Stream Modification - Protection against messages getting maliciously reordered, delayed, or replayed to effect unauthorized management operations. o Disclosure - Protection against eavesdropping on the exchanges between SNMP engines. AdventNet, Inc. 21

23 Specification for USM - USM consists of the general definition of the following communication mechanisms available. o Communication without authentication and privacy (NoAuthNoPriv). o Communication with authentication and without privacy (AuthNoPriv). o Communication with authentication and privacy (AuthPriv). Definition of different authentication and privacy protocols - Currently, the MD5 and SHA authentication protocols and the CBC_DES privacy protocols are supported in the USM. Definition of a discovery procedure - To find the SNMPEngineID of an SNMP entity for a given transport address and transport endpoint address. Definition of the time synchronization procedure - To facilitate authenticated communication between the SNMP entities. Definition of the SNMP framework MIB - To facilitate remote configuration and administration of the SNMP entity. Definition of the USM MIBs - To facilitate remote configuration and administration of the security module. Definition of the VACM MIBs - To facilitate remote configuration and administration of the access control module. The SNMPv3 focuses on two main aspects, namely security and administration. The security aspect is addressed by offering both strong authentication and data encryption for privacy. The administration aspect is focused on two parts, namely notification originators and proxy forwarders. SNMPv3 defines two security-related capabilities, namely the USM and VACM. USM provides authentication and privacy (encryption) functions and operates at the message level. VACM determines whether a given principal is allowed access to a particular MIB object to perform specific functions and operates at the PDU level. SNMPv3 Message Format The SNMPv3 message consists of the following fields. 1. msgversion - This field contains the SNMP message version. A value 0 is an SNMPv1 message, 1 is an SNMPv2c message, 2 is an SNMPv2 message, and 3 is an SNMPv3 message. The value of message version is used to choose between the different message processing models (SNMPv1, SNMPv2c, or SNMPv3) available in the SNMP engine/entity. The following fields are part of the SNMPv3 message and are not available in the SNMPv1 or SNMPv2c message. 2. msgid - This field contains the SNMP message identifier. This is the unique ID associated with the message. The msgid field is different from the reqid field available in the PDU. It is possible that a received PDU that is part of a message cannot be decoded due to security parameters between the SNMP entities. The msgid is used to relate the request with a response during a transaction. 3. msgmaxsize - This field gives the maximum size of the message which the requesting SNMP entity can accept. 4. msgflags - This field contains the message security level. The bit 0 of msgflags indicates whether a message is authenticated. The bit 1 indicates whether a message uses privacy. The bit 2 indicates whether a report PDU is expected for the message (in case the message is dropped or a response cannot be generated). 5. msgsecuritymodel - This field indicates the security model used to generate the message. It has a value of 3 when USM is used. 6. msgengineid - This field has the SNMPEngineID of the authoritative SNMP entity involved in the transaction. When a request PDU is generated from an SNMP engine, the remote peer (agent for Get request and manager for Trap request) is the authoritative SNMP entity. 7. msgengineboots - This field indicates the number of times the authoritative SNMP entity has booted. This field is used in authenticated message to validate the timeliness of a message. AdventNet, Inc. 22

24 8. msgenginetime - This field indicates the time since the authoritative SNMP entity has been rebooted. This field is used in authenticated messages to validate the timeliness of a message. 9. msgusername - This field contains the principal who originated the request. The fields msgusername and the msgengineid are used to locate the security data associated with the message from the USM database. This security data is used to authenticate and process the message. 10. msgsecurityparams - This field contains the security parameters that are security model dependent. It contains the authentication parameters and the privacy parameters for USM. For an AuthPriv message, the authentication parameter has the digest computed for the message using the authentication protocol applicable for the USM entry and the privacy parameter has the salt generated, while encrypting the message using the privacy protocol applicable to the USM entry. 11. contextengineid - Within an administrative domain, the contextengineid uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextname. 12. contextname - A contextname is used to name a context. Each contextname must be unique within an SNMP entity. 13. PDU - The SNMP PDU (Protocol Data Unit) is used for communication between the SNMP entities. PDU encapsulates the SNMP request ID, error status, variable bindings, and so on. There are different types of PDUs, such as GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, Trap-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, and Report-PDU. The exact format of the PDU depends on the type of the PDU. AdventNet, Inc. 23

25 MIB Overview Management Information Bases (MIBs) are a collection of objects or definitions that define the properties of the managed objects. To enable the SNMP manager or management application to operate intelligently on the data available on the managed device, the manager needs to know the names and types of objects in the device. This is made possible by the MIB modules, which are specified in the MIB files usually provided with managed devices. It should be understood that MIB is only an abstraction of data and not a physical database or a physically executable object. The following sections are dealt with in detail in this topic: Evolution Object Identifiers MIB Objects Object Identifiers with Instance Indexes SMI Evolution IAB recommended a two-pronged strategy for the development of Internet network management standards. The SNMP was used in the short run and the use of OSI network management framework was examined in the long run. On this basis, two documents were created, which defined the SMI and MIB. The documents were framed to be compatible with both the SNMP and OSI network management framework. In the short run, this strategy proved successful. However, the report of the Second Ad Hoc Network Management Review Group stated that the SNMP and OSI framework did not fulfill the exact requirements. Therefore, both were suspended which in due course led to the drafting of MIB II. MIB-I was the first version issued as RFC1156. MIB-II is a super set of MIB-I with some additional objects and groups and is defined in RFC1213. Object Identifiers The SNMP manager or the management application uses a well-defined naming syntax to specify the variables to the SNMP agent. Object names in this syntax are called Object Identifiers (Object IDs or OIDs). OIDs are series of numbers that uniquely identify an object to an SNMP agent. OIDs are arranged in a hierarchical, inverted tree structure. The OID tree begins with the root and expands into branches. Each point in the OID tree is called a node and each node will have one or more branches, or will terminate with a leaf node. The format of OID is a sequence of numbers with dots in between. There are two roots for Object Identifiers, namely iso and ccit. iso starts with.1 and ccit starts with.0. Most Object Identifiers start with , where 1=iso, 3=org, 6= dod, 1 = internet. The internet subtree branches into mgmt and private. To understand the concept of relative and absolute Object Identifiers, let us consider the AdventNet Object Identifier It specifies the path from the root of the tree. The root does not have a name or a number but the initial 1 in this OID is directly below root. This is called an absolute OID. However, a path to the variable may be specified relative to some node in the OID tree. For AdventNet, Inc. 24

26 example, specifies the syscontact object in the system group, relative to the internet ( ) node in the OID tree. This is called a relative OID. MIB Objects The internet subtree branches into mgmt and private. All the standard MIBs are under mgmt, while the private MIBs are under the private.enterprises subtree. The standard MIBs are those that have been approved by the IAB. Equipment and software vendors define the private MIBs unilaterally. A branch within the private.enterprises subtree is allocated to each vendor who registers for an enterprise Object Identifier. The distinction between the standard and private MIBs is based on how the variables are defined. The best example of a standard MIB is the RFC1213-MIB (also known as MIB-II). It is a MIB module which is typically supported by all SNMP agents on TCP/IP-enabled devices or systems. This MIB file contains a description of the object hierarchy on the managed device, as well as the Object ID, syntax, and access privileges for each variable in the MIB. To know more on RFC, visit One key aspect of MIBs is that, only the types of objects on the managed device are specified by the MIB and not the specific objects (or instances). For example, ifinoctets in RFC 1213-MIB specifies a type of object, for number of input octets on an interface, but the specific objects or instances of that type are specified as ifinoctets.1, ifinoctets.2, etc., depending on the number of interfaces. When specifying an object to the SNMP agent, a proper Object ID, which includes the instance, needs to be used by the manager. When not properly specified, the agent responds with a "No such variable" error. Object Identifier with Instance Indexes To obtain values of objects from the agent, you need to specify the instance of the object. Appending an instance index to the object identifier specifies the instance of an object. For example, the last 0 in:.iso.3.dod.1.mgmt.mib-2.1.sysuptime.0 is the instance index. An instance index of "0" (zero) specifies the first instance, "1" specifies the second instance, and so on. Since sysuptime is a scalar object, it has only one instance. Therefore, an instance index of zero is always specified when retrieving the value of a scalar object. An instance index higher than 0 can only be used in the case of columnar objects (in table), which can have multiple instances. SMI Structure of Management Information (SMI) is a set of rules used to specify the format for defining managed objects. SMI describes the MIB naming tree that is used to identify managed objects and defines the branch of the MIB tree where SNMP managed objects reside. The SMI does not define a managed object but describes a format for defining a managed object. The two versions of SMI are SMIv1 and SMIv2. SMIv1 is defined by RFC1155, RFC1212, and RFC1215 and the SMIv2 is defined by RFC1902, RFC1903, and RFC1904. SMIv1 is a backward compatible update of SMIv1. This means that it is possible to convert an SMIv2 MIB to SMIv1 except for objects whose data type is Counter64. But when it comes to converting SMIv1 to SMIv2, there is no mechanical way of doing it because there is more information in the SMIv2 than in SMIv1. Also, the SMIv2 format contains constructs to define requirement specifications and implementation specifications, which do not form a part of the SMIv1. AdventNet, Inc. 25

27 Release Notes Issue in closing the session on calling session.close() is fixed. 100% cpu utilization on closing the session is fixed. Package changes in the product as per.net standard (refer to apidocs). AdventNet SNMP API.NET is tested with Microsoft Visual Studio.NET Framework 2.0 AdventNet, Inc. 26

28 Installation Guide System Requirements Installing SNMP API -.NET Edition Package Structure Installing Service Pack This section explains the system requirements and installation details of AdventNet SNMP API. AdventNet, Inc. 27

29 System Requirements Hardware Requirements Software Requirements Hardware Requirements The following table describes the suggested minimum configuration of the system that runs the product. Processor Type Processor Speed Memory Disk Space Pentium 500 MHz 128 MB RAM 150 MB Software Requirements Minimum requirement of.net Framework version 1.1 redistributable package to run applications developed using the.net Framework, which can be downloaded from Minimum requirement of Microsoft Visual J#.NET version 1.1 Redistributable Package to run your Visual J#.NET applications on a computer that already has the Microsoft.NET Framework version 1.1 installed. This can be downloaded from 7D674D2C7CA1&displaylang=en Note: The.NET Framework version 1.1 should be installed before installing the Visual J#.NET version 1.1 AdventNet, Inc. 28

30 Installing SNMP API.NET Edition The AdventNet SNMP API -.NET Edition is supplied as zip file. Download and extract the zip to install the product. AdventNet, Inc. 29

31 Package Structure The directory structure and the files present under the <AdventNet/SNMPAPI> distribution are provided below. All the files are extracted under <AdventNet/SNMPAPI>directory. The following image displays the package structure of AdventNet SNMP API. Directory/File bin conf examples tutorials help lib mibs COPYRIGHT LICENSE_AGREEMENT Description Contains the Update Manager utility for installing the service packs. Contains the config files Contains the example applications if SNMP and MIB applications. Contains the simple application tutorials. Contains the help documentation Contains the AdventNetMibsAPI.dll and AdventNetSnmp.dll. Contains the standard MIB files Copyright of the product Product License Agreement AdventNet, Inc. 30

32 Installing Service Pack AdventNet periodically provides service packs or patches which fix certain bugs or provide new features and update some files related to documentation. These patch files can be downloaded from the AdventNet Web Site and updated with the base release. AdventNet SNMP API provides you a tool, UpdateManger, to install the service packs. During the installation of a patch, the corresponding files are updated in the product installation directory and certain bugs are fixed. UpdateManager can be used to perform the following functions: Install the Service Pack View the Installed Service Pack Versions Uninstall the Service Pack Install the Service Pack To install the service pack, follow the steps given below: 1. Invoke the UpdateManager by executing the updatemanager.bat located in <SNMPAPI_Home>\bin directory. The options to install, uninstall, view installed Service Pack versions, and exit will be shown and you will be prompted to enter your choice. 2. Enter i to install a new Service Pack. The screen will prompt you to enter the path where the new Service Pack is located. 3. Enter the absolute path where the new Service Pack (.ppm file) is placed. You will see the update happening and the message Service Pack installed successfully will be shown. The screen will prompt you to mention whether you want to continue. 4. Choose y to go to the first step. 5. Choose n to close the application View the Installed Service Pack Versions 1. Invoke the UpdateManager by executing the updatemanager.bat located in <SNMPAPI_Home>\bin directory. The options to install, uninstall, view installed Service Pack versions, and exit will be shown and you will be prompted to enter your choice. 2. Enter v to view the details of the already installed Service Packs. The screen will show you the list of Service Packs installed in the product. The screen will prompt you to mention whether you want to continue. 3. Choose y to go back to the first step, choose n to close the application. Uninstall the Service Pack To uninstall the service pack, follow the setps given below: 1. Invoke the UpdateManager by executing the updatemanager.bat located in <SNMPAPI_Home>\bin directory. The options to install, uninstall, view installed Service Pack versions, and exit will be shown and you will be prompted to enter your choice. 2. Enter u to uninstall a Service Pack. The screen will show you the list of installed Service Packs and prompt you to select the one to be uninstalled. 3. Enter the number corresponding to the Service Pack to be uninstalled. You will see the uninstallation happening and the message "Uninstalled successfully" will be shown. The screen will prompt you to mention whether you want to continue. 4. Choose y to go back to the first step, choose n to close the application. AdventNet, Inc. 31