spanning tree Trunk bpdus sent down access port caused blocking on other switch

Unanswered Question
May 26th, 2010

Hi all

I had a strange thing happen yesterday, I have 3 switches, A,B,C both B and C connect to A on a single connection, the connection from B to A is on a single vlan and just a normal access port, the connection from C to A was a trunk port with many vlans.

For some reason when we added switch C, the access port on switch A went into blocking mode, saying

8w0d: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk GigabitEthernet0/23 VLAN196.

8w0d: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking GigabitEthernet0/23 on VLAN0196. Inconsistent port type.

Is it right that the bpdu's from switch C's trunk will go out of the access port on the other switch and block the link? I have never seen this.

The only way to fix it was to turn off spanning tree on switch C, or I guess the other way would be to set the port between A and B a trunk port?

question is why did this happen?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Giuseppe Larosa Wed, 05/26/2010 - 03:10

Hello Carl,

I had seen the same happening sometime

you need to use

switchport mode access

on both switches with

switchport nonegotiate

or you need to move to trunk configuration on both ends. using mode trunk on both sides

that is even if downstream switch is configured with switchport mode access it still talks DTP (switchport nonegotiate) if upstream switch is left at dynamic desirable it may turn on trunking, as a result of this it will start to send proprietary BPDUs that contain the vlan-id of the instance.

the other side doing a consistency check disables the port on receiving these unexpected BPDUs

8w0d: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk GigabitEthernet0/23 VLAN196.

I would not disable STP on link I would make the link 802.1Q trunk on both ends

Hope to help


carl_townshend Thu, 05/27/2010 - 04:06


What I find strange is, the switch causing this is not even directly connected to it, it goes via another switch, How has this BPDU managed to get to it? Is it because it has been flooded out of the unmanaged switch between them?


carl_townshend Mon, 09/27/2010 - 08:29


Can anyone answer this question?

I dont understand why the bpdu's from the other switch are going out this port and blocking it ? if both ends are access ports then surely this should not happen ??

Peter Paluch Mon, 09/27/2010 - 09:02


Giuseppe is right. What happened is that the switch C was sending 802.1Q tagged BPDUs and they simply passed through the unmanaged switch. They were essentially flooded by it because all BPDUs, both IEEE and PVST, are sent to a multicast MAC address. Do not expect an unmanaged switch to block BPDUs - why should it do it? It does not understand the contents of these frames so it simply forwards them as best as it can. As these tagged BPDUs were received by an access port on switch A, the switch concluded that there is a misconfiguration in the network (which it really is) and decided to block the port.

Read about this protection here:

Using the BPDU Filter on the switch C can be a workaround but we are dealing here with fundamentally incorrect design: having an access port and a trunk port connected together via an unmanaged switch. The unmanaged switch cannot provide the VLAN isolation and will cause the tagged frames to leak to other ports. Also, having the possibility of a trunk port to talk to an access port and vice versa is essentially a misconfiguration.

The question is, what is accomplished by this design? Can it be changed?

Best regards,


rpastrana Thu, 10/03/2013 - 04:07

Hello, In this design, I think whenever the switch C is connected, sends BDPU with the information of a new change, to the Multicast MAC, whenever it goes through the port link of A-B, since it's an access port, it will block it, since access ports are not supposed to receive BDPU 802.1Q frames. I think Cisco working with 802.1Q BDPU frames it's easy to work with, but to understand it, I'd prefer to work with tagged/untagged frames, received/sent from. From this message:

8w0d: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk GigabitEthernet0/23 VLAN196.

8w0d: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking GigabitEthernet0/23 on VLAN0196. Inconsistent port type.

I guess GI 0/23 is the one where Switch B is connected. Since it's an access port, must receive or send untagged frames. Else will be STP violated and block the port. If there are BDPU frames being sent, must always be sent/receive through trunking ports to update/calculate the STP databse in each switch and will not be forwared through access ports. Except if they are Data frames, when they are received from untagged port(access port), from a host sending untagged frames, the frames will be tagged with the VLAN configured in the port and will be sent to its target through a trunk interface, if the target is in another switch, and will be untagged before sending it through the access port where the host target is connected.

My english sucks quite a bit, but I hope this could help somehow... By the way, as best practice with Layer 2 switches, communication beetwen them should always be with trunking interfaces.


chandra_rc16 Thu, 10/03/2013 - 05:08

Hi Carl,

Do you mind to attach your topolgy and config ?

I'm new here and learning CCNA and i'm also @ STP.




This Discussion