BPDU Filter and BPDU Guard

By Marko Milivojevic on December 6th, 2010

Judging from recent discussions I was part of recently, two Cisco’s spanning tree features are cause of major misunderstanding to quite a few people. Those two features are BPDU Filter and BPDU Guard. While ultimately very simple, there are good reasons for a confusion. I will do my best to clear out most of misconceptions in this blog.First of all, let’s do a quick overview what is the actual purpose of these two features. To do that, the best is to go directly to Cisco’s documentation and read it there. Here are the links to appropriate portions of the Catalyst 3560 Configuration Guide.

After reading the above two segments, we can conclude that we are not dealing with two features. Instead, we are dealing with two sets of two different features that share the same names. There are two different features called “BPDU Filter” and two different features called “BPDU Guard”. Allow me to explain in some more detail.

To do so, I will use the simple network shown on the diagram below.

BPDU Guard and BPDU Filter

All ports on the two switches except those shown on the diagram are disabled (shutdown) and below is the relevant configuration.

Cat2:

vtp mode transparent
vtp domain IPexpert
!
vlan 23
 name Cat2-Cat3
!
ip routing
!
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 23
!
no interface Vlan 1
!
interface Vlan23
 ip address 192.168.23.12 255.255.255.0
 no shutdown
!

Cat3:

vtp mode transparent
vtp domain IPexpert
!
vlan 23
 name Cat2-Cat3
!
ip routing
!
interface FastEthernet0/5
 switchport mode access
 switchport access vlan 23
!
no interface Vlan 1
!
interface Vlan23
 ip address 192.168.23.13 255.255.255.0
 no shutdown
!

R2:

interface GigabitEthernet0/1
 ip address 192.168.23.2 255.255.255.0
!

R5:

interface FastEthernet0/1
 ip address 192.168.23.5 255.255.255.0
!

I’ll use these IPs just for testing of connectivity and no other purpose. Let’s see if our connection works now.

Cat2:

Cat2#ping 192.168.23.13

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms

Now we’re ready to explore the different flavors of BPDU Filter and BPDU Guard. We will start doing that by exploring another feature, which is crucial for operation of the two we will be focusing on today. This is “portfast” feature.

Portfast

We all know that a switch will process BPDU frames on every layer 2 port. We also know that spanning-tree requires port to transition through different states before it can actually send any traffic. Depending on the flavor of the spanning tree protocol in use, these states are different, but the basic idea remains. This is all done with the ultimate goal of preventing bridging loops. Regardless of the STP version, this process takes time. Sometimes there is a need to bypass these states and make the port forward traffic immediately. This can be accomplished using “portfast” feature, or enabling the “edge port” functionality in rapid spanning-tree (incidentally, using “portfast” command).

Portfast has two modes of operation. One is global, the other one is per-port configuration. Global configuration will cause access ports to start forwarding traffic immediately, unless BPDU is received on the port. If BPDU is received, port loses portfast status and reverts to normal operation, i.e. passing through all the states.

On the other hand, enabling portfast feature on the port itself is unconditional. Regardless of any BPDU being received, port will remain in portfast state. This small, but, crucial difference is important for the remainder of our analysis. We will see that history, so to speak, repeats itself.

BPDU Filter: Global

Per documentation, global BPDU Filter is configured as part of global “portfast” configuration. The purpose of BPDU Filter is to prevent the switch from sending BPDU frames on ports that are enabled with portfast. Let’s configure portfast globally and enable BPDU filter globally on Cat2. We’ll observe what happens next.

Cat2:

spanning-tree portfast default
spanning-tree portfast bpdufilter default
Cat2#show spanning-tree interface FastEthernet0/2 portfast
VLAN0023            enabled
Cat2#show spanning-tree interface FastEthernet0/20 portfast
VLAN0023            disabled

We can clearly see that port facing R2 is in portfast state, while the port facing Cat3 is not. This is perfectly to be expected. Cat3 is sending BPDU frames (remember, it’s still just a switch) and Cat2 has disabled the portfast status on the port. Since R2 is not a switch, Cat2′s port facing it is still in portfast. While this is all very interesting, it doesn’t answer the question – are BPDU frames being sent from Cat2′s ports? Let’s test that.

