CCNP Switch - Protecting the STP Topology

Troubleshooting STP on Catalyst Switches Running Cisco IOS System Software
http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/28943-170.html

Switch2#  debug spanning-tree events
3d13h: STP: VLAN0001 new root port Fa0/1, cost 19
3d13h: STP: VLAN0001 Fa0/1 -> listening

Switch2# debug spanning-tree all
Switch2# debug spanning-tree bpdu

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_58_se/configuration/guide/2960scg/swstpopt.html

 - superior BPDU= one with a better bridge ID

 - by default, Loop Guard is disabled on all switch ports
 - by default, UDLD is disabled on all switch ports
 - by default, BPDU filtering is disabled on all switch ports
 - The individual loop-guard port configuration overrides command "spanning-tree loopguard default"
 - BPDU Guard on the same interface as BPDU filtering: BPDU Guard has no effect because BPDU filtering takes precedence over BPDU Guard. 
 - PortFast causes a switch or trunk port to enter the spanning tree forwarding state immediately, bypassing the listening and learning states.
 - "spanning-tree portfast default" activates PortFast only on ports in the access operational mode. If the port is operating as a trunk, this command does not apply to it. 
 - UDLD= physical protection of loosing BPDUs, LoopGuard=STP tool to detect lose of BPDUs
 - BPDU skew detection allows the switch to keep track of BPDUs that arrive late and to notify the administrator with syslog messages.

STP Protection options
Protection/Feature    FOR     Action if BPDU appear  BPDU disappear  Description
UplinkFast            access-SW   one or more redundant/potential root ports in BLK (if Root-port fail, uplink fast immediatly is UP)
BackboneFast          DSW/BSW  determine if alternative paths exist to the root bridge, in case the switch detects an indirect link failure

PortFast (PF)         access  lose PF->normal STP    -               Port transition to FWD without LSN/LRN, send BPDUs, can induce L2-loops

BPDU-Filter default   access  lose PF->normal STP    -               BPDUs are not sending on portfast enabled interfaces, lose PF if IN
BPDU-Filter on port   access  ingore BPDU, can create loop -         BPDUs are not sending and INGORED if IN on portfast enabled
BPDU-Guard            access  err-dis port           manual/timeout  PF have BPDU-Guard auto enabled, remains err-dis even no BPDUs IN
BPDU-Guard default    access  err-dis port           manual/timeout  PF have BPDU-Guard auto enabled, current+future ports
BPDU-Guard on port    access  err-dis port           manual/timeout 
BPDU-Filter takes precedence over BPDU-Guard

Root-Guard            trunk   root-inc               normal STP      If superior BPDUs are being received on the port
Loop-Guard            trunk   OK                     loop-inc (BLK)  IF BPDUs reappears, port automatically move through the normal STP
UDLD norm             trunk   syslog only            not needed      Send/Receive regular (def15 sec) special Layer 2 UDLD frames
UDLD aggr             trunk   err-dis+syslog         manual/timeout     #udld reset OR  #errdisable recovery cause udld

STP Inconsistent port states
 - Certain misconfigurations can lead to STP failure and cause network outage.
 - To prevent downtime, some enhancements were implemented so that STP detects certain cases of misconfiguration and the relevant port is put into an “inconsistent” state.

There can be different types of STP inconsistencies:
 - Loop inconsistency—Detected by the Loop Guard feature. Refer to STP Enhancements using Loop Guard and BPDU Skew Detection Features.
 - Root inconsistency—Detected by the Root Guard feature. Refer to STP Root Guard Enhancement.
 - EtherChannel inconsistency—Detected by the EtherChannel consistency detection feature. Refer to Understanding EtherChannel Inconsistency Detection.
        Case if one switch considers the multiple links to be a channel and a neighbor switch considers those links to be separate connections (L2 loops can occur).
 - PVID-inconsistency (Port VLAN ID)—A PVST+  BPDU is received on a different VLAN than it was originated: (Port VLAN ID Mismatch or *PVID_Inc).
   Caused be Native VLAN missmatch. (untagged SSTP BPDU with a VLAN type/TLV that does not match the VLAN where the BPDU was received).
 - Type-inconsistency—A PVST+ BPDU is received on a non-802.1Q trunk.(Access port receives an IEEE 802.1Q-tagged SSTP BPDU.)

Refer to   Troubleshooting Spanning Tree PVID- and Type-Inconsistencies

