Network management is the process of managing faults, controlling configurations, monitoring performance, ensuring security, and accounting for activity on a data network. Each of these tasks is necessary to have complete control of a data network environment, which is an essential component of an organization. The ISO Network Management Forum has defined network management as the sum of all activities required to perform fault, configuration, performance, security, and accounting management for a data network.
Network management platforms are software systems designed to perform the activities of network management. Some examples of network management platforms are Hewlett-Packard OpenView, Cabletron Spectrum, Sun Solstice Enterprise Manager, IBM NetView/ AIX, and CiscoWorks2000. Network management platforms provide the software architecture for network management applications that perform a wide variety of tasks. They cannot be grouped into a single category. Some present a network map and check on the status of all network devices, providing a fault management function. Some performance management tools plot network link utilization and send warnings if errors occur on a LAN interface. Still others look for network security issues and send warnings via e-mail or alphanumeric pagers .
Network management applications communicate with software on network devices called agents . The manager-to-agent communication enables the manager to gather a standard set of information, which is defined in a management information base (MIB). Each piece of information that exists in a MIB is called an object. A MIB contains objects useful to managers for accomplishing the tasks of network management. Figure 7-2 shows the relationship between a manager and an agent.
Figure 7-2. In a Network Management Protocol, the Manager Requests and Sets Information in the MIB, and the Agent Sends Trap Messages, Which Contain Information About Device Events to the Manager
The two types of MIBs are standard and proprietary. Standard MIBs, such as MIB-II (RFC 1213), provide basic objects applicable to nearly all devices on a data network. For example, MIB-II contains system information about a device, such as its uptime and name , interface-specific traffic and error counters, and IP protocol information. Technology-specific MIBs, which are standard, are for protocols such as Frame Relay (RFC 1285) or Token Ring (RFC 1315). They contain objects relating to a specific technology on a network device. Vendor-specific MIBs, which are proprietary, define objects specific to a single vendor's network devices.
Network management applications gather MIB information from devices and change the behavior of those network devices through the use of a network management protocol. The Simple Network Management Protocol (SNMP), defined in RFC 1157, is a standard network management protocol and is the most widely used. SNMP uses UDP at the transport layer and IP at the network layer. Proprietary network management protocols exist as well, and some vendors have implemented them in their network devices.
Communication between an SNMP agent and a manager occurs with five packet types:
A Get-Request is a message from the manager to an agent requesting a set of specific MIB objects, such as a device's name, location, number of physical interfaces, and so on. A Get-Next-Request is a message from the manager to an agent requesting the next piece of tabular data, as referenced from a specific point in the MIB. This message type is useful in MIB table traversal and in the retrieval of a table such as the IP routing table. A Set-Request is a message requesting the agent to change the value of a specific MIB object, such as changing the status of an interface on a device. An agent responds to each Get-Request, Get-Next-Request, or Set-Request by sending a Get-Response to the manager that contains the requested values of the MIB objects or shows the value of a MIB object that has been changed. A Trap message is an unsolicited message from the agent to the manager about an event.
Each SNMP agent is set up with a verification string called a community string. The community string is included in each request from the manager to get or set MIB information. The agent verifies it before responding. A community string is weak authentication encoded in ASCII. It should not be relied upon as a sole way of securing SNMP access to an agent. (See the tip that appears later in this section for suggestions on improving security.)
The Cisco IOS global configuration command snmp-server community configures the agent with the community string. An option of this command enables you to stipulate that the community string is applicable to read-only or read-write messages to the agent. Get-Request and Get-Next-Request messages are read-only; Set-Request messages are read-write. The keywords used to stipulate read-only and read-write are RO and RW, respectively. The default read-only community string for many network management applications is public, and the default read-write is often private. A final option of this global command is to specify an IP standard access list of hosts permitted to query the agent using the valid community strings.
In the following example, the Singapore router is configured for the RO community string Zipnet and the RW community string ZIPprivate. IP access-list 2 also is defined to permit the network manager at IP address 18.104.22.168 to use either community string. The access list number is the last optional parameter on both snmp-server community commands in the following example:
Singapore# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Singapore(config)# access-list 2 permit 22.214.171.124 Singapore(config)# snmp-server community Zipnet RO 2 Singapore(config)# snmp-server community ZIPprivate RW 2 Singapore(config)#^ Z
To augment the security of the SNMP agent on your IOS device, we suggest that you set up different community strings for RO and RW access. Furthermore, we recommend that you limit the hosts that can query your IOS devices via SNMP by using the access-list option to the snmp-server community command.
You must configure your Cisco IOS device to send SNMP Trap messages. The six standard SNMP Trap messages that all agents send are defined in RFC 1157:
A coldStart signifies that the agent has just been started. The warmStart Trap indicates that the agent software itself has just been reset. In practice, most agents send only coldStart Traps because the agent typically restarts when the device on which the agent is running is powered on. The linkUp and linkDown Traps alert a manager about the change of status for a link on the device. An authenticationFailure indicates that a manager has sent the agent an SNMP request with an incorrect community string. Finally, the egpNeighborLoss Trap tells the manager that an External Gateway Protocol (EGP) neighbor has become unreachable. This last Trap is rarely used because EGP has been superseded by BGP4.
The preceding six Trap messages are the standard SNMP Traps, but they are not the only ones that an agent can send. Many MIBs define protocol-specific Traps, such as Traps specific to ISDN, Frame Relay, or BGP4. At the time of this writing, the IOS supports the Traps for a variety of protocols and IOS functions, including BGP, Frame Relay, ISDN, X.25, environmental monitor, and IOS configuration changes.
The Cisco IOS can be set up to send SNMP Traps to any number of managers. You must use the snmp-server host command to specify the IP address and community string of the manager to which Traps should be sent. In the following example, the Singapore router is configured on the ZIP network to send SNMP Traps to the manager at IP address 126.96.36.199 using the community string Zipnet. The optional parameters of the snmp-server host command also are to specify that we want the agent to send SNMP, Frame Relay, and IOS configuration change Traps.
Singapore# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Singapore(config)# snmp-server host 188.8.131.52 Zipnet snmp frame-relay config Singapore(config)#^ Z
We suggest that you configure your SNMP agent to send Traps about all the technologies that are active in the device. SNMP Trap messages typically do not consume much bandwidth, and they can provide useful information for diagnosing network problems.
You can manually configure the SNMP agent in the IOS with the physical location and contact person for the device. Network management applications then can retrieve this information. You must use the global configuration commands snmp-server location and snmp-server contact to set up this information. Each of these commands enables you to enter a text string of 255 characters to describe the location or contact. In the next example, the Singapore router is configured with contact and location information:
Singapore# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Singapore(config)# snmp-server location 1 Raffles Place, Singapore Singapore(config)# snmp-server contact Allan Leinwand, firstname.lastname@example.org Singapore(config)#^ Z
The EXEC command show snmp demonstrates the SNMP statistics for a given device. This command is useful in helping you monitor the SNMP activity on the device. Following is the output of show snmp from the Singapore router:
Singapore> show snmp Chassis: 25014624 Contact: Allan Leinwand, email@example.com Location: 45 Raffles Place, Singapore 4620211 SNMP packets input 0 Bad SNMP version errors 0 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 23493606 Number of requested variables 0 Number of altered variables 576553 Get-request PDUs 4043613 Get-next PDUs 0 Set-request PDUs 4623230 SNMP packets output 0 Too big errors (Maximum packet size 1500) 1757 No such name errors 0 Bad values errors 0 General errors 4620166 Get-response PDUs 3064 SNMP trap PDUs SNMP logging: enabled Logging to 184.108.40.206, 0/10, 3064 sent, 0 dropped.
In the preceding output, you can see statistics relative to SNMP. The first line of output shows the system board serial number available via the Cisco proprietary MIB. The second and third lines show the text strings for the contact and the location of the device, as configured using the snmp-server contact and snmp-server location global configuration commands. Statistics on the total number of SNMP packets that are input, the total number of SNMP packets that are input with the wrong community string, and the total number of SNMP objects requested by managers (referred to as variables) are available in the beginning of the output. You can also see a breakdown of the SNMP packet types received.
The second section of the output shows the total number of SNMP packets that are output, various standard SNMP protocol errors sent, and the total number of response and Trap messages sent. The last two lines of the output show whether the agent is set up to send Traps (called SNMP logging), the IP addresses of each manager receiving Traps, and the number of Traps sent to each specific manager.