I am going to disable both active ports, clear spanning-tree counters, enable them and examine what happens.

interface range FastEthernet0/2 , FastEthernet0/20
 shutdown
!
Cat2#clear spanning-tree counters

Let’s re-enable the ports and check the counters.

Cat2:

interface range FastEthernet0/2 , FastEthernet0/20
 no shutdown
!
Cat2#show spanning-tree interface FastEthernet0/2 detail
 Port 4 (FastEthernet0/2) of VLAN0023 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.4.
   Designated root has priority 32791, address 0018.baf8.a200
   Designated bridge has priority 32791, address 001b.d4d3.0280
   Designated port id is 128.4, designated path cost 19
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   The port is in the portfast mode by default
   Link type is point-to-point by default
   Bpdu filter is enabled by default
   BPDU: sent 2, received 0
Cat2#show spanning-tree interface FastEthernet0/20 detail
 Port 22 (FastEthernet0/20) of VLAN0023 is root forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.22.
   Designated root has priority 32791, address 0018.baf8.a200
   Designated bridge has priority 32791, address 0018.baf8.a200
   Designated port id is 128.22, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 0, received 3

Note that Cat2 reports it has sent few BPDU frames towards R2 even with BPDU Filter being enabled on all portfast ports. There is a very good reason for this behavior. Imagine two switches connected using access ports with BPDU Filter enabled globally. How would they realize they should be sending BPDU frames to each other? This setup could spell a disaster in a network, so to prevent it, switches with globally enabled BPDU Filter will send “couple of BPDU frames” when they become active in an effort to remedy this race condition.

BPDU Guard: Global

The purpose of globally configured BPDU Guard is to disable (err-disable) all portfast-enabled ports should they ever receive BPDU frames. Let’s see if it works. I will enable the feature globally (first disabling BPDU Filter) and bounce the port between Cat2 and Cat3.

Cat2:

no spanning-tree portfast bpdufilter default
spanning-tree portfast bpduguard default
interface FastEthernet0/20
 shutdown
 no shutdown
!

As soon as the port comes up, we’ll see a log message:

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/20 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/20, putting Fa0/20 in err-disable state

It worked like a charm. There is one point I would like to make here. Even though global portfast relies on not receiving any BPDU frames, BPDU Guard will prevent the switch from receiving those frames and disable the port before it can change status. In a sense, BPDU Guard is older than portfast feature.

BPDU Filter: Port

We’ve seen in examples earlier that globally configuring BPDU Filter relies on the portfast status of the port. Behavior of the globally configured BPDU Filter is also not complete – couple of BPDU frames are still being sent when the port becomes active. In short, globally configured BPDU Filter is “conditional”. Contrary to this, BPDU Filter configured directly on the port is unconditional. It will always be active and no BPDU frames will be sent.

To test this claim we can use the existing setup on Cat2 and enable BPDU Filter on the port on Cat3. We have seen in the previous example that Cat2 disables the port when it receives BPDU frame due to BPDU Guard being enabled. if this doesn’t happen after configuring BPDu Filter on Cat3′s port, we will have our proof. Let’s try.

Cat3:

interface FastEthernet0/20
 spanning-tree bpdufilter enable
!

Let’s bounce the port on Cat2 to recover err-disable.

Cat2:

interface FastEthernet0/20
 shutdown
 no shutdown
!
Cat2#show spanning-tree interface FastEthernet0/20

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0023            Desg FWD 19        128.22   P2p Edge

We can see that the port is up, Cat2 considers it to be designated and an edge port. Edge port simply means that no BPDU frames are being received!

BPDU Guard: Port

Similar to BPDU Filter, globally enabled BPDU Guard is conditional. It will work only on portfast ports. If the port is not portfast, BPDU Guard will not be enabled. Simply said, this means it will not be enabled on any trunks by default. If we wish to enable BPDU Guard unconditionally on a port, we should do that on the port itself.

