Performance Data for Switch Processors

As with routers, switches have performance variables that need to be monitored. This section identifies some MIB variables, as well as CLI output variables that are important to watch for switches.

MIB Variables for Switch Backplane Utilization

From CISCO-STACK MIB, two variables for monitoring switch backplane utilization are as follows:

• sysTraffic

• sysTrafficMeter

The sysTraffic and sysTrafficMeter MIBs report the percentage of bandwidth utilization for the previous polling interval. sysTrafficMeter is the newer MIB object based on the System Traffic table, whereas sysTraffic is the original MIB object from the CISCO-STACK MIB. With the newer Supervisor III cards, which "touch" all three backplanes in the 5500 series switches, there are three different backplane percentages, one for each. This MIB object is gathered from sysTrafficMeter with sysTrafficMeterType of switchingBusA, B, or C. sysTraffic is equivalent to sysTrafficMeter, where switchTrafficMeterType equals systemSwitchingBus.

These MIB objects are important to assist in monitoring the backplane performance of the switch. All traffic must traverse the backplane of the switch to get to the appropriate destination ports. Typically, the utilization on the backplane is very small, due to the near wire rate speeds. You may find it more beneficial to monitor the sysTrafficPeak and sysTrafficMeterPeak if the utilization of the backplane is consistently low. These peak values are cleared when the system resets or when the port counters are cleared.

The recommended baseline thresholds for backplane utilization are 30 percent for the low threshold and 50 percent for the high threshold.

CLI Commands for Switch Processor Backplane Statistics

The show system and show traffic commands provide information related to that provided by the sysTraffic and sysTrafficMeter MIBs

Using the show system Command

A show system command output displays the current traffic percentage seen on the backplane of the switch, as well as the peak traffic percentage and the time it peaked. Switch hardware status indicators are also reported in this output, along with the system uptime.

The important data in this output are the traffic percentage, the peak backplane percentage, and the peak time. Correlations can be done between like switches in the network regarding the peak time to help determine possible issues. The traffic utilization number here is representative of the backplane speed of 1.2 Gbps. For a look at all three backplanes, as seen on the 5500 series switches with Supervisor III cards, refer to the show traffic command.

Example 11-8 shows sample output for show system.

Example 11-8 Using show system to obtain information on switch backplane usage.

 Console> show system PS1-Status  PS2-Status  Fan-Status Temp-Alarm  Sys-Status Uptime d,h:m:s  Logout ----------  ----------  ---------- ----------  ---------- --------------  ------ ok          none        ok          off         ok        3,02:08:53      20 min PS1-Type    PS2-Type Modem     Baud  Traffic  Peak      Peak-Time --------    -------- -----     ----  -------  -------  ------------------------- WS-C5008A   none     disable   9600  0%A      0%B       Wed Oct 22 1997, 14:17:56C System Name       System Location   System Contact ----------------- ----------------- ------------------------ Catalyst 5000     San Jose, CA      Susan x237 

The relevant information from Example 11-8 is as follows:

A "Traffic" refers to the current backplane utilization as it relates to the 1.2 Gbps backplane.

B "Peak" refers to the peak backplane utilization seen since the last reboot or the last clearing of the port counters.

C "Peak-Time" is the time at which switch reached its peak backplane utilization. This is important to track in order to compare to possible issues in the network that occur at roughly the same time. The ability to make such comparisons is why it is a good idea to keep all switches synchronized with respect to the time and date.

Using the show traffic Command

This command applies to the Supervisor III card engines only and is representative of all three 1.2 Gbps backplane utilizations in the switch, A, B, and C. The current and peak utilizations and peak time are displayed. The command will show up only in switches that have the Supervisor III card.

The output from this command identifies the usage on each 1.2 Gbps backplane as it applies to the Catalyst 5500 series switches. Typically, the traffic percentages should be the same across all backplanes. The newer line cards, such as gigabit ethernet, use all three backplanes when transmitting and receiving frames, whereas the older line cards, such as the 10/100 ethernet cards, use only one of the backplanes. It is important to note the slot layout in the 5500 chassis to understand what cards can go where. See Chapter 10 for details relating to the slot/bus dependencies.

