I don't believe that turning OFF STP will acheive the same affect as you claimed...
As a switch I will do one of two things upon receipt of an STP BPDU:
- If (x)STP is enabled, the switch will absorb the BPDU in the data-plane, punt it to the control-plane for processing and regenerate a new BPDU to forward upstream as a 'responsible xSTP citizen'
- If (x)STP is *disabled*, then BPDUs are simply seen as data-plane traffic that pass through the switch like any other frame.
So one way to address the 'rogue device' sending BPDUs is to turn xSTP *on* and then enable 'edge mode' on that port so that BPDUs will always be blocked, but the port will remain active. Another way would be to enable 'bpdu-guard' but this will block BPDUs and put the port into a 'bpdu error' state (refer to 'show interface <interface-name> extensive | match error' and/or 'show spanning-tree interface' and look for the port in question and it should be in a blocking state) and this error state will need to be cleared in order for the port to return to a forwarding state.
However, if you have no need for spanning-tree in your environment, but you have a device connected that is sending BPDUs (and you don't have the ability to stop the BPDUs from being generated from that device in the first-place) then you might want to block BPDUs from traversing the network and the command 'set protocols layer2-control bpdu-block interface <interface-name> gives you the ability to block BPDUs without having to create a firewall filter and apply it to an interface nor enable spanning-tree to achieve the same affect plus possibily incur other unwanted side-effects from adding STP to your enivronment just for the sake of BPDU blocking.
Hope this helps.
SC