VTP Prunning On A Interface

[Hasan3535]

Dear All,

I do have an issue with VTP.  I want to have 2 VTP Server at the same site but they shouldn't distribute their  Vlan Database.

The topology is;  Edge SW - Distribution - BB (Site 1) - BB (Site 2) - Distribution - Edge SW

Both sites uses very old Edge Switches like 2950 - 2960 etc so VTP V2 is used here. VTP Server is on Site 1 and VTP Prunning is enabled. The problemis  the limit of Creating Vlans. It had reached the limit of creating vlans. When a new vlan is created the old series SW deletes their Vlan database and falls to transparent mode.

So what I want to do is; Separate the Site 1 and Site 2 to different VTP Servers. All are locally connected. So Site 1 Doesn't need to create the vlan to Site 2 and it is vice versa.

VTP v3 can't use here. Is there a solution to isolate the interfaces so they won't share the vlan database with each other? Site 1 and Site 2 are connected with a single Interface.

[M02@rt37 · Accepted solution]

Hello @Hasan3535,

Use different VTP domain names for the two sites. Using different VTP domain you effectively isolate their VLAN databases. The VLAN information will not be shared between the sites, and any changes made to VLANs in one site will not affect the other.

Configure the correct VTP domain name on all switches in each respective site. Also, make sure that the VTP modes on the switches are set to "server" so that you can create and manage VLANs.

It's also a good practice to ensure that the VTP passwords (if set) are different for the two sites to prevent any accidental mixing of VLAN databases.

[Hasan3535]

Thanks for your answer.

This actually more secure way as well. I guess I can't drop the VTP packets on a specific interface. That will be more easy transition for us but if I can't do that I guess there won't be any other solution for that.

[Joseph W. Doherty]

Like M02@rt37, I too would have suggested using different VTP domains.

"Site 1 and Site 2 are connected with a single Interface."

Which would be a trunk, correct?

Possibly, depending on device, you might be able to block VTP packets cross the two sites' link, but, again, if your intent is to not share a VTP database between sites, then you logically now have different VTP domains, so defining them as such, would be the "better" method.  (I assume, what you're trying to avoid is the need to reconfigure all your VTP devices at the one site.[?])

If you're as dependent on VTP as you might be, if not already using an explicit VTP domain and VTP passwords, you might want to do so on/at both sites.  Makes it just a tad more difficult to "accidentally" change your VTP database.

You also mention using VTP pruning, it works, but I once spent a couple of days resolving a network problem due to VTP pruning.

I recall, the issue was, a field engineer added an access port, on a switch, which immediately started to work just fine.  About 5 minutes later, it stopped working.  The issue was caused by (I further recall) something like:

sw1 <trunk> sw2 <trunk> sw3 <trunk> sw4

Where VLAN X was active on sw1, and then an access port, on sw4, was defined to use VLAN X too.  The latter was the first time VLAN X was used on sw4.  Note VTP pruning was active and VLAN X was NOT used on sw2 or sw3.

As noted, initially the newly defined VLAN X port on sw4 worked fine, but after a few minutes, VTP, as it didn't see sw2 using VLAN X, pruned that VLAN from the sw1 <> sw2 trunk.

I don't recall whether this was a "feature" or a "bug" but our immediate "fix" was to disable VTP pruning, and do manual pruning.  (Longer term, we also didn't bother to determine if this was a "feature" or a "bug" as we were upgrading such L2 topologies to L3, where same VLAN access ports never were on multiple devices.)

[Hasan3535]

Thanks for you detailed answer @Joseph W. Doherty 

"Site 1 and Site 2 are connected with a single Interface."

Which would be a trunk, correct?  Yes it is

The reason that I want to block the vtp packets on these trunk interfaces is; there hundreds of switches and I need to configure all of them. I agree the idea but it will be too hassle to the configure all those switches.

Also there is concern that we experienced before;

There was no VTP configuraiton on another site ( not here actually) Let's say another company. They were not using VTP. We configured a new VTP Server with domain and password. All were fine. They didn't get the Vlan database but once we forced " vtp primary force" All the switches in the network wiped out their vlan database and got the new vlans from VTP server. Again there were no VTP Configuration on any switches.

So What I am gonna do is; I will set up a VTP Client which has all the vlans. Then put it in transparent mode and create a New VTP Domain And Password. So this Switch will already have the Vlan Database. Will set this as Server after.

I will Join another switch to VTP Domain as a Client and will Delete a Vlan from Server and see the new Switch delete the vlan from its database or now. And will check some of old switches as well how they act.

That would be my scenario as this is a live Network. I want to be cautious

So do you think the revision number will continue the same when the new domain created as the old VTP or it will renew its number and count from the beginning? So Guess it will be 2 different VTPs.

And when a new switch added to network it won't have the VTP Database because it doesn't know the VTP Domain and Password??? But what we experienced was the opposite actually.

[Joseph W. Doherty · Accepted solution]

