VTP Design Question for Modular Switchblock network

Unanswered Question
Dec 10th, 2009

Hi,

I am familiar with use and concept of VTP however I have never used it in a large network deployment, certinaly not in a modular switch block architecture. However, as a result of recent issues due to trunk link mis-configurations and spanning-tree, I am thinking about deploying VTP.

Our network design is very straight forward with a core layer consisting of 2 x 6509 (with sup720-3B) which interconnects several distribution switch blocks (all comprised of dual 6513's again with sup720-3B). Each pair of distribution switches aggregates access layer switches (layer 2 only) and provide resilient HSRP gateways for access into the network, and also act as STP root / secondary root bridges. All standard stuff. We have changed the VTP domain name from "NULL" to "MA" for the sake of seeing something meaningful in Ciscoworks topology services, but thats as far as it goes. VTP is set to transparent on all devices.

What I would like to do is just enable VTP within the distribution switch blocks, each with its on VTP domain name, leaving the core as transparent but still on the "MA" VTP domain. Each distribution switch will be a VTP server with all access switches configured to be VTP clients.

Is this an advisable deployment ? We currently use Rapid-PVST and I am aware of the limitations this brings with it (i.e. no more than 64 STP instances on a 2950 etc).

I am ruling out VTP v3 as I do not want to move to 12.2(33)SXI, instead we are standardising on 12.2(33)SXH6 which seems to be one of the most stable releases of IOS I have seen in ages, plus it support Layer 3 NAC, which for some reason Cisco have pulled from the SXI train.

Any help / guidance would be helpful.

Chris.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Thu, 12/10/2009 - 02:15

Hello Chris,

>> What I would like to do is just enable VTP within the distribution switch blocks, each with its on VTP domain name, leaving the core as transparent but still on the "MA" VTP domain. Each distribution switch will be a VTP server with all access switches configured to be VTP clients.

this is exactly our setup in large campuses and it works well.

if your links from distribution to core are L3 links VTP has no sense there.

About STP limitations on lower end switches you need to use switchport trunk allowed vlan to limit number of STP instances to minimum required.

VTP pruning can limit unnecessary traffic but it doesn't help in limiting number of STP instances.

Hope to help

Giuseppe

cbeswick Thu, 12/10/2009 - 02:33

Many thanks for the reply.

"if your links from distribution to core are L3 links VTP has no sense there."

Our backbone links are layer 3, however we do have a number of campus wide Vlans that span the core and distribution switch blocks. So presumably I can just disable VTP on the distribution switch ports that link to the back bone ? i.e. "no vtp" ?

"About STP limitations on lower end switches you need to use switchport trunk allowed vlan to limit number of STP instances to minimum required. VTP pruning can limit unnecessary traffic but it doesn't help in limiting number of STP instances."

I wanted to completely remove the need for manual configuration on trunk ports, and instead rely on VTP pruning to take care of unnecessary broadcasts. However I see exactly where your coming from in terms of limiting the number of spanning tree instances. We have already breached the limit of 64 Vlans within each block for the C2950s. I think a migration to MSTP may be necessary within each Switch Block, followed by a migration to MSTP in the Core to handle the site wide Vlans. We could then use VTP pruning without worrying about instances.

I know that the site wide Vlans are generally a bad idea. Everytime I think about them a chill goes down my spine. We will soon have Sup720-3B modules across the entire campus, so I will be investigating MPLS VPNs / Multi VRF and AToMPLS / VPLS to cater for this.

Jon Marshall Thu, 12/10/2009 - 02:36

cbeswick wrote:

Hi,

I am familiar with use and concept of VTP however I have never used it in a large network deployment, certinaly not in a modular switch block architecture. However, as a result of recent issues due to trunk link mis-configurations and spanning-tree, I am thinking about deploying VTP.

Our network design is very straight forward with a core layer consisting of 2 x 6509 (with sup720-3B) which interconnects several distribution switch blocks (all comprised of dual 6513's again with sup720-3B). Each pair of distribution switches aggregates access layer switches (layer 2 only) and provide resilient HSRP gateways for access into the network, and also act as STP root / secondary root bridges. All standard stuff. We have changed the VTP domain name from "NULL" to "MA" for the sake of seeing something meaningful in Ciscoworks topology services, but thats as far as it goes. VTP is set to transparent on all devices.

What I would like to do is just enable VTP within the distribution switch blocks, each with its on VTP domain name, leaving the core as transparent but still on the "MA" VTP domain. Each distribution switch will be a VTP server with all access switches configured to be VTP clients.

Is this an advisable deployment ? We currently use Rapid-PVST and I am aware of the limitations this brings with it (i.e. no more than 64 STP instances on a 2950 etc).

I am ruling out VTP v3 as I do not want to move to 12.2(33)SXI, instead we are standardising on 12.2(33)SXH6 which seems to be one of the most stable releases of IOS I have seen in ages, plus it support Layer 3 NAC, which for some reason Cisco have pulled from the SXI train.

Any help / guidance would be helpful.

Chris.

Chris

Like Giuseppe, i have used the design you are talking about and it does work well. As Giuseppe says, if your links to the core are L3 then each distribution block has to be it's own VTP domain anyway because you can't send VTP across L3 links.

Having said that personally i am a big fan of VTP transparent. If you have a very dynamic environment where vlans are being created/deleted all the time then VTP transparent is not the best solution but in any other scenario i would opt for it if given the choice.

You say that you are having issues with STP but VTP server/client is actually a bigger culprit than VTP transparent in this regard. Again, as Giuseppe mentioned, VTP pruning will not help with this. I find if you manually have to add a vlan to each switch then you only add it to the switches that need it. With VTP server/client mode the temptation is just to add it to the server and then it gets sent to each client switch. This is how each switch ends up with far more vlans than it is actually using.

And of course there is always the risk with VTP server/client mode of wiping the vlan database if a new switch is introduced that has a lower revision number.

There is nothing wrong with VTP server/client and if you are going to use it then i think your suggestion is the best solution but i just wanted to put a different perspective.

Jon

cbeswick Thu, 12/10/2009 - 02:54

Hi Jon,

Many thanks for your response.

"And of course there is always the risk with VTP server/client mode of wiping the vlan database if a new switch is introduced that has a lower revision number."

This is my number one concern with VTP and has been one of the major reasons in the past that is keeping me from using it. However I am now finding that the number of Vlan changes made on access switches on a daily basis is taking up far too much time within my team and that it would save us alot of time by deploying VTP.

However we would first need to migrate to MSTP to remove the many STP instances as an issue. Migrating to MSTP isn't something I have done before and fills me with a dread

Going back to my previous point about having campus wide vlans spanning our Layer 3 links into the core - Will enabling VTP on the distribution switches cause any problems with the management of these Vlans, assuming I disable VTP on the backbone links ? Remember that the core will be set to VTP transparent anyway. In this scenario the Cores will be the root bridges for these god awful site wide Vlans.

Jon Marshall Thu, 12/10/2009 - 03:13

cbeswick wrote:

Hi Jon,

Many thanks for your response.

"And of course there is always the risk with VTP server/client mode of wiping the vlan database if a new switch is introduced that has a lower revision number."

This is my number one concern with VTP and has been one of the major reasons in the past that is keeping me from using it. However I am now finding that the number of Vlan changes made on access switches on a daily basis is taking up far too much time within my team and that it would save us alot of time by deploying VTP.

However we would first need to migrate to MSTP to remove the many STP instances as an issue. Migrating to MSTP isn't something I have done before and fills me with a dread

Going back to my previous point about having campus wide vlans spanning our Layer 3 links into the core - Will enabling VTP on the distribution switches cause any problems with the management of these Vlans, assuming I disable VTP on the backbone links ? Remember that the core will be set to VTP transparent anyway. In this scenario the Cores will be the root bridges for these god awful site wide Vlans.

Chris

Can you just clarify what connections you have from the distribution to the core. I was assuming L3 but if you have campus wide vlans then there must be L2 connectivity from the distribution to the core ??

Jon

cbeswick Thu, 12/10/2009 - 03:20

Jon,

Sorry for the missunderstanding. The backbone links arent routed ports, they are switchports which use layer 3 SVI's to form OSPF adjacencies with the rest of the network. To allow legacy applications that use non routable protocols we also trunk campus wide Vlans across these switch ports some of which transition right the way through the core to all the other distribution switch blocks. These campus wide vlans have their roots and secondary roots configured on the 2 core 6509s.

Jon Marshall Thu, 12/10/2009 - 03:34

Chris

That makes sense now

As Giuseppe says, VTP is concerned with transmitting vlan information between switches and nothing to do with the transmitting of data so you should bnot have an issue with the campus wide vlans as long as they are consistenly numbered which obviously they already are.

Jon

Giuseppe Larosa Thu, 12/10/2009 - 03:20

Hello Chris,

VTP deals with propagation of vlan-ids, having VTP transparent on core switches it is not a problem.

About MST: be aware that Cisco has also a pre-standard MSTP and an 802.1s MST implementation so you need check what is supported on C2950 on current or target IOS release.

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea11x/configuration/guide/swmstp.html

I may be wrong I think this is pre-standard

with MST or MSTP you need a change of mind: as explained by Francois Tallet in other posts: you should divide the vlan space (4094 vlans) between the multiple possible instances: when you need a new vlan you pick up one from the subset associated to the instance with the desired topology.

This because changing the MST config is not handly and without impact and you can associate non existing vlans to MST instances.

Hope to help

Giuseppe

Actions

This Discussion