Changing VTP domain and loss of connectivity

[switchtower]

I thought this would be very straight forward, but I guess not.

Currently the network I manage consists of 3 main sections with two 6500's for the dist layer, in each section, which in turn, have layer 3 connections to a set of 6500's acting as the core.

I inherited this network, and the person before me allowed layer 2 connections to span into the different sections and the entire building is one large VTP domain.

Because of the number of VLAN's on the network, I need to limit the scope of spanning tree and remove any unused VLAN's from the sections.

I have configured all the trunk ports to 'nonegotiate', to turn of DTP, but when I change the domain on the access layer (2960's), I loose connectivity to the servers behind the access switch, but still have connectivity the management VLAN.

I'm assuming I'm missing some sort of configuration on the 6500, so if anyone can point me in the right direction, that would be great.

[milan.kulik]

Hi,

trunk port 'nonegotiate' does not disable VTP.

So when changing to a new VTP domain name, you are having a different VTP domains on each trink side, so if the access layer switch is configured as VTP client, it loses his VLAN definitions.

I suppose VLAN1 is your management VLAN? That would explain why you keep your management VLAN connectivity.

What's you goal?

Removing VTP completely?

I suppose it should be possible to change the access switch to a VTP server first within the current domain. This should save the VLANs definitions locally.

Changing to VTP transparent then should keep the VLANs configured locally.

Hopefully, you will be able to communicate with VLANs on the other trunk side (VTP server).

You should be able to remove unnecessary VLANs locally from the access switch then.

After all access switches migrated to the transparent mode, you can migrate the core switches, too.

I hope this scenario should work, but I highly recommend testing in a lab first!

Remember "VTP bomb" possibility, playing with VTP client-server changes could increase the VTP revision number and remove all VLANs from your VTP domain if done incorrectly :-((

HTH,

Milan

[switchtower]

I don't lose the VLAN's on the client device, the only thing that changes is the revision number of the new VTP domain.

I have verified this in Cisco documentation and in a test lab. I can reproduce this problem in a lab too.

[milan.kulik]

Hi,

yes, the version number should reset.

But I'd expect losing the VLANs on a client.

Are your sure you see them with sh vlan command? What does the sw int ... switchport command show on the trunk?

Are the VLANs still present on the client after a switch reboot?

I remember I was running different VTP domains on a trunk in the past. But there were VTP servers available in each of them.

Are you running VTP ver. 2?

BR,

Milan

[switchtower]

Only the revision number changes, here is the output of 'show vtp status' from the 2960 in the lab.

Before client VTP change:

Switch#show vtp status

VTP Version : 2

Configuration Revision : 3

Maximum VLANs supported locally : 255

Number of existing VLANs : 85

VTP Operating Mode : Client

VTP Domain Name : b2s1vtp

VTP Pruning Mode : Enabled

VTP V2 Mode : Enabled

VTP Traps Generation : Disabled

After:

Switch#show vtp status

VTP Version : 2

Configuration Revision : 0

Maximum VLANs supported locally : 255

Number of existing VLANs : 85

VTP Operating Mode : Client

VTP Domain Name : changedvtp

VTP Pruning Mode : Enabled

VTP V2 Mode : Enabled

VTP Traps Generation : Disabled

Yes, they are both running VTP Version 2.

Thanks for all your suggestions.

[Giuseppe Larosa]

Hello Nick,

when you change the VTP domain you need before to configure trunk with

switchport trunk encapsulation dot1q

switchport mode trunk

switchport no negotiate

if the mode is desirable/dynamic by detecting the VTP name mismatch the ports are placed in access mode.

this can isolate the vlans that are still present on the switch.

Last week I did some activity and I've noticed the same about VTP : changing the VTP domain name with vtp mode client resets the revision number but doesn't delete the vlans learned by the previous domain as I would expect.

So verify the configuration of trunk ports the mode must be trunk or you can keep only the native vlan or access vlan

Hope to help

Giuseppe

[switchtower]

Giuseppe,

Thanks for you reply, I do appreciate it. I have verified these configurations on both sides.

In my lab, I did notice something odd that I didn't have configured before. We use HSRP between the dist switches and I setup something similar in my lab.

The two dist switches are both VTP servers, and have the aforementioned configurations on the trunk links between them.

When I changed the VTP domain on one of them, HSRP tried to become the active gateway for all VLAN's on both devices. Almost like they were no longer able to communicate with each other even though I have specified no negotiate, switchport mode trunk, and switchport trunk encapsulation dot1q.

There is definitely something I'm missing on the multilayer switches that I just can't figure out.

[glen.grant]

It sounds like the trunks aren't working right . When you force on trunks it will say trunking unconditionally as long as there is a layer 1 link on the port and it may not be working correctly . Verify both sides of the trunk are configured exactly the same . This is the problem with forcing on trunk links it will say trunking no matter what even if the trunk is not working correctly. Verify the native vlans are the same on both sides. Did you put the access switch into transparent mode before changing the domain name ? Maybe you can post a "show interface switchport" for both sides of a trunk link that you are having problems with.

[switchtower]

Thanks Glen for your response.

Below is the output from my lab setup. I have verified the configuration is exactly the same on either side, both in the lab and in my production network.

Name: Gi0/1

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: Off

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk private VLANs: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Name: Fa0/1

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: Off

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

I have a feeling it's something to do with the multilayer switching on the 6500's and on the 3550 in my lab since it's happing on both.

[steve1wking · Accepted solution]

Ensure that you have VTP pruning turned off on the VTP Servers. If pruning is on and you change the VTP domain the client switches will not be able to tell the VTP server which VLANs it is currently using. And because VLAN 1 can NEVER be removed from a trunk, it remains up.

So if you need to change the VTP domain on a section of switches, ensure that you turn off DTP and VTP Pruning.

switchtower and I figured this out today after racking our brains.

[Giuseppe Larosa]

Hello Steve,

very good note

Best Regards

Giuseppe

[milan.kulik]

Hi Steve,

wouldn't changing the access switch from a VTP client to a server have the same effect?

IMHO, without a VTP server avaulable within the new domain you are not able to remove the unnecessary VLANs (which was the initial reason of tthis conversation).

BR,

Milan

[steve1wking]

I would stray away from changing the VTP mode on the access switches as much as possible. All it takes is another engineer that "missed the email" or "forgot" to screw up the entire VLAN database for your whole management domain.

If you put the access switches in server/client/transparent mode, the same issue will occur. The access switches will trunk the VLANs back to the distribution, but the distribution will prune everything except for VLAN 1.

Although, changing the switch from a client to a server will make that switch a server switch of the new VTP domain, it still will not correct the automatic pruning problem. Since still the access switch will not be able to negotiate with the VTP domain on the distribution layer (original servers). This would really be an unnecessary change.

The simplest process is just turning off DTP and VTP automated pruning.

[milan.kulik]

Hi Steve,

you are right.

I remember I was running two different VTP domains connected by a trunk in the past (CatOS switches though) without pruning disabling. But as pruning is disabled by default, I was probably just a lucky guy.

But let me repeat the question:

The initial purpose of the VTP change was to remove the unnecessary VLANs. Is it possible without a VTP server within the new VTP domain?

There is one possibility:

As the original request said:

"need to limit the scope of spanning tree", disabling unnecessary VLANs on trunks manually would deccrease the number of STP instances

(see

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080890613.shtml#topic12)

BR,

Milan

[steve1wking]

Hi Milan,

VTP pruning does not affect STP instances. VTP pruning is to reduce link utilization and switch CPU usage due to unknown unicast frames.

The next step in our endevour to reduce the number of virtual ports on the switch is to manually prune VLANs from the trunks.

VTP automatic pruning does not stop an STP instance from running on the rack switch for that VLAN. The only way to stop that is to manually prune the VLAN from the trunk as well.

Removing the unused VLANs from the VLAN database also reduces the number of virtual ports on a switch because that VLAN is no longer able to trunk across a link.

I am not sure if I understand your initial question about the VTP server within the new VTP domain. But I will try and answer it.

You only need a VTP server within a VTP domain if you want to allow VLAN database modifications to be propagated to all the other switches in that management domain. While you are migrating the VTP domain to the new one, you don't need a server in that management domain until you are done and are ready to start making global modifications.

I hope this helps.