cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2385
Views
0
Helpful
9
Replies

STP Question Concerning BPDU's

Dean Romanelli
Level 4
Level 4

Hi All,

I have a question about STP and BPDU's.  If a port in a redundant topology stops recieving BPDU's, it runs the risk of erroneously moving to the forwarding state.  However, things like BPDUGuard and BPDUFilter prevent ports from recieving BPDU's, and are usually applied on edge ports.

So, if ports need to recieve BPDU's to know the status of the topology, why would we want to prevent any ports from recieving those BPDU's?  That would seem to suggest edge ports with these features enabled constantly believe the topology is in a failed state.

Can someone clarify?

Thanks,

9 Replies 9

Simon Leigh
Level 1
Level 1

Hi there.

Normally you would use BPDU Guard on a n edge port where servers/workstations connect so if someone 'accidentally' plugs in a switch the port goes into err disable and prevents network issues.

Sent from Cisco Technical Support iPhone App

Aninda Chatterjee
Cisco Employee
Cisco Employee

Hi Dean,

As a network administrator, you'd want to configure portfast enabled ports (or edge ports, as it is termed in Rapid-PVST+) when these ports go to servers, end user workstations etc as Simon has very correctly stated. These are ports where you never expect to receive a BPDU.

The receipt of a BPDU on such a port would not be normal according to your network and this needs to be prevented. What if an end user plugged in a really old switch into one such port and it happened to have the best priority in your network? You would suddenly have your entire layer 2 switched network converging towards this really old closet switch (this is under the situation where there are no spanning-tree best practices deployed, of course).

The above scenario and others alike are reasons why BPDU guard etc were developed. Because on an edge port I never intend to receive a BPDU, the receipt of one can be harmful to my network. Which is why BPDU guard prevents the processing of this BPDU and error-disables the port.

Please feel free to ask more!

Regards,

Aninda

Hi guys,

First of all, thank you for replying, and sorry this response is so late.  Anyway, to the topic, I believe perhaps my phrasing of the question wasn't clear. 

I'm aware of the function and importance of BPDUGuard and BPDUFilter, and understand they should be applied to edge ports, but what confuses me is that BPDUGuard/Filter would seem to contradict normal Spanning-tree behavior.

That is, for example:  A non-edge port in a Spanning-Tree topology that is in blocking state needs to continue receiving BPDU's from the legitimate network. If the blocked port stops receiving BPDU's, it assumes the path to the root bridge is broken and moves to forwarding state. This suggests that switchports need to receive BPDU's to ensure the network is not broken.

HOWEVER, we are also told that edge ports should never receive BPDU's, and Guard/Filter are tools to ensure that never occurs.  This makes perfect sense to me when talking about an edge port receiving ingress traffic from a rogue switch; as this would be catastrophic and topology poisioning.

However, are we to assume that edge port also should never receive BPDU's from the legitimate upstream topology? 

It is difficult for me to explain, so perhaps I can just ask this:

Are BPDU's that come from the legitimate root switch only exchanged on root, designated and blocked ports?  If so, than the legitimate topology (i.e. the topology you know of that is in place) will never send a BPDU to an edge port, and the only threat is a rogue BPDU being injected into the edge-port?

Hi Dean, Simon and Aninda,

Please allow me to join.

However, are we to assume that edge port also should never receive BPDU's from the legitimate upstream topology?  

Edge ports by definition should not face any "legitimate upstream topology" - that would contradict their nature of edge ports that connect only to non-switching end devices. While it is indeed possible that two edge ports are inadvertently (or intentionally) connected together, or connected to some upstream switch, this is a situation that goes directly against their purpose and intended usage, and that is why the BPDUGuard is recommended to be used on them - to put them into the err-disabled state as soon as a BPDU arrives, as it proves that the edge nature of the port has been lost.

Are BPDU's that come from the legitimate root switch only exchanged on  root, designated and blocked ports?  If so, than the legitimate topology  (i.e. the topology you know of that is in place) will never send a BPDU  to an edge port, and the only threat is a rogue BPDU being injected  into the edge-port?

I am not sure if I understand this question correctly. However, regarding the operation of an edge port, such a port continues to send and receive BPDUs just like any other non-edge port. A device connected to an edge port has no way of determining that it is connected to an edge port, as this information can not be derived from the contents of BPDUs sent out from edge ports.

Feel welcome to ask further!

Best regards,

Peter


I am not sure if I understand this question correctly. However, regarding the operation of an edge port, such a port continues to send and receive BPDUs just like any other non-edge port. A device connected to an edge port has no way of determining that it is connected to an edge port, as this information can not be derived from the contents of BPDUs sent out from edge ports.

Feel welcome to ask further!

Best regards,

Peter

Hi Peter,

That's what confuses me a bit.  If an edge port continues to send and recieve BPDU's, then what happens if it stops receiving BPDU's from the network? Blocked ports, for example, assume the path to the root bridge is broken and attempt to transition into forwarding state when they stop receiving BPDU's.  What do edge ports deduce when/if they stop receiving BPDU's from the network?

Furthermore, if an edge port should still send and receive BPDU's to/from the network, wouldn't BPDUGuard prevent this from taking place?  Or does it only prevent BPDU's from coming into the ingress of the edge port (i.e. from a newly connected rogue switch)?

