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