|
|
This chapter describes the asks that you can perform to monitor the router and network.
For a complete description of the router monitoring commands mentioned in this chapter, refer to the "Router and Network Monitoring Commands" chapter of the Configuration Fundamentals Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
This chapter describes the tasks you can perform to manage the router and its performance on the network. Perform any of the tasks in the following sections:
The Simple Network Management Protocol (SNMP) system consists of the following three parts:
The SNMP manager can be part of a Network Management System (NMS) such as CiscoWorks. The agent and MIB reside on the router. To configure SNMP on the router, you define the relationship between the manager and the agent.
Figure 40 illustrates the communications relationship between the SNMP manager and agent. A manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited traps to the manager to notify the manager of network conditions.
Cisco IOS Release 11.3 software supports the following versions of SNMP:
Cisco IOS Release 11.3 ED removes support for the following version of SNMP:
SNMPv2C replaces the Party-based Administrative and Security Framework of SNMPv2Classic with the Community-based Administrative Framework of SNMPv2C while retaining the bulk retrieval and improved error handling of SNMPv2Classic.
Both SNMPv1 and SNMPv2C use a community-based form of security. The community of managers able to access the agent's MIB is defined by an IP address access control list and password.
SNMPv2C support includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2C improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions.
You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol and another using the SNMPv2 protocol.
Cisco's implementation of SNMP supports all MIB II variables (as described in RFC 1213) and SNMP traps (as described in RFC 1215).
Cisco no longer supports RFC 1447, "SNMPv2 Party MIB" (April 1993) or RFC 1450, "SNMPv2 MIB" (April 1993).
Cisco provides its own private MIB extensions with every system. One of the set of MIB objects provided is the Cisco Chassis MIB that enables the SNMP manager to gather data on system card descriptions, serial numbers, hardware and software revision levels, and slot locations. Another set is the Entity MIB (RFC 2037), which describes the logical resources, physical resources, and logical-to-physical mappings of devices managed by a single SNMP agent. The Entity MIB also records the time of the last modification to any object in the Entity MIB and sends out a trap when any object is modified.
There is no specific command that you use to enable SNMP. The first snmp-server command that you enter enables both versions of SNMP.
To configure SNMP support, perform any of the tasks in the following sections. The second task is required; all other tasks are optional.
You can assign views to community strings to limit which MIB objects an SNMP manager can access. You can use a predefined view, or create your own view. If you are using a predefined view or no view at all, skip this step.
To create or modify an SNMP view record, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify a view record. | snmp-server view view-name oid-tree {included | excluded} |
To remove a view record, use the no snmp-server view command.
You can enter this command multiple times for the same view record. Later lines take precedence when an object identifier is included in two or more lines.
Use an SNMP community string to define the relationship between the SNMP manager and the agent. The community string acts like a password to permit access to the agent on the router. Optionally, you can specify one or more of the following characteristics associated with the string:
To configure a community string, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define the community access string. | snmp-server community string [view view-name] [ro | rw] [access-list number] |
You can configure one or more community strings. To remove a specific community string, use the no snmp-server community command.
For an example of configuring a community string, see the section "SNMP Examples" at the end of this chapter.
Using SNMP packets, a network management tool can send messages to users on virtual terminals and the console. This facility operates in a similar fashion to the EXEC send command; however, the SNMP request that causes the message to be issued to the users also specifies the action to be taken after the message is delivered. One possible action is a shutdown request. After a system is shut down, typically it is reloaded. Because the ability to cause a reload from the network is a powerful feature, it is protected by the snmp-server system-shutdown global configuration command. If you do not issue this command, the shutdown mechanism is not enabled. To enable the SNMP agent shutdown mechanism, perform the following task:
| Task | Command |
|---|---|
| Use the SNMP message reload feature and request a system shutdown message. | snmp-server system-shutdown |
To understand how to use this feature with SNMP requests, read the document OLD-CISCO-SYSTEM-MIB.my, available on Cisco Connection Online.
You can set the system contact, location, and serial number of the SNMP agent so that these descriptions can be accessed through the configuration file. To do so, perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Set the system contact string. | snmp-server contact text |
| Set the system location string. | snmp-server location text |
| Set the system serial number. | snmp-server chassis-id text |
You can set the maximum packet size permitted when the SNMP agent is receiving a request or generating a reply. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Establish the maximum packet size. | snmp-server packetsize byte-count |
You can limit the TFTP servers used for saving and loading configuration files via SNMP to the servers specified in an access list. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Limit TFTP servers used for configuration file copies via SNMP to the servers in an access list. | snmp-server tftp-server-list number |
To monitor SNMP input and output statistics, including the number of illegal community string entries, errors, and requested variables, complete the following task in EXEC mode:
| Task | Command |
|---|---|
| Monitor SNMP status. | show snmp |
To disable both versions of SNMP (SNMPv1 and SNMPv2C), perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Disable SNMP agent operation. | no snmp-server |
The SNMP trap operations allow a system administrator to configure the agent router to send information to an SNMP manager when a particular event occurs.
To configure the router to send traps to a host, perform the following tasks in global configuration mode:
The snmp-server host command specifies which hosts will receive traps. The snmp-server enable traps commands globally enables the trap production mechanism for the specified traps.
However, some traps are not controlled by the snmp-server enable traps command. These traps are either enabled by default or controlled through other commands. For example, by default, SNMP link traps are sent when an interface goes up or down. For interfaces expected to go up and down during normal usage, such as ISDN interfaces, the output generated by these traps may not be useful. Use the no snmp trap link-status interface configuration command to disable these traps.
In order for a host to receive a trap, a snmp-server host command must be configured for that host, and the trap must be enabled globally through the snmp-server enable traps command, through a different command, such as snmp trap link-status, or by default.
Optionally, you can specify a value other than the default for the source interface, message (packet) queue length for each trap host, or retransmission interval.
| Task | Command |
|---|---|
| Specify the source interface (and hence IP address) of the trap message. | snmp-server trap-source interface |
| Establish the message queue length for each trap host. | snmp-server queue-length length |
| Define how often to resend trap messages on the retransmission queue. | snmp-server trap-timeout seconds |
Full RMON packet analysis as described in RFC 1757 is available only on an Ethernet interface of the Cisco 2500 series and Cisco AS5200 series routers. RMON requires that SNMP be configured. A generic RMON console application such as Frontier NETscout Manager or Traffic Director is recommended in order to take advantage of RMON's network management capabilities.
RMON can be very data and processor intensive. Users should measure usage effects to ensure that router performance is not degraded and to minimize excessive management traffic overhead. Native mode is less intensive than promiscuous mode.
All Cisco IOS software images ordered without the explicit RMON option include limited RMON support (RMON alarms and event groups only). Images ordered with the RMON option include support for all nine groups (statistics, history, alarms, hosts, hostTopN, matrix, filter, capture, and event). As a security precaution, support for the packet capture group allows capture of packet header information only; data payloads are not captured.
To enable RMON on an Ethernet interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable RMON. | rmon {native | promiscuous} |
In native mode, RMON monitors only the packets normally received by the interface. In promiscuous mode, RMON monitors all packets on the LAN segment.
The default size of the queue that holds packets for analysis by the RMON process is 64 packets. To change the size of the queue, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Change the size of the RMON queue. | rmon queuesize size |
To set an RMON alarm or event, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Set an alarm on a MIB object. | rmon alarm number variable interval {delta | absolute} rising-threshold value [event-number] falling-threshold value [event-number] [owner string] |
| Add or remove an event in the RMON event table. | rmon event number [log] [trap community] [description string] [owner string] |
You can set an alarm on any MIB object in the access server. To disable an alarm, you must enable the no form of this command on each alarm you configure. You cannot disable all the alarms you configure at once. Refer to RFC 1757 to learn more about alarms and events and how they interact with each other.
To display the current RMON status, perform one or more of the following tasks in EXEC mode:
| Task | Command |
|---|---|
| Display general RMON statistics. | show rmon
or show rmon task |
| Display the RMON alarm table. | show rmon alarms |
| Display the RMON buffer capture table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon capture |
| Display the RMON event table. | show rmon events |
| Display the RMON filter table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon filter |
| Display the RMON history table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon history |
| Display the RMON hosts table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon hosts |
| Display the RMON matrix table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon matrix |
| Display the RMON statistics table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon statistics |
| Display the RMON top-n hosts table. Available on Cisco 2500 series and Cisco AS5200 only. | show rmon topn |
For an example of configuring RMON alarms and events, see the section "RMON Alarm and Event Examples" at the end of this chapter.
The Cisco Discovery Protocol (CDP) is a media- and protocol-independent protocol that runs on all Cisco-manufactured equipment including routers, bridges, access servers, and switches. With CDP, network management applications can learn the device type and the SNMP agent address of neighboring devices. This enables applications to send SNMP queries to neighboring devices.
CDP runs on all media that support Subnetwork Access Protocol (SNAP), including local-area network (LAN), Frame Relay, and Asynchronous Transfer Mode (ATM) media. CDP runs over the data link layer only. Therefore, two systems that support different network-layer protocols can learn about each other.
Each device configured for CDP sends periodic messages to a multicast address. Each device advertises at least one address at which it can receive SNMP messages. The advertisements also contain time-to-live, or holdtime, information, which indicates the length of time a receiving device should hold CDP information before discarding it.
There is a CDP MIB for the management of CDP on Cisco devices.
To configure CDP, perform the tasks in the following sections:
To set the frequency of CDP transmissions and the hold time for CDP packets, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Specify frequency of transmission of CDP updates. | cdp timer seconds |
| Specify the amount of time a receiving device should hold the information sent by your device before discarding it. | cdp holdtime seconds |
CDP is enabled by default. You can disable it with the no cdp run command.
To reenable CDP after disabling it, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable CDP. | cdp run |
CDP is enabled by default on all supported interfaces to send and receive CDP information. However, some interfaces, such as ATM interfaces, do not support CDP. You can disable CDP on an interface which supports CDP with the no cdp enable command.
To reenable CDP on an interface after disabling it, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable CDP on an interface. | cdp enable |
To monitor and maintain CDP on your device, perform one or more of the following tasks in privileged EXEC mode:
| Task | Command |
|---|---|
| Reset the traffic counters to zero. | clear cdp counters |
| Delete the CDP table of information about neighbors. | clear cdp table |
| Display global information such as frequency of transmissions and the holdtime for packets being transmitted. | show cdp |
| Display information about a specific neighbor. Display can be limited to protocol or version information. | show cdp entry entry-name [protocol | version] |
| Display information about interfaces on which CDP is enabled. | show cdp interface [type number] |
| Display information about neighbors. The display can be limited to neighbors on a specific interface, and expanded to provide more detailed information. | show cdp neighbors [type number] [detail] |
| Display CDP counters, including the number of packets sent and received and checksum errors. | show cdp traffic |
| Display information about the types of debugging that are enabled for your router. See the Debug Command Reference for more information about CDP debug commands. | show debugging |
The response time reporter feature allows you to monitor network performance, network resources, and applications by measuring response times and availability. With this feature you can perform troubleshooting, problem notifications, and preproblem analysis based on response time reporter statistics.
The response time reporter feature is currently available only with the IBM feature set of the Cisco IOS software. A CiscoWorksBlue network management application will be available to support the response time reporter feature. Both the CiscoWorks Blue network management application and the router use the Cisco Round Trip Time Monitor (RTTMON) MIB.
You can use the response time reporter feature to troubleshoot problems by checking the time delays between devices (such as a router and an MVS host) and the time delays on the path from the source device to the destination device at the protocol level.
You can also use this feature to send any combination of SNMP traps and SNA Alerts/Resolutions when one of the following has occurred: a user-configured threshold is exceeded, a connection is lost and reestablished, or when a timeout occurs. Thresholds can also be used to trigger additional collection of time delay statistics.
You can use this feature to perform preproblem analysis by scheduling the response time reporter and collecting the results as history and accumulated statistics. You can then use the statistics to model and predict future network topologies.
See the end of this chapter for "Response Time Reporter Examples."
| Task | Command |
|---|---|
| Step 1 Enter response time reporter configuration mode. | rtr probe |
| Step 2 Specify the type of probe. | type {echo | pathecho} protocol type type-target |
You must configure the probe's type before you can configure any of the other characteristics.
To configure optional characteristics, perform the following tasks in response time reporter configuration mode:
In most situations, you do not need to change the statistical distribution interval or size. Only change the size when distributions are needed (for example, when performing statistical modeling of your network).
To control how much and what type of statistics are stored on the router, complete the following optional tasks in response time reporter configuration mode:
To control how much and what type of history is stored on the router, complete the following tasks in response time reporter configuration mode. The first task is required; the remainder are optional.
To disable history collection, use the default value (0 lives) for the lives-of-history-kept command rather than the filter-for-history none response time reporter configuration command. The lives-of-history-kept command disables history collection before the probe's operation is attempted, and the filter-for-history command with the none keyword checks for history inclusion after the probe's operation attempt is made.
You can configure the probe to send threshold notifications and use those notifications to trigger additional collection of time delay statistics. You can also configure the probe to send notifications when the probe loses connection, reestablishes connections, times out, and first succeeds after a timeout.
To configure the probe's reaction conditions, perform the following optional tasks in global configuration mode:
| Task | Command |
|---|---|
| Schedule the probe by configuring the time parameters. | rtr schedule probe [life seconds] [start-time {pending | now | hh:mm [month day | day month]}] [ageout seconds] |
If the probe is in a pending state (the default), you can define the conditions under which the probe makes the transition from pending to active with the rtr reaction-trigger global configuration command. When the probe is in an active state it immediately begins collecting information.
| Task | Command |
|---|---|
| Stop all probes and clear the response time reporter configuration information. | rtr reset |
 | Caution Use the rtr reset command only in extreme situations such as the incorrect configuration of a number of probes. |
