Overview of System Interfaces

Interfaces have several characteristics that affect the way you monitor them. The topology, duplexity, and transmission characteristics all affect how you calculate utilization and what errors you monitor.

One characteristic is the topology: point-to-point or broadcast. A point-to-point link connects two interfaces. Generally, all WAN interfaces fall in this category. A broadcast topology has more than two interfaces connected. Broadcast topologies are used almost exclusively in LANs. Shared Ethernet is a good example of a broadcast topology. However, with the rise of switched Ethernets, many Ethernet links are now point-to-point.

The duplexity has a great effect on performance measurements and calculations. A link is either full- or half-duplex. Full-duplex interfaces can transmit and receive data simultaneously. Half-duplex interfaces can only either transmit or receive data. Full-duplex interfaces are generally point-to-point; half-duplex interfaces may be multipoint or point-to-point.

Another characteristic is transmission speed or bandwidth of the link. Obviously, you need to know the transmission speed of a link in order to calculate the utilization of the link. For WAN links, the transmission speed is generally determined by a separate clock signal. For LAN links, the transmission speed is predetermined and the clock is embedded in the data itself. There is an object in the ifTable called ifSpeed. Cisco routers use an interface configuration command:

bandwidth kilobits

The bandwidth interface command will set the value of ifSpeed, which is useful for calculating the utilization of an interface.

Special Considerations for Sub-interfaces

There are some special types of interfaces that you will need to monitor. Initially, interfaces table (ifTable) from RFC 1213 had an entry for every physical interface on a device. But newer technologies such as Frame Relay, ATM, and VLANs introduced a different type of interface: the virtual interface, or sub-interface. On a Frame Relay interface, for example, you may have several different Permanent Virtual Circuits (PVCs). Several functional aspects, such as split horizon, make it desirable to treat each PVC as a separate virtual interface, although they all reside on the same physical interface. Sub-interfaces allow you to treat each PVC as a separate interface. And although the overall utilization of the physical interface is most important, the amount of traffic on individual sub-interfaces is of great interest as well.

However, from the definitions in RFC 1213, it is difficult to fill all the entries in the ifTable for sub-interfaces. It is quite possible that not all objects in the ifTable apply to a particular sub-interface. For example, how do framing errors apply to a virtual interface? Framing errors are physical errors and therefore apply only to the physical rather than the virtual interface. The concept of sparse tables was introduced in RFC 1573 (later superceded by RFC 2233). This concept means that a row in the ifTable for a sub-interface may not have values in columns where the objects do not apply to the sub-interface.

Cisco IOS implemented support for generic sub-interfaces, starting in IOS version 11.1. Frame Relay and ATM LANE sub-interfaces support was added in IOS 11.1. Support of other ATM sub-interfaces was added in IOS 12.0T. As of this writing, ifTable support for ISL VLAN sub-interfaces is planned for IOS version 12.1(3)T.

With the addition of rows for sub-interfaces to the ifTable, the table becomes sparse. For a sub-interface row, there will be no values for the objects that do not apply to the sub-interface. The device will return a "no such name" error when such an object is accessed. The SNMP get and getNext operations have no problem dealing with sparse tables. However, there are some NMS applications that may have problems when they try to walk a sparse table. There is a workaround in IOS with the hidden global configuration command:

no snmp-server sparse-table

This workaround causes those objects to return a value of 0 rather than a "no such name" error.

Special Considerations for ifIndex

A further complication introduced with the ifTable support of sub-interfaces is that of ifIndex. When sub-interfaces are added on the fly, they are appended to the end of the ifTable. However when the router re-initializes, the interfaces re-index with the result that for many interfaces, the ifIndex changes. Because ifIndex can change from re-boot to re-boot, you should not depend on ifIndex to know which interface you are polling. For example, if you poll ifDescr in a router with a Frame Relay connection:

 %4> snmpwalk 10.29.4.2 ifDescr interfaces.ifTable.ifEntry.ifDescr.1 : DISPLAY STRING- (ascii):  Ethernet0 interfaces.ifTable.ifEntry.ifDescr.2 : DISPLAY STRING- (ascii):  Serial0 interfaces.ifTable.ifEntry.ifDescr.3 : DISPLAY STRING- (ascii):  Serial1 interfaces.ifTable.ifEntry.ifDescr.4 : DISPLAY STRING- (ascii):  Loopback0 interfaces.ifTable.ifEntry.ifDescr.5 : DISPLAY STRING- (ascii):  Loopback253 interfaces.ifTable.ifEntry.ifDescr.6 : DISPLAY STRING- (ascii):  Serial0.1 interfaces.ifTable.ifEntry.ifDescr.7 : DISPLAY STRING- (ascii):  Serial0.2 interfaces.ifTable.ifEntry.ifDescr.8 : DISPLAY STRING- (ascii):  Serial0.3 interfaces.ifTable.ifEntry.ifDescr.9 : DISPLAY STRING- (ascii):  Serial0.4 interfaces.ifTable.ifEntry.ifDescr.10 : DISPLAY STRING- (ascii):  Serial0.5 interfaces.ifTable.ifEntry.ifDescr.11 : DISPLAY STRING- (ascii):  Serial0.6 interfaces.ifTable.ifEntry.ifDescr.12 : DISPLAY STRING- (ascii):  Serial0.7 interfaces.ifTable.ifEntry.ifDescr.13 : DISPLAY STRING- (ascii):  Serial0.8 interfaces.ifTable.ifEntry.ifDescr.14 : DISPLAY STRING- (ascii):  Serial0.9 interfaces.ifTable.ifEntry.ifDescr.15 : DISPLAY STRING- (ascii):  Serial0.100 interfaces.ifTable.ifEntry.ifDescr.16 : DISPLAY STRING- (ascii):  Async1 

