Why STP/RSTP sends BPDU on access ports?

[jsricardofelix]

I learned that STP/RSTP sends BPDU through access ports, but I didn't find the reason for that.

Some points that I thought:

1) As BPDU uses a multicast address, it should be forward to all interfaces?!

2) BPDUs are sent on Access Ports to prevent connection mistakes?!

Apart from those 2 points (maybe even the 1st is wrong), I didn't see any other reason. Thanks community.

[Martin L]

Yes, it is STP Multicast address and it goes to every interface - even access port just in case you connect a hub or switch instead of end device like a PC. Root Switch creates BPDUs but others copy it, modify to add or edit values like cost, and pass it over to another switch.

Regards, ML
**Please Rate All Helpful Responses **

[MHM Cisco World]

SW don't know other side connect to access port may be is SW may be not, the way that SW can detect that by sending BPDU.

[paul driver]

Hello
EDITED_
Access-ports should not send or receive stp BPDUs because they are access/edge-ports, And these ports are suppose to only to be attached to edge nodes.
They do participate in this stp process unless that is portfast is enabled then they bypass this and go straight into a forwarding state, Now if a bpdu is seen on one of these ports then it will lose its portfast status and again participate in the stp process, However there is also a stp feature to prevent these access/edge ports sending or receiving stp BPDUs when portfast is enabled or not and this is called bpduguard which will block the access-port if a bpdu is seen.

[Amer Alnassir · Accepted solution]

As you have guessed, the first point is wrong. This behavior has nothing to do with multicast. First of all, you need to know that the assumption that STP/RSTP know that access ports do not connect to switches and hence no need to send BPDUs out of them is wrong. In fact, even access ports can connect to other switches and hence, they should send out BPDUs to let the neighboring switch(s) know that an STP switch is connected to this port. RSTP standard introduced a feature called "Edge Ports", and is known in the Cisco world as PortFast. This feature was implemented internally by Cisco with legacy STP as it does not impact interoperability. The following document states: "By default, spanning tree sends BPDUs from all ports regardless of whether PortFast is enabled."

Document: "Configuring Spanning Tree PortFast, BPDU Guard, BPDU Filter, UplinkFast, BackboneFast, and Loop Guard" https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4000/8-2glx/configuration/guide/stp_enha.html#wp1046787

If you wish to prevent PortFast-enabled ports from sending BPDUs, you may use BPDU Filtering feature.

*Recall that PortFast requires explicit configuration and is not enabled by default on access ports.

Hence, your second point is correct. In fact BPDUs are sent out access ports to prevent loops (the same reason they are sent out trunk ports.

[paul driver]

Hello
@Amer Alnassir  Access-ports should not send or any receive bpdu's  hence why they are access ports if they do receive bpdus then they should NOT be configured as access ports hence why access ports have a l2 security feature such as bpdu-guard that can be applied to negate such receipt of them

If you wish to prevent PortFast-enabled ports from sending BPDUs, you may use BPDU Filtering feature.

---

Bpdu filtering does what is says , it filters any receipt of bpdu's basically ignoring them so this feature should not be applied to access ports as this has a potential to cause loops with /without portfast being enabled.

Without STP PF enabled and bpdu-filtering applied on an access port, stp will participate in the stp process then transition into a forward state and will filter any received bpdu's thus potentially to cause loops

STP PF and BPDU-filtering enabled both or either applied on the interfaces the access ports will transition into a forward state straightaway and will filter any bpdu's so again has a potential to cause loops.

[Amer Alnassir]

Hello @paul driver
From a network design perspective, I definitely agree with you that access ports should not be connected to other switches. This is a bad practice. However, from the operational point of view, access ports can connect to other switches and communicate within the access VLAN. I am quite sure this is basic for you, but I just need to highlight that answering the original question in this post should address the operational side as we are talking about a standard. In other words, the question is about the philosophy of the design of the standard itself. Recall that the original STP standard predated VLANs and even predated switches. We must make it clear for readers that access ports DO send BPDUs by default, and to explain why. We also have to make sure that this is not confused with Edge-Ports as the reader could be someone who is not really familiar with those concepts.

CORRECTION to my comment: First 802.1Q edition came in 1998. 802.1t-2001 amendment states in 9.2.5 that introducing system-id extension is to support multiple instances in the 802.1s which is a supplement to 802.1Q. Standardized VLANs (1998) definitely predated standardized RST (2001).  

Regarding BPDU filter, it filters both incoming and outgoing BPDUs. If configured globally, it will apply to edge ports which will loose both edge port and BPDU filter features upon receipt of a BPDU. However, if it is configured on an interface level where PortFast is not configured, it will stop sending and processing BPDUs and will not participate in STP. This can be used when connecting two different networks with different STP domains where it is the administrator's responsibility to make sure that no redundant links between the two STP domains exist. For sure I agree with your recommendation to avoid such a feature in order to prevent loops when dealing with a production network. However the question here is much more basic and using this feature for test purposes would be so helpful for mere understanding of functionality.

Thanks

[paul driver]

Hello

@Amer Alnassir

Naturally switchports do send bpdu's, My OP is indeed incorrect I meant to state switchports should not expect to receive BPDU's especially on an ports that are configured as an access/edge port (administrative mode of static access)

[Giuseppe Larosa]

Hello @Amer Alnassir ,

I agree the main reason for still sending BDPU out of access ports is loop prevention.

As you have noted the port edge function or in Cisco terms spanning-tree portfast does not prevent the switch from sending out STP BDPUs.

In legacy STP the STP portfast avoids the listening and learning state ( 15 seconds each) and provide help to end user stations for example to avoid DHCP to time out and so on.

The edge port concept is very important in Rapid STP and it is not an optional feature but an integral part of a good implementation.

In Rapid STP the fast convergence is achieved by rapid exchange of STP BPDUs with appropriate flag bit set  ( proposal / agreement).

In a Rapid STP domain a single point to point link betweern two switch performs handshake and comes out with roles and states for both ports.

The edge port feature avoids that the sync wave propagates to user ports where for the missing of a peering switch it should wait for the timers to expire.

For this reason first RSTP implementations reported time of convergence comparable or worse then traditional STP and there were several threads about this here in the forums.

So the edge port feature is very important in RSTP.

Hope to help

Giuseppe

[Amer Alnassir]

Hello @Giuseppe Larosa 

Thanks for your comment which I think is a very rich summary about Edge Ports in RSTP. And YES, it is definitely not optional nor luxury anymore when using RSTP. If this key feature was not used on user ports, it will be definitely worse than legacy STP in case of adding a link in the network which will trigger a sync wave causing those access ports to move to discarding and wait for 2xFD time to become forwarding.

Thanks.

[Joseph W. Doherty · Accepted solution]

#2 is the principle reason.  In fact, even when you know your L2 topology has no (intentional) loops, it's good practice to use STP for this very reason.  (Occasionally, someone will inquire in a loop free L2 network can STP be disabled.  The answer is yes, but not recommended for this reason.)

BTW, other posters have mentioned "port fast".  This bypasses/shortcuts a couple of STP's initial start up steps.  However, if (at least on Cisco) a "port fast" port "sees" a loop develop it can block the port to break the loop.  The risk, though, is a L2 loop might cause the switch to go into "meltdown" before the switch blocks the port.