Verify commands
show spanning-tree inconsistentportsshow interfaces status err-disabled
show errdisable detect     <--what will be detected (shutdown without autorecovery)
show errdisable recovery   <--timers for auto recovery
 Note: If the port stops receiving inconsistent BPDUs, the *-inconsistent state is cleared and STP changes the port state based on normal STP operation. A syslog message is sent to indicate the change:
%SPANTREE-SP-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/1 on vlan 1. Port consistency restored.

*Mar  1 01:52:35.186: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk GigabitEthernet1/0/4 VLAN1.
*Mar  1 01:52:35.186: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking GigabitEthernet1/0/4 on VLAN0001. Inconsistent port type.
*Mar  1 01:52:50.193: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking GigabitEthernet1/0/4 on VLAN0001. Port consistency restored.

Example Type-inconsistency:
Solution: correct link on SW1 to trunk
SW1(access link)----(trunk link)SW2(configured as root primary)
SW1#sh spanning-tree
VLAN0001
  Spanning tree enabled protocol ieee
..
             This bridge is the root
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg BKN*4         128.1    P2p *TYPE_Inc
Gi1/0/4             Desg BKN*4         128.28   P2p *TYPE_Inc

Example PVID-inconsistency :
Used 3 vlans: 1,50,999
SW1#sh int gi 1/0/1 sw | inc Trunking Native Mode
Trunking Native Mode VLAN: 1 (default)
SW1#

SW2(config)#int range GigabitEthernet0/1-4        
SW2(config-if-range)#switchport trunk native vlan 999
After ~ 1min, appears:
*Mar  1 02:05:24.405: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 999 on GigabitEthernet1/0/1 VLAN1.
*Mar  1 02:05:24.405: %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/1 on VLAN0999. Inconsistent peer vlan.
*Mar  1 02:05:24.405: STP[999]: Generating TC trap for port GigabitEthernet1/0/1
*Mar  1 02:05:24.405: STP: VLAN0999 Gi1/0/1 -> blocking
*Mar  1 02:05:24.405: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/1 on VLAN0001. Inconsistent local vlan.
*Mar  1 02:05:24.405: STP: VLAN0001 sent Topology Change Notice on Gi1/0/1
*Mar  1 02:05:24.405: STP[1]: Generating TC trap for port GigabitEthernet1/0/1
*Mar  1 02:05:24.405: STP: VLAN0001 Gi1/0/1 -> blocking
*Mar  1 02:05:24.405: STP: VLAN0001 new root port Gi1/0/4, cost 4
*Mar  1 02:05:24.405: STP: VLAN0001 Gi1/0/4 -> listening
*Mar  1 02:05:24.405: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 999 on GigabitEthernet1/0/4 VLAN1.
*Mar  1 02:05:24.405: %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/4 on VLAN0999. Inconsistent peer vlan.
*Mar  1 02:05:24.405: STP[999]: Generating TC trap for port GigabitEthernet1/0/4
*Mar  1 02:05:24.405: STP: VLAN0999 Gi1/0/4 -> blocking
*Mar  1 02:05:24.405: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/4 on VLAN0001. Inconsistent local vlan.
*Mar  1 02:05:24.405: STP: VLAN0001 Gi1/0/4 -> blocking
*Mar  1 02:05:24.405: STP: VLAN0001 we are the spanning tree root
SW1#sh spa | inc VLA|P2p
VLAN0001
Gi1/0/1             Desg BKN*4         128.1    P2p *PVID_Inc
Gi1/0/4             Desg BKN*4         128.28   P2p *PVID_Inc
VLAN0050
Gi1/0/1             Root FWD 4         128.1    P2p
Gi1/0/4             Altn BLK 4         128.28   P2p
VLAN0999
Gi1/0/1             Desg BKN*4         128.1    P2p *PVID_Inc
Gi1/0/4             Desg BKN*4         128.28   P2p *PVID_Inc
SW1#

Errdisable state and errdisable auto recovery option
You have to manually re-enable the port or interface to take it out the errdisable state unless you configure an errdisable recovery option
We can configure the switch to automatically re-enable any error-disabled interfaces after a specified timeout period.
This gives the offending issue a chance to be cleared by the user (for example, by removing an unapproved device) without the need for administrative intervention.
SW-4500(config)#errdisable recovery cause ?
  all                 Enable timer to recover from all causes
  arp-inspection      Enable timer to recover from arp inspection error disable state
  bpduguard           Enable timer to recover from BPDU Guard error disable state
  channel-misconfig   Enable timer to recover from channel misconfig disable state
  dhcp-rate-limit     Enable timer to recover from dhcp-rate-limit error disable state
  dtp-flap            Enable timer to recover from dtp-flap error disable state
  gbic-invalid        Enable timer to recover from invalid GBIC error disable state
  l2ptguard           Enable timer to recover from l2protocol-tunnel error disable state
  link-flap           Enable timer to recover from link-flap error disable state
  pagp-flap           Enable timer to recover from pagp-flap error disable state
  psecure-violation   Enable timer to recover from psecure violation disable state
  security-violation  Enable timer to recover from 802.1x violation disable state
  storm-control       Enable timer to recover from storm-control error disable state
  udld                Enable timer to recover from udld error disable state
  unicast-flood       Enable timer to recover from unicast flood disable state
  vmps                Enable timer to recover from vmps shutdown error disable state
STP Protection Features
Guidelines for Applying STP Protection Features in a Network
STP BPDUs loss
Spanning Tree Protocol Problems and Related Design Considerations
Most of STP failures relate to a massive loss of BPDUs. The loss causes blocked ports to transition to forwarding mode (and create L2 loops):
 - duplex mismatch
 - unidirectional links
 - packet corruption (show interfaces counters error)
 - resource errors
 - portfast configuration error
 - incorrect STP timer tuning and diameter issue
 - software errors

1) Duplex mismatch
 - If manually set the duplex mode to Full on one side of the link and leave the other side in autonegotiation mode, the link ends up in half-duplex. (A port with duplex mode set to Full no longer negotiates)
 - The worst-case scenario is when a bridge that sends BPDUs has the duplex mode set to half-duplex on a port, but the peer port on other end of link has the duplex mode set to full-duplex.
 
Duplex mismatch on the link between bridge A and B can easily lead to a bridging loop
Because bridge B has configuration for full-duplex, it does not perform carrier sense before link access. Bridge B starts to send frames even if bridge A is already using the link. This situation is a problem for A; bridge A detects a collision and runs the backoff algorithm before the bridge attempts another transmission of the frame. If there is enough traffic from B to A, every packet that A sends, which includes the BPDUs, undergoes deferment or collision and eventually gets dropped. From an STP point of view, because bridge B does not receive BPDUs from A any more, bridge B has lost the root bridge. This leads B to unblock the port connected to bridge C, which creates the loop.
Whenever there is a duplex mismatch, these error messages are on the switch consoles of Catalyst switches that run CatOS and Cisco IOS Software:

CatOS:  CDP-4-DUPLEXMISMATCH: Full/half duplex mismatch detected on port [mod]/[port]
Cisco IOS:
%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet5/1 (not half duplex), with TBA05071417(Cat6K-B) 4/1 (half duplex).
2) Unidirectional Link
 - Unidirectional links are a common cause of a bridging loop. On fiber links, a failure that goes without detection often causes unidirectional links.
 - Another cause is a problem with a transceiver.
 - Anything that can lead a link to stay up and provide a one-way communication is very dangerous with regard to STP.

3) Packet Corruption
 - Packet corruption can also lead to the same kind of failure.
 - If a link has a high rate of physical errors, you can lose a certain number of consecutive BPDUs. This loss can lead a blocking port to transition to forwarding state. You do not see this case very often because STP default parameters are very conservative. The blocking port needs to miss BPDUs for 50 seconds before the transition to forwarding.
 - The successful transmission of a single BPDU breaks the loop.
 - This case commonly occurs with the careless adjustment of STP parameters. An example of an adjustment is max-age reduction.

4) Resource Errors
 - STP is implemented in software, even on high-end switches that perform most of the switching functions in hardware with specialized ASICs.
 - If for any reason there is an overutilization of the CPU of the bridge, resources can be inadequate for the transmission of BPDUs.
 - The STA is generally not processor-intensive and has priority over other processes.