Hi Dean,

If an edge port continues to send and recieve BPDU's, then what happens if it stops receiving BPDU's from the network?

In RSTP, an edge port continues to send BPDUs, and is prepared to receive and process BPDUs should they arrive - but for an edge port, they are not supposed to arrive. If a BPDU arrives to an edge port, the port will process it as usual, but its type of edge port will be lost and the port will revert to the operation of a non-edge port. You surely recall that an edge port has its operation modified: it immediately becomes Designated Forwarding upon link-up, it does not generate TCs, it is not affected by Sync operation, and MAC address table flush operations during TC handling do not affect addresses learned on it. All these features of an edge port will be lost if the port receives a BPDU because in that case, its operational type will automatically change to non-edge port.

So the question of "what will happen if an edge port stops receiving BPDUs" is not really correct. There is no such thing as an edge port continuously receiving BPDUs - the very first received BPDU would have caused an edge port to drop its edge type and become a non-edge port. Perhaps there is an imprecision in what we say when stating that "edge ports send and receive BPDUs". In reality, we want to say that edge ports send BPDUs and will process any received BPDUs should they come - but for a port to keep its edge type, BPDUs must not really arive.

What do edge ports deduce when/if they stop receiving BPDU's from the network?

In fact, edge ports should never receive BPDU - they are just ready to process received BPDUs if they arrive. Edge ports immediately become Designated Forwarding, which is in effect the same role and state they would end up in anyway even they were non-edge ports and no BPDUs were received. With edge ports, there is the implicit assumption that there is no bridging device connected, so no STP negotiation needs to take place, as no switching loop should occur through a non-bridging device.

Furthermore, if an edge port should still send and receive BPDU's  to/from the network, wouldn't BPDUGuard prevent this from taking place?

Yes, it would indeed. Receiving a BPDU would mean that the port is not at the edge of the network anyway. Classic RSTP rules dictate that this port immediately transitions to non-edge type. Cisco's BPDU Guard in addition causes this port to become err-disabled.

Or does it only prevent BPDU's from coming into the ingress of the edge port (i.e. from a newly connected rogue switch)?

Quite right. In fact, the BPDU Guard err-disables the port because it assumes that a switching loop may have already occured (e.g. connecting two edge ports together immediately results into a temporary switching loop as both ports are initially Designated Forwarding) and the traffic caught in the loop may be so huge that regular processing of the BPDUs sent by both ports may not be possible anymore.

As always, feel welcome to ask further! STP, despite its fundamental simplicity, is a protocol that exceeds all expectations at misunderstandings

Best regards,

Peter

@Dean Romanelli 

I guess we need to travel back in time to understand a bit of the actual purpose of an edge port.
 
 An edge port is never supposed to be part of an active STP topology but however if it does , it might be due to poor STP practices . If there is a case the edge port receives a STP BPDU , it automatically loses its edge port status.
Now , ask yourself this question, what happens if an edge port receives a STP BPDU ?! Simple. It participates in STP as any other port. 
However, this is not ideal. So BPDU guard/Filter were introduced in order to maintain the edge port status even if the edge port receives a STP BPDU.
As you might know, BPDU guard will "error disable the edge port" if it ever encounters a STP BPDU.
Also to touch base with "the blocked port need to receive BPDU's in order to stay blocked" i believe "LOOP GUARD" will help prevent a blocked port on a LAN segment if it ever stops receiving BPDU's.
STP makes sure to elect the best ports to process BPDU's for a LAN segment and if for some reason , after topology convergence, the blocked port does not receive superior information , loop guard will intervene and keep the port to be blocked by stating the port is in "loop-inconsistent" state.
BPDU GUARD/BPDU FILTER apply to "Edge" ports with "PortFast" enabled.
LOOP Guard applies to a non-designated port on a LAN segment to help prevent loops.
 

Hello


@Dean Romanelli wrote:

Hi All,

 

I have a question about STP and BPDU's.  If a port in a redundant topology stops recieving BPDU's, it runs the risk of erroneously moving to the forwarding state.  However, things like BPDUGuard and BPDUFilter prevent ports from recieving BPDU's, and are usually applied on edge ports.

 

So, if ports need to recieve BPDU's to know the status of the topology, why would we want to prevent any ports from recieving those BPDU's?  That would seem to suggest edge ports with these features enabled constantly believe the topology is in a failed state.

 

Can someone clarify?

 


On the switch access-ports are edge ports and with stp portfast applied they are designed to go straight into a designated/forwarding state when they come up.

Access ports only send bpdu's but they DONT expect to receive any so if they do start to begin to receive stp bpdu's then that port will lose its edge port status and revert to a non-edge port type and go through its stp transition process until that port is torn down and restarted.

Applying stp bpduguard as you have stated will negate such a port change and block the port until you either manually restated that port or err-recovery has been applied to automatically recover the port when the bpdus have ceased to be received.on the port.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

@Dean Romanelli
@Adi14
@Peter Paluch@Aninda Chatterjee

Apologies to everyone - didnt realize you guys had already replied -  For some reason on my phone this post was showing has a unanswered!


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: