04-02-2008 08:49 AM - edited 03-05-2019 10:08 PM
Hi,
I had a broadcast storm that killed some switches on my lan. The problem was a loop.
The setup was : smc 5ports switch with a loop----3 com dual-speed hub ----catalyst 2950.
The swithport setup was :
interface FastEthernet0/1
switchport access vlan xxx
switchport mode access
spanning-tree portfast
The global commands are:
spanning-tree mode pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
It's not right to use access port with a hub, but the spanning-tree portfast bpduguard default handles if a loop occurs and a non-cisco hub or switch send BPDU packets.
The problem is that the 2950 didn't drop the port err-disabled and the storm occurs, the CPU of the switches 99% usage.
Did you have issues like that, and how can I prevent this?
Thanks
04-02-2008 09:19 AM
It may be that you did not err-disable because your hub does not transmit bpdus.
You may want to look into storm control. i do not know what type of switch you have but you can do individual ports or a range of ports.
Just config a port
storm-control ?
04-02-2008 09:42 AM
The problem with the global configuration "spanning-tree portfast bpduguard default" is that it is only applied to port that are "operationally" portfast (edge). Basically, a port configured for portfast starts as an edge port. But as soon as it receives a BPDU, it is not considered an edge port any more. So if the global bpduguard configuration was entered after the port has received a BPDU, then BPDUguard will not be applied to this port. I don't know if this was the case for you, but that could be a reason why the port did not go err-disable. If the smc bridge is looping frames, the 2950 is very likely to receive one of its own BPDU that will trigger bpduguard. But it might take some time if the smc does not privilege BPDUs (it might be possible that the loop is preventing this bridge from accepting and relaying a single BPDU).
So eventually, I don't really know what to tell you;-) Maybe you should try configuring BPDUguard directly on the interface. Else, can you reproduce this behavior?
Thanks and regards,
Francois
04-02-2008 10:51 AM
I posted this issue because I can't reproduce this behavior. I enter the command spanning-tree portfast bpduguard default in every access switches. It was on before the issue. I have devices in my lab with the same setup and, everytime I induce a loop in my smc, the switch put the port in err-disabled. The Cisco switch receive BPDU packets then shuts the port.
If spanning-tree portfast command is not entered on the port, the loop burns the cpu of the Cisco to 100%, but on my setup the command was on. In that case I must put spanning-tree bpduguard enable command on port to avoid this.
My switchport macro are like that:
Hub
macro name hub_vlanxxx
description hub xxx
no cdp enable
switchport access vlan xxx
switchport mode access
# Enable port security limiting port to a single
# MAC address -- that of desktop
switchport port-security
switchport port-security maximum 24
# Ensure port-security age is greater than one minute
# and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
# Configure port as an edge network port
spanning-tree bpduguard enable
# Remark all inbound data packets with COS=0 & DSCP =0
mls qos cos override
no shut
@
PC
macro name pc_vlanxxx
description pc vlan xxx
switchport host
no cdp enable
switchport access vlan xxx
# Enable port security limiting port to a single
# MAC address -- that of desktop
switchport port-security
switchport port-security maximum 1
# Ensure port-security age is greater than one minute
# and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
# Remark all inbound data packets with COS=0 & DSCP =0
mls qos cos override
no shut
@
Any ideas?
Thanks
J.S.
04-02-2008 11:04 AM
J.S.,
The only thing I can think of is that somehow the port was not running bpduguard because it had received a bpdu before you configured the global command. This configuration stuff might have happened months before the problem occurred.
That's of course a just a guess;-)
F.
04-03-2008 05:57 AM
Thanks for the clues, sadly it doesn't apply to my issue, I rebooted that switch not a long time before my trouble. The global bdpugard command was entered before.
I don't figure how it happened now, maybe I should search elsewhere.
J.S.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: