STP pruning one VLAN interface

[jsteckenberg]

Greetings,

I seem to have created a problem that has me pretty stumped, and could use some help determining the cause and solution.

This is a sprawling campus network with about 100 access switches (48 port 2960's) all off a single 6509 (sup720) that handles routing for several VLAN interfaces, with physical fiber interfaces to several remote locations, in some cases they are a few miles away. 

All of the switches are configured with an IP address within the network ID used on this VLAN (it's 10.254.0.0), and with a default gateway of 10.254.1.1, which is assigned to a VLAN interface on the 6509.

The way it looks to me is like STP is pruning this VLAN and only this VLAN--The VLAN is allowed on all trunks and configured on all the switches, if you run "show interfaces trunk" it comes up as allowed on all the trunk ports, but not in the active or forwarding tables.  It's the same on every switch I have looked at, including the root bridge (not the 6509, a 3750 distribution switch in one of the remote locations--this decision was made at some point before I joined up, I don't know why).  There is also no route to that network ID on the 6509, but this is not surprising.

The VLAN that has the problem is used to manage switches, so this prevents me from remotely accessing most of the switches, but does not impact users.

The trouble started when we decided to get a new 6509 to relocate the physical core--at this point I was simply trying to back up the IOS image from the switch.  I configured a port on one of the access switches as an access port on VLAN 254, and gave a valid IP address to the copper interface on one of the supervisor modules.  The device had no other configuration other than default.  As soon as the two physical ports were connected devices stopped communicating over this VLAN.  I quickly shutdown the interfaces on the new switch and the access switch, and then unplugged my cable, but the VLAN did not come back up.

I have tried the usual things that made sense to me, shut/no shut on the VLAN interface on the root bridge and on the access switch I was using, even rebooted the access switch I was using--I had not saved my configuration changes.

At this point the entire network is configured exactly the same way as before the problem occurred, but the VLAN is still pruned.

One thing to note is that prior to my attempt to use this VLAN this way there was not a single access port on it, there are a number of other ways I could have configured things to temporarily get the new switch talking to the rest of the network, but that was what made sense to me at the time.

I feel like I must be missing something obvious here, but nothing is coming to me.  I am considering changing the root bridge or rebooting the current one, but am reluctant to do so without fully understanding the problem.

If anyone can point me in the right direction, maybe suggest some diagnostic steps I can take I will be very appreciative.

Thank you,

Josh

[Reza Sharifi]

Hi Josh,

To better help you, can you provide a sample diagram of how one of the access switches (2960s) connect to the core 6500 and the 3750s?

Also, on your diagram can you indicate what devices are layer-2, what devices are layer-3 and also the root bridge?

HTH

[jsteckenberg]

This is the best diagram I have right now--no one ever made any, but I have started working on it.

You don't see the problem vlan, the way it is set up, all of the physical connections on the diagram are trunks and carry every vlan on the network.  The 3750 (root bridge) is one of the distribution switches you see (VLAN11).  All the vlan's are also carried on the trunks connecting to the access switches (which are not on the diagram).  The "single layer 3 switch" (6509) is the only device serving as a router internally.

Is that enough information?

[paul driver]

Hello

i am wondering if this switch you attached overwrote vtp db

is the 6509 running as the vtp server.

Is this vlan in the vtp database?

try adding the  management vlan again on the vtp server?

sh vlan brief

sh vtp status

Res

Paul

[jsteckenberg]

Thanks Paul

I am going to try this suggestion when I have physical access tomorrow, It would not be a surprise if VTP got me in trouble since it has been simply off or transparent in most of my prior experience (I actually believed it was off here too, but should have checked more carefully), show vtp status indicates that the 6509 is a vtp server, and sh vlan bri does not display the management vlan (although it is in the running config).

I take it that I simply configure "no int vlan 254" and then "int vlan 254" to get it back into the vtp db?

Is there a need to check for other vtp servers first or anything else to prevent doing more harm than good?

Thanks,

Josh

[Reza Sharifi]

You have just a few vlans and really don't need VTP at all.  Just change the mode in every device to vtp transparent, that means you are not running VTP.

HTH

[jsteckenberg]

This is what I want to do (even though I need to double the vlan count soon to support new services), but will all the existing vlan configuration be lost when I change to off/transparent?

[petenixon]

Once you change to transparent mode, the switches will only forward VTP but not permit you to make any changes, so you'll be ok (you wont lose your current vlan config).

Just out of curiosity, have you run the switchport trunk vlan pruning none on your trunk interface?

 

[jsteckenberg]

no, I have never seen that configured anywhere on this network--it prevents vtp from pruning the interface?

[petenixon]

Yep, the command negates any pruning command previously entered and could be used in conjuction with switchport trunk allowed vlan all to ensure you're carrying all the vlans on the trunk.

[paul driver]

Hello

Be careful regards vtp -

My original query was to see if by you attaching a new switch to your network, it inadvertently  caused a vtp synchronisation of the vtp DB and thus overwriting the current active vtp DB resulting in lost of layer2 connectivity.

If your switches  were already in transparent mode then these wouldn't have been affected however any switches running as vtp clients/servers MAY have been providing:

1) the switch you added  had the same vtp credentials
2) this switch had a higher revision number than the current vtp servers and was running as a client or server.

"I take it that I simply configure "no int vlan 254" and then "int vlan 254" to get it back into the vtp db" - No this isn't the case the inter vlan xx command is a layer 3 logical interface and WILL NOT create the L2 equivalent , this needs to be done manually either via

1)
vlanxx
exit

2)applying a access port to the vlan
int xx
switchport access vlan xx

res
Paul
 

[jsteckenberg]

this needs to be done manually either via1)
vlanxx
exit

2)applying a access port to the vlan
int xx
switchport access vlan xx

Of course--that makes more sense--thanks again. 

Yes VTP scares me, I am inclined to lab test this before I change anything.  I visited some of out distribution and access switches this morning, and several are in VTP server mode, fewer are in client mode.  I think it's just default settings on most of the devices.

Is it safe to re-add the vlan at the 6509--will it propagate over the rest of the switches without creating new problems, even if several of them are set as vtp servers?  All the vtp servers an clients seem to have the same revision number, which also matches the new switch (it was in the default server mode, but is off the network now, and I set it to transparent for when it is added again).

This will prove that vtp is running on the network and solve my immediate problem.  After that I need to come up with a plan to get rid of it without creating a substantial amount of downtime.

[paul driver · Accepted solution]

Hello

Is it safe to re-add the vlan at the 6509--will it propagate over the rest of the switches without creating new problems, even if several of them are set as vtp servers? - Yes providing the the vtp server you apply the new vlan too - you are happy for the rest of its vtp datebase to overwrite all the other switches in that vtp domain with is vlan information?

The reason this will occur as at present you have stated all switches have the same revision number so when changes are made to a vtp db of a vtp client/server ( adding or removing vlans) the revision number of that vtp switch will increase thus initiating a synchronisation to all vtp enabled switches in that same vtp domain to accept the new revision.

res

paul

[jsteckenberg]

Thanks everyone, this discussion got me through the process, and I learned quite a bit from it.  I was able to restore my VLAN by re-adding it on the 6509, and now I know how to prevent this issue when introducing new switches in a vtp domain.  I have also confirmed that I can change a client mode switch to transparent mode without loosing the vlans on that switch.  I will gradually change all the switches to transparent, and just manually add vlans in the future.