categorized into eight different groups, totaling 114 managed objects. More groups were added to define MIB-II, which now replaces MIB-I. All managed objects in the SNMP environment are arranged in a hierarchical or tree structure. The leaf objects of the tree, which are the elements that appear at the bottom of the diagram, are the actual managed objects. Each managed object represents some resource, activity or related information that is to be managed. A unique object identifier, which is a number in dot notation, identifies each managed object. Each object identifier is described using abstract syntax notation (ASN.1). SNMP uses these object identifiers to identify the MIB variables to retrieve or modify. Objects that are in the public domain are described in MIBs introduced in Request for Comments (RFCs). They are readily accessible at: http://www.ietf.org All vendors are encouraged to make their MIB definitions known. Once an assigned enterprise value has been given, the vendor is responsible for creating and maintaining sub-trees.
Content 6.2 Network Management 6.2.6 SNMP protocol The agent is a software function embedded in most networked devices, such as routers, switches, managed hubs, printers, and servers. It is responsible for processing SNMP requests from the manager. It is also responsible for the execution of routines that maintain variables as defined in the various supported MIBs. Interaction between the manager and the agent is facilitated by the Simple Network Management Protocol (SNMP). The term simple comes from the restricted number of message types that are part of the initial protocol specification. The strategy was designed to make it easier for developers to build management capabilities into network devices. The initial protocol specification is referred to as SNMPv1 (version 1). There are three types of SNMP messages issued on behalf of an NMS. They are GetRequest, GetNextRequest and SetRequest. All three messages are acknowledged by the agent in the form of a GetResponse message. An agent may issue a Trap message in response to an event that affects the MIB and the underlying resources. The development of SNMPv2c addressed limitations in SNMPv1. The most noticeable enhancements were the introduction of the GetBulkRequest message type and the addition of 64-bit counters to the MIB. Retrieving information with GetRequest and GetNextRequest was an inefficient method of collecting information. Only one variable at a time could be solicited with SNMPv1. The GetBulkRequest addresses this weakness by receiving more information with a single request. Secondly, the 64-bit counters addressed the issue of counters rolling over too quickly, especially with higher speed links like Gigabit Ethernet. The management entity is also referred to as the manager or network management station (NMS). It is responsible for soliciting information from the agent. The solicitations are based on very specific requests. The manager processes the retrieved information in a number of ways. The retrieved information can be logged for later analysis, displayed using a graphing utility, or compared with preconfigured values to test if a particular condition has been met. Not all manager functions are based on data retrieval. There is also the ability to issue changes of a value in the managed device. This feature enables an administrator to configure a managed device using SNMP. The interaction between the manager and the managed device does introduce traffic to the network. Caution should be taken when introducing managers on to the network. Aggressive monitoring strategies can negatively affect network performance. Bandwidth utilizations will go up, which may be an issue for WAN environments. Also, monitoring has a performance impact on the devices being monitored, since they are required to process the manager requests. This processing should not take precedence over production services. A general rule is that a minimum amount of information should be polled as infrequently as possible. Determine which devices and links are most critical and what type of data is required. SNMP uses UDP as a transport protocol. Since UDP is connectionless and unreliable, it is possible for SNMP to lose messages. SNMP itself has no provision for guarantee of delivery, so it is up to the application using SNMP to cope with lost messages. Each SNMP message contains a cleartext string, called a community string. The community string is used like a password to restrict access to managed devices. SNMPv3 has addressed the security concerns raised by tranmitting the community string in cleartext. An example of what the SNMPv2c message looks like is illustrated in Figure . A detailed presentation of the protocol can be found in the Internet standard RFC1905. The fact that the community string is cleartext is no surprise to anyone who has studied the Internet Protocol (IP) protocol suite. All fields specified in the protocol suite are cleartext, except for security authentication and encryption specifications. The community string was essentially a security placeholder until the SNMPv2 working group could ratify security mechanisms. The efforts were referred to the SNMPv3 working group. All SNMP-based management applications need to be configured to use the appropriate community strings. Some organizations frequently change the community string values to reduce the risk of malicious activity from the unauthorized use of the SNMP service. In spite of the weakness associated with community-based authentication, management strategies are still based on SNMPv1. Cisco devices do support SNMPv3 message types and the increased security capabilities, but most management software applications do not support SNMPv3. SNMPv3 supports the concurrent existence of multiple security models.
Content 6.2 Network Management 6.2.7 Configuring SNMP In order to have the NMS communicate with networked devices, the devices must have SNMP enabled and the SNMP community strings configured. These devices are configured using the command line syntax described in the following paragraphs. More than one read-only string is supported. The default on most systems for this community string is public. It is not advisable to use the default value in an enterprise network. To set the read-only community string used by the agent, use the following command: Router(config)#snmp-server community string ro More than one read-write string is supported. All SNMP objects are available for write access. The default on most systems for this community string is private. It is not advisable to use this value in an enterprise network. To set the read-write community string used by the agent, use the following command: Router(config)#snmp-server community string rw There are several strings that can be used to specify location of the managed device and the main system contact for the device. Router(config)#snmp-server location text
Router(config)#snmp-server contact text These values are stored in the MIB objects sysLocation and sysContact. Web Links Configuring SNMP http://www.cisco.com/en/US/products/hw/ switches/ps628