12-28-2010 08:22 AM - edited 03-06-2019 02:44 PM
I have read many resources about VTP and not found an answer to some questions because often the informations seem inconsistent.
First question
It is not clear if "advertisement requests" are sent only from clients or also from servers.
Second question
It is not clear if, when I change the configuration on a server and after the adjacent switch receive the advertisement from that server, this second switch send an advertisement on his own too or it forwards the first advertisement received from the server without change it.
Third question
This third question is a consequence of the second. It is not clear if VTP messages are forwarded without changing the ethernet and the trunk header.
In other words, transparent switches do not absorb these message and so they forward them unchanged I presume, but servers and clients do absorb these messages and it is not clear if before forwarding them, they process them and send messages with the same informations but with different headers. I presume that they process and forward them at the same time even if, in this case, when a switch receives a message with an updated revision number, it would forward a not useful message. I do not know if, before the forwarding of VTP messages, the switch does intelligent processing in order to understand if it makes sense to forward that message and in this case if it changes or not the original header. In other words: if and when servers and clients do "TRANSPARENT BRIDGING" of VTP messages?
Thanks.
Solved! Go to Solution.
12-28-2010 01:11 PM
Hello Matteo,
>> in other words: if and when servers and clients do "TRANSPARENT BRIDGING" of VTP messages?
Never they need to process them so they cannot simply forward them.
VTP messages have a proprietary encapsulation LLC/SNAP and a L2 multicast destination MAC address.
VLAN Trunking (VTP)
0x2003 : last two bytes of SNAP header a sort of protocol type
01-00-0c-cc-cc-cc : destination MAC address
The majority of Cisco control protocols use an IEEE 802.3 SNAP encapsulation, including LLC 0xAAAA03, OUI 0x00000C, which can be seen on a LAN analyzer trace
So a frame should look like
Preamble|01-00-0c-cc-cc-cc|SA|0xAAAA03|0x00000C|0x2003| VTP payload
see best practices for IOS based switches
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#cg1
Propagation of new VTP information takes some time (minutes) in the network and this should demonstrate that messages are processed and not forwarded immediately.
>> about trunking header from the same document
CDP, VTP, and PAgP updates are always forwarded on trunks with a VLAN 1 tag. This is the case even if VLAN 1 has been cleared from the trunks and is not the native VLAN. If you clear VLAN 1 for user data, the action has no impact on control plane traffic that is still sent with the use of VLAN 1.
Edit:
also this one about VTP version 3,2,1
http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml
Well, documents speak of forwarding of VTP messages, but in my experience the behaviour is more similar to RIP then to OSPF flooding just to make an example.
Hope to help
Giuseppe
12-28-2010 01:11 PM
Hello Matteo,
>> in other words: if and when servers and clients do "TRANSPARENT BRIDGING" of VTP messages?
Never they need to process them so they cannot simply forward them.
VTP messages have a proprietary encapsulation LLC/SNAP and a L2 multicast destination MAC address.
VLAN Trunking (VTP)
0x2003 : last two bytes of SNAP header a sort of protocol type
01-00-0c-cc-cc-cc : destination MAC address
The majority of Cisco control protocols use an IEEE 802.3 SNAP encapsulation, including LLC 0xAAAA03, OUI 0x00000C, which can be seen on a LAN analyzer trace
So a frame should look like
Preamble|01-00-0c-cc-cc-cc|SA|0xAAAA03|0x00000C|0x2003| VTP payload
see best practices for IOS based switches
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#cg1
Propagation of new VTP information takes some time (minutes) in the network and this should demonstrate that messages are processed and not forwarded immediately.
>> about trunking header from the same document
CDP, VTP, and PAgP updates are always forwarded on trunks with a VLAN 1 tag. This is the case even if VLAN 1 has been cleared from the trunks and is not the native VLAN. If you clear VLAN 1 for user data, the action has no impact on control plane traffic that is still sent with the use of VLAN 1.
Edit:
also this one about VTP version 3,2,1
http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml
Well, documents speak of forwarding of VTP messages, but in my experience the behaviour is more similar to RIP then to OSPF flooding just to make an example.
Hope to help
Giuseppe
12-28-2010 02:41 PM
Hello Giuseppe and thanks for your answer.
You told me about these documents some time ago but the argument was not so clear.
Do you know if SA field of the frame you have described is always the SA of the first sending switch?
I think that if the SA of the first sending switch appears only when messages are received by adjacent switches, then
we can conclude that we have not transparent bridging, even if I do not care about the time elapsed for the propagation.
Thanks a lot for the information about time propagation of the message.
Do you think that the document refers to transparent bridging when it uses the term "forward"?
Why do you say "in my experience"? For me transparent bridging is one and only one technique and we should
be sure when a protocol implements it. May be the document says what you think but use a not very clear term.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide