cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3331
Views
0
Helpful
16
Replies

STP LOOP ISSUE

Hi All

we had a issue where an IPT phone was plugged into one of the switch1( SW1) port  in VLAN 200/Voice

What we found is the 2nd port on the same phone was also plugged into  switch1( SW1)  and this caused issues at the customer network.

Once we shut down the ports the services came back.


However noticeed on the port config voice VLAN have “spanning-tree bpdufilter enable” which basically says don’t send or receive BDPU’s..

Definition-This command prevents ports that are in a Port Fast-operational state from sending or receiving BPDUs. (Enabling BPDU filtering on an interface is the same as disabling spanning tree on it and can result in spanning-tree loops.)  ???? .

I think having BDPU guard on the ports would have helped us here.

Below is the port configs

interface GigabitEthernet x/y

switchport access vlan 150
switchport mode access
switchport voice vlan 200
qos trust dscp
spanning-tree portfast
spanning-tree bpdufilter enable
service-policy input VOIP-PHONE


Need your help to know exact root cause for loop in the network  when IPT phone connected to the network,

also If such issue needs to avoid in future  what will be the standard port configuration to be defined . please help

16 Replies 16

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

Definition-This command prevents ports that are in a Port  Fast-operational state from sending or receiving BPDUs. (Enabling BPDU  filtering on an interface is the same as disabling spanning tree on it  and can result in spanning-tree loops.)  ???? .

This is a correct assesment. The port stopped receiving and sending BPDUs. As a result, it did not negotiate in STP with any other port to which it was connected. That in turn caused the switching loop.

A small correction: if the BPDU Filter is configured directly on an interface as is in your case, the port does not have to be configured with PortFast. Regardless of the PortFast setting, the BPDU Filter configured on an interface stops receiving and sending BPDUs unconditionally.

I think having BDPU guard on the ports would have helped us here.

That is correct. You should use BPDU Guard instead of BPDU Filter on the ports towards your IP phones.

Best regards,

Peter

I'm not sure if BPDU Guard would stop the loop becuase the loop enters from the PC port on the phone and goes out the SW port on the phone back to the swich..There is no BPDU recieved on the port to put it in the err-dissable state. I dont think that phones send BPDU's.
-You could disable the unused switchports..

Hello Jeremy,

You're right in your assumption that an IP phone usually does not send BPDUs. However, don't forget that ports on a switch do send BPDUs. If an IP phone is connected via both its ports to a switch, it will simply relay the BPDUs received from each switchport, and that will trigger the BPDU Guard.

In fact, the BPDU Guard is not even necessary here: it will cause the port to be err-disabled, but even without the BPDU Guard, one of the ports on the switch would remain Blocking (or Discarding), simply as if you directly connected two ports on a same switch.

Best regards,

Peter

Hello peter ,

Thanks for the response , so root cause for the issue  is  enabling  command  ""  spanning-tree bpdufilter enable ""

on the switch port  ,  if it is only spanning tree port fast  without  "" bpdu gurad  " would have  restricted the loop ????.

Hi,

The IP phone does sort of have a switch within it but doesn't process BPDU's. and simply relays it. Put it this way you can use trunk two switches using an IP Phone and you can see it work as if the switches are connected to back to back

Peter,

I must admit something though. I faced a scenario where an engineer accidently patched  one of the switchport on a switch to another port on the same switch directly  and created a trunk link on the ports and put some vlans. A loop was created and brought the network down at the specific site. We had to shut one of the links and it restored. This is something different to what you mentioned in your last 2 statements in your last post.

Can you please shed some more light on this? What could have possibly happened here? shouldnt the port with the higher number go into blocking mode or something?

Regards, Kishore

Hi Kishore,

 I faced a scenario where an engineer accidently patched  one of the  switchport on a switch to another port on the same switch directly  and  created a trunk link on the ports and put some vlans. A loop was created  and brought the network down at the specific site. We had to shut one  of the links and it restored. This is something different to what you  mentioned in your last 2 statements in your last post.

This is difficult to comment without seeing the configuration of both ports. However, I can tell with absolute certainty that all STP version are capable of handling this situation without any loops - we do these kinds of loops regularly when demonstrating STP behavior.

The creation of a loop in this case must have been caused by some additional configuration on the ports - perhaps PortFast, BPDU Filter, native VLAN mismatch or simply no STP running in some VLAN. Once again, with plain port configuration without meddling with STP settings on that port, STP would not allowed the creation of a switching loop.

Best regards,

Peter

Peter, i belive the config was as follows.

sw encap dot1q

sw mode trunk

sw native vlan 255

span portfast enable  << cant ascertain if this was there.

The scenario happened almost like 6 months ago. the trunk config we have is just a standard simple one.

i will try it myself tomorrow and see what happens.

Thanks again for your insight into this.

Hi Kishore,

PortFast ports still send and receive BPDUs, and if a BPDU is received, then the port loses the operational PortFast state until it is disconnected. There is a slight chance that the PortFast caused ports to become Forwarding by default before they could actually exchange BPDUs, and the ensuing switching loop was so huge that it prevented the switches from processing the received BPDUs. That's a speculation, though.

If BPDU Filter was configured on at least one of those ports, that would explain the situation perfectly.

Best regards,

Peter

ebarticel
Level 4
Level 4

Port security enabled and configured would have also helped with the loop prevention.

Hello peter ,

Thanks for the response , so root cause for the issue  is  enabling  command  ""  spanning-tree bpdufilter enable ""

on the switch port  ,  if it is only spanning tree port fast even  without  "" bpdu gurad  " would have  restricted the loop ????.

Hello Santosh,

Thanks for the response , so root cause for the issue  is  enabling  command  ""  spanning-tree bpdufilter enable ""

Yes - in your case, it looks that way.

on the switch port  ,  if it is only spanning tree port fast even   without  "" bpdu gurad  " would have  restricted the loop ????.

If only the PortFast was configured, the loop would not be prevented but it could still be detected at most a couple of seconds after physically creating it. You see, the difference between PortFast and non-PortFast ports is that a PortFast port becomes immediately Forwarding, whilst non-PortFast becomes immediately Blocking after connecting. If two PortFast ports are connected together, they initially both become immediately Forwarding, creating a loop. There's no way to prevent this, apart from removing the PortFast configuration. However, as PortFast ports still send BPDUs, at most in 2 seconds, they would send a BPDU to each other and recognize that they are in fact not eligible to run as PortFast ports, so they would revert to normal STP operation.

This also means that not even BPDU Guard is going to prevent the loop from occuring, it is just going to react after it has been created. However, it is a good precaution to configure it nevertheless.

Best regards,

Peter

Hello peter ,

thanks for your detailed information , the conclusion is 

1) The switch port with  " Access vlan port  or / & voice vlan port   with config  "port fast enabled " , will not able to prevent loop . even we have bpdu guard configured

2) the port with config ,  "access vlan port " voice vlan port" ,  without port fast  can effectively prevent the loop , even though we do not have bpdu guard enabled

above points results  only in the scenario where  switch ports ( loop)  connectivity  through  IPT phone only ,  if yes  any suggestion on the config to avoid the loop .

If user connects the switch  port  cable to another switch port  with  config    "port fast bpdu guard enabled"   The BPDU Guard feature error disables the port completely when a BPDU is heard on the port fast ????.

Regards

Santosh

Hello Santosh,

1) The switch port with  " Access vlan port  or / & voice vlan  port   with config  "port past enabled " , will not able to prevent loop  . even we have bpdu guard configured

Correct. The loop may exist for a very short time and be almost undetectable - but that cannot be guaranteed. Because both ports with PortFast immediately become forwarding, the loop always exists in the moment of connecting those ports together.

2) the port with config ,  "access vlan port " voice vlan port" ,   without port past  can effectively prevent the loop , even though we do  not have bpdu guard enabled 

Correct. The downside of this solution is the it will take 30 seconds for a non-edge ports to become Forwarding which may be annoying to users.

Please note that many switches automatically add the spanning-tree portfast command as soon as you configure a voice VLAN on a port. You would need to manually remove that command.

Best regards,

Peter

Hello peter ,

Thanks for your patience and support on this . I have final queary  which i have raised  in the last post

3) If  user  connects ( loop) the switch  ports  cable to another switch ports  with   config    "port fast bpdu guard enabled"   The BPDU Guard feature error  disables the port completely when a BPDU is heard on the port fast ????.  or  It will also opens the gate for loop

Getting Started

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:

Review Cisco Networking products for a $25 gift card