Just thought I'd toss this out..
We've got a large campus. They use VTP which means that every VLAN configured gets copied out to every switch in the VTP. Up to 75 switches in a VTP. SO, with defaults of all VLANs allowed on every trunk, there are 75 switches particpating in every spanning tree. With MST, every VLAN runs an instance of spanning tree PER vlan.
All the above is pretty much set in stone for at least 1-3 years. It will take that long to architect all the changes to move this infrastructure to a better place.
So... spanning tree can be a real bitch. In small shops you don't even need to configure spanning tree, it just works cause you don't have enough switches in the wrong configuration to cause problems.
We've already proven out that manually pruning vlans off trunks is very benefiical. I've read from Cisco's documentation that automatic pruning of vlan's does not remove switches from participating in the spanning tree of the pruned vlan's. It only reduces traffic. So prunign mode is not helpful for mitigating spanning tree complexities.
So if you made it that far...
I'm trying to work out how to recommend maintaining the configs of the hundreds of trunks.
So here is my first assumption as to what would be best.
A=====trunk=====B=====trunk=====C=====trunk=====D
SWITCH A interface g0/1 switchport trunk allowed vlan 1,400,500,550
SWITCH B interface g0/1 switchport trunk allowed vlan 1,400,500,550
SWITCH B interface g0/2 switchport trunk allowed vlan 1,500,550
SWITCH C interface g0/1 switchport trunk allowed vlan 1,500,550
SWITCH C interface g0/2 switchport trunk allowed vlan 1,550
SWITCH D interface g0/1 switchport trunk allowed vlan 1,550
In this simplistic example, all the intermediary trunks must carry the vlans needed for edge switches. If I need to set a port on Switch D to VLAN 600 I've got to reconfig six ports on 4 switches. (ugh!)
Yes better vlan organization would elimiante this crap but unless one of y'all has a time machine in your pocket and can undo this unholy mess from about 5-8 years ago...move on.
From a troubleshooting this works... If i need to add vlan 600, I can look at my trunk ports on the switch I'm on and bingo I see it isn't there. But It needs a lot of changes. And if I've got two upstream swithces for redundancy I need to folow all the paths. (double ugh)
A=====trunk=====B=====trunk=====C=====trunk=====D
SWITCH A interface g0/1 switchport trunk allowed vlan 1,400,500,550
SWITCH B interface g0/1 switchport trunk allowed vlan 1-1004
SWITCH B interface g0/2 switchport trunk allowed vlan 1,500,550
SWITCH C interface g0/1 switchport trunk allowed vlan 1-1004
SWITCH C interface g0/2 switchport trunk allowed vlan 1,550
SWITCH D interface g0/1 switchport trunk allowed vlan 1-1004
In this config, the downstream switch accepts all vlans from above. The upstream switch has control. That means, vlan 400, which exists on EVERY switch in the VTP will have a spanning tree instance on SWITCH D, which will send it's BPDU's up to switch C, but switch C will ignore that traffic. I've seen spanning tree flodds go down a pipe only to be ignored at the other end cause that end won't allow that vlan. I can live with that.
The problem is if I'm on switch d, I don't know what VLAN's I'm really getting. I've got to go upstream and look at my trunk config on C. That's ugly.
A=====trunk=====B=====trunk=====C=====trunk=====D
SWITCH A interface g0/1 switchport trunk allowed vlan 1-1004
SWITCH B interface g0/1 switchport trunk allowed vlan 1,400,500,550
SWITCH B interface g0/2 switchport trunk allowed vlan 1-1004
SWITCH C interface g0/1 switchport trunk allowed vlan 1,500,550
SWITCH C interface g0/2 switchport trunk allowed vlan 1-1004
SWITCH D interface g0/1 switchport trunk allowed vlan 1,550
The opposite is to pass all vlanss from above, but have the downstream edit out what it doesn't need. THis might make the most sense. If I'm logged onto switch D and setting up a port for vlan 600, I can see that vlan isn't available. I still have to walk all the tree's looking for that vlan and propigating down multiple paths.
Now up at the distribution I would definitley still choke off a lot of vlans for security and stability.
So anybody come up with a good method of maintaing messy trunks/vlan configs? I've got to present how we are going to config and maintain trunks soon and I'm still tossing around what is the most manageable way to undo some of the damge campus-wide vlans have caused.
Personally I hate VTP as it causes more problems and encourages junior techs to forget that you have to pay attention to the propigation of vlans, spanning tree, and trunk control.
DiGiTAL_ViNYL (no email)