Vlan issues, 2950 and/or 3500XL series

[brian-vachon]

Hey all,

As most know there is a number of vlan's restriction with the 2950 and 3500XL series. That restriction is 64.

Here's the senerio....

1, Very large campus

2, A LOT of vlans

3, More vlans planned for an ongoing project and even more for an upcomming project.

4, The biggie...must use VTP, customer wants a centralized point to manage their vlans.

Total amount of vlans will be in excess of 100.

I think to myself, should be no problem. I'll do vtp pruning at the core and also only allow specific vlans on specific trunks.

Well, I lab'd it before implementing and it's not working the way I anticipated....Pruning is working great, restricting what vlans can traverse the trunk is also working great. Problem is that all the vlans are still being advertised thru VTP. What's happening is that the 2950's and 3500's are reverting back to transparent mode due to their vlan limitation.

Getting a message "%SW_VLAN-6-VTP_MODE_CHANGE: VLAN manager changing device

mode from CLIENT to TRANSPARENT."

Thus the access layer switches do not learn about any of the vlans, everything breaks, I get frustrated start swearing and pull my hair out and

say wah wah wah.

Am I missing something here folks? Ideas?

Thanks,

Brian

[milan.kulik]

Hi,

are you sure you are receiving this messages on Cat3500XLs?

I remember an Ask the Expert discussion on this forum a year ago with the resultes:

There was a limit on VLANs configured on 3500XLs (256? I'm not sure). But only 64 of them were able to run STP. So if you added 65'th VLAN, one (random) VLAN stopped STP.

Maybe later on Cisco decided to fix this problem with 64 VLANs limit for VTP running on 3500XLs. I've not heard about it. I'd expect this aproach on newer device lines (2950 maybe, definetely 2940s have this limit only 8 VLANs). I'd expect 3500XL left without this limit, they are EoS so no new features should be added to their IOS.

To your problem:

VTP really advertises ALL VLANs, you can't change this behaviour.

VLAN prunning doesn't help, it only blocks broadcasts when there are no VLAN assigned ports down the trunk, but doesn't decrease STP instances running on the switch nor VLANs advertised by VTP.

You have to disable VLANs on trunks manually anyway.

So I'd try do downgrade the switches to some older IOS which might have not this VTP automatic mode change implemented.

If downgrade is not possible, I'd move all your switches to transparent mode.

I'd prepare a vlan.dat file with a big number of VLANs (1-200) configured and copy it to Flashes on all switches. (Two files to be precise: one for 3500XLs, one for 2950s.)

Disable proper VLANs on trunks manually. (You have to do it anyway because of 64 STP instances limit.)

Use one refference switch VLAN database for VLAN descriptions.

This way you'll have a big number of VLANs prepared but not used.

Adding a new VLAN to your network will only mean:

1. Change the VLAN description on the refference switch.

2. Enable this VLAN on proper trunks.

3. Assign ports to this VLAN where necessary.

There might be some little problems with trunk negotiations, e.g. But I think when disabling VLANs on trunks manually, you can also configure trunks to nonegotiate.

I know this doesn't fulfil your

"4, The biggie...must use VTP, customer wants a centralized point to manage their vlans"

requirement. But I can't imagine any other solution on this devices.

You can use CiscoWorks, e.g., as "a centralized point to manage their vlans".

Good luck,

Milan

[brian-vachon]

Hi Milan,

You are right on the money about several things...

1, Message is from a 2950, I do not have a 3500 in my lab.

2, 3500..it is 64 STP instances, not 64 vlans, I knew it was one of the 2, I was working with a 2950 in my lab...my bad

Now you said a couple things that peaked my interest!

1, Transparent..not an option, my customer has an extremely understaffed IT department (who doesn't? ). Too many edge devices to have to do that to, or to facilitate changes for them would be a nightmare.

2, CiscoWorks...now I know CW, I thought inside and out. I know I can asign vlans thru CW, but where can you manage them? How would they be pushed to the edge devices? It will not act as a VTP server nor handle/create multiple VTP domains as far as I know. Are you thinking there is a way to do this? Can you elaborate on how you think CW can help in this senerio?

3, 2940's..great to know. I wasn't aware of the 8 limitation. Thanks.

The other option that I'm seriously contemplating, which right now I think is the only viable solution (unless CW pans out), is multiple VTP servers and strategically configure the vlans on those devices to allow for no more than 64 instances of STP.

Please, let me know your thinking on CW. Now it's got me thinking! Damn, back to the lab to investigate the CW option!

Thanks again,

-Brian

[milan.kulik]

Brian,

my idea was to move all switches to transparent mode, prepare vlan.dat file with 200 prepared VLANs and to use CiscoWorks as a central point of trunk manual configuration (denying unnecessary VLANs from trunks).

I don't know any possibility of using CiscoWorks as VTP server or something like that.

If you are able to divide the nework to sveral VTP domains conatining less than 64 VLANs, you can use this aproach.

But the network will be a little complicated.

Cisco doesn't recommend usin more than one VTP domain in L2 network (but it's possible).

Just be careful on the domain edges. You need to set trunks to nonegotiation there (you need the same VTP domain on both trunk sides when negotiating).

Regards,

Milan