sstringham
asked on
Switch Loop preventing DOS
I have a bunch of 3560 POE switches in my network. The individual ports are configured with voice vlans and data vlans. We had a user plug a cheap microswitch (netgear, linksys, etc.) into the back of the phone, and then their PC, printer, etc. into that. The phone is connected to the switch.
They had a loose cable that was plugged into something else earlier and thought that needed to be plugged in. This created a switching loop in the microswitch. Well, it brought that whole LAN segment down due to the broadcast/traffic storm loop.
What can I do to prevent this in the future. As the microswitch is not participating in STP, and neither is the phone?
interface FastEthernet0/5
switchport access vlan XX
switchport mode access
switchport voice vlan YY
priority-queue out
mls qos trust dscp
spanning-tree portfast
They had a loose cable that was plugged into something else earlier and thought that needed to be plugged in. This created a switching loop in the microswitch. Well, it brought that whole LAN segment down due to the broadcast/traffic storm loop.
What can I do to prevent this in the future. As the microswitch is not participating in STP, and neither is the phone?
interface FastEthernet0/5
switchport access vlan XX
switchport mode access
switchport voice vlan YY
priority-queue out
mls qos trust dscp
spanning-tree portfast
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can also setup port security to only allow 2 mac-addresses (the phone and 1 pc)
Agreed.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
oh only the link to IOS 12.1 and before seems to work?? however if you find your switch manual it will have the updated commands and knowing IOS they will be almost identical to the ones above. (using a few ?'s you should be able to get it sorted)
the command from a switch is
#int f1/0/3
#storm-control broadcast [number of packets that you want the limit to be]
#storm-control action shutdown
you can also use the same command to limit unicast and multicast. (good for detecting loops )
all you need to do is look to see waht your background level of broadcasts are. then times this by 2 or 3 to insure you have anice buffer and you should be fine.
A true broadcast storm will incress packet levels massivly.
#int f1/0/3
#storm-control broadcast [number of packets that you want the limit to be]
#storm-control action shutdown
you can also use the same command to limit unicast and multicast. (good for detecting loops )
all you need to do is look to see waht your background level of broadcasts are. then times this by 2 or 3 to insure you have anice buffer and you should be fine.
A true broadcast storm will incress packet levels massivly.
switches at desktop sometimes neccessary evil. Good to control installations so BPDU guard good way to make sure no one does it without ones control
ASKER
I then recreated the scenario on my lab switch (cisco 3560 <-> Phone <-> microswitch). I then put a cable loop into the microswitch. It drove the switch nuts, and the port did not shut down. It bounced a few times though.
I then implemented the bpduguard. Then, reintroduced the loop. The port was shut down within 2 seconds in an err-disable state. Perfect.
I implemented the BPDUGuard as a default on my floor switches. So:
Conf t
spanning-tree portfast bpduguard default
end
wr mem
I tried the problem in production, and again, a disabled port.
Thanks folks for the recommendation.