Does portfast disable Spanning-Tree?

Lessons Discussion
1

This topic is to discuss the following lesson:

4

Hi Rene,

I realized when you show
SW1#show spanning-tree interface FastEthernet 0/24 detail

q1) The “bpdu receive” is 0 - why ? ( non-root bridges do not send bpdu to root bridge ?)

q2) What is the difference between “P2P Edge” and “P2P” ? What do that actually meant ?

q3) Do we use portfast on ports that we are sure will not cause a loop ?

Regards,
Alan

5

Hi Alan,

  1. With PVST, BPDUs are relayed from the root bridges down the tree to other non-root bridges.
  2. P2P Edge means that portfast has been enabled. Portfast enabled interfaces don't trigger a TCN. Take a look at the portfast tutorial here, I explained it there.
  3. That's right, Cisco IOS warns you when you enable it on interfaces. It doesn't disable STP though so it's not like you will have permanent loops.

Rene

6

Hi all,
i have a port in access but from the output i see that port is in blocking:

interface GigabitEthernet5/0/47
 switchport access vlan 201
 switchport mode access


show spanning-tree vlan 201 blockedports
Name                 Blocked Interfaces List
-------------------- ------------------------------------
VLAN0201             Gi5/0/47


Port 431 (GigabitEthernet5/0/47) of VLAN0201 is backup blocking 
   Port path cost 4, Port priority 128, Port Identifier 128.431.
   Designated root has priority 24777, address 00be.758e.31c0
   Designated bridge has priority 24777, address 00be.758e.31c0
   Designated port id is 128.430, designated path cost 0
   Timers: message age 16, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   Link type is point-to-point by default
   BPDU: sent 2644, received 3230774

Can you explain me that?

thank you

7

Hello Valero

Spanning Tree doesn’t only apply to trunk ports, but is also active on access ports as well. So it is perfectly normal to see access ports in the blocking state. This is the case even if you’re using portfast, as shown in the lesson.

In this particular case, GigabitEthernet5/0/47 is actually a backup blocking port. This is a port state that we see when we use Rapid Spanning Tree. A backup blocking port will be used when there are two or more physical links between two switches. More about the backup port state can be seen at the following lesson:

I hope this has been helpful!

Laz

9

Hi, if portfast doesn’t disable spanning-tree we should always see BPDU’s on this interface.
Even when we connect an unmanaged switch to an access port ?
Do we need a BPDUGuard in order to block the port when a BPDU is received or does spanning-tree still do its job and block the port in case of a loop ?

Thanks,
Oliver

10

Hello Oliver

In order to be clear, let’s define what it means to “disable spanning tree”. You can achieve this by either using the global no spanning-tree vlan x command on a particular VLAN or on all VLANs by simply issuing the no spanning-tree command. The result is that no BPDUs will be sent or received on the specified VLAN, or on the switch as a whole. These commands are configured globally.

Secondly, you can use the BPDUfilter feature to prevent BPDUs from being sent from a specific port, and causes the port to ignore any incoming BPDUs. This essentially disables STP on this interface.

So disabling STP essentially means that outgoing BPDUs are disabled, and incoming BPDUs are ignored.

So yes, any port that has portfast enabled will still send out BPDUs, even if an unmanaged switch is connected to that port.

Portfast and BPDUGuard are two different but interrelated features:

  • Portfast will allow a port to go directly to the forwarding state when connected
  • BPDUGuard will cause a port to shutdown if a BPDU is received

Portfast and BPDUGuard should be used together, and by default, any port that is configured using Portfast will have BPDUGuard enabled. This ensures that layer 2 loops will not be created accidentally on ports that are used to connect to hosts.

I hope this has been helpful!

Laz

1 Like
11

Hello Laz,
thanks a lot !
“by default, any port that is configured using Portfast will have BPDUGuard enabled”
but that only appplies if BPDUGuard is enabled globally (spanning-tree portfast bpduguard default) . If this is not set, than BPDU Guard needs to be set per interface (spanning-tree bpduguard enable).

Assume you have following scenario:

DistriSW1 - AccessSW1 - UnmSW1 - User Ports
DistriSW1 - AccessSW2 - UnmSW1 - User Ports

The question is what is the unmanaged switch (UnmSW1) doing with the BPDU’s in this scenario ?

I see here 2 choices:

  1. The Unmanaged switch doesn’t process BPDU’s at all and discards them and also doesn’t forward it (not transparent forwarding).
    —> In that case it is a good idea to have BPDU guard enabled on the managed switch.

  2. The Unmanaged switch doesn’t participate STP, but transparently forwards the BPDU’s.
    —> In that case we wouldn’t need BPDUGuard. In fact it would block the ports on the managed Access Switch (AccessSW1 / AccessSW2 ) and no traffic can flow… which is also not desired :slight_smile:

According to Peter at https://community.cisco.com/t5/switching/portfast-to-non-managable-switch/td-p/1715877 the unmanaged switch could be transparent to BPUD’s.

Thanks again,
Oliver

12

Hello Oliver

Yes, you are correct.

This depends upon the unmanaged switch. You see, some higher-end unmanaged switches run STP. This STP cannot be disabled, it just runs, and is typically configured with default STP values. If this is the case, it will process BPDUs like an STP-enabled switch. If however, your unmanaged switch does not run STP, then it may do one of two things:

  1. Just forwards BPDUs like it forwards any other Layer 2 frames. BPDUs have a destination MAC address of 01 80 c2 00 00 00, which is a multicast address reserved for use with STP. But because it’s multicast, it will simply be sent out all other ports.
  2. If the unmanaged switch is smart enough, it will realize this is a BPDU and will simply block it. This is unlikely, however, although it may choose to be implemented by the manufacturer of the switch.

So if the unmanaged switch doesn’t run STP, then yes, it is most likely transparent to BPDUs, so it simply forwards them. If it runs STP, it will process them normally. In any case, it is best not to mix unmanaged with managed switches. However, because this is often necessary (I’ve done it countless times :innocent:) it is best NOT to configure portfast on the Cisco switch port connected to the unmanaged switch. Treat it like any other switch to switch connection.

I hope this has been helpful!

Laz

1 Like
13

This may be more to do with the spanning tree lesson than portfast but as it was mentioned earlier here I thought I ask the question here.
In relation to the question and answer below:

I just have a quick question in relation to Rene’s answer to the above question.
I agree with “With PVST, BPDUs are relayed from the root bridges down the tree to other non-root bridges.” as this makes sense with old style spanning tree (pvst) but I always thought with RAPID PVST that ALL switches sent BPDU’s every two seconds whether they are the root or not.
I have looked around my network and I can see that even though I am running Rapid pvst everywhere when I look at the interfaces that are not blocked and up and connecting to the root, the BPDU’s are showing as only incrementing coming from the root and the non-root switches don’t seem to be sending bpdu’s towards the root.
I have checked the ports and as expected they are NOT edge ports.
What am I missing here ? I always thought in rapid spanning tree that even non root bridges sent bpdus every two seconds ?

14

Hello Sean

You are correct that RSTP (which is the same as RPVST+) will have every switch send BPDUs. In the RSTP lesson, Rene states that:

BPDUs are now sent every hello time. Only the root bridge generated BPDUs in the classic spanning-tree and those were relayed by the non-root switches if they received it on their root port. Rapid spanning-tree works differently…all switches generate BPDUs every two seconds (hello time). This is the default hello time but you can change it.

Now having said that, the output of the show spanning-tree interface detail command should indeed show BPDUs both incoming and outgoing. However, I suspect that one of the following is taking place:

  1. The output of this command may only count BPDUs that are generated by the root bridge. It may be that the command is rigged that way. And that would make sense because that is the important bit of info for troubleshooting. Also, as the lesson above states, this new BPDU is called a version 2 BPDU, and includes additional flags that tell it the port role, via which it can be discerned if it is a BPDU from the root or from another non-root switch. Although I did do some research, I was unable to find any documentation supporting this, but this is one possibility.
  2. Although unlikely, we always have to examine the possibility that RSTP is correctly configured. Remember, RSTP is backward compatible with STP, so if it falls back, it will behave like STP.

In order to determine the reality of the situation, I suggest you set up a Wireshark capture to see if you get BPDUs going in both directions. This will completely clarify the situation. If you do so, let us know of your results!

I hope this has been helpful!

Laz

15

Hi Laz,

I searched several other forums on this and its not well documented but it seems from what I’ve been able to find is that root ports don’t send BPDU’s unless there is a topology change.
This is totally news to me.
I have a huge production network and all switch ports are showing the same in that BPDU’s are not being sent towards the root and are only getting sent to the root in the case of a Topology change.
I even just labbed this up here at home on a few switches also just to be sure and its the same in that the BPDU’s aren’t incrementing on the port towards the root.
All switches in production and in my lab are running rapid pvst+
I double checked all this under show spanning tree summary command.

16

Hello Sean

Rapid PVST+ does indeed send BPDUs out of designated and root ports every hello time, as detailed in this documentation:

Although it is based on a Nexus device, the logic is the same.

The issue you are seeing depends upon the way in which you are measuring the BPDUs on the interfaces. Rapid PVST+ BPDUs are different from regular STP BPDUs. How are you counting the BPDUs on your interfaces? Could it be that you are counting only legacy BPDUs and not RPVST BPDUs?

I suggest you also use Wireshark to capture such traffic and see all the control packets that are being exchanged, to verify your observation.

Let us know how you’re counting those, and we can help you troubleshoot further.

I hope this has been helpful!

Laz