|
Home > Archive > CCNA > October 2001 > VTP, ISL, Trunks and BS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VTP, ISL, Trunks and BS
|
|
| chunder 2001-10-08, 10:44 pm |
| ok.
VTP server is a Catalyst 5509 (Switch0). VTP Clients are 3 Catalyst 3548xl's (Switch1, 2, 3).
Server sits on floor 1. all Clients sit on floor 3. ONE giga-fiber link from Switch0 (port 1/1) straight to Switch1 (port Gi0/1). Switch1 (from Gi0/2) also connects to Switch2 (to Gi0/1) via Gbic. Then Switch2 (from Gi0/2) connects to Switch3 (to Gi0/1) via Gbic. follow me? no? draw it out...
ok. trunking is enabled (using ISL) on Switch0 1/1 and on Switch1 Gi0/1. Switch1 sees the VLANs as configured on Switch0 but the others (Switch2 & 3) don't...
do i also need to set trunking to on (of course with ISL, if so) on Gi0/2 on Swithc1 and Gi0/1 & 0/2 on Switch2 and Gi0/1 on Switch3?
oh, the 3500s are in a management cluster (if that matters).
it's probably something simple like that but i need the time to get on these switches while no one else is and try it...
thanks for your input.
*hopefully this shall help spark some discussion in this board again.. if not, oh well, huh. | |
| depamo 2001-10-09, 12:54 am |
| Here we go, you have 4 switches daisy chained from the 5509 out with some other VTP capable switches.
So long as you have them connected, this is a good place to start. I recommend you go one switch at a time, disconnect those that you have not added yet to better find problems with configuration.
Since your 5509 is the base server VTP switch, we will start there, it should be good since you see something on one of the switches. The next switch out, only have the connection to the base switch, you will have to reset your configuration so you might want to copy to a text editor or something.
Issue a clear config all (this will erase your config, but you need to do it to reset your config revision number to 0). Power cycle the switch to insure it is reset, once up again check your turnk port and VTP domain on the 5509, then set your trunk port and mode, set your VTP mode, and then set your VTP domain to match the 5509 VTP domain.
You can check your config with the show vtp domain command to make sure all is well.
Then you just repeat out the daisy chain. Once you get all that straight, you can enable your VLAN's again from the server and assign them on the access switches.
Although I do admit, there is some question about using a daisy chain method here. The switch with the highest MTBF should be the central source of the lines to the access switches. Right now you have multiple points of failure that can isolate parts of the network with an outage that could be avoided. Overall changing the configuration will increase speed and reliability in the long run. Anyhow, your network, have fun!!
It is quite a bit of work to go through each command for configuring each step so you should be able to get the rest form the Cisco Web Site once you get the general idea. | |
|
| actually much easier than that. You must set the other links as trunks... Otherwise there just regular connection and wont pass vlan info accross.
your right there just enable trunking with isl on all connections between switches and your golden..... | |
| chunder 2001-10-09, 10:59 pm |
| thanks guys. good ideas, especially from depamo... not that 007's isn't a good idea, it's just that depamo's was a little more thorough and probably what i'll have to do should the "quick fix" not work initially. 
again, thx to you both. | |
| depamo 2001-10-09, 11:12 pm |
| Forgot to say why you need to go through the power cycling before entering your switches in the network on a VTP.
Each time a change to the network is sensed from the servers in the network (those switches that can change VLAN information for the VTP domain) the revision number is incremented and then sent out, in suit all the other switches send it out.
If you have a switch that has a VLAN update still in the NVRAM where they are stored, when you activate VTP even if it is a client, it will send this out to all the other devices which can override your VLAN configurations on your 5509 since it received an update that was higher then what it had in memory.
Just looking out for your best interests, would hate to have you post back that you enable your trunk and your VLAN's went screwy on you. | |
|
| try my suggestion before you knock it. Regardless of VTP configuration you will never pass vlan information across to your other switches if they arent set as trunks.
You could play with VTP and revision number, which are both very important, although, if you setup the other switches as clients they wont over take the VTP domain with their config. But unless you have trunking between switches how do you expect them to pass along vlan info?????????
If you have a config where one switch is server and the other three our clients, where is your revision problem???
Maybe Im missing something but I dont see how syncing your VTP setup, and worrying about revisions in this type of config will help you.
Please write back when your done and let us know what solved your problem, Im curious to see what Im missing here??????????
thanks | |
| dmaftei 2001-10-10, 12:05 pm |
| quote:
Originally posted by 007
...if you setup the other switches as clients they wont over take the VTP domain with their config.
I think this is where you're missing something. If the new switch is client and it happens to have a revision number higher than the "good" revision number in the VTP domain, it will take over. I don't know if the power cycles are necessary, though. You need to be sure that the revesion number on the new switch is small, and, afaik, you can do that by changing the domain name to something else, and changing it back to the good name. | |
|
| hmmmmm,, that interesting, I have to look this up,, thanks for bringing to my attention.
But, without setting those uplinks between swicthes as trunks, how will he pass the vlan info accross those links?? | |
| Mat P 2001-10-10, 12:37 pm |
| I agree trunking will be needed to pass traffic from all vlans, though your VTP advertisements should (I think) pass as they are on default vlan anyway.
Chunder mentioned clustering, I was really impressed first time I saw this, for anybody that hasn't seen it try this demo at cisco's site - as far as I remember it isn't on CCNA or BCMSN - saves a customer buying Cisco works, if all they want is basic management.
http://www.cisco.com/warp/public/779/smbiz/multimedia/
As long as you don't change any of your management domain names (I think)on your switches clustering should still work. | |
| Quintoh 2001-10-10, 1:52 pm |
| Question:
Shouldn't the power cycles return those switches' revision number back to zero? If so they shouldn't be able to take over and send the bad info.
Quintoh | |
|
| guys if you read the intital post, The server swicth and one client switch who are trunked work just fine, the problem is that the other 2 switches that dont have trunks configured cant see any vlan info. How is this a VTP issue?????? why does one of the switches on the 3rd floor work fine but the other 2 dont??? | |
| dmaftei 2001-10-10, 2:28 pm |
| My impression was that everybody's in agreement that there should be trunk links between switches.  | |
|
| I've already agreed with you!!
I would suspect two things :
1. Trunking
2. VTP
Without trunking the only traffic to pass would be default VLAN - these links need trunking on.
VTP - It is also possible that VTP could be configured incorrectly, maybe the domain names are wrong, maybe the switches are really set to transparent, though apparently not.
What dmaftei/depamo are saying is correct as always! If trunking is enabled and one of the two switches is at a later revision number then this configuration WILL overwrite all his vlan info on the server, this link expands on this.
http://www.cisco.com/warp/public/473/21.html#VTP Troubleshooting and Caveats
Dmaftei doesn't want trunking enabled just in case this is the case - it probably isnt.
The link above describes ways to put new configurations on your VTP clients.
It also says "Remember, VTP packets are carried on VLAN 1, but only on trunks (ISL, dot1Q or LANE)." I only found this after my last post!
So your both right, but they are possibly using unfortunate experience (or somebody elses experience) to ensure that he doesn't create problems for the users who are up and running - especially when it is an issue which is well documented and tested!
Hope that helps!! | |
| dmaftei 2001-10-10, 3:10 pm |
| quote:
Originally posted by Mat P
I've already agreed with you!!
I guess you did, but my comment was for 007. Anyway, your last post is a nice summary of this thread. | |
|
| guys help me understand this. I checked in both the LAN swithcing book, and building multilayer switched networks.
I guess the only difference between client and server switches in a vtp domain, is that the server configured switch will store vtp info in nvram, that way it knows when a change is being made and populate out to others in the domain. Thats why if you reboot the client the revision will go to 0. However, up untill this point I always though that if you have a switch configured as client and you added it to an existing vtp domain, the revision didnt matter because its not a server. However, after doing some reading I see that both clients and servers can forward vtp info, is that what it does by default when you first insert into to domain, if it has highest revision #???? | |
| chunder 2001-10-10, 5:42 pm |
| there's been some really good input from you all and i appreciate that.
i will definately make certain i do take into consideration the things you have mentioned (too bad i won't be performing the operation for a little while).
initially, i could have stated my situation like this:
i have a Managed Cluster of 3 Cat. 3548xl's that are daisy-chained to each other. on the 1st switch in the cluster is a Gig-fiber link to our 5509 (no other switch connects directly to the 5509).
the 5509 is acting as a VTP server in my domain. i set all 3 of the 3500s to client in same domain. trunking is enabled only on both ends of that gig-fiber link from the 1st 3500 to the 5509. as a result, only the 1st 3500 can see the same VLAN information as configured on the 5509. given that the 3500s are in a cluster, should i enable trunking on the links that connect the 3500s to each other to make the other 2 switches see that same VLAN information? or do switches in a cluster still need trunking on all links? had i stated my question that way, would any of you answered differently?
maybe some of you would but i don't think i would have wanted you to -- given the information that you have provided.
ok, who has a lab similar enough to my production environment to test it?
again, thanks guys and good discussion. | |
| dmaftei 2001-10-10, 6:11 pm |
| quote:
Originally posted by 007
However, after doing some reading I see that both clients and servers can forward vtp info, is that what it does by default when you first insert into to domain, if it has highest revision #????
Yup. Check the link poster by Mat (without the #VTP, though: try here and jump to troubleshooting) | |
| dmaftei 2001-10-10, 6:16 pm |
| quote:
Originally posted by chunder
maybe some of you would...
I wouldn't... 
I guess you need the trunk links even if you have the cluster. | |
| depamo 2001-10-11, 9:27 pm |
| Why clear your configuration and power cycle the switches.
Cisco recommends this to make sure that you don't knock out your entire network. A switch will hold information on VLAN's until an update with a higher revision number is received from the server in its VTP domain. If it gets one with a lower revision number, it will immediatly send out the information that it has with the higher revision number to make sure the rest of the network has the most up to date information.
Unfortunatly if you start a switch with some old information in it with a higher revision number, it will wipe out all VLAN information across the entire VTP domain as it will send out its update and all receiving switches will dump their VLAN information in favor of the higher revision number information.
It can be a pain in the booty. You can just clear your configuration but you can probably see from this information that I just stated why they want you to be absolutly sure that this will not happen. Some switched networks can have upto 30-40 switches with one switch crashing everything if this happens.
Another good reason to keep your VTP domain separate between your Core and Switch Blocks from the domain in the Switch block, just in case, you won't have to reconfigure your core connections, really big pain in the booty. | |
| chunder 2001-10-19, 10:58 pm |
| i went into my Cisco Cluster Management web page for the cluster upstairs.
i selected the Gi0/1 int on sw3 as it was the last on the chain. then i used the handy GUI to tell that port to be an ISL Trunk port -- which makes it so the cluster can't see that switch anymore (and this i new from before).
then i went to Gi0/1 on sw2 and did the same. can't see it anymore too -- and this was expected.
then i went to Gi0/2 on sw1 and did as on the other 2. then i closed the GUI and went back in after waiting a minute or two.
all is well. thing that makes me mad is that i was SOOOOOO close 1 month ago (monthly maintenace weekends here) but it was getting late and others wanted to bail... so, i come to you all and you all basically reaffirmed what i thought i should have done.
thanks! good thread? i hope.
over and out. |
|
|
|
|