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?
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?
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.
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
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...