Please help on spanning tree loop prevention

Unanswered Question

Hi All,

I would like to gather feedbacks on best hardening or prevention techniques available on cisco equipments to prevent spanning tree loop or broadcast-storm.

I have the below already configured:

All FA ports are configured with portfast and BPDU guard.

**QN: What other settings need to be confgured?

I have this query in mind, and need some expert to advise on this.

Qn: BPDU guard is capable of err-disable a port when receiving BPDU packets/request, If the device connecting to this port is non-cisco equipment, will it work? or it will only NOT WORK on devices not running Spanning Tree tecniques (be it cisco or non- cisco).

Qn: for broadcast storm prevention, is there a need to configure the storm-control action? will it work if there isn't an action configured but a threshold level is configured?

Will the above settings protect against such malicious acts:

1) User plug in a rogue switch directly to the port

2) user plug in a hub to the port , then a rogue switch to the hub

3) user plug in a cable on point A and plug the other end to point B on the same switch

4) user with ip-phone has their PC-port plug to another LAN point (be it same switch/ different switch)

Thanks a lot

Charles

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Tue, 03/31/2009 - 02:02

Hello Charles,

BPDU guard is effective in detecting any type of STP BPDU including legacy 802.1D and we see this in action almost every day.

About your questions:

Victor has provided two good links.

1) User plug in a rogue switch directly to the port

>> effective as explained above

2) user plug in a hub to the port , then a rogue switch to the hub

>> effective because rogue switch BPDUs still reach the switch port

3) user plug in a cable on point A and plug the other end to point B on the same switch

>> effective, this is the point where bpdu guard provides real protection and bpdu filter causes problems

4) user with ip-phone has their PC-port plug to another LAN point (be it same switch/ different switch)

this requires some investigation the point is that if the ipphone propagates BPDU from primary switch port to pc port the event is detected.

To verify this is enough to have a PC on the PC port to use a sniffer sw and to see if BPDUs are seen on the PC port.

Edit:

I had to copy your questions and then I've modified this post

Hope to help

Giuseppe

Hi,

Thanks for your clear response.

after much research, my findings are the same as yours for point 1-3. for point 4, what i can do to best prevent will be to disable port-fast on the switchports connecting to IP-phones, this forces BPDU to be exchange/negotiate with the end-devices causing it to goes into block state IN CASE the ip-phone is not capable of sending BPDU packets (ie, forwarding state forever)

I have additonal 2 more points to be discuss.

5)rogue switch which is not running spanning tree technique

6)preventing broadcast storm

For point 6, the best will be storm-control command. but i need advise on the level to be set, 50%?

Giuseppe Larosa Tue, 03/31/2009 - 02:47

Hello Charles,

first of all portfast doesn't disable STP BPDUs sending or receiving by itself unless you use bpdu filter that I strongly don't suggest.

bdpu guard doesn't stop the sending of BPDUs out the port

5) that rogue switch not speaking STP would be an hub: you cannot detect this with BPDU guard you should think to add port security for this case: if multiple MAC addresses are seen on the port there is an hub.

port security allows to react to this event.

6) we use storm-control at 1% on GE ports with no problem, you could think to use 10% on FE ports.

the amount of legitimate broadcast traffic is proportional to subnet size we have /24 client vlans.

Actually, ARP uses broadcast in an healthy network. Then there is windows networking: we use WINS servers that minimize broadcast traffic originated by PC networking.

So depending on subnet size, window networking model you can find the right value for storm-control.

We use also loop guard on uplinks together with storm control

Hope to help

Giuseppe

Hello Giuseppe,

The reason i suggest disabling port-fast is because there is a recent issue in my environment whereby a user plug in both ports of their IP-Phone (avaya) to the the switchports on their desk which result in a loop.

As i already had bpdu guard and portfast configured, the best i can think of is to disable portfast unless there is another better idea. May i know if you know of another technique?

Will consider on the port-security portion.

for storm-control level, you mentioned it should be proportional to subnet size, is there any best practice table which i can refer to?

Just to clarify, do we configure loop guard or root guard on the fibre uplink to the core switches? of course, i assume the same config (be it loop/root) should be configure vice-versa (on the core switch interface as well as access switch interface)

Regards,

Charles

Giuseppe Larosa Tue, 03/31/2009 - 13:07

Hello Charles,

1) portfast

you meant to disable STP portfast this can be seen as a security measure that helps in avoiding a loop by using the STP timers for listening and learning states so that there is time to detect the bpdus.

This can have some side effects you may need to enable portfast on demand when a pc needs to boot on lan to be rebuilt.

Port-security provides protection from hubs.

I haven't a table for storm control however we use 1% on GE and also on FE links with no problem. As I wrote before also some aspects of windows networking can influence the right choice.

I think you can use the same values if you use WINS (or if you are not using windows based PCs)

loop guard has to be configured on both sides of uplinks and we have it also on direct link between distribution switches.

The reason is probably consistency in behaviour.

Hope to help

Giuseppe

Actions

This Discussion