cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1151
Views
5
Helpful
21
Replies

VTP error 4006+2950+3500Xl

gopal_voip
Level 1
Level 1

hey guys

im at site now, i have a core 4006 with vtp server mode and domain name, now a trunk from 4006 goes to cat2950 which is again attached to a Cat3500Xl switch which is uplinked to another Cat2950,in a line, now teh issues is between teh first 2950 and 3550 teh vtp statistics shows that cat 2950 is downloading teh vtp adverts from 4006 but is not giving it to cat3550Xl, i have doen everything possible, changed domain, name revision number,vtp modes, but in vain.

now the system error in cat2950 says that teh number of STP instances has exceeded teh platform capacity of 64, and cat 3550 says MD5 message digest failure.

i have doen pruning on teh 4006 interface attached to 2950 and also between 2950 and 3550Xl.but im guess im in HEll....

there are 2 more uplinks from the same 2950 going elsewhere.

and i have 80 vlans configured.

guys just HELPpppp

Shukky.

21 Replies 21

glen.grant
VIP Alumni
VIP Alumni

I believe what you are running into is that the old 3500 XL will only support 64 vlans in client mode . I don't know your config but 80 vlans seems like a lot between only 4 switches . How many vlans are you allowing on the link down from the 4006 ? If you passing more than 64 down the link the 3500 is balking and it will change itself to transparent mode automatically if this happens .The 3500 is only capable of 64 individual STP instances . You may have to think about replacing the 3500 xl if you want to use client server in your current config . Also all the domain names on the switches must match . Don't know what the MD5 message is from .

Glen,

Correct me if I'm wrong, but I don't think pruning VLANs fom the trunk will help here. Pruning the VLAN from the trunk only stops the VLAN data; it doesn't stop the VLAN itself from being propagated through VTP. And if the VLAN is propagated by VTP, then the 3500 will have a Spanning Tree instance for it, even if none of the trunks are actually carrying the VLAN.

So the 3500 is actually better off in transparent mode so that you can decide locally which VLANs it should participate in. Then it is appropriate to prune the unwanted ones from the trunk, just to avoid having to process their flooded traffic.

Kevin Dorrell

Luxembourg

dear glen/kevin

its a campus network with approx 30-35 switches, i just replaced my 3750 with this 3500, i agree, pruning will not help, as its for traffic only and not for number of Vlans.

ok the 64 STP instance im getting is in cat2950, hey just hold, Bcos its going to transparent AUTOmatically thats why i was getting this message:

% Domain xxx not in updating mode.

ok ok ok, so now im seeing it, correct me if im wrong .how do i actually see which mode my swicth in , though in VTP status it shows, "cleint " mode.

now how do i Curtail teh number Vlans advertised by the 4006 server.i only require just 5-10 vlans on those trunk links. period.

will going to site on monday , ineed good solution for that .

what command for Vlan filtering amd where to use it, 4006 ???

thanx bhai

Shukky

Shukky,

You are right that it is probably telling "half truth" when it says it is in client mode. I guess it is behaving like it was in transparent mode at the moment, but would revert back to client behaviour if the number of VLANs fell below 64.

I don't think you can restrict the VLANs advertised by the 4006 VTP. It is all or nothing.

If I were you, I would force the 2950 into transparent mode, because then you know exactly where you stand with it. Then you can simply locally remove the VLANs that are not relevant to that switch. I guess that in its current pseudo-client/pseudo-transparent mode, it won't let you remove VLANs anyway.

Let us know what happens - it's interesting.

Kevin Dorrell

Luxembourg

Kev , I don't know , I guess I thought when you manually prune off (cleared the trunk of vlans not wanted) it did not send out bpdus for that specific vlan because manually pruning them affects the spanning tree diameter . Also glancing thru some of cisco's info i ran across this statement .

