Understanding Cisco Switch Monitoring: Resource Impact And Efficiency

Monitoring the resource load on a Cisco switch is a critical aspect of network management. The switch's Central Processing Unit (CPU) plays a pivotal role in its overall performance, and high CPU utilisation can lead to various issues. Cisco switches offer tools to monitor and troubleshoot CPU usage, helping administrators ensure optimal performance and stability.

The `show processes cpu` command is a fundamental tool for analysing CPU utilisation on Cisco switches. It provides insights into the average CPU utilisation over different time periods, such as the last five seconds, one minute, and five minutes. Additionally, the `show processes cpu history` command displays a historical graph of CPU usage, helping identify spikes and patterns.

Other commands, such as `show version`, `show interfaces`, and `show memory`, provide complementary information about the switch's performance and resource utilisation. By regularly monitoring these metrics and analysing CPU usage patterns, administrators can identify potential bottlenecks and fine-tune the switch's configuration to optimise its performance.

Furthermore, Cisco switches offer features like the Embedded Event Manager (EEM) for automated data collection during high CPU conditions, providing detailed insights for troubleshooting. Understanding CPU utilisation and managing resource load effectively are essential for maintaining a stable and efficient network infrastructure.

CPU Utilization Overview

The CPU of a Cisco switch has two distinct functions when the boot process is complete: running different processes under IOS to carry out the function of a switch operating in a network, and sending/receiving packets to/from the switching hardware. The CPU performs both of these functions simultaneously.

The CPU becomes too busy when either an IOS process consumes too much CPU time or the CPU receives too many packets from the switching hardware. When either of these two CPU consumers requires the CPU resource to the detriment of the other, the CPU is too busy. For example, the CPU may be receiving a lot of packets from the hardware because of a broadcast storm on the network. In this case, the CPU is so busy processing all the received packets that the other IOS processes aren't given access to the CPU resource. This is just one example of a possible root cause for high CPU utilization.

Under normal operating conditions, on a non-stackable switch at a minimum, the CPU will have a certain baseline utilization. Depending on the model and the type being used, this can range from 5% to 40%. If the switch is stacked, the CPU will operate normally a few percent higher. The number of members in the stack makes a difference to the overall CPU utilization. In a stacked switch, the CPU utilization is measured on the master switch only. If the CPU is busy 5% of the time, it is idle the other 95% of the time. The switch will never report CPU utilization at 0%. There are multiple background IOS processes running on timers that execute multiple times a second, which is why even in the simplest of deployments, the switch never reports 0% CPU utilization.

The switch CPU utilization can be determined by entering the `show processes cpu sorted privileged EXEC` command. The output shows how busy the CPU has been in the past 5 seconds, the past 1 minute, and the past 5 minutes. The output also shows the utilization percentage that each system process has used in these periods.

To find CPU usage due to the subprocesses and tasks operating under a specific process, use the `show process cpu detailed` command. To sort for high activity usage, use the `show process cpu sorted` command.

CPU usage can be monitored on a per-switch basis in a stacked environment. It is recommended that the following variations of the `show process cpu` command are run at periodic intervals:

> Note: The switch is a multicore platform that is different from its predecessors. A single core can experience high CPU, so it is important to monitor each core when running these commands.

In some instances, high CPU utilization is normal and does not cause network problems. High CPU utilization becomes a problem when the switch fails to perform as expected.

The CPU utilization history shows only the total CPU utilization over time. It does not show the CPU time spent at the interrupt level. Knowing the time spent at the interrupt level is critical for determining the cause of CPU utilization. The CPU utilization history shows when the CPU is consistently receiving network packets, but it does not show the cause.

If the CPU utilization percentage is high and the interrupt percentage is low, the high CPU utilization is caused by one or more system processes consuming the CPU resource. This is less common than high CPU utilization caused by the receipt of network packets. When a system process is consuming most of the CPU resources, an event usually triggers the process to become active. Review the syslog for any unusual events.

Troubleshooting High CPU Utilization

To troubleshoot common high CPU utilization problems, follow these steps:

• Issue the "show processes cpu" command to identify the Cisco IOS processes consuming CPU cycles.
• Use the "show platform health" command to further identify platform-specific processes.
• Check the CPU queue that receives traffic to identify the type of CPU-bound traffic.
• Identify the root cause and take corrective action or adjust configurations.

