Spanning tree loop question

[Patrick McHenry]

Recently I've been creating redundancy to switches that our servers connect  to. I've been creating a redundant link by connecting them to our secondary root switch. One 6509 is the primary for all VLANs. That will change soon, hopefully.

I've been connecting the redundant links slowing over the past few weeks without any problems. When I connected a redundant link of one of the switches the link came up so I thought it was good. Apparently the other side never came up.  The output on the server switch said something link BKN* and LOOP_INC. Other switches ports that are blocking say Alternate.

First, how is this possible? For one side to be connected and the other not connected.

Did I create a loop or blackhole?

And is this something UDLD aggressive mode would have fixed?

Thanks, Pat.

[cadet alain]

Hi,

post a diagram of topology as well as sh spann  for the vlan you are interested in on all your switches

Regards.

Alain.

[Patrick McHenry]

Alain,

I've shut the port on the server switch as I wanted to stop any problems that it might have created. So, I don't have the any span output for that switch that would be helpful, only what I posted(BKN* and LOOP_INC.) I attached a diagram. Hope that helps.

Thank you, Pat.

[cadet alain]

BKN* and LOOP_INC

it is due to loop guard feature.

How many Server switch have you got? 3  or only one?

I think you should also link your  primary root  and secondary root

Regards.

Alain.

[Patrick McHenry]

We do have a 10gig link between the Distribution switches. Sorry, I should have drawn that. We have about 20 server switches.

Are you saying that the switch detected a loop? What are some reasons that it didn't just settle at Alternate like the others?

Thanks, Pat.

[cadet alain]

Hi,

Alternate means it is a blocking port but which can become forwarding immediately if there is a topology change so it has nothing to do with loop detection, this normal behaviour.

Are you saying that the switch detected a loop

exactly because of the loop guard feature which was configured  on the switch with the spanning-tree guard loop command.

Can you post running of the switch where this message was issued.

Regards.

Alain.

[Patrick McHenry]

Alain,

I've attached the running config of the switch. I'm really just wondering why it gave me the BKN* and LOOP_INC instead of making the port an alternate like the rest of the switches.

Just to pick your brain....I've been thinking about configuring UDLD on all my switches. This is recommended practice, correct?

Thanks, Pat.

[cadet alain]

hi,

spanning-tree loopguard default was indeed in the config.

On which port was it happening?

 I'm really just wondering why it gave me the BKN* and LOOP_INC instead 
of making the port an alternate like the rest of the switches.

As I told above because of the feature it detected a loop and then disabled the port, now we must discover why.

Regards.

Alain.

[Patrick McHenry]

Like I alluded to in my original post, could this have something to do with one of the sides of the link not receiving or transmitting? I do not have UDLD configured so could one of the links have thought that the other was down and tried to forward anyway?

Thanks, Pat

[cadet alain]

Hi,

udld and loopguard are somewhat similar features.

take a look here: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml#loop_guard_vs_uld

Regards.

Alain.

[Patrick McHenry]

Clears things up a bit. Thanks for the doc and all the responses. It appears that loopguard blocked the link from a software failure or a link failure of somekind. I'll check the fibers and try some new gbics.

Would you recommend configuring UDLD aggressive on all trunk ports?

Thanks again, Pat.