Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Spanning Tree Issue Root in BKN* State

Need some help with STP, I have not run across this issue before and have set several of these IE3000 switches up in my own environment with no issues. This gear is at a remote site that I am trying to help out.

VLAN 100 is for management, VLAN 125 is a newly created and the one being tagged across the trunk.

The topology is as follows:

Passport 8600 (yea Passports sorry) this is the layer 3 device managing the routing on the local LAN it is slated for a Cisco replacement.

The Passport is connected to a 3750X

3750X is connected to a 3750v2

The 3750v2 is connected to a Cisco IE3000 (Industrial Ethernet) switch.

Everything works fine and routes as it should up to the 3750v2. I can ping the default gateway for VLAN 125 @ 10.5.125.1 /24. I can get a response from client devices on another subnet residing on the 3750v2 and from an SSH session in the 3750v2.

The issue lies between the connection from the 3750v2 and the IE3000 switch. I can get the link to work when it is a single VLAN (management) and not a trunk port. However, when I add the additional vlan to the IE3000 and configure both ends to act as a trunk I lose connectivity.

When I do a show spanning tree vlan 125 on the IE3000 I see that the following states:

Gi1/1    Root      BKN*    200000                  128.1    P2p Bound(PVST) *PVST_Inc ---- Uplink to 3750v2

Fa1/4    Desg      FWD    200000                  128.3    P2p Edge --- Laptop on 10.5.125.0 /24 network

When I do a show int status on both switches the trunked ports show as ‘connected.’ The only access devices that reside on the 125 network are on the IE3000. I just have the one plugged in now for testing, but it will be 11 devices on the IE3000 in total.

The only link back into the main network from the IE3000 is the single Gi 1/1 going to 1/0/40 on the 3750v2. The 3750v2 output for show spanning tree vlan 125 has it in a Desg FWD state for 1/0/40. I am no expert by any means on STP, but did not think a port would go to a BKN state if it was the only path back into the network. It is obvious that is my issue because there is no way for traffic to traverse the trunk if the port is being blocked

Any suggestions on my next steps for troubleshooting/resolution?

Thanks,

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Spanning Tree Issue Root in BKN* State

Hello Phil,

The message in show spanning-tree tells you about an important problem: you have a native VLAN mismatch on the trunk.

Can you post the output of the show int trunk command from both the IE3000 where you see that message (the one with the Gi1/1 port in the BKN* state) and from the 3750v2 switch that should be directly connected to this IE3000?

Also, I believe such occurences are accompanied by logging messages produced by CDP and STP about native VLAN or PVID mismatch. Can you look them up in the IE3000 log buffer and post them here as well? Their contents may be important in narrowing down the problem cause.

The BKN is a shorthand for "Broken". This is a distinct state from Blocking state and is seen only on ports where the STP detects a configuration or operation issue that could have disastrous effects. A Broken port is always put into Discarding (Blocking) state, however, this state will be held as long as the the issue persists.

Best regards,

Peter

3 REPLIES
Cisco Employee

Spanning Tree Issue Root in BKN* State

Hello Phil,

The message in show spanning-tree tells you about an important problem: you have a native VLAN mismatch on the trunk.

Can you post the output of the show int trunk command from both the IE3000 where you see that message (the one with the Gi1/1 port in the BKN* state) and from the 3750v2 switch that should be directly connected to this IE3000?

Also, I believe such occurences are accompanied by logging messages produced by CDP and STP about native VLAN or PVID mismatch. Can you look them up in the IE3000 log buffer and post them here as well? Their contents may be important in narrowing down the problem cause.

The BKN is a shorthand for "Broken". This is a distinct state from Blocking state and is seen only on ports where the STP detects a configuration or operation issue that could have disastrous effects. A Broken port is always put into Discarding (Blocking) state, however, this state will be held as long as the the issue persists.

Best regards,

Peter

New Member

Re:Spanning Tree Issue Root in BKN* State

Thanks Peter, I realized after posting I misstated blocking. I have never seen a port in BKN mode before. I did discover that the IE3000 defaults to spanning tree mode mst when using their express setup. Not familiar with mst configurations, but that seemed to be the issue. Another IE3000 on the network running mst took over. I changed the config back to rapid-pvst and it came out of BKN. I never use express/wizard for setup so I had not seen this issue in my environment.

Going to do a little reading on mst and see what its all about.

Thanks

Sent from Cisco Technical Support Android App

Cisco Employee

Spanning Tree Issue Root in BKN* State

Hi Phil,

Oh, I've made a huge mistake here, in fact. The PVST_Inc is not a native VLAN mismatch but rather PVST Simulation Inconsistency failure. Please ... accept my apologies.

Issues with PVST Simulation are difficult to explain without going quite deep into MST internals and its specific behavior in Cisco implementation when trying to make it interoperate with PVST/RPVST.

Regarding MST and information about it, I strongly suggest reading these documents in the sequence:

http://blog.ine.com/2008/07/27/mstp-tutorial-part-i-inside-a-region/

http://blog.ine.com/2008/09/24/mstp-tutorial-part-ii-outside-a-region/

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml

Regarding PVST Simulation Inconsistency, I am planning to write a document to be posted here on CSC in a few weeks. So far, suffice it to say that these requirements must be met for a switch to correctly interoperate MST and (R)PVST:

  • Either a MST region must contain a switch whose priority in MST Instance 0 (MSTI0 or IST) is set so low that it beats priorities of all other switches in the (R)PVST region in any VLAN, effectively becoming the root for all VLANs outside the MST region
  • Or the MST Instance 0 priorities of all switches in a MST region must be higher than any priority of any (R)PVST switch in any VLAN (i.e. none of the switches in the MST region can ever become a root for any (R)PVST region VLAN) and in addition, the priority of the VLAN1 root bridge in the (R)PVST region must be higher than priorities of all other VLAN (2-4094) root bridges in the (R)PVST region.

As probably neither of these requirements was met in your network, the switch decided to declare a PVST Simulation inconsistency and block the port.

Best regards,

Peter

26980
Views
0
Helpful
3
Replies
CreatePlease to create content