Question regarding VTP (studying for CCNA)

[Sauro]

I came across a figure while reading Wendell Odom's ICND2 book, regarding VTP, which is confusing me.

My understanding/confusion of how VTP works is related to the following assumption:

Any switch receiving a VTP frame, regardless of what VTP state it is in, will forward the VTP message out all trunks.

The figure that confuses me shows three interconnected switches (SW1, SW2, and SW3 - SW1 connects to SW2 and SW3, SW2 connects to SW1 and SW3, SW3 connects to SW1 and SW2 [3 total lines on this LAN]). SW1 and SW3 are in VTP domain Larry while SW2 is in domain larry. SW1 is a VTP Client, SW2 and SW3 are VTP Servers. No VTP passwords are configured.

The link between SW1 and SW3 is not configured as a trunk, therefore no VTP frames will be sent on this link - this link can be considered useless for this example, so we are essentially left with a stack of switches SW1- SW2 -SW3. There exists working trunks from SW1 to SW2 and SW2 to SW3.

Regardless of SW2 having a non-matching VTP domain, shouldn't SW1 still receive VTP updates from SW3 (assuming SW1 has a lower revision number as well)?

The book is stating because the connection between SW1 and SW3 is not trunking, VTP will not work properly.

I hope I have been explicit enough, and look forward to your answers. Thank you in advance.

 

[drebo]

Set all switches to VTP mode transparent and forget that VTP exists. This is how the real world is configured.

Also, I don't recall any VTP questions on the CCNA composite exam.

 

[her209]

The figure that confuses me shows three interconnected switches (SW1, SW2, and SW3 - SW1 connects to SW2 and SW3, SW2 connects to SW1 and SW3, SW3 connects to SW1 and SW2 [3 total lines on this LAN]). SW1 and SW3 are in VTP domain Larry while SW2 is in domain larry. SW1 is a VTP Client, SW2 and SW3 are VTP Servers. No VTP passwords are configured.

Example 1-6, Figure 1-12, right?

The link between SW1 and SW3 is not configured as a trunk, therefore no VTP frames will be sent on this link - this link can be considered useless for this example, so we are essentially left with a stack of switches SW1- SW2 -SW3. There exists working trunks from SW1 to SW2 and SW2 to SW3.

Correct. There is no trunking occuring between SW1 and SW3. Most likely due to a switchport mode misconfiguration, e.g., one side is configured as an access port, not to negotiate, or both ports are configured for dynamic auto trunking and therefore no trunking is negotiated.

Regardless of SW2 having a non-matching VTP domain, shouldn't SW1 still receive VTP updates from SW3 (assuming SW1 has a lower revision number as well)?

The book is stating because the connection between SW1 and SW3 is not trunking, VTP will not work properly.

It won't work because SW2 is operating in VTP server mode and not transparent mode. See my explaination below.

My understanding/confusion of how VTP works is related to the following assumption:

Any switch receiving a VTP frame, regardless of what VTP state it is in, will forward the VTP message out all trunks.

My understanding is that only a switch operating in VTP transparent mode forwards received VTP messages from one trunk out its other trunks. Although, a switch operating in VTP server mode will immediately start sending out VTP messages as soon as a VTP domain name is configured.; hence, if a switch operating in VTP server mode with a null domain name hears that VTP message, it will start using that domain name assuming both are not using VTP passwords, with the switch with the lower revision wiping out its VLAN database and updating it to match the high revision one.

The book doesn't explicitly state whether VTP servers and clients still forward VTP messages that do not match its own VTP domain and password, but it does make mention that switches in VTP transparent mode version 1 do not forward VTP updates that do match its domain name and password.

 

[Railgun]

If a device is in a different VTP domain, it will not exchange info but will forward VTP information from the another domain. But as it's not a trunk, VTP will not function anyway.