BTW, if one or (ideally) both site interconnect switches support VTP "off" mode, they will not accept VTP updates, nor pass them along as VTP "transparent" mode may.  Using this mode might make those switches the block between VTP spreading between sites.  (Likely a 2950 won't support this mode, but a 2960, with a "new enough" IOS version, does, I believe.)

For switches in "off" mode, like "transparent" mode, you would need to update VLAN DB, on the switch.

As to how VTP operates, where VTP gets a big "funky" is when dealing with null domain names, as such a VTP client/server will accept whatever comes to it (assuming it's has a better revision number).  (If switch has a null domain name, it will migrate its domain name to an explicit one, as passed to it, or so I recall.  I also recall, it's a bit tricky to get the VTP domain name back to null status - you might have to erase the local VLAN DB.)

[Hasan3535]

VTP "off" mode Works for me. It would be better this way for us.

I checked they do support off mode. Perfect. And also when it is in off mode, They won't recieve or transit any VTP Verisons right? 

What I found is;

VTP mode off – similar to VTP transparent mode, with a difference that a switch using this mode will not forward received VTP updates. This command is supported only in VTP V3.

So what I understand still the V1 and V2 packets will go in/out.

[Joseph W. Doherty]

Hmm, where did you find that information where "off" mode is only supported in VTPv3?

I'm wondering that feature may have been released with v3, and only be available on a v3 capable device, but I've used in/with v1/v2 mode active.  Such v1/v2 no longer worked as a VTP client or server, but never confirmed they wouldn't relay VTP as any additional downstream switch, if any, also not configured as client or server.  Again, all switches NOT in v3 mode.

[Hasan3535]

Perfect then. That's what I need right now.  Thanks for your helps.

I found the information on a couple of sources. 

I am gonna try it and let you know the results as it seems that it disables globally the VTP.

[Joseph W. Doherty]

Ah, I'm now that I'm back at a PC (prior reply made on my phone), being curious, I wondered about "off" mode being somehow limited to just usage in VTPv3.

In this Cisco TechNote (Understand VTP), there's no mention of VTPv3, but there a description of the "off" mode.

• Off—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.

Other Cisco documentation, expand on this, such as Nexus 7000:

• Off— Behaves similarly to the transparent mode but does not forward any VTP packets. The off mode allows you to monitor VLANs by using the CISCO-VTP-MIB without having to run VTP. On Cisco Nexus 7000 Series devices, because VTP is a conditional service, its MIB is loaded only when the corresponding feature is enabled. The CISCO-VTP-MIB does not follow this convention. It is loaded by the VLAN manager and will always return the correct values whether the VTP process is enabled or disabled.

Or this 3650 documentation, which also describes VTPv3, but, unless I missed it, doesn't tie "off" mode being limited to VTPv3.

VTP off

A switch in VTP off mode functions in the same manner as a VTP transparent switch, except that it does not forward VTP advertisements on trunks.

So, again, certainly possible this feature was introduced concurrent with VTPv3, but when it's supported, it doesn't seem to be limited to VTPv3 - and such has been my experience.

Whatever other sources that you're reading, might either be incorrect and/or poorly worded.

However, in my (above) 3560 reference, features unique to VTPv3 are described, and again, besides "off" mode not being one of them, there is one feature, I found might be nice, for you, if it was (but isn't) supported in v1 or v2:

VTP Version 3

VTP version 3 supports these features that are not supported in version 1 or version 2:

•

Enhanced authentication—You can configure the authentication as hidden or secret. When hidden, the secret key from the password string is saved in the VLAN database file, but it does not appear in plain text in the configuration. Instead, the key associated with the password is saved in hexadecimal format in the running configuration. You must reenter the password if you enter a takeover command in the domain. When you enter the secret keyword, you can directly configure the password secret key.

•

Support for extended range VLAN (VLANs 1006 to 4094) database propagation. VTP versions 1 and 2 propagate only VLANs 1 to 1005. If extended VLANs are configured, you cannot convert from VTP version 3 to version 1 or 2.

---

Note 

VTP pruning still applies only to VLANs 1 to 1005, and VLANs 1002 to 1005 are still reserved and cannot be modified.

---

•

Private VLAN support.

•

Support for any database in a domain. In addition to propagating VTP information, version 3 can propagate Multiple Spanning Tree (MST) protocol database information. A separate instance of the VTP protocol runs for each application that uses VTP.

•

VTP primary server and VTP secondary servers. A VTP primary server updates the database information and sends updates that are honored by all devices in the system. A VTP secondary server can only back up the updated VTP configurations received from the primary server to its NVRAM.

By default, all devices come up as secondary servers. You can enter the vtp primary privileged EXEC command to specify a primary server. Primary server status is only needed for database updates when the administrator issues a takeover message in the domain. You can have a working VTP domain without any primary servers. Primary server status is lost if the device reloads or domain parameters change, even when a password is configured on the switch.

•

The option to turn VTP on or off on a per-trunk (per-port) basis. You can enable or disable VTP per port by entering the [no] vtp interface configuration command. When you disable VTP on trunking ports, all VTP instances for that port are disabled. You cannot set VTP to off for the MST database and on for the VLAN database on the same port.

When you globally set VTP mode to off, it applies to all the trunking ports in the system. However, you can specify on or off on a per-VTP instance basis. For example, you can configure the switch as a VTP server for the VLAN database but with VTP off for the MST database.

However, I do see there is an additional VTPv3 "off" mode feature, unique to it.  This also might account for what your other sources are either confused by, or not properly conveying the "off" mode distinctions between v1/2 vs. v3.