Example 11-9 shows sample output for show traffic.

Example 11-9 Using the show traffic command to get information on switch backplane utilization.

 Console> sh traffic Switching-Bus Traffic  Peak     Peak-Time ------------- ------- ------- ------------------------- A             5%A      10%B     Thu Jun 18 1998, 22:45:20 C B             4%A      15%B     Fri Nov 13 1998, 09:59:31C C             6%A       8%B     Fri Nov 13 1998, 11:30:13 C 

The following information is of interest in Example 11-9:

A "Traffic" refers to the current backplane utilization as it relates to the appropriate 1.2 Gbps backplane.

B "Peak" refers to the peak backplane utilization seen since the last reboot or the last clearing of the port counters.

C "Peak-Time" is the time at which the switch reached its peak backplane utilization. This is important to track in order to compare to possible issues in the network that occur at roughly the same time. This is a reason why the use of NTP in the network can assist in this correlation. See the section entitled "Setting Up NTP" in Chapter 18 for more information.

CLI Commands for Monitoring Traffic Utilization on NMP

There are really no MIB objects to look at relating to the processor traffic or the NMP (Network Management Processor) on the switch. You must rely mainly on show commands to get this information specifically, show netstat interface and show netstat stats.

The command show netstat interface, in conjunction with show netstat stats, indicates the amount of traffic hitting the NMP along with the IP traffic destined to the switch, such as SNMP, Telnet sessions, or ICMP pings.

These two commands are useful for baselining the amount of traffic, necessary or unnecessary, hitting the processor on the switch. Ideally, the amount of traffic destined to and from the switch's NMP should be minimal and the majority should be IP. Unnecessary traffic would be frames such as broadcasts from user segments, which indicate that the sc0 port on the switch is in the same VLAN as the user traffic. It is recommended to keep the NMP (sc0) interface off the user segment VLANs to avoid this unwanted traffic; otherwise, the processor can get bogged down processing these frames. Looking at both the IP traffic and total NMP traffic allows you to draw a comparison between the IP and "other" packets. IP traffic is typically the traffic destined to the switch, such as Telnet sessions, SNMP requests, and ICMP pings. Other traffic typically seen on the NMP is BPDUs for all VLANs.

Example 11-10 provides example output for both show netstat interface and show netstat stats.

Example 11-10 Using show netstat interface and show netstat stats to get switch backplane utilization information.

 Switch> sh netstat int Interface          InPackets    InErrors OutPackets OutErrors sl0                        0           0          0         0 sc0                    50000A          0     32000 B        0 Interface Rcv-Octet             Xmit-Octet --------- -------------------- -------------------- sc0       60000C                20000D s10       0                     0 Interface Rcv-Unicast           Xmit-Unicast --------- -------------------- -------------------- sc0       100000E                20000F s10       0                     0 Switch> sh netstat stats udp:         0 incomplete headers         0 bad data length fields         0 bad checksums         0 socket overflows         103 no such ports tcp:         161 G packets sent                 85 data packets (139 bytes)                 0 data packets (0 bytes) retransmitted                 68 ack-only packets (64 delayed)                 0 URG only packets                 0 window probe packets                 4 window update packets                 4 control packets         122 packets received                 87 acks (for 141 bytes)                 4 duplicate acks                 0 acks for unsent data                 111 packets (6375 bytes) received in-sequence                 0 completely duplicate packets (0 bytes)                 0 packets with some dup. data (0 bytes duped)                 0 out-of-order packets (0 bytes)                 0 packets (0 bytes) of data after window                 0 window probes                 0 window update packets                 0 packets received after close                 0 discarded for bad checksums                 0 discarded for bad header offset fields                 0 discarded because packet too short         2 connection requests         0 connection accepts         2 connections established (including accepts)         2 connections closed (including 0 drops)         0 embryonic connections dropped         87 segments updated rtt (of 89 attempts)         0 retransmit timeouts                 0 connections dropped by rexmit timeout         0 persist timeouts         2 keepalive timeouts                 2 keepalive probes sent                 0 connections dropped by keepalive ip:         293488 H total packets received         0 bad header checksums         0 with size smaller than minimum         0 with data size < data length         0 with header length < data size         0 with data length < header length         0 fragments received         0 fragments dropped (dup or out of space)         0 fragments dropped after timeout         0 packets forwarded         0 packets not forwardable         0 redirects sent icmp:         Redirect enabled         24 calls to icmp_error         0 errors not generated 'cuz old message was icmp         Output histogram:                 echo reply: 3                 destination unreachable: 24         0 messages with bad code fields         0 messages < minimum length         0 bad checksums         0 messages with bad length         Input histogram:                 echo reply: 67808                 destination unreachable: 24                 echo: 3         3 I message responses generated 

