Spanning Tree Root Bridge Dispute C3750-V2

[Daniel Hunter]

I am seeing unusal spanning tree behaviour on VLAN 1 when adding a new switch stack to our network. The network is part of a user estate consisting of a pair of C6509s each connect to a number of C3750 switch stacks. Each stack has a single trunk to each of the C6509s with the native VLAN set to a shutdown VLAN (2). Spanning tree mode is configured to rapid-pvst. C6509-1 is configure as to be the root bridge using: spanning-tree vlan 1,2,x,x,x,x priority 8192 and C6509-2 is configured to: spanning-tree vlan 1,2,x,x,x,x priority 16384 Each C3750 stack is configured with: spanning-tree uplinkfast (I know this isn't active under rpvst but ensure priority for all VLANs is 49152) All this works as expected, then along comes the C3750-V2 (15.0.2.SE2), we can add the stack successfully to the network but both the C6509s give the following for "show spanning-tree vlan 1": Gi1/17 Desg BLK 4 128.17 P2p Dispute The same coomand on the C3750-V2 show a bridge priority of 49153 and "This bridge is root" under the root ID. To add to the confusion all the other VLANs on the switch are showing C6509-1 as the root bridge. Have I misconfigured something or has anyone else seen this behaviour? Regards Dan

[Jose Solano]

Hi,

Can you check if the vlan 1 is allowed on both ends of the trunks between the 6509 and the 3750 stack? 

Hope this helps.

[Daniel Hunter]

That's interesting (and annoyingly overlooked): All ends of the trunk show the full set of vlans under "allowed and active in the management domain" but vlan 1 is missing from the 6509 end under "forwarding state and not pruned". Putting the trunk native vlan back to 1 obviously brings vlan 1 back to a forwarding state and returns spanning tree back to a consistent state. This isn't consistent with the operation of the 3750 or what I'd expect. Again am I overlooking the obvious or is this expected on the V2?

[Jose Solano]

Hi,

If you dont have any acitve ports associated with vlan 1 then it will not be active and in forwarding state even if it is allowed on the trunk, after you put back the native vlan to 1 then vlan 1 will become active and therefore the 6500 will claim the root state and the dispute will go away.

Regards,

[Daniel Hunter]

That is correct. However on the old 3750 stacks there are no active vlan 1 ports and the native vlan has been changed and vlan remains in a forwarding state. I thought the default vlan always stayed in a forwarding state, part of the reason vlan 1 cannot be deleted, to handle management traffic such as cdp (cdp is working across the trunk). I guess that makes it impractical to ever change the native vlan and a problem if you have security people who still believe vlan hopping is more than a theoretical threat. (As an after thought turning off VTP pruning also fixes the problem) Thanks for responding