Catching the source of a STP Loop

[dan_track]

Hi

The other day I found an Avaya phone plugged into the switch twice, so causing a loop in the network. I got some suggestions from people here as to how to go about tracking this offending device down. The advice really helped and saved me a lot of grief.

The key point for me was noticing that when I ran "show spanning-tree detail" I saw a fastethernet port incorrectly receiving bpdu's. However when I reran the command a few minutes later the same port showed no bpdu's received. As far as a I know a normal access port should not receive bpdu's only a trunk connected to another switch. On this occassion I got lucky and I saw the bpdu but I could equally have seen the output when it stated no bpdu's received. My questions are:

1) What other way could I have gone to find the same information? If there is another way. Or is it just a case of keep re-running the "show spann detail" command until I get lucky and see a port receive a bpdu.

2) Why does the counter relating to number of bpdu's received in the "show spann de" command get reset to "0"?

Thanks

Dan

[Kevin Dorrell · Accepted solution]

I am guessing that one or both of the ports became errdisabled. Maybe one or both of the ports had bpduguard. In that case, one port will errdisable itself, while the other ... well the other will stay up because it is on the other side of the telephone's internal switch. It may be this errdisabling that clears the counter.

It is possible to configure your switch so that it recovers from the errdsable state after a certain time. Is that the case with your switch?

show errdisable recovery will tell you if there are any errdisabled ports waiting to recover. A show int status will show you generally if you have any ports currently errdisabled.

I would put bpduguard on all ports that could connect to these phones. The phones with internal switches are just asking to be plugged in twice. If the installer does not do it by accident, the user will sooner or later. These phones generally do not run Spanning-Tree, and do not generate BPDUs.

BTW, an access port can still receive BPDUs if it happens to be connected to another switch running Spanning-Tree. It does not necessarily have to be a trunk.

Kevin Dorrell

Luxembourg

[dan_track]

Congratulations on getting your CCIE!!

I'm still studying for my first CCNP exam... BSCI.

Regarding the switch configuration. Yes I have errdisable set to recover any ports after 3 minutes. In hidsight I think that was a mistake from my part. Now I'm going to permanently disable them if they get shutdown by the switch, and then I'll investigate why they got shutdown.

For all you people out there NEVER underestimate a user :), they bring havoc to your network!!!

Thanks for the insight

Dan

[lamav]

Dan:

With regard to question 1...

Whether an access port should receive a BPDU or not depends on whether it is cofigured for PortFast. In a valid configuration, PortFast-enabled ports do not receive BPDUs. Reception of a BPDU by a PortFast-enabled port signals an invalid configuration. This is where BPGU Guard can help. A port configured for BPDU Guard will shut down upon receipt of a BPDU, even if PortFast is not configured on that port.

Now, as an aside, according to Cisco, STP still runs on a PortFast enabled interface and will revert to a blocking state if it has to. I'm not 100% sure how to interpret that statement. Perhaps it means that a PortFast enabled port will still send BPDUs, but for sure, it should not receive BPDUs.

The latter part makes perfect sense. If you configure a port for PortFast, it means you expect to plug a device into it that does not run spanning-tree, like a PC, laptop, server, or other end-device. If some knucklehead plugs a BPDU-running switch into a PortFast eneabled port, that port will receive BPDUs and then shut itself down to prevent a loop.

I don't have an answer for the second question. All I can think of is that the statistics may be taken over a set period of time and resets to zero once the new period begins.

HTH

Victor

[lamav]

Kevin:

CCIE??

Just noticed that.

Congrats, man!

Victor

[Kevin Dorrell]

Thank you Victor! 9th May, R&S, #20765. I have difficulty coming to terms with it myself!

Kevin Dorrell

Luxembourg

[lamav]

LOL :-)

Im very happy for you, buddy. Enjoy the feeling!

Victor

[Giuseppe Larosa]

Hello Kevin,

congratulations !

best regards

Giuseppe

[Kevin Dorrell]

Grazie tanto Giuseppe. Non avrei potuto farlo senza tutti miei colleghi qui su NetPro. Mi rendo conto comunque che c'ho ancora tanto da imparare.

Ciao,

Kevin