Trunking not working on cisco switch

[spidey07]

This is really weird. Cookie if you can figure it out. There are 3 switches involved. A with bridge ID A, B with bridge ID B, C with bridge ID C. Bridge A has a priority of 200 and should be the root.

They are connected like so.

B----C
|
|
A

The interconnects are trunks. A-B is trunk mode desirable on both ends, as is B-C. Siwtch A is running native IOS, B and C are hybrid/CatOS. The B-C trunk comes up fine and all vlans are active and in spanning-tree forwarding state. Once the trunk between A and B is brought up...

The message on switch B is "new root for VLAN X, root mac is bridge C". That's unusual, should be switch A. This message is constantly repeated every two seconds (hello time) and all vlans on this A-B trunk do not function and have no layer2 connectivity.

 

[jlazzaro]

DTP signaling issue between IOS and CatOS? Have you tried tweaking the trunk configurations for A-B? On / On, On / Nonegotiate, Nonegotiate / Nonegotiate, etc...

What do you get on B when you disable B-C then bring up A-B?

 

[spidey07]

You don't get off that easy.

Figure out what's wrong with it. The only method allowed is desirable on both ends.

 

[p0lar]

Originally posted by: spidey07
You don't get off that easy.

Figure out what's wrong with it.

ha! I'm mobile this week or I'd emulate at home to see if I can reproduce.

Good luck with the cookie.

 

[jlazzaro]

stab 2:

since you are running only one instance of spanning tree, the cisco gods determined a network on the trunk shouldnt use this A-B link, therefore it has no option but to disable it completely. Enter PVST?

 

[spidey07]

PVST+ is used on all switches.

It's so easy you'll smack yourself.

 

[nightowl]

I am going to say there is a VTP domain miss-match and a possible native vlan miss-match as well.

 

[jlazzaro]

.........(o)(o)
....w" ¯¯¯¯¯ "w
..W -=====- W
...."w _____ w"
.w""""""""""""""""w
W____________W : Me want cookie

 

[nightowl]

LOL at the Cookie Monster.... the text drawing is pretty good too!

 

[spidey07]

Originally posted by: nightowl
I am going to say there is a VTP domain miss-match and a possible native vlan miss-match as well.

You get cookie. Sorry jlazzaro, you were on the right track, but DTP was doing exactly what it should.

I'm so used to things being in transparent mode that I completely forgot about a vtp domain mismatch. There is next to nothing on the IOS side to see this without debugging.

How WOULD you diagnose this with IOS? Lots of versions don't give you a error/log message. What's even weirder is what started happening with spanning-tree (switch B), this was on the native VLAN. Almost like it was receiving and processing BPDUs but there was a logical break somewhere at layer2. Getting superior BPDUs from the trunk port, but still calling the B-C link the root port.

 

[Cooky]

VTP can indeed be the culprit that you'd sometimes miss because it's not in the running-config.

I've had to troubleshoot, where a new switch was installed w/ the correct vtp domain.
The trunk came up, but the new switch just wouldn't learn the vlan's from the vtp server.
Turns out a vtp password was set.
Had to find a switch on the network that supports the command to show you what the password is.

 

[nightowl]

What tipped me off was that none of the VLANs made it through the STP process on the trunk link. However, the new root is what threw me off still and made the VTP answer somewhat of a guess.

Spidey, I am curious why you are using DTP and not statically defining trunks. I have never done it in the past (other than for a Cisco cert) nor would I recommend anyone use it for critical switch links.

Also, the VTP domain is in the running config on all IOS based switches now that the vlan database command has be depricated.

 

[Cooky]

Also, the VTP domain is in the running config on all IOS based switches now that the vlan database command has be depricated.

It's true that the vlan database command is being depricated, but I still don't see vtp domain in running-config of any of our IOS based switches.

What version of code do you see it in?

Also, I've seen some Cisco docs that actually recommend using DTP / desirable mode for trunk ports. (I don't have hard evidence since I can't remember which doc)

I didn't have a problem w/ it until once the trunk port wouldn't come up between an IOS and a CatOS switch.
We've been hard coding trunk ports ever since.

 

[nightowl]

I know that DTP is not recommended to be used for HA links because it can add time for negiotiation which slows the failover process. Also, in earlier versions of Catalyst IOS the vtp configuration was not in the running-config. It would disappear after a reboot,, iirc. As for the version of code, I checked on 12.2(25)SEE2 (3550) and it was there after a reboot.

I am looking to see if I can find when the commands were added to be shown in the config files.

 

[jlazzaro]

Originally posted by: Cooky
but I still don't see vtp domain in running-config of any of our IOS based switches.

i believe vtp domain name / mode will ONLY show up if you are in transparent mode. 3750 running 12.2(25)SEB2:

Switch(config)#vtp mode server
Setting device to VTP SERVER mode.
Switch(config)#^Z
Switch#sho run | i vtp
Switch#

Switch(config)#vtp mode client
Setting device to VTP CLIENT mode.
Switch(config)#^Z
Switch#sho run | i vtp
Switch#

Switch(config)#vtp mode trans
Setting device to VTP TRANSPARENT mode.
Switch(config)#^Z
Switch#sho run | i vtp
vtp domain TEST
vtp mode transparent
Switch#

 

[nightowl]

That looks to be correct. I am seeing the same thing with SEE2.

 

[spidey07]

Nightowl,

Every data center design expert I've spoken with say to use desirable for trunking. I used to force everything as well but these eggheads pointed out all sorts of reasons why you should used desirable - I think it was to avoid any spanning-tree misconfigurations or calculations and vlan hopping. As far as failover the trunks should already be established.

There's also the layer2 trunk failover feature that is used in data center high availablity designs that allow for a redundant loopfree topology.