Here are the relevant data from Example 11-10:

A "InPackets" are the total amount of all packets received on the NMP.

B "OutPackets" are the total amount of all packets transmitted from the processor (NMP).

C "Rcv-Octet" is the total amount of bytes received on the NMP. From this value, in conjunction with the "receive packet" count, you can determine the traffic utilization of the NMP, as well as the average packet sizes hitting the NMP. Refer to Chapter 4, "Performance Measurement and Reporting," for utilization formulas.

D "Xmit-Octet" is the total amount of bytes transmitted from the processor. Because the backplane interface from the processor is full-duplex, you can determine the outbound utilization for the NMP as well. Based on the utilization formula defined in Chapter 4, you can use the Outpackets and Xmit-octets to get your result, but typically the NMP won't be sending a lot of information. You really should need to focus only on the inbound packets to get utilization numbers for the processor.

E "Rcv-Unicast" is the total amount of unicast packets received on the processor. From this value, along with "InPackets," you can determine the amount of broadcast and multicasts hitting the NMP by using Equation 11-2:

Equation 11-2

F "Xmit-Unicast" is the total amount of unicast packets sourced from the processor (NMP). There is no need to calculate broadcast utilization on the outbound side of the processor because the switch sources few, if any, broadcast packets.

G TCP "packets sent" is one of two counters you can use to figure out how many IP packets were sourced from the switch because these are the only two counters for transmit. The other counter is ICMP "message response generated."

H IP "total packets received" is the total amount of IP packets destined to the switch processor (NMP).

I ICMP "message response generated" is the total amount of ICMP packets, such as ping, sourced from the processor. Used in conjunction with TCP packets sent, it basically gives you the total amount of IP packets transmitted from the processor.

MIB Variables for Dynamic CAM Entries

From the BRIDGE-MIB, which is extracted from RFC 1493, you can use the dot1dTpFdbAddress from the dot1dTpFdbTable, where the value is equal to 3 or "learned," to determine what MAC addresses are in the forwarding table on the switch. This value is stored as a unicast MAC address for which the bridge has forwarding and/or filtering information. These MAC address values alone don't mean much and can produce a lot of data. Therefore, you need to count the number of entries and store that count value, based on a dot1dTpFdbStatus equal to "learned" (value of 3).

Trending MAC address data is valuable for keeping track of the total number of CAM entries (MAC addresses) learned dynamically by the switch. This monitoring helps keep track of the "flatness" in your network, especially when correlating to the total number of VLANs per switch. For example, if you have one VLAN defined on the switch and you see 8,000 MAC addresses, you know you have 8,000 MAC addresses for one VLAN, which is extensive for one subnet.

Because the CAM aging time, by default, is five minutes, you should gather the CAM table frequently. For example, poll for the data prior to your busy time and then maybe once during your busy time. Because users can turn off their computers when they leave for the day, it is wise to snapshot the CAM table during the day when computers are up and active to find the maximum CAM entries learned. There is more than enough memory to store up to 16,000 MAC address in the bridge (forwarding) table on the Catalyst 5xxx series switches.

The recommended baseline threshold is 8,000 entries or 50 percent of the maximum entries allowed per switch. The numbers should be much smaller per subnet or VLAN. Depending on the type of traffic per VLAN, the number of CAM entries can vary. If there is nothing but TCP/IP traffic, 500 nodes may the limit, whereas on Appletalk segments, 200 may be the limit.

A related MIB object from the BRIDGE MIB (RFC 1493) is dot1dTpFdbStatus. This MIB provides the status of the MAC address entry.

The meanings of the values are as follows:

• other(1): none of the following. This would include the case where some other MIB object (not the corresponding instance of dot1dTpFdbPort, nor an entry in the dot1dStaticTable) is being used to determine if and how frames addressed to the value of the corresponding instance of dot1dTpFdbAddress are being forwarded.

• invalid(2): This entry is no longer valid (for example, it was learned but has since aged out), but has not yet been flushed from the table.

• learned(3): The value of the corresponding instance of dot1dTpFdbPort was learned, and is being used.

• self(4): The value of the corresponding instance of dot1dTpFdbAddress represents one of the bridge's addresses. The corresponding instance of dot1dTpFdbPort indicates which of the bridge's ports has this address.

• mgmt(5): The value of the corresponding instance of dot1dTpFdbAddress is also the value of an existing instance of dot1dStaticAddress.

CLI Commands for CAM Entries

The output from show cam dynamic shows the MAC addresses, the VLAN, the port the MAC is learned on, and the total number of dynamically learned CAM entries (MAC addresses) on the Catalyst series switches, excluding the XL series. The show cam count dynamic command shows only the total CAM entries learned.

The output from show cam count dynamic may be an easier way than using SNMP to get the data you're ultimately looking for, especially if you are concerned about the amount of data flowing over your network. With this command, you don't have to grab the whole forwarding table and then act on it.

Example 11-11 shows sample output from show cam dynamic.

Example 11-11 Using show cam dynamic to get CAM entry information.

 Switch> sh cam dynamic VLAN  Destination MAC     Destination Ports or VCs ----  ------------------  ------------------------ 5A    00-60-2f-44-f6-99   2/52B 5     00-10-0b-c2-bb-fe   4/1 5     00-60-3e-cd-71-ac   2/61 5     00-90-92-b8-63-ff   2/61 Total Matching CAM Entries = 4 C Switch> sh cam count dynamic Total Matching CAM Entries = 4 C 

The information highlighted in Example 11-11 is as follows:

A "VLAN" shows what VLAN the appropriate MAC address resides in.

B "Destination Ports or VCs" displays the port or ATM VC (LANE) where the MAC address originates.

C "Total Matching CAM Entries" is the total number of MAC address entries seen by the switch.

MIB Variables for Calculating Logical Ports

Five MIBS need to work together to determine the number of logical ports configured on the switch. From CISCO-STACK-MIB, they are as follows:

• portIndex

• vlanIndex

• vlanPortIslVlansAllowed

• vlanSpantreeEnable

• vlanPortIslOperStatus

PortIndex, vlanIndex, and vlanPortIslVlans are used to enumerate the number of ports and VLANS on the switch. vlanSpantreeEnable is used to determine whether the vlan is running spanning tree, which is required to determine logical ports, and vlanIslOperStatus is used to determine what ports are trunks. For non-ISL-based trunk ports, such as 802.1q and 802.10, the vlanIslOperStatus, in conjunction with the vlanIslAdminStatus, will dictate what ports are trunk ports in those configurations. VLAN indexing is described in detail in the section "MIBs to Monitor for Spanning Tree Topology Changes" in Chapter 15, "Monitoring VLANs."

On your Catalyst 5xxx series switch, ensure that the sum of the logical ports across all instances of spanning tree for different VLANs does not exceed the number allowed for each supervisor engine type and memory configuration. Refer to Equation 11-3 and the following port constraints based on the Supervisor cards to compute this sum. Practical port constraints (not based on the Catalyst Series Release note) are the following:

• 250 for Supervisor Engine I (with 20 MB DRAM)

• 1000 for Supervisor Engine II

