Have a delima 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 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 cluster, the VM's might be any any of the ESX hosts, and therefore, I have to have every VLAN on every 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 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 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). Is there anything I'm missing that would make this solution work?
Reply to
Loading thread data ...


My understanding is that the switch strips the VLAN tag from the frames on receipt, uses an internal mechanism to pass the frame through the switch maintaining the VLAN ID and then re-tags the frame on exit.

This mechanism allows for example a frame to be received via an ISL trunk and then to be sent on an 802.1Q trunk or an access port.

So:- I would expect that you will not be able to bypass an architectural limit on the number of vlans.

However - I have no experience of this and I could be completely wrong:)

If you can point me to some ducumentation I will take a look. (typos is us:)

Reply to

Thats correct, even to pass the VLAN through a switch trunked in, and trunked out, the VLAN must be configured in the VLAN database on that switch, even if the switch in VTP Transparent mode. And the switch will not let you add more VLANs to the database than the hardware will support. VTP doesn't gain you new abilities, it just saves you from having to manually configure the VLAN database by hand instead of mostly magically (until it breaks, like VTP is want to do).

If the VLAN ID is not in the VLAN database, the packets will not make it through the trunks.

The 2960's were the wrong platform to roll out if doing a large number of VLAN trunking due to their smallish number or VLANs supported. Could be worse, the ancient c2924XL's only supported 64 VLANs. That was painful when I first ran up against those limits, especially in a ~260 unit MDU layout.

My suggestion to the OP is to lose the largish layer-2 network that you are seem to be creating, and start doing layer-3 to the switch edge, at which point you can create layer-2 trunks out from your L3 devices directly into the ESX machines. Let the L3 do the routing for you as needed, and backhaul that into where it needs to go. I do both real routed IPs for ESX clusters. If I needed NAT/Firewall, I use firewall boxes that can handle the throughput and can do enough VLANs trunked directly into the ESX clusters.

The 4500 SupIV's are fairly cheap used, and support a ton of VLANs. But if they are your L3 devices, you don't need to maintain a consistant Layer2 environment at that point anyway, and then each one can do the 1005 VLANs that a SupIV can do. You'll find this sort of general suggestion in the Cisco SRNDs as well, push layer-3 as close to the edge as you can, and things will go better for you..

Reply to
Doug McIntyre Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.