Hi Vasanth, - Page 2

Monica Lluis · ‎01-19-2016

This session will provide an opportunity to learn and ask questions about how to troubleshoot CPU issues in the Cisco Catalyst Switches IOS architecture.

Ask questions from Monday, January 25 to Friday February 5, 2016

Featured Experts

Naveen Venkateshaiah is a customer support engineer in High-Touch Technical Services (HTTS). He is an expert on Routing, LAN Switching and Data Center products. His areas of expertise include Cisco Catalyst 3000, 4000, 6500, and Cisco Nexus 7000,Nexus 5000, Nexus 3000, Nexus 2000, UCS, and MDS SAN Switches. He has over 8 years of industry experience working with large enterprise and Service Provider networks. Venkateshaiah holds a CCNA, CCNP, and CCDP-ARCH, AWLANFE, LCSAWLAN Certification. He is currently working to obtain a CCIE in Data Center.

Abhishek Soni is a customer support engineer in High-Touch Technical Services (HTTS). He is an expert on Routing, LAN Switching and Data Center products. His areas of expertise include Cisco Catalyst 3000, 4000, 6500, and Cisco Nexus 7000. He has over 8 years of industry experience working with large enterprise and Service Provider networks. Soni holds a CCNA and CCNP Certification. He is currently working to obtain a CCIE in routing and switching.

Find other https://supportforums.cisco.com/expert-corner/events.

** Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions

I hope you and your love ones are safe and healthy
Monica Lluis
Community Manager Lead

Abhishek Soni · ‎02-04-2016

Hi Vasanth,

All the control plane protocols traffic go to CPU for processing. For example: STP, ARP, LACP and routing protocols hellos.

Following are other Causes for punting traffic to CPU:

- Fragmentation
- Same interface forwarding (to generate ICMP redirects)
- Destination not in routing table
- ACL log
- ACL deny
– no route packet (to generate ICMP unreachable)
- Forwarding exception (out of TCAM/adj space)
- Feature exception(out of TCAM space / conflict)
- SW supported feature (crypto, nbar, GRE)
- TTL=1
- IP options
- Multicast path setup
- Multicast RPF drops
- Platform specific traffic handling
- Forwarding path issues requires troubleshooting
- Glean (Packets requiring ARP resolution) / Receive(Packets falling in the Receive case)
- Packet destined to router
- A feature applied on ingress or egress interface causing packet to be process switched
- A field set on the packet which is not supported in hardware and requires process switching.

So above are the set of packets destined to CPU.

Following link will provide few more details.

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/troubleshooting/cpu_util.html?referring_site=RE&pos=2&page=http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4000-series-switches/65591-cat4500-high-cpu.html

Please let me know if you have any further questions.

Thanks,

Abhishek Soni

vasanth77 · ‎02-04-2016

Hi Abi,

thanks to share you experience,

Can you please give a example for the below points,so I can catch the exact.

-Platform specific traffic handling

- A feature applied on ingress or egress interface causing packet to be process switched
- A field set on the packet which is not supported in hardware and requires process switching.

-- Forwarding path issues requires troubleshooting

Abhishek Soni · ‎02-05-2016

Hi Vasanth,

Really nice question. I appreciate your interest. Please find my replies.

1.

====

Example for Platform specific traffic handling:-

GRE Tunnel not supported by 3750 but still can be configured. Even though this feature can be configured with CLI, the packets can be neither switched by hardware, nor by software, which increases the CPU utilization.

Only DVMRP tunnel interfaces are supported for multicast routing in the Catalyst 3750. Even for this, packets cannot be switched with hardware. It will be software processed.

Workaround - There is no workaround for this problem. This is a hardware limitation in the Catalyst 3750 Series Switches

Encrypted traffic:

If there is no Encryption Service Adapter (ESA) in the router, encrypted packets must be process-switched.

So there are built-in ASICs for some features in Hardware and they can be hardware switched. If not, packet will be software switched (processed by CPU).

Every platform has different limitation and way of traffic handling.

2.

=====

Example: A feature applied on ingress or egress interface causing packet to be process switched:-

Using an ACL with the log keyword - Since a log keyword requires a syslog message to be generated this must be punted to the RP CPU as it cannot be done in hardware. Remove the log keyword from the ACL.

