cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
778
Views
10
Helpful
3
Replies

Weird Spanning tree problem

Patrick McHenry
Level 4
Level 4

Please refer to the attached document

I was just issuing some spanning-tree show commands on the root switch(Core1) when I noticed that the root cost for VLAN 17 was 20, not 0. All the other VLAN costs were and are supposed to be 0. when I entered sh spanning-tree, it read "This bridge is the root" for all VLANs except 17 but, the MAC for the root of VLAN 17 was that of Core1. I assumed that Core1 was still the root but, it was taking some weird path to get back to itself. Does this make sense?

In addition, Core1, the root switch, had a root port on gig2/2, which I thought was strange as the root switch shouldn't have a root port.. So I followed the root port to a server switch

Now, while trouble-shooting this problem with my Sysadmin, we noticed that a port that connects to a server on the server switch was connected to a trunk port(under normal conditions it is an access port). Somehow it was changed - we don't know why. We changed the port that the server was connected to, back to an access port, and then instantly Core1 was reading "This bridge is the root". and the root cost was again 0 And the proper links were being blocked.

First off , does anyone know what could have happened?

Why, when the server port was changed to trunk, the root path cost for VLAN 17 changed to 20 on Core1? Why, would the fact that it became a trunk, change anything?

Why, when the server port was changed back to an access port, the root path cost for VLAN 17 changed to 0 on Core1.

Thanks, Pat.

3 Replies 3

PETER EIJSBERG
Level 1
Level 1

My guess is that somehow the trunk created a loop between vlan 1 and vlan 17. When the BPDUs from vlan 1 are looped back into vlan 17, the core1 switch will show as root with a lower prio than in vlan 17 (in Cisco PVSTP the vlan id is added to the priority). So suddenly a new switch appeared behind the new trunk port with a lower root priority, and STP converged on vlan 17....

Now only need to find an explanation how this BPDU was looped back from one vlan to the other....

Peter

Thank you for the response. Since the last upgrade to the Community, It doesn't seem like I am getting email notifications when someone answers a post.

I'm going to have to think about what you said. Orginally that is what I was thinking that the server itself was advertising a lower priority but, when then didn't it become the root? Meaning, why did the Core still have the same MAC for the root bridge. Although it wasn't reading "This bridge is the root".

thanks for looking at this involved post, Pat.

Hi,

a native VLAN mismatch on the trunk possibly?

The server switch having VLAN17 as native while Core2 having VLAN1?

In that case the server switch would receive the VLAN1 STP BPDU  untagged on the trunk and use it for VLAN17 intself.

(Don't forget there's also 802.1D BPDU sent for VLAN1 together with Cisco BPDU on the trunks to make it nmore complicated.)

HTH,

Milan

Review Cisco Networking for a $25 gift card