Managing Your OSPF Network
Access Lists for SNMP Access lists can be used to prevent SNMP messages from traversing certain router interfaces, and therefore, from reaching certain network devices. For example, this feature can be used to prevent other NMSs from altering the configuration of a given router or router group. Access lists are extremely useful in complex internetworks and are implemented across the majority of Cisco’s supported protocols. Multiple Community Strings For SNMPv1 operation, Cisco permits multiple community strings so that a router can belong to multiple communities. Further, community strings can be either read-only or read/write. This feature provides further security by restricting the capability to alter the configuration of Cisco devices to those that have the community string assigned the read/write capability. Traps Cisco’s SNMP implementation allows trap messages to be directed to multiple management stations. This capability allows virtually instantaneous notification of network problems across the internetwork. If, for example, packet collisions are excessive in one area of the network, management stations throughout the internetwork can be notified immediately. Cisco provides two extra traps useful in internetwork environments: reload and tty connection-closed. These traps serve to alert network administrators that routers are being reloaded (which, in turn, may indicate more serious problems) and that virtual terminal connections are closing. Additional Resources on SNMP OperationThis section gave you a very brief overview of Network Management and SNMP. There are other areas concerning the operation of SNMP that you might need to understand or tasks you need to know how to perform with SNMP. That information is beyond the scope of this book although this section will provide you with some additional resources. There are also additional resources available in Chapter 12 and the bibliography at the end of the book. SNMP Commands The following URL is a link to the commands used to configure SNMP parameters, such as management station and traps. http://www.cisco.com/univercd/cc/td/doc/product/access/acs_fix/750/700cr/700crsnm.htm#xtocid109576 The following commands are covered in this section; reset SNMP trap host, set SNMP contact, set SNMP location, set SNMP trap, set SNMP trap host, and show SNMP. Configuration Considerations for SNMP Inform Requests or Traps The SNMP Inform Requests feature allows routers to send inform requests to SNMP managers. Routers can send notifications to SNMP managers when particular events occur. For example, an agent router might send a message to a manager when the agent router experiences an error condition. SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send any acknowledgment when it receives a trap. The sending device cannot determine if the trap was received. However, an SNMP manager that receives an INFORMREQUEST acknowledges the message with an SNMP response PDU. If the manager does not receive an INFORMREQUEST, it does not send a response. If the sender never receives a response, the INFORMREQUEST can be sent again. Thus, informs are more likely to reach their intended destination. Management Information Base (MIB)From the perspective of a network manager, network management takes place between two major types of systems: those in control, called managing systems, and those observed and controlled, called managed systems. The most common managing system is called a Network Management System (NMS). Managed systems can include hosts, servers, or network components such as routers or intelligent repeaters. To promote interoperability, cooperating systems must adhere to a common framework and a common language called a protocol. In the Network Management Framework, that protocol is the Simple Network Management Protocol (SNMP). The exchange of information between managed network devices and a robust Network Management System (NMS) is essential for reliable performance of a managed network. Because some managed devices have a limited capability to run management software, most of the computer processing burden is assumed by the NMS. The NMS runs the network management applications, such as CiscoWorks or CiscoView, which present management information to network managers and other users. In a managed device, specialized low-impact software modules, called agents, access information about the device and make it available to the NMS. Managed devices maintain values for a number of variables and report those, as required, to the NMS. For example, an agent might report such data as the number of bytes and packets in and out of the device, or the number of broadcast messages sent and received. In the Internet Network Management Framework, each of these variables is referred to as a managed object. A managed object is anything that can be managed, anything that an agent can access and report back to the NMS. All managed objects are contained in the Management Information Base (MIB), a database of the managed objects. An NMS can control a managed device by sending a message to an agent of that managed device requiring the device to change the value of one or more of its variables. The managed devices can respond to commands such as SET or GET commands, the former of which are used to control the device; the latter of which are used by the NMS to monitor the device. Management Information Base (MIB) ComponentsA Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network management protocol such as SNMP. MIBs are composed of managed objects and are identified by object identifiers. MIB data is organized into a tree structure as illustrated in Figures 9-5, 9-10, and 9-11. All the management for Internet (1) (that is, networking) devices fall under the branch labeled Internet. Within that branch are several other branches, which are as follows (refer to Figure 9-5):
|
EAN: 2147483647
Pages: 200