Using a PBR route-map without a set statement - Any traffic that matches a PBR route-map with no set statement will be punted. This is due to the fact that we need to program the next-hop in hardware and if the next-hop is not known, this traffic must be punted to determine the next hop. Configure a set statement OR remove the policy route from the interface.

3.

====

Example: A field set on the packet which is not supported in hardware and requires process switching.

- Fragmentation: If packet needs to be fragmented when it needs to be sent out then we need to sent it to CPU as fragmentation cannot be done in hardware.

- TTL = 1 packets: Packets having TTL=1 and needs multicast routing are always sent to CPU

- Packets that require protocol translation

4.

====

Example: Forwarding path issues requires troubleshooting:-

- If a packet is coming to the switch, then ideally it has to be forwarded in Hardware. But there are no CEF/Hardware entries for the destination, packet will be punted to CPU. It means we need to check the forwarding path of that packet in the switch.

- the troubleshooting varies from platform to platform. Following document is an example about how incomplete CEF entries can caused the packets to be punted to CPU.

http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-120-mainline/47205-cef-whichpath.html

Please let me if you have any question on this. Thank you!

Best Regards,

Abhishek Soni

vasanth77 · ‎02-07-2016

Hi Abi,

Well explained.

Software switched means that Processed by CPU,then It lead to High CPU utilization.

If a hardware is not supported for a feature but it was configured on that device(SWITCH/Router),So at that time that process is handled by CPU ,so it utilize more of it CPU resources.

am I right?

This is the error came in a console of 7200 series router handling 350 Mbps traffic,It also configured for netflow export,I also tried to increase that aggregation cache to 128K,

Error log: Enqued to process level

26000 packets were dropped due to adjacency issue .

can You please tell me why it enqued to process level

I gone through one cisco document and I configured aggregation cache to 128 K,

but still those Netflow packets were not exported to NMS

For your reference Plz see this discussion

https://supportforums.cisco.com/discussion/12693551/enqueued-process-level-was-seen-router

Abhishek Soni · ‎02-08-2016

Thanks Vasanth!

If a feature is not supported by HW then it will be SW switched. Yes you are right here.

Every platform has different hardware capacity for netflow TCAM. If it is going above the size then you will see the packets are getting process switched.

Since we mainly support LANSW platfroms. I would request you to reach out to platform team who supports 7200 series routers.

Thanks for understanding!

robert.vizitiu1 · ‎01-26-2016

Hello Jessica,

Maybe an output of the "show int stats" can help you check how many packets are routed using processor.

A high number of packets through processor can indicate high cpu.

Robert

balamurugan48011 · ‎01-26-2016

Hi Naveen&Abi

I have some issue with my 6880 core switch,the problem is sometimes switch is getting 60 to 70 percentage high cpu utilization, not regularly.

I have attached some txt file for your reference.This file having show outputs of history , logg, span.

Could you please help me to find out the problem and suggest about troubleshoot also.

Thanks

Bala

Abhishek Soni · ‎01-27-2016

Hi Bala,

Thank you for reaching out. I have checked the logs and see consistent CPU is never going more than 30% (the '###') and we do see spikes going upto 70% (the '***'). I do not think if it is a reason to worry unless you see very frequent spikes.

if possible, you can provide me output of 'show process cpu sort' , when the CPU is high.

INEXO-M1-CS#show process cpu history

    2222333332222233333222222222222222333332222233333222222222
    5555000008888877777666669999955555000008888877777666669999
100
 90
 80
 70
 60
 50
 40               *****                         *****
 30 **********************************************************
 20 **********************************************************
 10 **********************************************************
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per second (last 60 seconds)

    3333443343333333333333343334333335333333333443333333333333
    7697228527383652336987627560742223436327887227966334346453
100
 90
 80
 70
 60
 50                                  *
 40 ********** * **   ***********    *  *  **********     * *
 30 ##########################################################
 20 ##########################################################
 10 ##########################################################
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

    5544545444455566444444644474445444545654554444454454445444454544445454
    3764170619220174468485264505971744141707016668619925858373763484651554
100
 90
 80
 70               *           *          *
 60  *            **      *   *          *                *    *        *
 50 *** **** * ***** ** **** *******  * ******************* * ** ** *****
 40 **********************************************************************
 30 ######################################################################
 20 ######################################################################
 10 ######################################################################
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%

balamurugan48011 · ‎01-27-2016

Thanks for your reply Abi,I understood your point, but my worry is that spikes reaching 70 percentage for some time.

