08-17-2013 04:37 PM - edited 03-07-2019 02:59 PM
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,
08-17-2013 05:37 PM
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
08-17-2013 10:17 PM
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
09-01-2013 02:10 PM
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?
09-01-2013 04:50 PM
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
09-01-2013 06:42 PM
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)?
09-02-2013 12:10 AM
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
02-09-2019 10:39 PM - edited 02-09-2019 10:42 PM
02-10-2019 05:29 AM - edited 02-10-2019 05:31 AM
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.
02-10-2019 06:08 AM
@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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide