BPDU & CPU

Answered Question
Jan 15th, 2008
User Badges:
  • Gold, 750 points or more

Dear all


portfast blocks a port from sending or receiving BPDUs (as defined by documentation).


1-When Switch creates BPDU packets, and floods them. is this CPU handeled?


2- are BPDUs still forwarded to interface configured with portfast & bpdufilter and interface drops this traffic or does the switch simply not send any BPDUs to these ports.


I am planning to reduce baselined CPU level by removing SPT where not needed.


TIA


Sam



Correct Answer by Francois Tallet about 9 years 4 months ago

There are two kinds of bpdufilter: per-port bpdufilter or global bpdufilter (effective on portfast ports).

- per port bpdufilter is dangerous. As it was stated earlier, it filters both outgoing and incoming bpdus and can result in STP failing from protecting your network against accidental cabling error or misconfiguration. Furthermore, bpdus are always handled in software. So even when bpdufilter is configured on a port, the bpdu will be sent to the cpu for inspection, and this will roughly take as much cpu to discard the bpdu with bpdufilter as it would take with no bpdufilter (that's a reason why bpduguard can be useful, because if an edge port is hammered by bpdus, you'd rather bring it down to protect your cpu).

- global bpdufilter does not filter incoming bpdus. In fact, as soon as a bpdu is received on a port, this feature is disabled. It just filters out the outgoing bpdus. This can provide some cpu relief if you are running pvst with lots of edge trunks (trunks configured for portfast, with no L2 neighbor). That's not a frequent scenario. If you are running MST or PVST with access edge ports, you are only sending one bpdu per physical port, and configuring the feature will not save much on your cpu utilization.

HTH,

Francois

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Kevin Dorrell Tue, 01/15/2008 - 02:54
User Badges:
  • Green, 3000 points or more

Do you have a reference for that? AFAIK, portfast does not block the sending or receiving of BPDUs. It is bpdufilter that does that.


What portfast does is to skip the listening and learning phases, and to prevent the generation of TCNs towards the root every time the access port goes up or down. This prevention of TCNs from your access ports will save a lot of CPU on ALL your switches, and will improve your network stability.


I would strongly advise against enabling bpdufilter unless you have a specific good reason. BPDUs (and bpduguard) are your only defense against users doing unspeakable things with crossover cables, especially if you have portfast on your access ports.


Kevin Dorrell

Luxembourg


Jon Marshall Tue, 01/15/2008 - 02:56
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi Sam


Portfast does not block the port from sending or receiving BPDU's. A portfast enabled port still participates in STP. A portfast enabled port stops a TCN (Topology Change Notification) being sent when the port transitions from down to up and vice-versa.


The spanning-tree algorithm generally does not impact heavily on the CPU unless you exceed the maximum STP instances that the switch can support.


Jon

ankbhasi Tue, 01/15/2008 - 03:05
User Badges:
  • Cisco Employee,

Hi Sam,


1) Yes BPDU packets are handled by CPU. Software sends these packets to CPU for processing.


2) Portfast configured interfaces are still able to participate in STPand are still able to send and receice BPDUs. Its a known fact that this may result in STP loop if port is by mistake connected to other switches. Now there are 2 optional configuration which may prevent this kind of situations which is BPDU Guard and BPDU Filter.


If BPDU guard is configured then it thinks that portfast configured ports should not receive BPDU and if at all they receive this means there is a chance of STP loop and it puts the port in errdisable state.


If BPDU Filter is configured it prevents portfast ports in sending and receuving BPDUs with a minor exception that during link initilization a small number of BPDUs are sent before they are filtered by BPDU Filtering.


HTH


Ankur


*Pls rate all helpfull post

cisco_lad2004 Tue, 01/15/2008 - 03:34
User Badges:
  • Gold, 750 points or more

Apologies to all for my 1st line. of course I meant bpdufilter and not portfast.


Part of my question has been answered by Ankur.


for ports configured with bpdufilter, does switch/ cpu still try to flood BPDUs out of a port configured with bpdufilter and it is the interface that drops the message ?


what I need to clarify is whether cpu can still be affected by handling BPDUs even if all ports are configured with BPDUFILTER.


TIA


Sam

ankbhasi Tue, 01/15/2008 - 03:46
User Badges:
  • Cisco Employee,

Hi Sam,


When BPDU filter is configured it does not send or receive BPDUs but during link initilization a small number of BPDUs are sent before they are filtered by BPDU Filtering code block.


BPDUs are CPU processed so when there is a link initilization and even when ports are configured by BPDU Filter there will be a small number if BPDUs which will be processed by CPU but that will surely not affect your CPU utilization.


HTH


Ankur


*Pls rate all helpfull post


cisco_lad2004 Tue, 01/15/2008 - 04:15
User Badges:
  • Gold, 750 points or more

Thanks Ankur, this clarifies my doubts !


Sam

Correct Answer
Francois Tallet Tue, 01/15/2008 - 09:58
User Badges:
  • Gold, 750 points or more

There are two kinds of bpdufilter: per-port bpdufilter or global bpdufilter (effective on portfast ports).

- per port bpdufilter is dangerous. As it was stated earlier, it filters both outgoing and incoming bpdus and can result in STP failing from protecting your network against accidental cabling error or misconfiguration. Furthermore, bpdus are always handled in software. So even when bpdufilter is configured on a port, the bpdu will be sent to the cpu for inspection, and this will roughly take as much cpu to discard the bpdu with bpdufilter as it would take with no bpdufilter (that's a reason why bpduguard can be useful, because if an edge port is hammered by bpdus, you'd rather bring it down to protect your cpu).

- global bpdufilter does not filter incoming bpdus. In fact, as soon as a bpdu is received on a port, this feature is disabled. It just filters out the outgoing bpdus. This can provide some cpu relief if you are running pvst with lots of edge trunks (trunks configured for portfast, with no L2 neighbor). That's not a frequent scenario. If you are running MST or PVST with access edge ports, you are only sending one bpdu per physical port, and configuring the feature will not save much on your cpu utilization.

HTH,

Francois

cisco_lad2004 Tue, 01/15/2008 - 10:51
User Badges:
  • Gold, 750 points or more

Many thanks Francois !


so even if bpdufilter is enabled on the port, CPU is inspecting outgoing BPDUs only. incoming ones will disable portfast status and will therefore hit CPU anyway.

would you have a link documenting this ?


My reason for this whole conversation is we have 4510 deployed and though configured with only 5 VLANs, all modules are used (48 ports each) and trunking all VLANs. This resulted in a very large config file, so each time config is saved CPU hits the roof and occasionally crashed few switches.

CoPP is not supported on the IOS we are running and supervisor engine cannot be upgraded with more SDRAM . so, one of my options is to reduce the baseline CPU by looking at SPT then move on to mac address learning.


I don't expect comments on the above, but just thought I add some background info to make the post more interesting.

But if u have any suggestions on how this should be dealt with, I would be delighted.


Once again many thanks !


Sam


Francois Tallet Tue, 01/15/2008 - 11:00
User Badges:
  • Gold, 750 points or more

Hi Sam,

It seems that you are in the particular case where global BPDU filter will provide some relief. It will save the CPU from sending all those helpless BPDUs on all those ports x 5 vlans.

Now I said "helpless BPDUs" because I assume that the remote ports are not running STP. If you plan on receiving BPDUs on the ports, global BPDU filter will be disabled automatically anyway (because the port will lose its oper-portfast status and global bpdufilter is only working on port that are edge ports) and this would be the safe thing to do.

If you configure BPDU filter on the interface, you will not send BPDUs any more (saving CPU), you will not accept BPDUs any more (but they would still hit the CPU), and you would basically lose the added security provided by STP.

Regards,

Francois

Actions

This Discussion