IP Phone brought down 3560 Switch

Answered Question
May 25th, 2010

Hello,

I recently had a situation whereby someone plugged 2 patch cables from the same stack into the 2 ports of a 7911 phone, thus bringing down the stack.


Ports affected were Fa0/11 anf Fa0/13. Both went error dsiabled (as expected), but when one of the ports was re-enabled it brought the stack down. Portfast and BPDU guard were both enabled (see config below).

We're about to start a Rollout of 3500 IP phones and I can see this happening again (due to user error). My query is, is there any other config changes/commands we can use to prevent such a catastrophic event happening again due to a cabling error.


Fa0/11

!
interface FastEthernet0/11
switchport access vlan 20
switchport mode access
switchport voice vlan 60
switchport port-security maximum 3
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
switchport port-security aging static
srr-queue bandwidth share 15 20 20 45
priority-queue out
mls qos trust dscp
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input User-Edge-Policy

interface FastEthernet0/13
switchport access vlan 20
switchport mode access
switchport voice vlan 60
switchport port-security maximum 3
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
switchport port-security aging static
srr-queue bandwidth share 15 20 20 45
priority-queue out
mls qos trust dscp
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input User-Edge-Policy
!

I have this problem too.
0 votes
Correct Answer by jkillion about 6 years 8 months ago

Hey Patrick -

With portfast enabled, a port goes directly to forwarding mode and bypasses the initial STP steps.  When go directly to fowarding *and* create a physical loop, you create an processor issue.  This is due to L2 frames having no TTL field, thus continuing to loop infinitum.  To stop the packets from looping, one of the following must happen...

1.  Utilize STP to block one of the redundant ports.

2.  Unplug one of the cables.

3.  Wait for the sun to nova.

I would go with options one or two....

From a proactive approach, you do have BPDU guard enabled which is a great start.  The mistake you made was not heeding the BPDU condition.  If a port goes err-disabled, you should check to ensure a physical loop has not been created prior to re-enabling the port.

Your other option is to turn portfast off on the port, thereby allowing STP to do take care of blocking any secondary cable plugged in by accident.

HTH

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
jkillion Tue, 05/25/2010 - 08:40

Hey Patrick -

With portfast enabled, a port goes directly to forwarding mode and bypasses the initial STP steps.  When go directly to fowarding *and* create a physical loop, you create an processor issue.  This is due to L2 frames having no TTL field, thus continuing to loop infinitum.  To stop the packets from looping, one of the following must happen...

1.  Utilize STP to block one of the redundant ports.

2.  Unplug one of the cables.

3.  Wait for the sun to nova.

I would go with options one or two....

From a proactive approach, you do have BPDU guard enabled which is a great start.  The mistake you made was not heeding the BPDU condition.  If a port goes err-disabled, you should check to ensure a physical loop has not been created prior to re-enabling the port.

Your other option is to turn portfast off on the port, thereby allowing STP to do take care of blocking any secondary cable plugged in by accident.

HTH

Leo Laohoo Fri, 05/28/2010 - 18:38

I can see you have "spanning-tree portfast" and "spanning-tree bpduguard enable" but do you have the global command to re-enable a disabled port?  If you have, then take this off.

Actions

This Discussion