General Network Management


This section covers general network-management issues such as the following:

  • Configuring SNMP on devices

  • Capturing SNMP and Telnet output through scripting

  • Using syslog

  • Using RMON

How Do I Configure Logging to a syslog Server?

Aside from traps, Cisco devices provide useful device state information by using the UNIX syslog facility. Whereas SNMP traps are well-defined and tend to reflect stateful changes, logging messages from Cisco devices are free-form text with well-defined names that reflect a wide range of conditions. The types of messages can range from debugging information such as when you enable debugging, to so-called "emergency" level messages, which reflect a catastrophic event such as a failing interface.

You can configure your routers and switches to forward their console messages onto a common syslog server so that you can capture and store all messages from all devices for later use. Enabling syslog messaging helps when troubleshooting and eliminates having to Telnet to different devices in order to view their individual logs.

To enable syslog message forwarding for IOS devices:

 logging host 

To enable syslog message forwarding for Catalyst IOS devices:

 set logging server enable set logging server ip_addr 

where ip_addr is the IP address of the server running syslogd. You can define more than one destination syslog server if you desire.

You can specify which messages are forwarded to the syslog server based on message severity with the following command on IOS devices:

 logging trap level 

where level is one of the seven syslog severity descriptions. By specifying a severity level, all messages with that severity level and above (more critical) will be forwarded to the syslog server.

TIP

Setting a logging level of "warnings" should suffice under normal conditions in order to catch all pertinent messages.


For example, with the following command

 logging trap warnings 

all syslog messages of severity warnings, errors, critical, alerts, and emergency will be forwarded.

The same mechanism exists for Catalyst IOS switches, but it is more granular in that you can specify severity levels for each family of services on the switch. Please refer to switch configuration documents for the different message types and how to set the severity for message forwarding.

Please see "Setting up Logging" in Chapter 18, "Best Practices for Device Configuration," for more information.

How Do I Configure an RMON Threshold?

RMON thresholds are set by configuring RMON events and alarms. A threshold consists of at least one and usually two components: an alarm (required) and an associated event (optional). The alarm defines the variable to monitor and the rising and falling thresholds to watch for. An event is associated with a particular alarm and defines the action that should occur if a particular threshold has been exceeded. An event action can consist of logging the event, sending a trap, or both.

RMON specifies that you create the thresholds using SNMP. This is the preferred method when creating thresholds using scripts or commercial software. Because the RMON protocols and methods are IETF standards, you can use any vendor's RMON configuration software that supports RFC 1757.

Cisco also provides a method to define thresholds on IOS devices by using the command-line interface. Some Cisco customers find the command line method easier when deploying the same RMON configuration to many devices.

Example 19-1 shows the IOS commands necessary to define a threshold that generates an SNMP trap if a router's CPU utilization exceeds 90 percent (rising threshold) or falls below 50 percent (falling threshold).

Example 19-1 Using the CLI to define a threshold and alarm.
 RMON event 100 log trap public description "CPU avgBusy5 exceeded 90%" owner pdellama RMON event 101 log trap public description "CPU avgBusy5 no longer excessive" owner pdellama RMON alarm 100 lsystem.58.0 60 absolute rising-threshold 90 100 falling-threshold 50 101 owner pdellama 

Please see Chapter 5, "Configuring Events," and Chapter 6, "Event and Fault Management," for more information concerning events and thresholding. Please see "Remote Monitoring MIB and Related MIBs" in Chapter 8, "Understanding Network Management Protocols," for more details on RMON. See Chapter 9, "Selecting the Tools," for more about the types of tools available for configuring RMON.

What Threshold Values Should I Use?

Throughout Part II of this book, we provide some starting threshold value recommendations, but avoid providing definitive values for you to use.

The reason why most engineers cannot provide a consistent answer to the question of what threshold values to use is that each network is different. No default threshold value can exist for most measurable attributes on a device that is consistent across all implementations.

Threshold values should be based on the current behavior of your network, and related to theoretical maximum capacity or capability of the data you are measuring. Thesholds should also be set at a level that alerts you to a problem before it seriously affects the network's capabilities and performance, but doesn't alert you so infrequently to cause the alarms to be ignored.

Setting thresholds that accurately reflect a particular network's behavior comes from a combination of learning your network and experience. Use the recommended thresholds in Part II as starting values. In addition, Chapter 2, "Policy-Based Network Management," provides tips on how to learn the current network behavior and Chapter 5 provides more information on selecting and defining thresholds.

How Can I Track if a Router or Switch Disappears from the Network?

Using ping (or ICMP) remains the best method to determine the presence of a device. Whether you build your own tool or use the status-monitoring capabilities provided with most network management software, ping/ICMP provides the easiest method for determine whether a device is reachable.

If a device becomes unreachable, it has either died, rebooted, or been turned off; or the network path between the network management station and the device has become unreachable. Either way, using ICMP is the quickest and simplest way to learn of a network fault. Commercial network management software generally displays the presence of a device in terms of availability through color-coded maps or tabular reports.

For more information, please see "Availability" in Chapter 4, "Performance Measurement and Reporting," and refer to "Availability Monitoring" in Chapter 9.

How Do I Graph Data that Require a Calculation?

Sometimes, you need to collect multiple variables in order to analyze the performance of a device or its interfaces.

For instance, to determine the utilization of a given network interface, you must collect the inbound and outbound traffic counts, and compare them to the theoretical maximum capacity of the interface. This analysis also may require the conversion of data to common data types (such as converting everything to bits-per-second).

For more information concerning the calculation of performance related data, see Chapter 4.

How Can I Enable or Disable Certain Types of Traps?

There are two types of traps to enable on Cisco devices: system-related traps and interface-related traps. System traps are those traps that apply to the system as a whole, whereas interface-related traps apply to a specific interface.

Configuring Traps on IOS Devices

As described in Chapter 18, you must use the snmp-server enable trap command in conjunction with the snmp-server host command to define which trap types will be generated to which trap receivers. By default, no trap receivers are defined.

In short, the snmp-server enable trap command defines which traps are available to be sent to trap receivers. The snmp-server host command defines trap receivers and the trap types that will be sent to a specific receiver. Thus, you can send different sets of traps to each defined trap receiver.

Because the relationship between these two commands varies for trap types based on IOS version, please refer to the IOS documentation for details related to your version of code.

The configuration in Example 19-2 enables two trap types for the router config and frame-relay and specifies two network management trap receivers.

Example 19-2 Configuring traps and trap receivers on an IOS device.
 snmp-server enable traps config snmp-server enable traps frame-relay snmp-server host 172.26.10.254 public snmp-server host 172.26.35.118 public config 

In Example 19-2, the first trap receiver (172.26.10.254) will receive all traps enabled for this router. The second trap receiver (172.26.35.118) will receive only config-related traps. Note the snmp-server enable line. You can enable all available traps by typing the snmp-server enable traps command with no argument. Also, note that if snmp-server enable traps config were not enabled, config traps would not be sent to the 172.26.35.118 destination.

NOTE

You must specify the trap community string to be used when sending a trap. Like a community string with SNMP gets or sets, the trap community string is intended to provide a simple method to authenticate the source of the trap. Because the community string is sent over the network in clear text, it is not a very secure method for authentication. By default, most network management trap reception software ignores the community string included with a trap. If this form of authentication is inadequate for your SNMP needs, consider using SNMP informs, which are covered in Chapter 8.


Configuring Traps on Catalyst IOS Switches

Suppose you want to configure the following:

  • Define a trap receiver of 172.26.10.254 with community string public

  • Enable the bridge and chassis traps

Example 19-3 demonstrates how to do so.

Example 19-3 Sample session of enabling trap receiver on a Catalyst 5000 switch.
 Console-outburst> (enable) set snmp trap 172.26.10.254 public SNMP trap receiver added. Console-outburst> (enable) set snmp trap enable bridge SNMP bridge traps enabled. Console-outburst> (enable) set snmp trap enable chassis SNMP chassis alarm traps enabled. 

By default, specific interface linkUp/linkDown traps are enabled. To disable the traps for specific ports, use the set port trap command. Also, keep in mind that you must specify a trap receiver with the set snmp trap command; otherwise, the port traps will have nowhere to go and will never reach a network management workstation.

In Example 19-4, we have enabled port traps for ports 2/1 2/12. Notice that the show port output for port 2/1 now reflects that the port trap is enabled.

Example 19-4 A sample port trap configuration on a Catalyst 5000.
 Console-outburst> (enable) set port trap 2/1-12 enable Ports 2/1-12 up/down trap enabled. Console-outburst> (enable) sho port 2/1 Port  Name               Status     Vlan       Level  Duplex Speed Type ----- ------------------ ---------- ---------- ------ ------ ----- ------------  2/1                     connected  1          normal a-half  a-10 10/100BaseTX Port   Security  Secure-Src-Addr    Last-Src-Addr      Shutdown  Trap -----  --------  -----------------  -----------------  --------  --------  2/1   disabled                                        No        enabled  <<<<<< 

For more information on configuring traps, please refer to "Enabling SNMP on Cisco Devices" and "Controlling SNMP Trap messages" in Chapter 18.

How Can I Collect Information that Is Available in a show Command, but Not Through SNMP?

Unfortunately, not all device information is available via SNMP. In such cases, you must determine whether the information you need is reported in any other form by a device. Sometimes, useful information is available only from a command-line show command or perhaps a console message.

Before resorting to using show commands, keep in mind that Cisco has more than 200 MIB documents published on Cisco Connection Online (CCO), which represent the supported MIB objects in Cisco devices. You should verify that a particular piece of information is not available via SNMP by following the guidelines in Appendix A,"CCO, MIBs, Traps, and Your NMS."

If you decide you must collect information that is only available in a command-line show command, there are multiple methods to do so. The most commonly used method is using the Expect language, which was originally part of the Tcl language, but has since been ported into other languages. The original version of Expect for Tcl was written by Don Libes, and the Tcl Expect homepage can be found at http://expect.nist.gov/.

Expect provides a method to feed input and collect output from a terminal session using a script. Austin Schutz has written a PERL module that performs the same functionality as Tcl Expect. The module can be downloaded from http://www.perl.com/CPAN/modules/by-module/Expect/.

The chapters in Part II of this book contain the most widely used show commands and syslog messages that do not have SNMP equivalents. Please see Appendix B,"ATM Accounting Files," for an sample Expect script written using the Perl Expect module.

How Can I Force a Router to Consistently Provide the Same Source IP Address for Any Traps or syslog Messages?

Because syslog messages and SNMP traps are encapsulated in IP packets, they are subject to IP routing rules. Thus, if there are multiple routes from a Cisco device to a network management workstation, the source IP address of the syslog message or trap can vary, based on which port the packet is sourced from. Figure 19-1 illustrates how traps and syslog messages can contain different source IP addresses when arriving from the same device.

Figure 19-1. Traps and syslog Messages Have Different Source IP Addresses, Depending on the Interface from Which They Are Sourced

graphics/19fig01.gif

When traps come in from the same device with different source IP addresses, some network management software may not be able to discern that the messages are from the same device when trying to do a DNS name lookup. In addition, different IP addresses from the same device can make reading an event log difficult.

NOTE

With switches, the source IP address of an event is not an issue because there is only one IP address to manage a switch by. The same IP address will be used when a trap or syslog message is generated.


To alleviate this issue, IOS routers can be configured to use a consistent IP address on syslog messages and traps by implementing a loopback interface.

Example 19-5 illustrates how to implement a consistent source IP address for syslog messages and traps using a loopback interface. (Note that this is a partial configuration.)

Example 19-5 Configuring a loopback interface for consistent source IP address in traps and syslog messages.
 interface Loopback0  ip address 10.10.100.50 255.255.255.255 ! logging source-interface Loopback0 snmp-server trap-source Loopback0 

In Example 19-5, a virtual interface called loopback0 is created, which has an IP address of 10.10.100.50 associated with it. Notice that a host subnet mask of 255.255.255.255 can be used to minimize the use of whole subnets. The use of a host subnet mask may cause problems for some network management. If this is the case for you, consider using variable length subnets of /30 instead.

The logging source-interface and snmp-server trap-source commands specify that any syslog message or trap generated by this box use the source IP address of loopback 0, or 10.10.100.50 in this example.

For more information on using a common source IP address for traps and syslog messages, please see "Setting Up a Loopback Interface" in Chapter 18.

Why Can't I Collect RMON Statistics from a Switch?

By default, RMON is not enabled on Catalyst 4000, 5000, and 6000 switches. This can cause problems when you try to configure any of the RMON groups on a device. For example, when trying to collect etherstats from a Catalyst 6500, you may get an error saying they don't exist.

Most likely, RMON has not been enabled on the switch. Run the following command to enable RMON on a switch:

 Console-outburst> (enable) set SNMP RMON enable SNMP RMON support enabled. 

To verify that RMON is enabled, type the show snmp command. Example 19-6 shows sample output from doing so.

Example 19-6 Run the show snmp command to verify that RMON is enabled.
 Console-outburst> (enable) sho snmp RMON: Enabled Traps Enabled: Port,Chassis,Bridge Port Traps Enabled: 2/1-12 Community-Access     Community-String ----------------     -------------------- read-only            public read-write           private read-write-all       secret Trap-Rec-Address                           Trap-Rec-Community ----------------------------------------   -------------------- public 


Performance and Fault Management
Performance and Fault Management: A Practical Guide to Effectively Managing Cisco Network Devices (Cisco Press Core Series)
ISBN: 1578701805
EAN: 2147483647
Year: 2005
Pages: 200

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net