The Continuing Evolution of OSPF
Agent An agent is a network management software module that resides in a managed device. It has local knowledge of management information and translates that information into a form compatible with SNMP. To be a managed device, each device must have firmware in the form of code. This firmware translates the requests from the SNMP manager and responds to these requests. The software, or firmware, not the device itself, is referred to as an agent. The Management Information Base The MIB (Management Information Base) is an established database of the hardware settings, variables, memory tables, or records stored within files; these are called data elements. These data elements make up a configuration, status, and statistical information base used to define the functionality and operational capacity of each managed device. That information is referred to as a MIB. Each data element is referred to as a managed object. These managed objects are comprised of a name, one or more attributes, and a set of operations that can be performed on the managed object. SNMPv2: A Brief IntroductionWith the growth of networks and the Internet throughout the country and the world, the need to expand SNMP quickly became apparent. The result was SNMPv2, and as technology changes it is beginning to be revised so that soon we will have SNMPv3. Problems arose in association with the SETREQUEST command in SNMPv1. SNMP Managers, either intentionally or unintentionally, were corrupting the configuration parameters of managed objects; this was seriously interfering with network operations. Seeing a need to fix this security problem, in the fall of 1992 the IETF established two working groups to define enhancements to SNMPv1. The first group was to focus primarily on designing security functions, and the second group directed its combined efforts to defining enhancements to the SNMP protocol. What the two groups came up with was SNMPv2. This second version alleviated the security problems by adding encryption and authentication countermeasures. In addition to the security fixes, SNMPv2 incorporated a manager-to-manager capability and two new PDUs: GETBULKREQUEST and INFORMREQUEST. The manager-to-manager capability enables SNMP to support distributed network management, where one network management system (NMS) can report management information to another network management system (NMS). The additional two PDUs added in SNMPv2 are: GETBULKREQUEST and INFORMREQUEST. They supplement the five commands already in SNMPv1: GETREQUEST, GETNEXTREQUEST, SETREQUEST, RESPONSE, and TRAP. Finally, to support manager-to-manager interaction SNMPv2 added Alarm and Event groups to the SNMPv2 MIB. The Alarm group permits the managers to establish thresholds that, if breached, will trigger an alarm. The Event group specifies when a Trap should be issued based on one or more MIB values. These two groups also support the manager-to-manager capability that was introduced in version 2. SNMPv2 Operational EnhancementsYou might have thought that the GETBULKREQUEST is very similar to the GETNEXTREQUEST. This is true, but with one major exception. The GETBULKREQUEST tells the agent to return as much data as can fit into a response message starting with the next largest value than the requested managed object instance. The GETBULKREQUEST has two very important features:
The INFORMREQUEST supports the use of a hierarchical system of NMSs, and it also standardizes communication between NMSs. The enterprise network manager can establish the INFORMREQUEST command, so when certain criteria are met and thresholds are exceeded, an “event” is generated in which a transmission of an INFORMREQUEST command informs another NMS of the threshold violation. The Enterprise network manager can also program the various NMSs under his control to broadcast the INFORMREQUEST command to one or more NMSs. With the advent of this manager-to-manager communication and the use of alarms, one Enterprise Network Management Station (ENMS) can be monitored at all times while the others are programmed to report information to the ENMS only during those times when they are unattended. Security Enhancements The authentication protocol is designed to reliably identify the integrity of the originating SNMPv2 party. It consists of authentication information required to support the authentication protocol used. The privacy protocol is designed to protect information within the SNMPv2 message from disclosure. Only authenticated messages can be protected from disclosure. In other words, authentication is required for privacy. The SNMPv2 specifications discuss two primary security protocols: one for authentication and one for privacy. These are the Digest Authentication Protocol and the Symmetric Privacy Protocol. The Digest Authentication Protocol verifies that the message received is the same one that was sent. Data integrity is protected using a 128-bit message digest calculated according to the Message Digest 5 (MD5) algorithm. The digest is calculated at the sender and enclosed with the SNMPv2 message. The receiver verifies the digest. A secret value, known only to the sender and the receiver, is prefixed to the message. After the digest is used to verify message integrity, the secret value is used to verify the message’s origin. To help ensure message privacy, the Symmetric Privacy Protocol uses a secret encryption key known only to the sender and the receiver. Before the message is authenticated, this protocol uses the Data Encryption Standard (DES) algorithm to effect privacy. DES is a documented National Institute of Standards and Technology (NIST) and American National Standards Institute (ANSI) standard. Additional SNMPv2 Resources You can find general information about SNMPv2 at the following URL: http://www.ietf.org. You can find Cisco-specific SNMPv2 information at the following locations:
|
EAN: 2147483647
Pages: 200