Now, if a new circuit is added:

 %5> snmpwalk 10.29.4.2 ifDescr interfaces.ifTable.ifEntry.ifDescr.1 : DISPLAY STRING- (ascii):  Ethernet0 interfaces.ifTable.ifEntry.ifDescr.2 : DISPLAY STRING- (ascii):  Serial0 interfaces.ifTable.ifEntry.ifDescr.3 : DISPLAY STRING- (ascii):  Serial1 interfaces.ifTable.ifEntry.ifDescr.4 : DISPLAY STRING- (ascii):  Loopback0 interfaces.ifTable.ifEntry.ifDescr.5 : DISPLAY STRING- (ascii):  Loopback253 interfaces.ifTable.ifEntry.ifDescr.6 : DISPLAY STRING- (ascii):  Serial0.1 interfaces.ifTable.ifEntry.ifDescr.7 : DISPLAY STRING- (ascii):  Serial0.2 interfaces.ifTable.ifEntry.ifDescr.8 : DISPLAY STRING- (ascii):  Serial0.3 interfaces.ifTable.ifEntry.ifDescr.9 : DISPLAY STRING- (ascii):  Serial0.4 interfaces.ifTable.ifEntry.ifDescr.10 : DISPLAY STRING- (ascii):  Serial0.5 interfaces.ifTable.ifEntry.ifDescr.11 : DISPLAY STRING- (ascii):  Serial0.6 interfaces.ifTable.ifEntry.ifDescr.12 : DISPLAY STRING- (ascii):  Serial0.7 interfaces.ifTable.ifEntry.ifDescr.13 : DISPLAY STRING- (ascii):  Serial0.8 interfaces.ifTable.ifEntry.ifDescr.14 : DISPLAY STRING- (ascii):  Serial0.9 interfaces.ifTable.ifEntry.ifDescr.15 : DISPLAY STRING- (ascii):  Serial0.100 interfaces.ifTable.ifEntry.ifDescr.16 : DISPLAY STRING- (ascii):  Async1 interfaces.ifTable.ifEntry.ifDescr.17 : DISPLAY STRING- (ascii):  Serial0.200 

You can see that the new sub-interface is appended to the end of the ifTable. But if the router is reloaded, the interfaces will re-index:

 %6> snmpwalk 10.29.4.2 ifDescr interfaces.ifTable.ifEntry.ifDescr.1 : DISPLAY STRING- (ascii):  Ethernet0 interfaces.ifTable.ifEntry.ifDescr.2 : DISPLAY STRING- (ascii):  Serial0 interfaces.ifTable.ifEntry.ifDescr.3 : DISPLAY STRING- (ascii):  Serial1 interfaces.ifTable.ifEntry.ifDescr.4 : DISPLAY STRING- (ascii):  Loopback0 interfaces.ifTable.ifEntry.ifDescr.5 : DISPLAY STRING- (ascii):  Loopback253 interfaces.ifTable.ifEntry.ifDescr.6 : DISPLAY STRING- (ascii):  Serial0.1 interfaces.ifTable.ifEntry.ifDescr.7 : DISPLAY STRING- (ascii):  Serial0.2 interfaces.ifTable.ifEntry.ifDescr.8 : DISPLAY STRING- (ascii):  Serial0.3 interfaces.ifTable.ifEntry.ifDescr.9 : DISPLAY STRING- (ascii):  Serial0.4 interfaces.ifTable.ifEntry.ifDescr.10 : DISPLAY STRING- (ascii):  Serial0.5 interfaces.ifTable.ifEntry.ifDescr.11 : DISPLAY STRING- (ascii):  Serial0.6 interfaces.ifTable.ifEntry.ifDescr.12 : DISPLAY STRING- (ascii):  Serial0.7 interfaces.ifTable.ifEntry.ifDescr.13 : DISPLAY STRING- (ascii):  Serial0.8 interfaces.ifTable.ifEntry.ifDescr.14 : DISPLAY STRING- (ascii):  Serial0.9 interfaces.ifTable.ifEntry.ifDescr.15 : DISPLAY STRING- (ascii):  Serial0.100 interfaces.ifTable.ifEntry.ifDescr.16 : DISPLAY STRING- (ascii):  Serial0.200 interfaces.ifTable.ifEntry.ifDescr.17 : DISPLAY STRING- (ascii):  Async1 

The problem is how to know which interface you are actually polling. The preceding example makes it clear that you cannot poll a specific ifIndex and expect to always poll the same interface. The trick is to poll for a handle so you know which entry in the ifTable corresponds to the desired interface. There is an object (ifDescr) that fits the bill to a certain degree. Although ifDescr is descriptive enough to use in routers, in switches it only returns the type of interface: "10/100 utp Ethernet (cat 3/5)," for example. Not a very helpful description if you are looking for slot and port number.

There were several extensions to the ifTable defined in RFC 1573 (later superceded by RFC 2233) in the ifXTable. Two of these new objects can assist you in identifying which interface you are polling. One object is ifName. ifName is a DisplayString that will return the name of an interface such as "Serial0/0.2" for a router and "5/22" for a switch.

You may want your own definable handle to identify an interface. Another object, ifAlias, is a display string that returns whatever handle you assign to it. The alias can be configured either via an snmp set or via the interface configuration command:

description "string"

ifAlias takes the place of the deprecated lofIfDesc object from the OLD-CISCO-INTERFACES MIB.

However, ifAlias only applies to Cisco routers. Catalyst switches do not support ifAlias. Catalyst switches have implemented a different object that you may use as an identifying handle. Catalyst switches use the portName object in the portTable in Cisco's proprietary STACK MIB. You may set this alias with the following command:

set port name x/y

where x/y is the slot number/port number.

Special Considerations on Interface Counters

In SNMP, a counter is defined to count occurrences of a particular event such as the transmission of a bit or a packet. In general, an SNMP counter will count events starting at system initialization and keep increasing until the register hits the limit. That would be 2³² (or 4,294,967,296) for a 32-bit counter for example. Then, the counter wraps back to 0 and starts over. So an SNMP counter will go to 0 when the counter wraps or if the system reinitializes. When you are sampling counters, it is important to distinguish between when the counter wraps or when the counter is set back to 0 by a reload or reset. Generally, you can monitor the object sysUpTime in the mib-2 systems group to see how long the system has been operational. If your sampling of a counter detects that it went to 0, you can check sysUpTime to see whether the system was also reset during the last sampling period. If the system did not reset, it is reasonable to assume that the counter wrapped.

There are notable exceptions to the previous rule. When using show commands to troubleshoot a problem, it is common to use a command called clear counters to reset the show interface counters to 0. That action sets the counters to more sane levels so you can perceive increments in certain errors, etc. The exception here is a difference between the way the clear counters command was implemented on Cisco IOS on routers and on Cisco IOS on Catalyst switches:

• In routers, the clear counters command clears only the show interface counters. The SNMP counters remain intact.

• In Catalyst switches, the clear counters command clears both the show command counters and the SNMP counters. Both the show command counters and the SNMP counters are reset to zero.

So, on a Catalyst switch, an SNMP counter may go to 0 because of a wrap, a reset, or the execution of the clear counters command. The clear counters command on a Catalyst switch clears both port and mac counters for both show command and SNMP counters. To determine whether an SNMP counter has been reset to 0 by the clear counters command, there are two objects in the CISCO-STACK-MIB. sysClearMacTime and sysClearPortTime are similar to sysUpTime. They will tell you in TimeTicks how long it has been since that command was executed.

Special Considerations on High-Speed Interfaces

The original interface counters defined in mib-2 are 32-bit counters. For a 10 Mbps interface, a 32-bit counter could theoretically wrap in 57 minutes. Avoiding discontinuities is easy with such a long period. But for 100 Mbps, the minimum theoretical wrap time is 5.7 minutes. And for 1 Gbps interfaces, it falls to 34 seconds. Granted these times are for transmission of back-to-back full-sized packets, a theoretical ideal. Even so, the higher the interface speed, the harder it becomes to avoid missing a counter wrap. As a solution to this problem, SNMPv2 SMI defined a new object type counter64 for 64-bit counters. Therefore, there are several new 64-bit counters defined in the extension interface table (ifxTable) defined in RFC 1573 (later superceded by RFC 2233):

• ifHCInOctets

• ifHCInUcastPkts

• ifHCInMulticastPkts

• ifHCInBroadcastPkts

• ifHCOutOctets

• ifHCOutUcastPkts

• ifHCOutMulticastPkts

• ifHCOutBroadcastPkts

Although basic support for 64-bit counters was written into to router IOS in version 11.3, as of IOS 12.0, only ifHCInOctets and ifHCOutOctets have been implemented for ATM LANE LEC sub-interfaces only. For Catalyst workgroup switches, 64-bit counter support was implemented in version 3.1.

NOTE

You must use SNMPv2c or SNMPv3 protocol to retrieve any counter64 objects.