|
Home > Archive > CCNP > August 2001 > Switching - VTP Modes
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 |
Switching - VTP Modes
|
|
| peterd 2001-08-23, 7:49 am |
| hi,
I'm booked in for the switching exam next week so I'm hitting the practice questions.
One is asking about the three VLAN modes, server, client & transparent. It then goes on to give an explanation that states:
"Switches in transparent mode do not participate within the VTP domain, they forward all advertisements but are not active within the management domain. However they can create, modify and delete VLANs"
I'm not sure about that last part, it doesn't look right to me. The Cisco Press Book (Webb) p 109 says that it doesn't advertise it's VLAN config, doesn't synchronise with received adverts but v2 will forward received adverts.
There's no mention of transparent mode being able to create modify and delete VLANs.
Can they do so, or is the practice question explanation wrong?
Regards
Peter | |
| dmaftei 2001-08-23, 8:05 am |
| quote:
Originally posted by peterd
"Switches in transparent mode do not participate within the VTP domain, they forward all advertisements but are not active within the management domain. However they can create, modify and delete VLANs"
I'm not sure about that last part, it doesn't look right to me.
It means switches in transparent mode can create, modify and delete their own VLANs. These VLANs are not advertised in the VTP domain, and the VLANs advertised in the VTP domain are ignored.
HTH | |
| peterd 2001-08-24, 1:32 am |
| Hi,
I did wonder if that was what it meant, thanks. The book doesn't seem to mention it at all. Or maybe I've missed it...
Regards
Peter | |
|
| Peter,
I was doing a Boson test this morning and there was a similar question. It's worth bearing in mind that when using VTP Version 1 a transparent switch doesn't forward advertisements. VTP version 2 does.
Cisco press BCMSn, P109.
Good luck next week, I'm taking mine soon in Leeds but the Boson questions on multicasting are putting me off - similar 2 weeks to the 2 weeks you mentioned recently!! Tomorrow never comes etc.
Mat P | |
| dmaftei 2001-08-24, 7:48 am |
| quote:
Originally posted by peterd
I did wonder if that was what it meant, thanks.
I'm positive that's what it meant. You can supplement the book with this Cisco VTP documentation. | |
| dmaftei 2001-08-24, 7:51 am |
| quote:
Originally posted by Mat P
It's worth bearing in mind that when using VTP Version 1 a transparent switch doesn't forward advertisements. VTP version 2 does.
Cisco press BCMSn, P109.
Not so, I'm afraid. According to Cisco (see link above) the only difference between VTPv1 and VTPv2 is that version 2 supports Token Ring VLANs, while version 1 doesn't. | |
|
| I don't want to keep going back and forth with this saying told you so, but the VTP link above states :
VTP Version 2 (V2) is not much different than VTP Version 1 (V1). The major difference is that VTP V2 introduces the support for Token Ring VLANs. If you are using Token Ring VLANs, you need to enable VTP V2. Otherwise, there is no reason to use VTP V2
It actually says the major difference not the only difference.
I think peter needs to make his own mind up on this one, although he also mentioned the relevant quote from BCMSN book in his original post and appears to agree with myself. I have been proved wrong in the past and will happily put my hands in the air if I am wrong this time.
Out of interest Dmaftei, how do I do the quotes??
Best of luck Peter,
Mat P. | |
| dmaftei 2001-08-24, 9:41 am |
| quote:
Originally posted by Mat P
It actually says the major difference not the only difference.
That's true. I suspect the minor differences are really minor. A switch in transparent mode that does not forward VTP advertisements would be another major difference. Let's think about it. You have three switches in a VTP domain:
A---B---C
A is in server mode, B is in transparent mode, C is in client mode. You want to create your VLANs on A, and have them propagated on C. B does not forward VTP advertisments. Oops!! The VLANs created on A will never make it to C. 
The whole point of having the transparent mode is to be able to deal with situations like this. If switches in transparent mode didn't forward VTP advertisments, you might as well not bother with a transparent mode at all. What would be the use of that?
Why don't you (or Peter) try this setup, and see if C learns the VLANs from A, through the transparent mode switch B?!
quote:
I have been proved wrong in the past and will happily put my hands in the air if I am wrong this time.
No need to put your hands in the air; we're here to discuss, not to shoot at each other. 
quote:
Out of interest Dmaftei, how do I do the quotes??
If you want to quote a whole message, click on the little page with a red arrow at the bottom of the message. If you want to paste something, put it between "[quo-te]" and "[/quo-te]" tags, without the dashes (I had to insert the dashes so that the tags are not interpreted). | |
| depamo 2001-08-24, 12:29 pm |
| As far as I know about the VTP Transparent mode was that it acts as a link for other VTP enabled switches in the same domain. It will not use the VTP information but it 'transparently' continues to send trunking information to other switches, it maintains tables on the trunking information and who needs what, it merely does not use the information in the trunk.
The purpose of the Transparent mode is to do exactly what you said, if a switch is not to participate in a VTP, it is transparent to the VTP domain if you need the semgent to keep the VTP information flowing to distant portions of your network. What it will not do is participate in the VTP through sending its own VLAN information through the domain.
So the ABC example above, if you have VLAN 1 on A and C, A is a server with C as a client and B as transparent, C will learn about VLAN 1 and be able to assign ports to VLAN 1.
As for VTP version 1 and 2, 2 does have some enhancements over 1 but most Catalyst switches can only talk version 1. Problem here?? Oh yes, version 2 is compatable with version 1 but it needs to talk down so all your version 2 switches talking in a VTP domain with version 1 switches are now literally transfering version 1 information only. So if you have an environment that is mixed, could cause some problems with information not propogating through due to lack of functionality in Version 1. | |
| Steve_NTS 2001-08-26, 9:33 pm |
| I hate to go back to this but pg 115 of CCNP Switching Exam Guide (Cisco Press - Hucaby)
says:
"in VTP version 1, a transparent mode switch does not even relay VTP information it recieves to other switches. In VTP version 2, transparent switches do forward received VTP advertisements out of their trunk port, acting as VTP relays"
But, http://www.cisco.com/univercd/cc/td...g/vtp.htm#21589
says this:
"Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version, and forwards a message only if the version and domain name match. Since only one domain is supported in the supervisor engine software, VTP version 2 forwards VTP messages in transparent mode, without checking the version."
any thoughts on this? | |
| strikeattack 2001-08-27, 7:51 pm |
| Regarding VTP1 and VTP2, this is from my notes regarding VTP....
There are two versions of VTP. There is a version one and a version two. The two types ARE NOT compatible. VTP version 2 offers Token Ring VLAN support.
The Cisco BCMSN press book doesn't really make any other mention of the differences. Interesting... Even if its not required for the test, I would like to know EXACTLY what the differences are... | |
|
| The Karen Webb BCMSN book P 112/113 details several differences between the two :
VTP 2 offers the following not in VTP 1 :
Token Ring support.
Unrecognised Type-Length-Value (TLV) support. not sure what this is though!!!
Version Dependant transparent mode. VTP 1 forwards VTP advertisements only if version and domain match. VTP 2 operating in transparent mode forwards all VTP messages without checking the version.
Consistency checks. New data entred via CLI or SNMP is checked for consistency. Data received via a VTP message or from NVRAM is not unless digest (assume MD5 digest)is correct.
Version number propogation. If all switches in a domain can run VTP 2, you only need to enable VTP 2 on one switch and all others change mode.
I've probably raised more questions now, such as what is Unrecognised TLV???
Mat P. | |
| peterd 2001-08-28, 5:26 am |
| Hi Mat,
You wrote:
Good luck next week, I'm taking mine soon in Leeds but the Boson questions on multicasting are putting me off - similar 2 weeks to the 2 weeks you mentioned recently!! Tomorrow never comes etc.
yep, but it eventually came around for me! I took the test about 2 hours ago (full report in another message) in Wakefield, Leeds is closer (I'm in Scunthorpe) but I don't like the traffic around Leeds, it's raving dangerous...
The boson questions were pretty tough I thought, far harder than the actual exam.
Regards
Peter | |
| dmaftei 2001-08-28, 8:02 am |
| quote:
Originally posted by Mat P
I've probably raised more questions now, such as what is Unrecognised TLV???
A TLV "field" is a triplet of fields in a PDU (protocol data unit) header. It's normally used for options. The T and V fields are fixed length (say, 1 byte), while the length of the V field is given by the value in the L field (you have a "2" in the L field, that means the V field is 2 bytes).
TLVs are a neat way of allowing for future, backwards compatible, protocol developments -- if you design your protocol to support "unrecognized TLVs", that is (BGP4 is designed this way, and apparently VTP2).
Say you have VTP2, which supports unrecognized TLVs. You get an idea that you should advertise the texture of your VLANs in VTP messages. You invent a new option, TEXTURE, and you use a TLV for it. T would be 1 byte wide, and its value would be 55 (or another available number), which will denote the TEXTURE option. L would be 1 byte wide, and its value would be 1. V would be 1 byte wide (from L's value), and its value could be 0 for SMOOTH, or 1 for ROUGH. So now you have a new option, TEXTURE, that would look like (bytes are sepparated by dashes):
55-1-0 for SMOOTH
55-1-1 for ROUGH
You implement this in your VTP, and now your switches can learn the TEXTURE of their VLANs. But you need to insert a VTP2 switch in your switch fabric. With no support for unrecognized TLVs, the VTP2 switch would probably crash, because it will have no idea what that "55" in 55-1-0 means. But VTP2 supports unrecognized TLVs, so when the switch sees the "55" it will think "oh, I don't know what this 'thing' is, so I'll ignore it, but I need to know how long it is, the next byte gives me the length, ok, it's 1 byte, so I'll skip that byte, and after that I can resume normal processing." That's pretty much all.
Great quote from Karen Webb, btw... |
|
|
|
|