General Interface Management

The questions in this section relate to general interface management issues for Cisco devices, such as the following:

• Measuring utilization

• Detecting whether an interface is operational

• Measuring errors

Can MIB II ifTable Variables (such as ifInOctets) Be Collected from Sub-interfaces?

When RFC 1213 (MIB II) was originally drafted, the interface table variables were designed to reflect information about physical interfaces. Since then, the need has arisen to measure certain interface-related characteristics of logical connections that exist over physical lines. For example, a single physical serial interface may carry multiple Frame Relay DLCIs over it.

Starting with IOS version 11.1, Cisco implemented the concept of sub-interfaces to represent multiple logical interfaces over a single physical interface. Consequently, certain sub-interface types are now represented in portions of the ifTable.

Implementation of particular sub-interface types varies, based on technology, platform, and version of IOS. For more details, please see "Special Considerations for Sub-interfaces" in Chapter 12, "Monitoring System Interfaces."

How Can I Collect Interface Utilization and Monitor It Over Time?

In order to track interface utilization, you need to know two aspects of the interface:

• What is the speed/clockrate of the interface?

• Is the interface half- or full-duplex?

If the interface is full-duplex, it does not make sense to report utilization as a single number. This is because a full-duplex interface can have a maximum capacity of twice its bandwidth.

Some network managers choose to report full-duplex utilization as a single number. They do this by using an equation that calculates utilization by taking the maximum of the two values for the differences of in and out bits. Although this approach allows you to report a single utilization number for an interface, it does not provide a very useful picture of what is happening in both directions. Instead, you should calculate two utilization measures: in and out. For more details, please refer to Chapter 4.

How Can I Measure Utilization for IOS Sub-interfaces?

The answer to this question depends on what type of sub-interface you are trying to measure. Different sub-interface types received SNMP support in different levels of IOS.

When interface information is not available for a particular type of sub-interface, there are usually alternative means for collecting the traffic information. For instance, RFC 1315 provides per-circuit octet counts with the frCircuitSentOctets and frCircuitReceivedOctets.

For more information, please refer to "Performance Monitoring for Sub-interfaces" in Chapter 12.

How Do I Collect Interface Utilization from High-Speed Interfaces such as ATM and Gigabit Ethernet?

Although the utilization equations described in "Measuring Utilization" in Chapter 4 apply to high-speed interfaces, you must look at variables other than ifInOctets and ifOutOctets because they can roll over quickly with fast interfaces. With the advent of RFC 1573 (which superceded RFC 1213), high-speed counters were introduced to alleviate problems of high-speed interface counters rolling over too quickly to be useful.

ifHCInOctets and ifHCOutOctets are 64-bit counters (as opposed to 32-bit) and should be used on the high-speed interfaces that support them. Please note that you must use version 2c or version 3 of the SNMP protocol in order to recognize 64-bit counters.

For more information on high-speed counters and the versions of router and switch code on which they are supported, please see ion "Special Considerations for High-Speed Interfaces," in Chapter 12.

How Do I Disable/Enable Traps for Specific Router or Switch Ports?

You may want to disable traps for specific router or switch ports to avoid getting a trap every time someone turns off his or her computer. On a router, issue the snmp trap link-status command. On a switch, issue the set port trap mod_num/port_num {enable|disable} command.

If you want to enable or disable interface traps with SNMP, you can set the ifLinkUpDownTrapEnable variable found in RFC 2233. By default, the traps are enabled for router ports and disabled for switch ports.

For more information, please see "Controlling SNMP Trap Messages" in Chapter 18.

Why Does My Interface Utilization Appear to Be Greater than 100 Percent?

This can occur under several circumstances:

• You are measuring utilization of a full-duplex interface using a half-duplex formula.

• You are using an incorrect value for the interface bandwidth and have most likely set the IOS interface bandwidth incorrectly. By default, the setting of bandwidth is the line speed of a physical interface.

• You have an error in the way you calculate utilization.

• You are using a commercial network-management product that incorrectly uses the half-duplex formula on full-duplex media.

For more information, please see "Utilization" in Chapter 4.

How Can I Measure Interface Health?

Like system health, interface health is an essential indicator of network efficiency. The following characteristics should be used for assessing interface health:

• Interface utilization

• Interface errors

• Interface status

Determine which ports to monitor. Generally, you should only manage ports that are critical to the operation of the network or servers. This includes all trunk ports, large router ports, and local WAN connections. Chapter 1, "Conducting a Network Audit," has more detail on how to select critical ports to manage.

For port status, configure port traps to be collected in a trap log. This allows you to report a fault as quickly as the device sends the trap and the network management station can process it. When the trap is received, the network management station displays the trap in its event log and can launch a script in response.

Monitor interface error rates can provide an error percent, or compare the error rate to total traffic to understand the accuracy of transmission.

In your knowledge base, store the device, interface name, speed, and duplexity. These serve as the seed information for polling. Keeping this information current can be a pain, but helps in more accurate data collection.

See "Accuracy" in Chapter 4 for details on measuring interface errors, and see Chapter 3, "Developing the Network Knowledge Base," for information concerning a knowledge base.

How Can I Detect When an Interface Goes Down?

There are three primary methods, all using RFC 2233 variables:

• Watch for linkDown traps from a device.

• Watch for interface status change messages in syslog.

• Poll the ifOperStatus and ifAdminStatus. If ifAdminStatus is up and ifOperStatus is down, the interface is intended to be up, but for some reason is down. There are exceptions to this method with some WAN interfaces. See "Link Status" in Chapter 12 for more details.

• Poll ifLastChange and watch for a change in value. IfLastChange contains the sysUpTime of the last interface state change. If, while polling ifLastChange the value changes, that indicates that the interface state changed since the last poll cycle.

For more information, see "Error/Fault Monitoring" in Chapter 12.

How Can I Determine the Bandwidth of an Interface or Sub-interface?

For LAN interfaces such as ethernet, Token Ring, and FDDI, you must check two things: the interface type and whether the interface is passing traffic full-duplex or half-duplex. So, for instance, a fast ethernet interface set to full-duplex indicates that the interface can simultaneously transfer traffic at 100 MBps in both directions. An SNMP set against ifSpeed for a fast ethernet interface would look like the following:

 ~% snmpget bikini-atoll ifSpeed.3 interfaces.ifTable.ifEntry.ifSpeed.3 : Gauge32: 100000000 

NOTE

Remember that ifSpeed is based on the IOS bandwidth setting for each interface, and may not reflect the actual speed the interface is using.

For WAN interfaces, determining bandwidth becomes trickier because the interface bandwidth reflects the fastest possible rate for a physical interface rather than the actual service you may be receiving from your service provider. For instance, with Frame Relay, the actual throughput you receive is dependent on multiple characteristics, including the Committed Information Rate you purchased and congestion in the service provider network. In such a case, you should calculate the bandwidth based on the optimal service you expect from your service provider.

For more information, please see Chapter 12.

How do I Track the Number of Broadcasts Received on a Particular Interface?

From RFC 2233, use the ifInBroadcast and ifOutBroadcast variables. Typically, using these variables and comparing them to the total amount of traffic will give you a ratio to determine how broadcast traffic rates may increase or decrease over time, compared to total traffic. These variables are first supported in IOS 12.0.

If you are running IOS prior to version 12.0, please use the RFC 1213 ifInNUcastPkts and ifOutNUcastPkts variables. The disadvantage of these variables is that there is no way to separate multicast counts from broadcast.

For more information, please see "Performance Monitoring for System Interfaces" in Chapter 12.

How Do I Clear Device SNMP Counters?

With Cisco routers, there is no way to reset SNMP counters (such as ifInOctets) without rebooting the device. Doing a clear counters command on the console only resets the counters viewed with show commands; the equivalent SNMP counters remain untouched. The SNMP counters cannot be reset other than by rebooting or re-initializing the agent (cold and warm restart).

However, with Cisco Catalyst IOS switches, the SNMP counters are reset, along with the show mac and show port counters, when you do a clear counters command.

For more information, please see "Special Considerations on Interface Counters" in Chapter 12.

How Can I Collect Interface Information when the Ifindex Always Changes for Interfaces?

The nature of SNMP is that you cannot depend on the ifIndex always being assigned to the same interface. Each time a box reboots, or each time a card is hot-swapped in or out of a box, the ifIndex can legally change for interfaces. This can create problems for network management software that might look at specific interfaces by using ifIndex.

The RFC 2233 MIB variables ifDescr, ifAlias, and ifName resolve this problem by allowing you to correlate a human readable name with the ifIndex for routers.

For more information, please see "Special Considerations for ifIndex" in chapter 12.