802.1Q VLAN trunks impose some limitations on the spanning tree strategy for a network. In a network of Cisco switches connected through 802.1Q trunks, the switches maintain one instance of spanning tree for each VLAN "allowed" on the trunks.

To me that says it won't propagate bpdu's if the vlan is not allowed across the trunk . Though it's a little vague . I think I would manually prune off everything but the 5 to 10 vlans he needs to be fed down to the switches and see what happens . Also I know this helped a situation we had with cpu utilization where spanning tree was using too much of the cpu cycles . We went thru and manually pruned everything not needed on the links and it brought that down a lot , which indicates to me a least it was having to handle a lot less spanning tree instances . Maybe I am off base here , don't know .

Glen,

Let me think aloud on this for a moment, if you don't mind, I'm not 100% sure of my ground here, but let's see where it leads us.

I think that what you say is right - if you prune the VLAN from the trunk it will no longer send BPDUs for that VLAN. (Query - should you prune the VLAN from both ends of the trunk, or is it sufficient to prune it from one end only ... and why?) It would be as if that link was shut down as far as the Spanning Tree topology of that VLAN was concerned.

But I think that is not the point. Even if the BDPUs are not going across that particular trunk, the VTP is still doing so. (AFAIK, the VTP is caried on VLAN 1.) So the VLAN is created in the VTP client switch, even if there are no BPDUs coming down that particular trunk. There might, for example, be a different link carrying that VLAN, in which case the switch would still need to know the existance of the VLAN. So I think the VTP client gets to know the existance of the VLAN from VTP, even after it has been pruned from that last of the trunks.

Which brings me to an interesting question: if you have a VTP client that learns the existance of a VLAN, but you prune the VLAN from all trunks leading to that switch, does that switch necessarily think that it is the root of the VLAN. I think so, but I have not tried the experiment yet. The VLAN becomes local to the switch, but may have an alter ego outside the switch. If you configure two ports on that VLAN, would they communicate? Would there be a Spanning Tree instance, cut adrift from the outside world? If there are no active ports on the VLAN, is there then still a Spanning Tree instance, or does it shut it down? And if so, is that instance taken off the 64 VLAN limit?

What a lot of unanswered questions! I need a switching lab to try it all out.

Thanks for reading this, and thanks in advance for your comments.

Kevin Dorrell

Luxembourg

gscholz
Level 1
Level 1

Have you tried resetting the VTP password

I have had that issue where I moved a switch from elswhere and the VTP passwords did not match.

kevin/glen hi guyz

now let me think aloud.:

my cat2950 has max of 64 STP instances reached,but then why is my cat3500XL , telling me, that "% Domain XXXX is not in updating mode ", now why is he behaving in that manner,(VTP transparent) ??? though it doesnt have any vlans configured.

my 2950 is sending updates, with MD5, but i have my MD5 digest failure in 3500XL.why is this thing failing,

in cat2950 the "show run" shows me that there are no STP runnin for soem Vlans.?

the Quest is so when the max STP instances has been reached, then this 2950 is not making any STP instances for the new vlan (overheads),!! agree??? so then it should work normally , secondly, i just made 2950 into VTP trasparent to remove all vlans, and convert it back to cleint mode, it again takes all from 4006, no issues, but it wont give it the below switch our dear ol' 3500Xl.

so shud i presume we DO NOT have any command which will curb the VLAN filtering , hey i saw a command in 4006 in some catOS like , Vlan Filter + map-class, whats that all about.??

so todays sunday , tomorrow will be at site, hope all goes well,

pls i hope u will respond optimistically or else i will be forced to make that port not a trunk but an daccess por and config for only one vlan, thus no trunking, but im thuinking , even if i get my old 3750 back, this problem will be there, as its not the new 3500's issue, its an existuing network issue.

pls throw soem light!!

Here is a useful looking document:

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml

especially these bits:

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml#cat25k

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml#ts_vtp_cfg_digest

I'm going to read it myself to see if it has any bearing on this case.