Troubleshoot a Failure
 - Check That Blocked Ports Receive BPDUs (show? panning-tree Bridge-group # )
 - Check for a Duplex Mismatch (show interfaces [interface interface-number] status )
 - Check Port Utilization (load and packets input/output)
 - Check Packet Corruption (runts, giants, no buffer, CRC, frame, overrun, and ignored counts)
 - Look for Resource Errors
 - Disable Unnecessary Features


Verify
SW-4500# show spanning-tree inconsistentports
Name                 Interface              Inconsistency
-------------------- ---------------------- ------------------
Number of inconsistent ports (segments) in the system : 0
SW-4500#

 - Under normal conditions, with all switches playing fairly and according to the rules, a loop-free topology is determined dynamically.
 - When BPDUs suddenly appear for some reason on a port that not expect BPDU, the STP topology can reconverge to give unexpected results.
 - When BPDUs suddenly disappear for some reason on a port that expect BPDU, a switch can make incorrect assumptions about the topology and unintentionally create loops.


Protecting Against Unexpected BPDUs
All switches in the STP domain need to receive the root’s BPDUs so that the network converges and a stable loop-free topology forms.
Cisco added two STP features that help prevent the unexpected appearance of rogue Root Bridge: Root Guard and BPDU Guard.

Root Guard
STP port roles:
■ Root port—Single port on a switch that is closest (with the lowest root path cost) to the root bridge.
■ Designated port—The port on a LAN segment that is closest to the root. This port relays, or transmits, BPDUs down the tree.
■ Blocking port—Ports that are neither root nor designated ports.
■ Alternate port—Ports that are candidate root ports (they are also close to the root bridge) but are in the Blocking state. These ports are identified for quick use by the STP UplinkFast feature.
■ Forwarding port—Ports where no other STP activity is detected or expected. These are ports with normal end-user connections.The root bridge always is expected to be seen on the root port and the alternative ports because these are “closest” (have the best-cost path) to it.

Root Guard feature was developed as a means to control where candidate root bridges can be connected and found on a network.
 - If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become root.
 - As long as the superior BPDUs are being received on the port (entire port=all vlans), the port will be kept in the root-inconsistent STP state.
 - The root-inconsistent state is effectively equal to a listening state. No traffic is forwarded across this port. In this way, the root guard enforces the position of the root bridge.
 - When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to normal use.
 - No data can be sent or received in that state, but the switch can listen to BPDUs received on the port to detect a new root advertising itself.
 - Use Root Guard on switch ports where you never expect to find the root bridge for a VLAN.
 - In case of unidirectional link, root guard does not help to resolve the issue. The UniDirectional Link Detection (UDLD) and loop guard features need to be used.

Interface configuration
Switch(config-if)# spanning-tree guard root
Verify
IOU3#
*Oct 12 02:16:24.627: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port Ethernet1/2 on VLAN0001.
IOU3#
IOU3#sh spanning-tree  | inc ROOT_Inc
Et1/0               Desg BKN*100       128.5    Shr *ROOT_Inc
Et1/2               Desg BKN*100       128.7    Shr *ROOT_Inc
Et1/3               Desg BKN*100       128.8    Shr *ROOT_Inc
IOU3#
IOU3#sh interfaces status
Port      Name               Status       Vlan       Duplex  Speed Type
Et1/0                        connected    trunk        auto   auto unknown
Et1/2                        connected    trunk        auto   auto unknown
Et1/3                        connected    trunk        auto   auto unknown
IOU3#sh interfaces status err-disabled
IOU3#

BPDU Guard
PortFast:
 - PortFast causes a switch or trunk port to enter the spanning tree forwarding state immediately, bypassing the listening and learning states.
 - If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops.
 - To prevent loops from occurring in a network, the PortFast mode is supported only on nontrunking access ports because these ports typically do not transmit or receive BPDUs.
 - PortFast BPDU guard prevents loops by moving a nontrunking port into an errdisable state when a BPDU is received on that port.
 - Enabling PortFast on a port is not the same as disabling the STP on it and not expect any BPDU packets.

BPDU Guard feature was developed to further protect the integrity of switch ports that have PortFast enabled.
 - If any BPDU (whether superior to the current root or not) is received on a port where BPDU Guard is enabled, that port immediately disables the port (with errdisable state)
 - The port is shut down in an error condition and must be either manually re-enabled or automatically recovered through the errdisable timeout function.
 - By default, BPDU Guard is disabled on all switch ports.
 - All ports that have PortFast enabled also have BPDU Guard automatically enabled.
 - When the BPDUs no longer are received, the port still remains in the errdisable state.
 - You should use BPDU Guard on all switch ports where STP PortFast is enabled.
 - You never should enable BPDU Guard on any switch uplink where the root bridge is located.

Enable BPDU Guard as the default
Switch(config)# spanning-tree portfast bpduguard default
Enable or disable BPDU Guard on a per-port basis
Switch(config-if)# [no] spanning-tree bpduguard enable
When the BPDUs no longer are received, the port still remains in the errdisable state.
Note: The default timeout interval is 300 seconds and, by default, the timeout feature is disabled.
Example:
IOU3#sh log | inc 1/2
*Oct 12 01:57:13.169: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Et1/2 with BPDU Guard enabled. Disabling port.
*Oct 12 01:57:13.169: %PM-4-ERR_DISABLE: bpduguard error detected on Et1/2, putting Et1/2 in err-disable state
*Oct 12 01:57:14.170: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/2, changed state to down
*Oct 12 01:57:15.170: %LINK-3-UPDOWN: Interface Ethernet1/2, changed state to down
IOU3#sh int ethernet 1/2 status
Port      Name               Status       Vlan       Duplex  Speed Type
Et1/2                        err-disabled trunk        auto   auto unknown
IOU3#
IOU3#sh interfaces status err-disabled
Port      Name               Status       Reason               Err-disabled Vlans
Et1/0                        err-disabled bpduguard
Et1/2                        err-disabled bpduguard
Et1/3                        err-disabled bpduguard
IOU3#

Protecting Against Sudden Loss of BPDUs
The STP topology’s integrity then depends on a continuous and regular flow of BPDUs from the root.
If the absence of BPDUs is actually a mistake and BPDUs are not being received even though there is no topology change, bridging loops easily can form.
Cisco has added two STP features that help detect or prevent the unexpected loss of BPDUs: Loop Guard and Unidirectional Link Detection (UDLD.

Loop Guard
The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop.
The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.

 - STP to function, some port will remain in the Blocking state as long as a steady flow of BPDUs is received.
 - If BPDUs stops for some reason, the last known BPDU is kept until the Max Age timer expires. Then that BPDU is flushed, and the switch thinks there is no longer a need to block the port. After all, if no BPDUs are received, there must not be another STP device connected there. The switch then moves the port through the STP states until it begins to forward traffic and forms a bridging loop.
 - by default, Loop Guard is disabled on all switch ports. 
 - Loop Guard doesn’t block the entire port; only the offending VLANs are blocked.

When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports.
 - While BPDUs are received, the port is allowed to behave normally.
 - When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state (effectively in blocking mode to prevent a loop from forming).
 - When BPDUs are received on the port again, Loop Guard allows automatically the port to move through the normal STP states and become active.

Enable Loop Guard as a global default, affecting all switch ports
Switch(config)# spanning-tree loopguard default
Enable or disable Loop Guard on a specific switch port
Switch(config-if)# [no] spanning-tree guard loop
You can enable Loop Guard on all switch ports, regardless of their functions.  The switch figures out which ports are nondesignated and monitors the BPDU activity to keep them nondesignated.

UDLD (unidirectional link)
Switches are connected by bidirectional links, where traffic can flow in two directions.
 - if a link has a physical layer problem, the two switches it connects detect a problem, and the link is shown as not connected.
 - in some cases, the two switches still might see a functional bidirectional link, although traffic actually would be delivered in only one direction.
 - A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link
 - Unidirectional Link Detection (UDLD) - Cisco-proprietary STP feature (other vendor analogue is DLDP)
 - When enabled, UDLD interactively monitors a port to see whether the link is truly bidirectional.
 - A switch sends  at regular intervals (The default is 15 seconds) special Layer 2 UDLD frames identifying its switch port at regular intervals.  UDLD expects the far-end switch to echo those frames back across the same link, with the far-end switch port’s identification added.
 - Requires both endsof the link to be configured for UDLD
 - By default, UDLD is disabled on all switch ports.
 - The default UDLD message interval times differ among Catalyst switch platforms.
 - If you decide to change the default message time, make sure that UDLD still can detect a fault beforeSTP decides to move a link to the Forwarding state.
 - You safely can enable UDLD on all switch ports.
 - in an EtherChannel: If one link within the channel becomes unidirectional, UDLD flags or disables only the offending link in the bundle, not the entire EtherChannel. UDLD sends and echoes its messages on each link within an EtherChannel channel independently.

UDLD has two modes of operation:
■ Normal mode—When a unidirectional link condition is detected, the port is allowed to continue its operation. UDLD merely marks the port as having an undetermined state and generates a syslog message.
■ Aggressive mode—When a unidirectional link condition is detected, the switch takes action to reestablish the link. UDLD messages are sent out once a second for 8 seconds. If none of those messages is echoed back, the port is placed in the Errdisable state so that it cannot be used

To enable globally
Switch(config)# udld {enable | aggressive | message time <seconds>}
enable - for normal mode
aggressive - for aggressive mode
message time - set the message interval to seconds, ranging from 7 to 90 seconds
Enable or disable UDLD on individual switch ports
Switch(config-if)# udld {enable | aggressive | disable}   <---  disable UDLD on a fiber-optic interface

Using BPDU Filtering to Disable STP on a Port
- If it is configured from global configuration mode BPDU Filtering will be enabled on all configured PortFast ports.
   If BPDU is received the port will lose is PortFast status and  BPDU Filtering will be disabled. The port is then taking back to normal STP.
- If is configured from the interface configuration mode the result is completely different as this will cause the specific port to stop sending AND receiving BPDUs (are dropped). 
The port ignores any incoming BPDUs and changes to Forwarding state. This solution is not recommended as it can result in bridging loops.

Prevents BPDUs from being transmitted from PortFast-enabled interfaces.
When enabled globally on the switch   (global> spanning-tree portfast bpdufilter default ):
  • Configures all PortFast ports for BPDU filtering
  • If BPDUs are seen, the port looses its PortFast status, BPDU filtering is disabled, and STP resumes default operation on the port
  • When the port comes up, it sends 10 BPDUs, if it hears any BPDUs during that time PortFast and BPDU filtering are disabled
When applied to an individual port  (interface > spanning-tree bpdufilter enable) :
  • It ignores all BPDUs it receives
  • It does not transmit BPDUs
  • Because it ignores incoming BPDUs, this can lead to bridging loop scenarios

The BPDU filtering feature can be globally enabled on the switch or can be enabled per interface, but the feature operates with some differences.

At the global level, you can enable BPDU filtering on Port Fast-enabled interfaces by using the spanning-tree portfast bpdufilter default global configuration command. This command prevents interfaces that are in a Port Fast-operational state from sending or receiving BPDUs. The interfaces still send a few BPDUs at link-up before the switch begins to filter outbound BPDUs. You should globally enable BPDU filtering on a switch so that hosts connected to these interfaces do not receive BPDUs. If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status, and BPDU filtering is disabled.

At the interface level, you can enable BPDU filtering on any interface by using the spanning-tree bpdufilter enable interface configuration command without also enabling the Port Fast feature. This command prevents the interface from sending or receiving BPDUs.
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_55_se/configuration/guide/3560_scg/swstpopt.html

BPDUs are sent on all switch ports—even ports where PortFast has been enabled. BPDUs also can be received and processed if any are sent by neighboring switches.

You always should allow STP to run on a switch to prevent loops. 
However, in special cases when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can use BPDU filtering to effectively disable STP on those ports.

 - By default, BPDU filtering is disabled on all switch ports.

By default, spanning tree sends BPDUs from all ports regardless of whether PortFast is enabled.
Configure BPDU filtering as a global default, affecting all switch ports
Switch(config)# spanning-tree portfast bpdufilter default
default - indicates that BPDU filtering will be enabled automatically on all ports that have PortFast enabled.
             If PortFast is disabled on a port, then BPDU filtering will not be enabled there


SW-2(config)#spanning-tree portfast bpdufilter
% Incomplete command.
Enable or disable BPDU filtering on specific switch ports
Switch(config-if)# spanning-tree bpdufilter {enable | disable}
Be very careful to enable BPDU filtering only under controlled circumstances in which you are absolutely sure.

Troubleshooting STP Protection
Switch# show spanning-tree inconsistentports  <---List the ports that have been labeled in an inconsistent state.
Switch# show spanning-tree interface <type mod/num> [detail]  <---Look for detailed reasons for inconsistencies.
Switch# show spanning-tree summary  <---Display the global BPDU Guard, BPDU filter, and Loop Guard states.
Switch# show udld [type mod/num]  <---Display the UDLD status on one or all ports.
Switch# udld reset  <---Reenable ports that UDLD aggressive mode has errdisabled.

BPDUGuard vs BPDUFilter
Example 1 - BPDU filtering
spanning-tree portfast bpdufilter default
!
interface f0/1
spanning-tree portfast
!
Interface f0/1 will prevent STP from sending BPDUs and ignore all received BPDUs.
However, if interface f0/1 receives any BPDUs, it will lose its portfast status and BPDU filtering will be disabled.
Normal STP operation will resume just as any other STP port on the switch.

Example 2 - BPDU guard
spanning-tree portfast bpduguard default
!
interface f0/1
spanning-tree portfast
!
Interface f0/1 will still send BPDUs and operate in a portfast operational state.
However, if interface f0/1 starts to receive any BPDUs it will be shutdown (err-disable) and must manually be re-enabled.
While similar in their configuration, they do behave very differently.