• 1000 for Supervisor Engine III (with fiber connections)

• 2500 for Supervisor Engine III

  Equation 11-3

  

  
  

Equation 11-3 is taken from the "Release Notes for the Catalyst 5000 Series Switches" available on CCO. See the References at the end of this chapter for the specific URL reference.

NOTE

When using Fast EtherChannel, be sure to count each port independently, not as one trunk. In addition, reduce the number of allowed spanning tree instances given in the formula for the number of logical ports when using Fast EtherChannel. This reduction will depend upon your specific topology.

In the formula, an ATM trunk is an ATM interface with a LAN Emulation Client (LEC) or an RFC 1483 PVC.

The recommended baseline threshold for number of logical ports is 50 percent of the total amount allowed, based on supervisor hardware version.

CLI Commands for Calculating Logical Ports

The show version command is helpful for getting the total number of physical ports installed on the switch. The show trunk command displays the total amount of trunk ports and the total number of VLANs per trunk port on the switch.

From these two commands, you can get the variables or calculate the variables needed to determine the amount of logical ports on the switch, based on the previous formula. You have to use the configuration to indicate which ports have spanning tree enabled and which ones don't. Only ports with spanning tree enabled apply to the formula.

Tracking of the logical ports can also help determine whether VTP, or Virtual Trunking Protocol, pruning needs to be turned on for the trunks, in order to restrict unnecessary VLANs from populating the switch.

TIP

There is no need for a switch to know about a particular VLAN if there are no users in that VLAN hanging directly off that switch or if the switch is acting as a transit switch for other users.

Example 11-12 shows sample output from the show version and show trunk commands.

Example 11-12 Using show version and show trunk to get information on the number of logical ports.

 Switch> show version WS-C5505 Software,Version McpSW:4.1(1)NmpSW:4.1(1) Copyright (c) 1995-1998 by Cisco Systems NMP S/W compiled on Jun 19 1998,11:55:01 MCP S/W compiled on Jun 19 1998,11:48:25 System Bootstrap Version:3.1.2 Hardware Version:1.0 Model:WS-C5505 Serial #:066058343 Mod  Port   Model         Serial #        Versions ---  ----  ------------   --------------- -------------------------- 1    2 A    WS-X5530      007472986       Hw : 1.5                                           Fw : 3.1.2                                           Fw1: 3.1(2)                                           Sw : 4.1(1) 3    1      WS-X5302      006809652        Hw : 4.5                                           Fw : 20.7                                           Fw1: 2.2(4)                                           Sw : 11.2(14)P, 4    12     WS-X5213      001906072       Hw : 1.0                                           Fw : 1.4                                           Sw : 4.1(1) 5    12     WS-X5203      007573748       Hw : 1.1                                           Fw : 3.1(1)                                           Sw : 4.1(1)             ...             ... etc. Switch> sh trunk Port      Mode         Encapsulation  Status        Native vlan --------  -----------  -------------  ------------  -----------  5/1A        on                           isl    trunkingB       1 Port      Vlans allowed on trunk --------  ----------------------------------------------------------------  5/1      1-1005 Port      Vlans allowed and active in management domain --------  ----------------------------------------------------------------  5/1 A                  1-4,6-10C Port      Vlans in spanning tree forwarding state and not pruned --------  ----------------------------------------------------------------  5/1      1 

Information of interest in Example 11-12 is as follows:

A "Port" is the total number of ports per module. Summing up these ports for all modules will give you the total number of ports for the switch. Under the show trunk output, each unique port number is displayed. Thus, all you need to do is total up the amount of ports shown under the command to get total number of trunk ports associated with the switch.

B "Status" indicates which trunk ports are in the ACTIVE trunking state.

C "Vlans allowed and active…" are the VLANs that are allowed to traverse each trunk port. Summing up all unique instances of VLANs per trunk port will give you the total number of VLANS per trunk port.

Related commands are the following:

• show port: Provides the trunking status for the ports, but not for the ATM interfaces.

• show vlan: Provides the number of VLANS assigned to the switch.