One of the interesting things its says in the flash presentation in the document is that a switch in transparent will only propagate VTP advertisements if the domain name and password are correct, or if the domain name is null. Does that have an impact on what is going on there? I think not, 'cos you say that the first 2950 is getting the VLAN config OK from the 4006, so it must have the right domain name and password. I think it is the 3500 that has the problem.

If I were you, I would try this:

1. Put the 3500 into tansparent mode. (Is it a 3500XL or a 3550?)

2. Change its VTP password, then change it back again. Be careful that it is case dependant, and can include hidden spaces.

3. Put the 3500 back into server mode. Does the configuration version go back up again?

Let us know what happens.

Kevin Dorrell

Luxembourg

hi kevin

no passowrds have been configured, i just made my 3500xl in tranpsparent mode, it working like magic.

but i stil need to nkow , whats teh issue now still, thats bothering me.

rgds

Shukky

India

Hi Kevin,

I'm not following all aspects of this very long thread but one note:

There is a difference between VTP ver 1 and ver 2 advertisement behaviour in the transparent mode.

I beleive ver 2 doesn't check the domain name and password anymore.

See http://www.cisco.com/warp/customer/473/103.html#vlan_trunking_protocol

Regards,

Milan

Milan,

I was rather hoping that you would join this conversation, 'cos I think of all the regulars you are one with the most experience in LAN switching.

It's a pity that V1 is still the default behaviour. I have left my switches all doing V1 - do you use V2? It's also a pity the show vtp domain is so misleading on this, with its "VTP Version" and "V2 mode". (The document also mentions V3, and I shall investigate that.)

I read the document about VTP, and I had several surprises. I cannot remember them all because I didn't bring my notes with me today, but here were some:

1. Transparent mode V1 takes account of VTP domain and password - so it's not really transparent. Thanks for pointing out that it applies to V1 but not V2. I had thought the only difference was support for Token Ring, but I think the difference in transparent behaviour is even more fundamental.

2. The VTP bomb works if the added switch is in server or in client mode. I had thought it was only servers. Looking at the protocol, it seems I was wrong.

3. An interface configured as trunk desirable will not form a trunk unless the VTP domain and password match. (Or presumably if the domain is null, and it learns it?)

4. The limits on Spanning Tree can be quite complex. In some boxes there is a limit on the number of VLANs learned from VTP. In some there is a limit on the Spanning Tree instances. On some there is a limit on the Spanning Tree port instances, i.e. (VLANs * number of ports in each one).

Kevin Dorrell

Luxembourg

Hi Kevin,

you are right, the show vtp domain output is pretty confusing.

I'm using VTP 1 still, I've got no time to move to ver. 2 and I don't think there is a big difference between v 1 and 2 from operational point-of-view.

V3 is not supported on XL switches, so I can't use it.

The document mentioned is one of my most favourite, it includes excellent information about trunk and control plane protocols, too.

To your "surprises":

1. and 2. - not widely-known features, most VTP descriptions don't mention it.

3. That's why I'm configuring all my trunks nonegotiate.

4. " In some boxes there is a limit on the number of VLANs learned from VTP." - 2940s especially, one of the most STUPID Cisco IOS features I've ever met.

" In some there is a limit on the Spanning Tree instances. " - 2900XLs - 3550s (I'm not sure about 3750).

"VLANs * number of ports in each one" - 4000s - 6500s - chassis-based switches.

See my discussion in "Ask the Expert archive" thread 2 years ago: http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Expert%20Archive&topic=Network%20Infrastructure&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.ee97145/51#selected_message

Best regards,

Milan

hi kevin\glen\milan

Thank you for your response and support, im now presuming that this was the best solution for the occasion and we need to manually create vlans in transparent mode in order to curtail teh number of vlans.

or leave the other vlans without their spanning tree, or else better , if im sure of my network architecture, then will not configure spanning tree.

Thanking you all

Prashant Shukla (Shukky)

India.