To test this behavior, let’s change the port between Cat2 and Cat3 to be 802.1q trunk. This will disable all BPDU Filter and BPDU Guard features on Cat2, since they are enabled globally. BPDU Filter on Cat3 will remain active, since it’s configured on the port itself.

Cat2:

interface FastEthernet0/20
 shutdown
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!

Cat3:

interface FastEthernet0/20
 shutdown
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!

Cat2:

Cat2#show spanning-tree interface FastEthernet 0/20

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001            Desg LRN 19        128.22   P2p
VLAN0023            Desg LRN 19        128.22   P2p 

We can see that port is no longer considered Edge and it’s definitely not portfast, since it’s going through the learning state.

We should be seeing similar behavior on Cat3.

Cat3:

Cat3#show spanning-tree interface FastEthernet0/20

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001            Desg FWD 19        128.22   P2p
VLAN0023            Desg FWD 19        128.22   P2p 

Now, let’s configure BPDU Guard on FastEthernet0/20 on Cat3 and see what happens.

Cat3:

interface FastEthernet0/20
 spanning-tree bpduguard enable
!

It will soon become obvious that absolutely nothing changes! The port is still operational. Remember, we still have BPDU Filter enabled on it:

Cat3:

Cat3#show running-config interface FastEthernet0/20
Building configuration...

Current configuration : 211 bytes
!
interface FastEthernet0/20
 switchport access vlan 23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable
end

Cat3#show spanning-tree interface FastEthernet0/20 detail
 Port 22 (FastEthernet0/20) of VLAN0001 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.22.
   Designated root has priority 32769, address 0018.baf8.a200
   Designated bridge has priority 32769, address 0018.baf8.a200
   Designated port id is 128.22, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   Bpdu guard is enabled
   Bpdu filter is enabled
   BPDU: sent 0, received 0

 Port 22 (FastEthernet0/20) of VLAN0023 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.22.
   Designated root has priority 32791, address 0018.baf8.a200
   Designated bridge has priority 32791, address 0018.baf8.a200
   Designated port id is 128.22, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   Bpdu guard is enabled
   Bpdu filter is enabled
   BPDU: sent 0, received 0

The important conclusion we should make here is that BPDU Filter configured locally on the port takes precedence, or as I like to say is older, than BPDU Guard. We can clearly see that switch doesn’t send nor receive any BPDU frames. Let’s now remove BPDu Filter and see what happens.

Cat3:

interface FastEthernet0/20
 no spanning-tree bpdufilter enable
!

Sure enough, as soon as I did that, familiar log message showed up.

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/20 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/20, putting Fa0/20 in err-disable state

Conclusions

In the CCIE lab attention to detail is of extreme importance. Not understanding the difference between features and how they behave depending how they have been configured can be a costly mistake. Hopefully this article cleared up some of the misconceptions I heard and read about these Cisco features in Catalyst switches.

Happy studies!

This post has been edited on January 22nd 2011 to correct minor errors and provide additional clarification of the initial test configuration.


Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

