STP LOOP ISSUE

[santosh.s.vijapur]

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

[Peter Paluch]

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

[Jeremy Halcomb]

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..

[Peter Paluch]

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

[santosh.s.vijapur]

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 ????.

[Kishore Chennupati]

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

[Peter Paluch]

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

[Kishore Chennupati]

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.

[Peter Paluch]

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