In addition to stopping all probes and clearing the response time reporter configuration information, the rtr reset command returns the response time reporter feature to the startup condition. This command does not reread the configuration stored in NVRAM. You must retype the response time reporter's configuration or perform a config memory command (this has the side effect of reconfiguring the router to its startup configuration).
The following sections provide system management examples:
The following example enables SNMPv1 and SNMPv2C. The configuration permits any SNMP manager to access all objects with read-only permissions using the community string public. This configuration does not cause the router to send any traps.
snmp-server community public
The following example permits any SNMP to access all objects with read-only permission using the community string public. The router will also send ISDN traps to the hosts 192.180.1.111 and 192.180.1.33 using SNMPv1 and to the host 192.180.1.27 using SNMPv2C. The community string public is sent with the traps.
snmp-server community public snmp-server enable traps isdn snmp-server host 192.180.1.27 version 2c public snmp-server host 192.180.1.111 version 1 public snmp-server host 192.180.1.33 public
The following example allows read-only access for all objects to members of access list 4 that specify the comaccess community string. No other SNMP managers have access to any objects. SNMP Authentication Failure traps are sent by SNMPv2C to the host cisco.com using the community string public.
snmp-server community comaccess ro 4 snmp-server enable traps snmp authentication snmp-server host cisco.com version 2c public
The following example sends Entity MIB traps to the host cisco.com. The community string is restricted. The first line enables the router to send Entity MIB traps in addition to any traps previously enabled. The second line specifies the destination of these traps and overwrites any previous snmp-server host commands for the host cisco.com.
snmp-server enable traps entity snmp-server host cisco.com restricted entity
The following example enables the rmon event command:
rmon event 1 log trap eventtrap description "High ifOutErrors" owner sdurham
This example creates RMON event number 1, which is defined as High ifOutErrors, and generates a log entry when the event is triggered by an alarm. The user sdurham owns the row that is created in the event table by this command. This example also generates a Simple Network Management Protocol (SNMP) trap when the event is triggered.
The following example configures an RMON alarm using the rmon alarm command:
rmon alarm 10 ifEntry.20.1 20 delta rising-threshold 15 1 falling-threshold 0 owner jjohnson
This example configures RMON alarm number 10. The alarm monitors the MIB variable ifEntry.20.1 once every 20 seconds until the alarm is disabled, and checks the change in the variable's rise or fall. If the ifEntry.20.1 value shows a MIB counter increase of 15 or more, such as from 100000 to 100015, the alarm is triggered. The alarm in turn triggers event number 1, which is configured with the rmon event command. Possible events include a log entry or an SNMP trap. If the ifEntry.20.1 value changes by 0, the alarm is reset and can be triggered again.
In the example shown in Figure 41, probe 1 is configured from router A to host 2, and probe 2 is configured from router B to host 2 to perform a normative analysis of the network to determine a baseline from which triggers (and reactions in general) are then configured. Also, two SNA Physical Units (PUs) are assumed to be configured: CWBC0A and CWBC0B. For information on configuring PUs, see the dspu host or the sna host command in the Bridging and IBM Networking Command Reference.
RouterA(config)#rtr 1RouterA(config-rtr)#type echo protocol snaLU2EchoAppl CWBC0ARouterA(config-rtr)#exitRouterA(config)#rtr schedule 1 start-time nowRouterA(config)#exit
RouterB(config)#rtr 2RouterB(config-rtr)#type echo protocol snaLU2EchoAppl CWBC0BRouterB(config-rtr)#exitRouterB(config)#rtr schedule 1 start-time nowRouterB(config)#exit
After you save the configurations (using the copy running-config startup-config command), the following information is stored in the configuration files. Note the addition of the "kept" commands in the configuration file. They are automatically included because they differ depending on the type you specify for the probe.
!Router A Configuration File ! Router A's PU Configuration sna host CWBC0A xid-snd 05dcc00a rmac 4001.3745.1088 rsap 4 lsap 12 focalpoint rtr 1 type echo protocol snaLU2EchoAppl CWBC0A paths-of-statistics-kept 1 hops-of-statistics-kept 1 samples-of-history-kept 1 rtr schedule 1 start-time now !Router B Configuration File !Router B's PU Configuration from the Configuration File: sna host CWBC0B xid-snd 05dcc00b rmac 4001.3745.1088 rsap 4 lsap 12 focalpoint rtr 2 type echo protocol snaLU2EchoAppl CWBC0B paths-of-statistics-kept 1 hops-of-statistics-kept 1 samples-of-history-kept 1 rtr schedule 2 start-time now
In the example shown in Figure 42, probe 3 is configured from router B to router A to perform troubleshooting of the network to determine a network problem from which triggers (and reactions in general) are then configured.
This example sets up a pathEcho (with history) pending entry from router B to router A via IP/ICMP. It will attempt to execute three times in 25 seconds (first attempt starts at 0 seconds) and will keep those three times with three buckets. It can be started five times before wrapping over stored history (lives 5). Because this configuration keeps history, it uses more RAM on the router.
RouterB(config)#rtr 3RouterB(config-rtr)#type pathEcho protocol ipIcmpEcho RouterARouterB(config-rtr)#frequency 10 RouterB(config-rtr)#lives-of-history-kept 5RouterB(config-rtr)#buckets-of-history-kept 3RouterB(config-rtr)#filter-for-history allRouterB(config-rtr)#exitRouterB(config)#rtr schedule 3 life 25RouterB(config)#exit
After you save the configuration (using the copy running-config startup-config command), the following information is stored in the configuration file. Note the addition of commands in the configuration file. They are automatically included because they differ depending on the type you specify for the probe.
rtr 3 type pathEcho protocol ipIcmpEcho 172.28.161.21 frequency 10 response-data-size 1 lives-of-history-kept 5 buckets-of-history-kept 3 filter-for-history all rtr schedule 3 life 25 start-time pending
Figure 43 shows probes 1, 2, and 3 in the network. This example shows how to configure a trigger if probe 2 encounters a connection loss from router B to host 2. If a connection loss occurs between router B and host 2, a trap is issued, an SNA NMVT Alert is issued, and probe 3's state is changed to "active."
RouterB(config)#rtr reaction-configuration 2 connection-loss-enableaction-type trapNmvtAndTriggerRouterB(config)#rtr reaction-trigger 2 3
|
|