Max VLANs

[jeffgraves]

Have a dilemma with max vlans. We're a service provider, and as such, we give each customer their own dedicated subnet and VLAN. The basic topology is 4500's as distribution switches and 2960's as access switches. We have ESX/HV hosts running off of the 2960's. Currently, we're running PVST, but the 2960's support a max of 128 instances which we're nearing, so we are looking to switch to MST or more likely, flex links.

However, the vlan database currently has 200 VLANs and we're nearly exhausted there, so I plan on adding more. The limit of the 2960's is 255 VLANs though. The problem is, with a massive ESX/HV cluster, the VM's might be any any of the ESX/HV hosts, and therefore, I have to have every VLAN on every switch because I may have cluster hosts on that switch. The 2960 access switches don't have any access ports tagged with those VLAN's, they just have a trunk port to the ESX/HV host, and a trunk port up to the distribution switches. I wouldn't need to do any VLAN pruning or limit the VLAN's being sent across the trunk ports.

If I switch from a VTP domain to VTP transparent mode, do the 2960's still have to have a VLAN in their local database in order to carry it over their trunk ports to the ESX/HV hosts or are they smart enough to just pass the already tagged VLAN traffic across the trunk ports up to the 4500's, which would effectively let me bypass the limit of 255.

I'd rather not have to double up customers on VLAN's (security concerns) or go out and purchase all new 3750's to replace all of the 2960's (don't have that kind of budget) to increase my limit to 1000 vlans. Is there anything I'm missing that would make this solution work?

[Jon Marshall]

If I switch from a VTP domain to VTP transparent mode, do the 2960's still have to have a VLAN in their local database in order to carry it over their trunk ports to the ESX/HV hosts or are they smart enough to just pass the already tagged VLAN traffic across the trunk ports up to the 4500's, which would effectively let me bypass the limit of 255.

Jeff, for the switch to pass the vlan traffic from one port to another the vlan must exist in the vlan database on that switch whatever VTP mode the switch is in so i'm afraid you won't get past the 255 limit.

Apart from upgrading the only thing i can suggest is organising the switches by vlans and having more control over which vlans are used on which switch ie. controlling which vlans the ESH/HV hosts can use on any one switch but i appreciate this is not an easy thing to do.

Jon

[jeffgraves]

Thanks Jon. Unfortunately, we lease space at a datacenter, so we have to put switches and hardware whever there is room, and that doesn't necessarily mean in close physical proximity to other systems.

I'm interested what other service providers do in these situations. Do they put multiple customers on the same VLAN, or not segment customers by subnet? I found some stuff on Q in Q which sounds like it would solve this issue, but that seems to be on the 12000 series.

[Jon Marshall]

jeffgraves wrote:
Thanks Jon. Unfortunately, we lease space at a datacenter, so we have to put switches and hardware whever there is room, and that doesn't necessarily mean in close physical proximity to other systems.
I'm interested what other service providers do in these situations. Do they put multiple customers on the same VLAN, or not segment customers by subnet? I found some stuff on Q in Q which sounds like it would solve this issue, but that seems to be on the 12000 series.

Jeff

Never worked in service provider enviroment so wouldn't like to say what they do. I doubt very much that they have customers on the same subnet/vlan. As far as i understand Q-in-Q allows the provider to allocate a dedicated vlan to each customer which is used to tag the customer traffic across the provider cloud so i'm not sure how this would solve your issue.

Jon

[Giuseppe Larosa]

Hello Jeff,

802.1Q tunneling is a L2 >>point to point<< transport  solution to carry 802.1Q tagged frames with an external customer 802.1Q tag it is supported also on switches including old C3550.

However, in your case I'm afraid it is not of help because C2960 are not in the middle of the path but at the access layer.

if supported you could configure trunk ports to ESX as tunnel but a different vlan-id should be used for each "tunnel" and you would end up with the same scalability limits or worse.

You should:

configure each C2960 as a VTP transparent (they put themselves to transparent automatically if  VTP DB is too big) and you should manage the local vlan database manually.

The use of switchport trunk allowed vlan on both ends of trunk uplinks allows to minimize the number of STP instances running (if PVST+ or Rapid PVST) but it is not of help if the problem is at the VTP level ( vlan DB size).

to have a "plug and play" environment you would need C3750 or C4948 but of course budget is a problem.

Hope to help

Giuseppe