Understanding peculiar VTP behavior

[sslproxy]

I'm using GNS3 with VIRL images (vios_l2-adventerprisek9-m.vmdk.SSA.152-4.0.55.E). I'm trying to understand the behavior I'm seeing. It almost seems like it's a fluke with the emulation.

I've posted over in /r/ccnp (found here) and I've gotten a bit of clarity in the process from responses but still not 100% clear on the behavior.

The following is my topology...

All links between switches are set as static trunks. RSTP is deployed and DSW1 is the root. VTP settings on all devices are default, seen as such...

CSW1#sh vtp status
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 :
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 0c46.12b5.2600
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)

Feature VLAN:
--------------
VTP Operating Mode                : Server
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 5
Configuration Revision            : 0
MD5 digest                        : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
                                    0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC

What I've noticed is that I can jump onto ASW1 and change the VTP domain name and as a result, that will update the domain on the directly connected devices (DSW1 & DSW2), but only those devices (along with reporting "MD5 digest checksum mismatch" on those devices in the process). In my previous linked post, I had mentioned that this was observed when switching ASW1 to a VTP client and the changing the domain but I can confirm this same behavior is occurs when ASW1 is both a client and a server.

One of the responses I received prior explained the behavior as follows....

"The expected behavior is this: when you have two connected switches in VTP server mode and a null domain, and you set the domain name on one of them, it will propagate to the other. This is why you saw the change occur in DSW1 and DSW2, as they're both connected to ASW1 via trunks.

The VTP update frames use the CDP destination MAC (01-00-00-cc-cc-cc) which doesn't flood."

First off, I previously mentioned this behavior is seen when ASW1 is a client or server. Still this begins to explain the issue. However it leaves me questioning why the behavior isn't the same for all devices? When thinking about the flow...

Update domain on ASW1 -> VTP advertisement frame is sent out to directly connected neighbors

If the above is true, I understand the VTP update frame isn't a flood. However, why does that flow not start over again on the DSW devices where they create their own advertisements after being updated?

The DSW1 device does not propagate it's own advertisement after the update. I took a packet capture to verify this. (The following confirms the active links that I was capturing on).

ASW1#sh spanning-tree | sec Gi0/0
Gi0/0               Root FWD 4         128.1    Shr

CSW1#sh spanning-tree | sec Gi1/2
Gi1/2               Root FWD 4         128.7    Shr

Another thing that throws me off  is the revision number stays 0 in this advertisement. I was under the assumption that devices should only update when the revision number increases. Is this not true with a domain update?

Also, one final question. For the ASW1/DSW2 link, both the ports on DSW2 are blocking. DSW2 still receives and accepts the VTP advertisements over these ports. I know STP blocking is technically not fully blocking and more referencing blocking of actual data. Is this expected behavior as well?

UPDATE: Okay so it appears what happens is that when I change the domain on ASW1, a VTP advertisement is sent out immediately and DSW1/2 take it. However the same behavior is slightly different on DSW1/2 as it doesn't send out a VTP update to their neighbors until the 300 second default timer is met.

I've also noticed that if I change the VTP password first on ASW1 before any other VTP changes are made, all the other devices do eventually end up taking the new domain. They don't get the updated password and as a result VLANs are not propagated. This still seems wonky, is this to be expected?

[Giuseppe Larosa]

Hello sslproxy,

you are performing tests in a lab scenario that does not represent real world usage of VTP.

When you use VTP in real world you configure:

A VTP domain name

the VTP password to protect the communication on all devices.

You need at least two VTP servers. All other devices can be configured as client.

Coming to your specific questions:

VTP allows a switch with VTP domain name null to accept the domain name received in a VTP update.

This is intended to allow easy plug and play insertion of a new switch in an existing VTP domain.

>> Another thing that throws me off is the revision number stays 0 in this advertisement. I was under the assumption that devices should only update when the revision number increases. Is this not true with a domain update?

A change in VTP domain name makes the revision number to be set to zero so I would say this is expected. The revision number will be incremented if new Vlans are created, one vlan is deleted or you change a Vlan name.

Actually, before  connecting a switch to a live network setting the switch to a different VTP domain name and the changing back the VTP domain name or setting VTP mode to transparent is a way to ensure the new switch will not have a revision number higher then current revision number in VTP domain live network and actually the VTP revision number is made equal to zero in case of change of VTP domain name.

>> I've also noticed that if I change the VTP password first on ASW1 before any other VTP changes are made, all the other devices do eventually end up taking the new domain. They don't get the updated password and as a result VLANs are not propagated. This still seems wonky, is this to be expected?

The VTP password needs to be configured manually and cannot be learned by VTP advertisements otherwise this security feature would be easily defeated and would be useless.

>> Okay so it appears what happens is that when I change the domain on ASW1, a VTP advertisement is sent out immediately and DSW1/2 take it. However the same behavior is slightly different on DSW1/2 as it doesn't send out a VTP update to their neighbors until the 300 second default timer is met.