could you please tell me about is this issue create any problem in our switch or not?

if creating any problem means what trouble shoot we need to do?

Regards,

Bala

Abhishek Soni · ‎01-27-2016

Hi Bala,

Your concern is right. But only if spikes are very frequent. In your case, I do not see any problem. To know why the CPU is spiking, you have to collect following output, when the CPU is high:

- show version

- show module

- show process cpu sort

In 'show process cpu sort', we can see if spikes are due to 'interrupt' or due to any process.

Like following:

INEXO-M1-CS#show process cpu | ex 0.00
CPU utilization for five seconds: 26%/0%

The '0%' in above output is interrupt. If that is increasing then it means CPU is spiking due to some traffic which is reaching to CPU and we need to capture it.

Please let me know if you have any question. Thank you!

balamurugan48011 · ‎01-27-2016

Hi Abi,

Thanks,I got it, if it is reaching more than 70 % means what could be the issue? and what are the troubleshoots we have to do? this is for basic knowledge.

Regards,

Bala

Abhishek Soni · ‎01-27-2016

Hi Bala,

I do not see any process eating much CPU. I think whenever you are seeing the must be due to 'interrupt'.

You can capture the packet which are hitting the CPU, using 'netdr' tool.

https://supportforums.cisco.com/document/59956/troubleshooting-netdr-capture-sup7206500

It captures '4096' packets and you can see where the most of the packets are coming from. You can trace the source IP/MAC and try to shut that port and see if issue gets resolved.

Thanks!

steve martin · ‎01-27-2016

I have a 4x 3750 switches linked with stackwise, I have a lot of replication jobs moving through the switches from SAN infrastructure. We are experiencing a lot of OSPF recalculations, causing temporary routing loss. This has reduced since adding a static. I think there is a problem with capacity with our switches rather than the ospf but would be interested to see what you think. It generally runs at 30 -40 % but spikes a lot see below.

111111111111111111111111111122222111111111111111111111111111
      666333333333355555888888888877777444443333322222333332222244
100
   90
   80
   70
   60
   50
   40
   30                             *****
   20 ***          ********************
   10 **********************************************************
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)

      222242232222222222492222322332212122322222232222492222223222
      878536818260385989276696357319697826087684008846267387330563
100                    *                             *
   90                    *                             *
   80                    *                             *
   70                    #                             #
   60                    #                             #
   50                    #                             #
   40     *             *#                            *#
   30 ********* * ******#*********** * ****** *** **#* ** **
   20 #########*#**#################**#**#######################
   10 ##########################################################
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

      999999999999999999999999999999999999999999999999999999999999999999999999
      876665356779687677786888877745555759688788888787877655544438325454446645
100 ****** ********************* **************************    * * *   **
   90 **********************************************************************
   80 **********************************************************************
   70 **********************************************************************
   60 **********************************************************************
   50 **********************************************************************
   40 **********************************************************************
   30 **********************************************************************
   20 ######################################################################
   10 ######################################################################
     0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
               0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%

Thanks

Steve

Abhishek Soni · ‎01-27-2016

Hi Steve,

Thanks for reaching out to us. Like you said, I can see a lot of CPU spikes happening, which indicates that some thing in your network is not stable. I would request you to collect following:

- show version

- show switch detail

- show logging

- show spann det | in ieee|from|occur|is exec

Also it would be great if you can get two iterations of following output when CPU is high:

- show controllers cpu-interface

- show process cpu sort | ex 0.00%

Thanks!

steve martin · ‎01-28-2016

Hello,

Thanks for responding, I'm currently not experiencing high cpu at this moment I'll add this information once I have it.

Cisco IOS Software, C3750E Software (C3750E-UNIVERSALK9-M), Version 15.0(2)SE, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Fri 27-Jul-12 23:26 by prod_rel_team

ROM: Bootstrap program is C3750E boot loader
BOOTLDR: C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(58r)SE, RELEASE SOFTWARE (fc1)

SHQ_SW_01 uptime is 17 weeks, 22 hours, 35 minutes
System returned to ROM by power-on
System restarted at 12:03:42 BST Wed Sep 30 2015
System image file is "flash:/c3750e-universalk9-mz.150-2.SE/c3750e-universalk9-mz.150-2.SE.bin"

If you require further assistance please contact us by sending email to
export@cisco.com.

License Level: ipbase
License Type: Permanent
Next reload license Level: ipbase

cisco WS-C3750X-12S (PowerPC405) processor (revision A0) with 524288K bytes of memory.
Processor board ID FDO1630Z0TX
Last reset from power-on
25 Virtual Ethernet interfaces
1 FastEthernet interface
172 Gigabit Ethernet interfaces
8 Ten Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.
512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address       : 60:73:5C:40:41:80
Motherboard assembly number     : 73-13329-03
Motherboard serial number       : FDO163009CJ
Model revision number           : A0
Motherboard revision number     : B0
Model number                    : WS-C3750X-12S-S
Daughterboard assembly number   : 800-32727-03
Daughterboard serial number     : FDO162922SK
System serial number            : FDO1630Z0TX
Top Assembly Part Number        : 800-35090-02
Top Assembly Revision Number    : B0
Version ID                      : V02
CLEI Code Number                : CMMFG00ARB
Hardware Board Revision Number : 0x04

Switch Ports Model              SW Version            SW Image
------ ----- -----              ----------            ----------
*    1 18    WS-C3750X-12S      15.0(2)SE             C3750E-UNIVERSALK9-M
     2 54    WS-C3750X-48P      15.0(2)SE             C3750E-UNIVERSALK9-M
     3 54    WS-C3750X-48P      15.0(2)SE             C3750E-UNIVERSALK9-M
     4 54    WS-C3750X-48P      15.0(2)SE             C3750E-UNIVERSALK9-M

Switch 02
---------
Switch Uptime                   : 17 weeks, 22 hours, 27 minutes
Base ethernet MAC Address       : FC:99:47:A0:A3:80
Motherboard assembly number     : 73-12553-06
Motherboard serial number       : FDO16340VKP
Model revision number           : F0
Motherboard revision number     : A0
Model number                    : WS-C3750X-48P-S
Daughterboard assembly number   : 800-32727-03
Daughterboard serial number     : FDO16340V83
System serial number            : FDO1634R1DT
Top assembly part number        : 800-31324-03
Top assembly revision number    : B0
Version ID                      : V03
CLEI Code Number                : COMJZ00ARC
License Level                   : ipbase
License Type                    : Permanent
Next reboot licensing Level     : ipbase

Switch 03
---------
Switch Uptime                   : 17 weeks, 22 hours, 27 minutes
Base ethernet MAC Address       : FC:99:47:A0:AC:80
Motherboard assembly number     : 73-12553-06
Motherboard serial number       : FDO16340VS8
Model revision number           : F0
Motherboard revision number     : A0
Model number                    : WS-C3750X-48P-S
Daughterboard assembly number   : 800-32727-03
Daughterboard serial number     : FDO16340UXQ
System serial number            : FDO1634R1EF
Top assembly part number        : 800-31324-03
Top assembly revision number    : B0
Version ID                      : V03
CLEI Code Number                : COMJZ00ARC
License Level                   : ipbase
License Type                    : Permanent
Next reboot licensing Level     : ipbase

Switch 04
---------
Switch Uptime                   : 17 weeks, 22 hours, 28 minutes
Base ethernet MAC Address       : 44:03:A7:9B:35:80
Motherboard assembly number     : 73-12553-08
Motherboard serial number       : FDO16491761
Model revision number           : K0
Motherboard revision number     : A0
Model number                    : WS-C3750X-48P-S
Daughterboard assembly number   : 800-32727-03
Daughterboard serial number     : FDO164912HM
System serial number            : FDO1649P1T6
Top assembly part number        : 800-31324-07
Top assembly revision number    : B0
Version ID                      : V04
CLEI Code Number                : COMJZ00ARD
License Level                   : ipbase
License Type                    : Permanent
Next reboot licensing Level     : ipbase

Configuration register is 0xF

SHQ_SW_01#show switch detail
Switch/Stack Mac Address : 6073.5c40.4180
                                           H/W   Current
Switch# Role   Mac Address     Priority Version State
----------------------------------------------------------
*1       Master 6073.5c40.4180     15     3       Ready
2       Member fc99.47a0.a380     13     3       Ready
3       Member fc99.47a0.ac80     11     3       Ready
4       Member 4403.a79b.3580     1      3       Ready

         Stack Port Status             Neighbors
Switch# Port 1     Port 2           Port 1   Port 2
--------------------------------------------------------
1        Ok         Ok                2        3
2        Ok         Ok                1        4
3        Ok         Ok                1        4
4        Ok         Ok                2        3