Her...no device will automatically change the domain in which it lives regardless of whether it's a server or client. That's a manual piece you need to configure in order to get VTP up and running. If you have two VTP servers or one server and one client, either scenario in a null domain, changing one server to some name will not force the others to also be in that new name.

VTP V2 should be used unless there's a specific reason not to. Servers, clients and transparent devices will all forward VTP updates from whatever domain. If they are in the same domain, they will act accordingly depending on the mode that's configured and its respective revision number.

 

[Emulex]

examcollection.com ?

 

[her209]

If a device is in a different VTP domain, it will not exchange info but will forward VTP information from the another domain. But as it's not a trunk, VTP will not function anyway.

In the example, a trunk was negotiated between SW1 and SW2; another trunk between SW2 and SW3.

Her...no device will automatically change the domain in which it lives regardless of whether it's a server or client. That's a manual piece you need to configure in order to get VTP up and running. If you have two VTP servers or one server and one client, either scenario in a null domain, changing one server to some name will not force the others to also be in that new name.

The book says this is what happens. I just confirmed this behavior on a pair of Cisco 2950's.

VTP V2 should be used unless there's a specific reason not to. Servers, clients and transparent devices will all forward VTP updates from whatever domain. If they are in the same domain, they will act accordingly depending on the mode that's configured and its respective revision number.

Ideally, this would be what happens, but maybe Cisco thought it was considered bad practice have discontiguous VTP domains.

 

[Sauro]

her209 - Thank you for responding, and I think you may have cleared it up for me.

I've gathered, from your answer, that since SW2 is in a separate VTP domain (and is configured as a VTP Server) from SW1 and SW3 that it will send out its own VTP messages - essentially ignoring messages received from other VTP domains. I am not sure if the book explicitly stated whether or not this was the case only making mention that a switch not configured for VTP would still forward frames regardless.

Actually it looks like Railgun may have stated that the frames get forwarded regardless - which is what the book led me to believe, and where my confusion stems...

 

[her209]

Ok, I recreated the scenario with the three Cisco 2950 switches.

But first, a disclaimer: For the book, it mainly focuses on the Cisco 2960 switch which uses a default trunking mode of dynamic auto. That is, when you enter the interface subcommand, switchport mode dynamic auto, the command is taken but does not show up when doing a show running-config under the interface. However, on the Cisco 2950 switch, when doing a switchport mode dynamic desirable, then the command is taken but doesn't show up. Therefore, I have always assumed that the 2950 uses a default trunking mode dynamic desirable.

Cabled physically, SW1-SW2-SW3
No cable connects SW1 and SW3.

When SW2 is configured in VTP server mode, the changes made to SW1's database are not copied to SW3. When SW2 is configured in VTP transparent mode, it works as expected with one CAVEAT. When SW2's domain name is mismatched, it doesn't forward the VTP messages sent from SW1 to SW3 and vice versa. I checked that VTP Version using the show vtp status which was reported as 2. I even issued the vtp version 2 command which changed the VTP V2 Mode from Disabled to Enabled in the show vtp status command.

What happened was I configured the ports to be used as trunks on SW1 and SW3 as switchport mode dynamic auto. On the ports to be used as trunks on SW2, I configured them to switchport mode dynamic desirable. When the VTP domain names match on SW1 and SW2 (blank VTP password), the trunk comes up and shows up when the show int trunk command is issued. But when the domain names do not match, then the trunk fails to come up because trunking is not negotiated as reported after issuing the debug dtp packets. To force the trunk to come up between SW1 and SW2, I have to force the port to become a trunk using the switchport mode trunk command on all ports to be used as trunk ports. After the trunks come up, the VTP messages from SW1 to SW2 is ignored because the domain name is mismatched

 

[Sauro]

That does answer my question then - VTP server mode must only forward frames with its own VTP domain.

Your findings sure are strange though, as far as the trunks coming up. I was to understand that VTP had no bearing on whether or not a trunk would physically come up - regardless of how VTP was configured.

Anycrap - thank you for testing this out. Only 159 more topics to get clear on!