cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
710
Views
0
Helpful
5
Replies

CAT5K SPANNING TREE high CPU utilization because of BPDU Rx

michael_tong
Level 1
Level 1

My Cat5K got 3x% CPU utilization. There is around 2x% used for stpBPDUrx process. I have 48 VLANs in my network. My Cat5K is the core switch and trunk the VLANs to the distribution. How can I find which port the receive BPDU come into this Cat5K?

5 Replies 5

milan.kulik
Level 10
Level 10

Hi,

first advice:

Is your network topology stable? If there is a flapping line, e.g., there might be topology changes detected causing STP instable and inferior BPDUs, e.g.

The best way how to detect unstable topology is to enable STP SNMP traps to be sent to your Network Management Station (HP OpenView or CiscoWorks). You can see STP TCN alarms then.

Second advice:

If the topology is stable, check the root port for each VLAN on your Cat5K (use sh spantree x for VLANx to detect it, then show spantree statistics [vlan] to see STP statistics for this port (VLAN on trunks) including the number od received BPDUs. The only root port should receive BPDUs in stable topology (I suppose you're running PVSTP).

Regards,

Milan

Thanks for your advices. Both are done before I post this case.

I have checked the TC counter. There is a number. But not increase continually. I believe that is because some port in the distribution layer switches without enable postfast.

There is only one root port of all vlans. It is a gigabit trunk on the sup3G. I also use the command "show spantree stat" to check the number of how many BPDU received. The output is:

......

......

PORT based information & statistics

config bpdu's xmitted (port/VLAN) 0(221540567)

config bpdu's received (port/VLAN) 793137(26128471)

......

......

I am not full understand the two numbers that follow "config bpdu's received (port/VLAN)". It seems the first number indecate this port receivce 793137 BPDU of this VLAN (it is a trunk port). But I don't know the what the second number mean for.

OK, the numbers explanation (from CatOS 7.5 Command Reference Guide):

"config bpdu's received (port/VLAN)- Number of BPDUs received by this port. The number in parentheses is the number of configured BPDUs received by the switch for this instance of spanning tree."

My understanding is that "this instance of spanning tree" means the whole VLANx.

I'd "clear spantree statistics ..." for all VLANs and the root port now and observe if there is any suspicious number of incoming BPDUs on the root port from some VLAN.

Regards,

Milan

Thanks again, Milan.

If the number in parentheses is the number of BPDU received by the switch of this VLAN, there is anohter problem...

My Cat5K is the backbone switch. There is only root port and designated port on it. And there is not blocked port. I use "show spantree blockport" to check it out. It show me "0"

Base on spanning tree theory, only root port and blocked port will received BPDU. There is only one root port on my Cat5K. Why the number is not match the number in the parentheses?

I also use the command "show spantree stat " to show the same-vlan port and trunk port one by one. Some of them are "0" receivced BPDU. Some of them are "1"/"2" received BPDU. I can not find another port with high BPDU received-rate.

I am worry if I clear the spantree statistics, I will loss some data to check the root problem out.

/Michael

Michael,

to the STP theory and BPDU numbers:

You are correct if the topology is absolutely stable.

But every time a trunk (or access line connecting two switches) goes down/up some BPDUs might be sent to both directions.

The statistics are cummulative since the switch has been reloaded.

So that's why I'd clear all the statistics - you will see what happens NOW in your network which is stable now. Also I'd clear VLAN statistics first - if you clear the port statistics first and VLAN statistics then you might see an output 30(0), e.g., which is a nonsense, of course. Clearing VLAN statistics doesn't clear port statistics as I would expect.

Regards,

Milan