SHQ_SW_01#show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 8 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

No Inactive Message Discriminator.

    Console logging: level debugging, 5304 messages logged, xml disabled,
                     filtering disabled
    Monitor logging: level debugging, 5 messages logged, xml disabled,
                     filtering disabled
    Buffer logging: level debugging, 5261 messages logged, xml disabled,
                    filtering disabled
    Exception Logging: size (4096 bytes)
    Count and timestamp logging messages: disabled
    File logging: disabled
    Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 6857 message lines logged

Log Buffer (4096 bytes):
/0/47, changed state to up
.Jan 18 10:35:44.535: %CLEAR-5-COUNTERS: Clear counter on interface GigabitEthernet3/0/47 by Intrinsic on vty0 (10.28.8.204)
.Jan 18 10:39:55.066: %SYS-5-CONFIG_I: Configured from console by Intrinsic on vty0 (10.28.8.204)
.Jan 18 12:02:36.164: %SSH-3-BAD_PACK_LEN: Bad packet length -1469438230
.Jan 18 12:05:27.661: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet4/0/47, changed state to down
.Jan 18 12:05:28.667: %LINK-3-UPDOWN: Interface GigabitEthernet4/0/47, changed state to down
.Jan 18 12:05:33.457: %LINK-3-UPDOWN: Interface GigabitEthernet3/0/47, changed state to up
.Jan 18 12:05:35.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/0/47, changed state to up
.Jan 19 09:24:26.159: %SYS-5-CONFIG_I: Configured from console by Intrinsic on vty0 (10.28.8.204)
.Jan 27 11:22:10.395: %SYS-5-CONFIG_I: Configured from console by Intrinsic on vty0 (10.28.8.204)
.Jan 27 11:41:40.644: %SYS-5-CONFIG_I: Configured from console by Intrinsic on vty0 (10.28.8.204)

VLAN0001 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 21 last change occurred 7w2d ago
          from StackPort1
VLAN0010 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 26 last change occurred 13w0d ago
          from Port-channel17
VLAN0020 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 37 last change occurred 11w0d ago
          from Port-channel11
VLAN0030 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 28 last change occurred 13w0d ago
          from Port-channel17
VLAN0040 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 32 last change occurred 1w1d ago
          from Port-channel5
VLAN0050 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 26 last change occurred 13w0d ago
          from Port-channel17
VLAN0060 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 165 last change occurred 1w1d ago
          from Port-channel5
VLAN0070 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 135 last change occurred 1w2d ago
          from StackPort1
VLAN0080 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 27 last change occurred 13w0d ago
          from Port-channel17
VLAN0090 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 27 last change occurred 13w0d ago
          from Port-channel17
VLAN0099 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 17w0d ago
          from Port-channel38
VLAN0100 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 27 last change occurred 13w0d ago
          from Port-channel17
VLAN0110 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 23 last change occurred 13w0d ago
          from Port-channel17
VLAN0120 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 17w0d ago
          from Port-channel38
VLAN0130 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 14 last change occurred 1w1d ago
          from Port-channel5
VLAN0140 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 17w0d ago
          from Port-channel38
VLAN0150 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 13 last change occurred 1w1d ago
          from Port-channel5
VLAN0160 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 17w0d ago
          from Port-channel38
VLAN0165 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 117 last change occurred 7w2d ago
          from StackPort1
VLAN0166 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 11 last change occurred 17w0d ago
          from Port-channel38
VLAN0167 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 117 last change occurred 7w2d ago
          from StackPort1
VLAN0168 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 11 last change occurred 17w0d ago
          from Port-channel38
VLAN0170 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 238 last change occurred 1w0d ago
          from StackPort1
VLAN0180 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 7 last change occurred 17w0d ago
          from Port-channel38
VLAN0200 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 13 last change occurred 1w2d ago
          from StackPort1
VLAN0204 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 17w0d ago
          from Port-channel38
VLAN0208 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 17w0d ago
from Port-channel38
VLAN0212 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 17w0d ago
          from Port-channel38
VLAN0990 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 118 last change occurred 7w2d ago
          from StackPort1
VLAN0999 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 123 last change occurred 7w2d ago
          from StackPort1
VLAN1000 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 122 last change occurred 7w2d ago
          from StackPort1

Thanks

Ask the Expert: Troubleshooting High CPU in Catalyst Switches