High CPU utilization can be caused by various factors, including process-switched packets, a high number of spanning-tree port instances, ICMP redirects, IPX or AppleTalk routing, and more. It is important to understand the specific processes and traffic types contributing to high CPU utilization to effectively troubleshoot and resolve the issue.

CPU Utilization History

To view the CPU Utilization History, the "show processes cpu history" command can be used. This command will provide a graphical representation of the CPU utilization over the specified time period. The output will show how busy the CPU has been and whether there have been any spikes in utilization.

It's important to note that the CPU utilization history may not always reflect the real-time CPU load. In some cases, additional monitoring tools may be required to get an accurate picture of the current CPU load.

The CPU utilization history can be used to identify potential issues with the switch. For example, if the CPU utilization exceeds the normal operating baseline for an extended period of time, it may indicate a problem with the switch. Additionally, frequent spikes or sudden jumps in CPU utilization may also be a cause for concern.

By analyzing the CPU Utilization History and identifying any abnormal behavior, network administrators can take corrective actions to optimize the performance of the Cisco switch.

CPU Utilization Commands

To determine the CPU utilisation of a Cisco switch, the following commands can be used:

• `show processes cpu sorted` - This command shows the CPU utilisation for the last 5 seconds, 1 minute and 5 minutes. It also shows the utilisation percentage that each system process has used in these periods.
• `show processes cpu history` - This command shows the CPU utilisation for the last 60 seconds, 60 minutes and 72 hours. The output provides a graphical view of how busy the CPU has been.
• `show process cpu` - This command displays the CPU and core processor usage.
• `history` - This command displays a graph of sustained CPU utilisation.
• `show ip traffic` - This command displays a count of IP packet types received by the switch.
• `show platform ip unicast statistics` - This command shows the number of punted IP packets.
• `show platform port-asic stats drop` - This command shows the CPU receive-queue discard counts.
• `show platform tcam utilisation` - This command shows the TCAM maximum capacity and usage.

CPU Utilization Solutions

Cisco switches have two distinct functions: running processes under IOS and sending/receiving packets to/from the switching hardware. When the CPU is too busy, it is likely that an IOS process is consuming too much CPU time or the CPU is receiving too many packets from the switching hardware.

Solutions

Limit Network Packets to the CPU

To prevent problem network packets from impacting CPU utilisation, stop them at the ingress interface. Use the following interface configuration command:

> storm-control { broadcast | multicast | unicast } level { level [ level-low ] | bps bps [ bps-low ] | pps pps [ pps-low ]}

If the root cause of high CPU utilisation is a Layer 2 loop, the spanning tree configuration could be the problem.

Policing Traffic

Policing traffic can limit the number of packets that enter a switch. It can deny ingress traffic, limit it to a specific bit-per-second rate, or permit some traffic while limiting other traffic. Policing can be done on the MAC address, the IPv4 header, the IPv6 header, or the Layer 4 port number.

Configure Dynamic ARP Inspection (DAI)

To prevent IP ARP packets from affecting CPU utilisation on Layer 3 switches, configure DAI and enter the following interface configuration command:

> ip arp inspection limit { rate pps [ burst interval seconds ] | none }

Change the SDM Template

The switch database management (SDM) template allocates the limited TCAM resources for different forwarding types. To resolve TCAM utilisation issues, choose the appropriate SDM template for the switch application. Use the following command to see the active SDM template:

> show sdm prefer

The default template on this switch allows only 2048 indirect Layer 3 routes in the TCAM. To allocate more TCAM resources to indirect Layer 3 routes, reduce some other TCAM resources. Use the following command to change to a template that reserves more resources for IP routing:

> sdm prefer template-name

To see a list of available SDM templates for your switch, use the following command:

> show sdm templates all

Optimise IP Routes

When it is not possible or practical to change the SDM template on a Layer 3 switch, reduce the number of routes in the TCAM by using summary routes or by filtering routes.

Using summary routes reduces the routing table size. Route summary is enabled by default for RIP and EIGRP and disabled by default for OSPF.

You can use route filtering to prevent unwanted routes from being programmed into the TCAM.

Frequently asked questions