This is an interesting note. However, your lab test is really a corner case that does not represent a real world implementation.

As I have noted above when you configure a network usual practice is to configure the VTP domain name, VTP mode and VTP password in all devices that should take part to the VTP domain.

Attempting to build the VTP domain by configuring the VTP domain name in a single device and then waiting to see what happens it is interesting for studies.

So the final result is that after 300 seconds DSW1 and DSW2 send new update with the new VTP domain name inserted in and the neighboring devices will move from null domain to received VTP domain name?

Edit:

>> Also, one final question. For the ASW1/DSW2 link, both the ports on DSW2 are blocking. DSW2 still receives and accepts the VTP advertisements over these ports. I know STP blocking is technically not fully blocking and more referencing blocking of actual data. Is this expected behavior as well?

Yes, STP blocking stops user traffic to be received or sent but does allow L2 signaling protocols including STP to be received or sent so VTP message can travel on ASW1 to DSW2 link even if it is in STP ALT / Block on the ASW1 side.

Hope to help

Giuseppe

[sslproxy]

Hey Giuseppe, thank you so much for taking the time to look into this and answer in detail. To bring your first statement into question....

"you are performing tests in a lab scenario that does not represent real world usage of VTP."

After reading through your response in full, I understand it as all the behavior I'm seeing is actually expected in a real world environment. In summary this is...

• All VTP devices in default server mode/null domain/no password
• A single device domain is updated, and as a result all other devices have their null domain updated
  • Revision number stays 0 as no VLAN changes are made, but devices see an update domain name and change accordingly
  • This is regardless of password set on the initial device the domain is configured on, however this password will need to be manually configured in the devices for VTP to actually work. 

For the last point, I previously understood that the password wouldn't be sync'd as that would defeat the purpose. I was just under the assumption that devices having different passwords to start (ie setting password on initial device, and null password left on all other devices) would prevent any kind of sync from occurring, including the domain name.

I should have notated that this is VTPv1. I'm unsure if this behavior is to be expected in v2/3. I'll have to continue testing.

I believe the only questionable behavior based on your response is the timing of this propagation of domain update. That is, the device it's actually configured on will instantly send out a VTP advertisement. The next L2 hop devices will update instantly in response but will wait for the 300 second timer before they send out their own VTP advertisements, then updating the devices on the following L2 hops.

"So the final result is that after 300 seconds DSW1 and DSW2 send new update with the new VTP domain name inserted in and the neighboring devices will move from null domain to received VTP domain name?"

Yes, that is the exact behavior I have observed and described above.

[Giuseppe Larosa]

Hello sslproxy,

>> This is regardless of password set on the initial device the domain is configured on, however this password will need to be manually configured in the devices for VTP to actually work.

No, this should not happen if the passwords are different or only one device has password set no form of update should happen also the domain name should not be updated. Martin provided some feedback on possible issues with the emulation environment.

Technically the VTP password is not sent on the message but it used to create an MD5 hash (sort of checksum ) of the VTP message contents.

So I would not expect real devices to accept a VTP domain name in case of VTP password mismatch.

>> I believe the only questionable behavior based on your response is the timing of this propagation of domain update. That is, the device it's actually configured on will instantly send out a VTP advertisement. The next L2 hop devices will update instantly in response but will wait for the 300 second timer before they send out their own VTP advertisements, then updating the devices on the following L2 hops.

You should realize that you are abusing of the "plug and play" feature about the VTP domain name learned by devices with VTP domain name null.

In real world nobody would like to wait for 300 seconds for each switch hop to see the VTP domain name propagated to all switches!

VTP version 3 is a totally different protocol with more advanced features and more security and features.

VTP version 1 is really legacy. VTP version 2 has some improvements.

Hope to help

Giuseppe

[sslproxy]

"No, this should not happen if the passwords are different or only one device has password set no form of update should happen also the domain name should not be updated."

Okay, this makes more sense now. I'll chalk that up to emulation errors.

"You should realize that you are abusing of the "plug and play" feature about the VTP domain name learned by devices with VTP domain name null.

In real world nobody would like to wait for 300 seconds for each switch hop to see the VTP domain name propagated to all switches!"

Have no worries, this isn't something I'm trying to use as a legitimate tactic to propagate the domain. I'm studying for the CCNP so I want to make sure I know every single piece of expected behavior as I can for such protocols. So knowing if this is to be expected or not is still pretty critical for me.

Thanks again for the responses!

[Martin L]

I would not trust vios_l2 image based on several bad reports of people who were using it while studying for CCIE Lab ;

 see CLN ccie rs study group https://learningnetwork.cisco.com/groups/ccie-routing-and-switching-study-group

[Martin L]

see https://learningnetwork.cisco.com/thread/133540