BPDU Filter and BPDU Guard, 4.0 out of 5 based on 21 ratings
Be Sociable, Share!

    Tags: BPDUFilter, BPDUGuard, CCIE Routing & Switching, CCIE Security, Portfast, Spanning-tree

    25 Responses to “BPDU Filter and BPDU Guard”

    1. Mohamed Saad says:

      Great Job Marko
      Can I ask you about something related to Etherchannel… ?
      how does the load balance is done when we bundle 3 links ??

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (1 vote cast)
      • Bojan Zivancevic says:

        I have doubts about the sentence
        “Global [PORTFAST] configuration will cause access ports to start forwarding traffic immediately, unless BPDU is received on the port. If BPDU is received, port loses portfast status and reverts to normal operation, i.e. passing through all the states.”

        I think this is not true, since this is the exact thing that global BPDUfilter is doing. Why would we need this command at all then? This is the first reason. :)
        The second reason I think it is not true is that there is no mention of such behavior in the cisco command reference… Portfast is just for enabling portfast feature, and all these BPDUxxxx commands are for other things.

        BTW this is a good article, these things do cause the confusion all the time…

        Bojan

        VA:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
        • The reason I wrote the article is because many people have the exact confusion about these features you expressed in your comment.

          My sentence is correct and you are free to repeat the steps I did to show it. Just connect two switches using access ports with globally enabled “portfast” and see if they are indeed “portfast” or not. I will agree that the documentation is a little bit misleading on this subject.

          Please note that global BPDUFilter filters OUTBOUND BPDU frames, not inbound. Only port-based BPDUFilter filters inbound frames. Disabling “portfast” state of the port is a function of globally configured “portfast” command and not BPDU Filter.


          Marko Milivojevic – CCIE #18427
          Senior Technical Instructor – IPexpert
          Join our Online Study List

          VN:F [1.9.22_1171]
          Rating: 5.0/5 (1 vote cast)
          • Vincent says:

            Hi Marco,

            I’ve been labbing this. I found a small difference. On the 3560 software I’m using (12.2(58)SE2), there is no difference in the ‘global’ or ‘interface’ mode of PortFast. In other words, in both modes of operation, the port will lose their portfast status. Below is the explanation in a setup where a 3560 switch is connected to the ethernet of my laptop, which is mapped to a cloudinterface on GNS3. I use a router with a brigde group to emulate another switch. This is convenient as our f0/3 interface doesn’t loose it’s link.

            Portfast on interface:
            lab-switch#sh run int f0/3 | inc portfast
            spanning-tree portfast

            lab-switch#sh span int f0/3 portfast
            VLAN0999 enabled

            lab-switch#sh span root | inc 999
            VLAN0999 25575 0064.4066.9b00 0 2 20 15

            So, our lab-switch is the root. It is sending the BPDUs throughout the network. The other switch (the gns3 router) has its interface shutdown.

            lab-switch#sh span int f0/3 det | inc BPDU
            BPDU: sent 13, received 0

            Now, we connect the other switch (no shut the interface). It immediately sends us a BPDU (which is inferior btw).

            lab-switch#sh span int f0/3 det | inc BPDU
            BPDU: sent 27, received 1

            This is confirmed on the lab-switch as we see the counter got increased. According to your statement, the port should remain in portfast because the configuration is unconditional. However, I’ve found that there is no difference in the STP handling when configuring globally or on the interface.

            lab-switch#sh span int f0/3 portfast
            VLAN0999 disabled

            The above shows. Portfast is now gone but it *is* enabled on the interface:

            lab-switch#sh run int f0/3 | inc portfast
            spanning-tree portfast

            If we do the same test for globally enabled portfast, we get the same results:

            lab-switch(config)#int f0/3
            lab-switch(config-if)#no spanning-tree portfast
            lab-switch(config-if)#shut
            lab-switch(config-if)#exit
            000463: *Mar 1 03:41:48.836 UTC: %LINK-5-CHANGED: Interface FastEthernet0/3, changed state to administratively down
            000464: *Mar 1 03:41:49.843 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
            lab-switch(config)#spanning-tree portfast default

            lab-switch(config)#int f0/3
            lab-switch(config-if)#no shut

            lab-switch(config-if)#do sh span int f0/3 detail
            Port 4 (FastEthernet0/3) of VLAN0999 is designated forwarding
            Port path cost 19, Port priority 128, Port Identifier 128.4.
            Designated root has priority 25575, address 0064.4066.9b00
            Designated bridge has priority 25575, address 0064.4066.9b00
            Designated port id is 128.4, designated path cost 0
            Timers: message age 0, forward delay 0, hold 0
            Number of transitions to forwarding state: 1
            The port is in the portfast mode by default
            Link type is point-to-point by default
            BPDU: sent 5, received 0
            lab-switch(config-if)#

            Now I no shut the interface on the GNS3 switch/router.

            lab-switch(config-if)#do sh span int f0/3 detail
            Port 4 (FastEthernet0/3) of VLAN0999 is designated forwarding
            Port path cost 19, Port priority 128, Port Identifier 128.4.
            Designated root has priority 25575, address 0064.4066.9b00
            Designated bridge has priority 25575, address 0064.4066.9b00
            Designated port id is 128.4, designated path cost 0 Hello is pending
            Timers: message age 0, forward delay 0, hold 0
            Number of transitions to forwarding state: 1
            Link type is point-to-point by default
            BPDU: sent 17, received 1

            Immediately, portfast is removed and the switch proceeds to the regular STP states.

            VA:F [1.9.22_1171]
            Rating: 0.0/5 (0 votes cast)
    2. Marc says:

      Thank you Marko, you just completely removed my confusion on this topic.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    3. lcg says:

      Have you thought about how bpduguard and bpdufilter work with trunked interfaces to a server (common with ESX)? I am familiar with configuring “spanning-tree portfast trunk” in that case, but sometimes even that takes too long to begin forwarding, so I’ve been thinking about enabling bpdufilter. However, my concern with that is that someone with a VM and two NICs will start fooling around with bridging…

      I’ve seen some recommendations about enabling bpduguard with ESX, as well. The concern in that case is spoofed bdpu frames from a VM. Assuming ESX forwards the bpdu frame, the switch will err-disable the interface due to bpdu guard, then ESX will move the VM to the next interface, which err-disables as soon as it see a bpdu, and so on. If the ESX host is in an HA cluster, when it becomes isolated because all interfaces are disabled, VMware HA will kick in, shutdown the VMs, and start the VMs on another host. At that point, the VM sending bpdus would isolate that that host as well and trigger another HA event. Soon, all the interfaces connected to the entire cluster would be err-disabled and none of the VMs would be powered up (due to the final HA event).

      Of course, if ESX doesn’t forward the bpdus from a VM, then none of that happens and enabling bpduguard is safe. Definitely not worth the risk until I’m sure, though! :)

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    4. venkat says:

      Mr Marko,

      What happens, when ‘bpdugaurd’ and ‘portfast’ are configured at interface level, bpdus received from neighboring switch?

      Thanks
      Roger

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    5. ciscoguy says:

      Hi Marko,

      With all due respect I happen to disagree with the following claim you do in your article regarding the per-interface portfast:

      “On the other hand, enabling portfast feature on the port itself is unconditional. Regardless of any BPDU being received, port will remain in portfast state. This small, but, crucial difference is important for the remainder of our analysis. We will see that history, so to speak, repeats itself”

      The reality is that if you configure the “spanning tree portfast” feature at the interface level in two separate switches and connect them back-to-back on those interfaces, as soon these ports receive the first BPDU they will move each other out of the portfast state immediately. The ports will jump from blocking to Forwarding in no time but the portfast status which is on what the global BPDU filter/guard rely on is lost. This can be verified by the “show spanning-tree portfast” command which will show both interfaces in disable for all the relevant VLANs

      Example:

      SW2#show runn int g 0/16
      Building configuration…

      Current configuration : 85 bytes
      !
      interface GigabitEthernet0/16
      switchport mode access
      spanning-tree portfast
      shutdown
      end

      SW3#show runn int g 0/16
      Building configuration…

      Current configuration : 85 bytes
      !
      interface GigabitEthernet0/16
      switchport mode access
      spanning-tree portfast

      After doing “no shut” on g0/16 on SW2

      SW2#show spanning-tree int g 0/16 portf
      Rack1SW2#show spanning-tree int g 0/16 portfast
      VLAN0001 disabled

      SW3#show spanning-tree int g 0/16 port
      VLAN0001 disabled

      Cheers,

      George

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (1 vote cast)
    6. cedric says:

      Other result than what stated below

      Portfast – “Global configuration will cause access ports to start forwarding traffic immediately, unless BPDU is received on the port. If BPDU is received, port loses portfast status and reverts to normal operation, i.e. passing through all the states.”

      When connecting two switches back-to-back with commands on both switches:
      (1) default configuration of connecting interfaces and
      (2) only “spanning-tree portfast default”,
      I found the link come up immediately without going through LIS/LRN , assoicated to VLAN 1, and Type P2p Edge

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      • Which STP mode were switches running in? How did you verify?


        Marko Milivojevic – CCIE #18427
        Senior Technical Instructor – IPexpert
        Join our Online Study List

        VN:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
        • cedric says:

          Debug log captured below right after “no shut” G0/24 port

          sw03(Version 12.2(44)SE)
          sw03#sh spanning-tree sum
          Switch is in pvst mode

          Debug Log:
          *Mar 8 23:52:48.764: set portid: VLAN0001 Gi0/24: new port id 8018
          *Mar 8 23:52:48.764: STP: VLAN0001 Gi0/24 ->jump to forwarding from blocking
          *Mar 8 23:52:48.848: %SW_MATM-4-MACFLAP_NOTIF: Host 001b.54e1.24a1 in vlan 1 is flapping between port Gi0/24 and port Gi0/13
          *Mar 8 23:52:49.385: STP: VLAN0001 sent Topology Change Notice on Gi0/13
          *Mar 8 23:52:49.385: STP: VLAN0001 Gi0/24 -> blocking
          *Mar 8 23:52:50.769: %LINK-3-UPDOWN: Interface GigabitEthernet0/24, changed sta te to up
          *Mar 8 23:52:51.776: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEth ernet0/24, changed state to up
          sw03#

          sw04 (Version 12.2(44)SE5)
          sw04#sho span sum
          Switch is in pvst mode

          Debug Log:
          *Mar 8 23:34:14.916: set portid: VLAN0001 Gi0/24: new port id 8018
          *Mar 8 23:34:14.916: STP: VLAN0001 Gi0/24 ->jump to forwarding from blocking
          *Mar 8 23:34:15.042: %SW_MATM-4-MACFLAP_NOTIF: Host 001b.54e1.24a1 in vlan 1 is flapping between port Gi0/24 and port Gi0/13
          *Mar 8 23:34:15.218: %LINK-3-UPDOWN: Interface GigabitEthernet0/24, changed state to up
          *Mar 8 23:34:15.227: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/24, changed state to up
          sw04)#

          VA:F [1.9.22_1171]
          Rating: 0.0/5 (0 votes cast)
    7. edw says:

      guys, enabling portfast on port level won’t enforce the portfast regardless of received bpdus !!!

      If on a portfast configured port you receive any bpdu THAT PORT WILL LOSE IT’S PORTFAST STATUS!

      Lab it and see for yourself!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      • This is actually a little bit more complicated than this :-). I think it’s time for a follow-up article to clarify this particular behavior.

        In short – you are right – the port will lose the portfast status when it receives BPDUs, but received BPDU will not force the port to fall back to listening/learning states. If it was forwarding, it will remain forwarding. Only if it goes back to blocking (not disabled) state, after losing portfast status, the port will behave like a normal port.

        VN:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
    8. Davy says:

      I don’t understand the output of spanning-tree counters
      under ‘BPDU Filter: Global’

      When BPDUfilter is globally configured it’s active for all portfast ports. Does this mean- ‘portfast configured -globally/port’ or ‘portfast configured AND portfast active’

      show spanning-tree interface fas0/2 portfast
      >portfast enabled
      show spanning-tree interface fas0/20 portfast
      >portfast disabled

      So I expect to see an increase of the ‘BPDU send counter’ on interface fas0/20- now it says 0

      I’m not sure about why it’s needed to send some BPDUs out on interface fa0/2 as BPDUfilter is enabled. We told the switch NOT send BPDUs. So- why required? Don’t get the race condition?

      VA:F [1.9.22_1171]
      Rating: 1.0/5 (1 vote cast)
    9. Kevin says:

      I’ve labbed up a portfast situation. Two switches directly connected by an access port, shut down the interface, applied portfast directly to interface, brought the interface up, show spanning inter fx/x portfast shows enabled, it begins forwarding, another show inter fx/x portfast a few moments later shows disabled. That contradicts this statement: enabling portfast feature on the port itself is unconditional. Regardless of any BPDU being received, port will remain in portfast state.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    10. Don says:

      this is confusing and spending far too much time on this trivia but anyhow….

      i have a 3560 switch connected to a 2801 router. running pvst. my test consist of turning on bridging on the fa0/0 of the router.

      portfast global or portfast interface has the same effect. it disables portfast when it receives a bpdu. shutting the interfaces and bringing them back up causes the interface to forward immediately. i believe it will only revert to non portfast state if the interfacce goes to STP blocking state.

      I have also noticed that the switch sends bpdus but does not receive any. it is like as if bpdufuilter has been enabled at the same time. NOTE: I have NOT applied the bpdugilter command.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    11. Don says:

      Follow up to last post

      I said

      “I have also noticed that the switch sends bpdus but does not receive any. it is like as if bpdufuilter has been enabled at the same time. NOTE: I have NOT applied the bpdugilter command.”

      It is not receiving any BPDUs because the router is not sending any. The switch is the root bridge so it is sending BPDUs but not receiving any. If I change the router to be the root bridge then I will receive bpdus.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    12. Jay says:

      it woulda helped if the config for the ports connecting the 2 switches ws also mentioned..

      are those trunks or access ports?

      J

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    13. Junaid says:

      wish we knew starting out how int f0/20 between the 2 switches is configured….

      if you start off reading the article thinking that the 2 switches are trunked…it’ll lead to confusion..

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    14. J Memon says:

      Interface Level Portfast is conditional

      sw1—-f0/1————f0/0 R1

      before

      Rack1SW1#sh spanning-tree interface f0/1 port
      Rack1SW1#sh spanning-tree interface f0/1 portfast
      VLAN0123 enabled

      show run for int sw 1 f0/1

      Rack1SW1#sr int f0/1
      Building configuration…

      Current configuration : 109 bytes
      !
      interface FastEthernet0/1
      switchport access vlan 123
      switchport mode access
      spanning-tree portfast

      AFTER

      Rack1R1(config)#bridge 123 protocol ieee
      Rack1R1(config)#bridge 123 priority 0

      Rack1R1(config)#int f0/0
      Rack1R1(config-if)#bridge-group 123

      Rack1SW1#sh spanning-tree interface f0/1 portfast
      VLAN0123 disabled

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    15. Diya says:

      Hi Marco,

      For simple summary, we can say that after a port received a bpdu the chain of reactions will be:

      pbdufilter interface> pbdugurad interface > pbduguard global > bpdu filter global. :)

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    16. vat says:

      portfast:
      * two modes of operation ( Global level and interface level)
      * can Send & receive BPDU on the port
      * Assume the end device doesnt need to send BPDU ( In ideal situation)
      * The portfast status is lost if a BPDU is received on the port

      BPDU Guard
      * 2 modes of implementaion ( global level and interface level)
      * error disables a port if BPDU is received on the port
      * used with portfast at global level

      spaning-tree portfast default
      spaning-tree bpdu-gurad default
      * can be used without portfast @ interface level

      BPDU Filter

      * 2 modes of operaion ( Global level and interface level)

      * gloablly used with portfast ( does send couple of BPDU but recieve BPDUs on the port. if BPDU is received ,the portfast status and BPDU filter is disabled)

      * if used @ interface level doesnt send or receive BPDUs

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    17. Rafael says:

      Marko, this has been very useful. However, I found that your statement regarding PORTFAST, “On the other hand, enabling portfast feature on the port itself is unconditional. Regardless of any BPDU being received, port will remain in portfast state. “, is not actually accurate.

      Have you replicated this??

      Here is my setup:

      I am using two swtiches interconnected as below:

      C3560 (Fa0/1) ——- (Gi0/1) C2960G
      (Fa0/2) ——- (Gi0/2)

      Fa0/1 is sending BPDUs; Fa0/2 is not sending BPDUs

      When i configure portfast on the Gi0/1 *interface*, I am getting exactly the same behaviour as when enabled globally; i.e. the portfast feature gets disabled autoamtically.

      On the 3560 I have the following config:

      Current configuration : 76 bytes
      !
      interface FastEthernet0/1
      description *** SUPPOSE TO SEND BPDUs ***
      end

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    18. Richard says:

      first question:
      I noticed that why the link of the two switches both are desgnated? supposedly, one is root and the other is designated.

      Second question:
      if bpdu filter is enabled on port and it means disable spanning-tree. How can loop occurs if the port never receives nor sends bpdu?

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)

    Leave a Reply