Portfast on access switches

[jasonsalomons]

So, I've been retouching up on my spanning tree knowledge and I was wanting to know how others in their own networks are deploying portfast on their access switches.

Firstly a quick question: Does globally enabling portfast spanning-tree portfast default turn a portfast port back to a traditional port should it received BPDUs?

Also what happens to a port when portfast is configured per interface only (rather than globally) and that port receives BPDUs from a connected switch? Does that port default back to listening/learning etc like it does under the global command or remain a portfast port?

I was reading up here: https://learningnetwork.cisco.com/thread/33283

and this comment was posted:

The most commonly deployed configuration I see these days is for the use  of PortFast in conjunction with BPDUGuard. Should there be a rogue  bridge introduction in the network, the error-disabled state and the  subsequent administrator notification is preferred to any other  automated response a layer 2 feature can introduce.

and also this comment:

I also like to set the errdisable recovery feature to re-enable the ports after a short period of time, like 60 seconds:

errdisable recovery interval 60

errdisable recovery cause bpduguard

So I would like to know how others are implementing portfast SAFELY in their own production networks (not lab enviroments). It might be worthwhile advising whether the commands you are using are configured at interface level or global level as they have two very different outcomes!).

[Reza Sharifi · Accepted solution]

Enabling portfast on switches in production is not harmful, as it will not disable spanning tree on the ports.  I usually use the interface range command and enable it on the access ports I want and not globally.  Globally works fine too, but sometimes you connect an access port to another switch with portfast enabled can cause loop in the network.

HTH

[jasonsalomons]

Thanks Reza, I read somewhere that configuring portfast only in global config has a differnent outcome than when it is configured only per interface so I've made some changes to my orignal wording to get a clear answer on portfast:

Does globally enabling portfast spanning-tree portfast default turn a portfast port back to a traditional port should it received BPDUs? (i assume YES)

Also what happens to a port when portfast is configured per  interface only (rather than globally) and that port receives BPDUs from a  connected switch? Does that port default back to listening/learning etc  like it does under the global command or remain a portfast port? If yes like the global command, is this common across all platforms, IOS versions etc?

According to this blog here, portfast on a global level, and on a port level have two very different outcomes:

http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/

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.

I would like to test this hopefully this week but am sitting for SWITCH before I am going to get a chance to lab it up.... grrrrrr.

[Peter Paluch]

Hello Jason and Reza,

According to this blog here, portfast on a global level, and on a port level have two very different outcomes:
 http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/
On the other hand, enabling portfast feature on the port itself is unconditional

That blog is outright wrong on this topic. Even if a PortFast is enabled directly on a port, it is not unconditional. If a port receives a BDPU even though it is configured via spanning-tree portfast, it will lose the PortFast operational status and will become a normal non-edge port. The command will not be removed from its configuration, just the operational state of the port move from edge to non-edge. This can be trivially demonstrated using the show span int XXX portfast command - it will either report the PortFast as enabled or disabled on a port.

The 802.1w (now 802.1D-2004) RSTP standard has explicit provisions that  cause an edge port move to non-edge operation if it receives a BPDU. Since PortFast is Cisco's implementation of edge/non-edge, it must behave as mandated by the standard.

I totally agree with Reza that if access ports are connected to other switches, it is best to activate PortFast only on a per-port basis. However, networks I have worked with always interconnected switches using trunks, so in those cases, I strongly vouch for using spanning-tree portfast default global config command. Especially in RSTP networks, properly configuring edge ports is crucial, otherwise the network's performance may be even worse than with STP.

Best regards,

Peter

[jasonsalomons]

Thanks Paul for clarifying. It seems there is alot of confusion regarding portfast, bpdugard, and bpdufilter across the internet and people give out false information which doesnt help those learning.

One other thing I'd like to clarify - is the below statetment incorrect?

BPDU Filter (Global): This depends on/is an add-on to the global configuration of Portfast.

Personally I would say that it doesnt matter if portfast is enabled globally or interface level when it comes to BPDUfilter but what is more important is where BPDUfilter is applied (ie Global or Interface) as these do different things.

Thanks,

Jason

[Peter Paluch · Accepted solution]

Hi Jason,

I don't want to hijack Reza's thread - on the other hand, I am myself seeing a lot of confusion regarding exactly these topics. Allow me to summarize them as I know them.

PortFast

• Can be activated either on port using spanning-tree portfast or globally using spanning-tree portfast default
• Regardless of how it is activated, it applies only to access ports
• If a trunk is to be configured as PortFast (only towards routers, firewalls, routers, etc., never towards switches!), the spanning-tree portfast trunk port level command has to be used
• Regardless of how it is activated, a PortFast-enabled port that receives BPDU loses its operational PortFast status and becomes a non-PortFast port until disconnected or shut down
  • There appears to be an exception to this rule for IOSes that support only STP/PVST and no RSTP/PVRST/MST, such as router images run in Dynamips. In these IOSes, the PortFast configured on a port indeed seems to be persistent even if BPDUs are arriving. The CCNP SWITCH exam, however, is concerned with current hardware switches that support STP/RSTP/MSTP, so this exception should not be taken into consideration for the purpose of the exam - it is mentioned here just for completeness.

BPDUGuard

• Can be activated either on port using spanning-tree bpduguard enable or globally using spanning-tree portfast bpduguard default
  
• If activated on port, applies to that port immediately
• If activated globally, applies only to PortFast ports (regardless how they got into PortFast mode)
• Regardless of how it is activated, a BPDUGuard-protected port that receives BPDU will be immediately err-disabled

BPDUFilter

• Can be activated either on port using spanning-tree bpdufilter enable or globally using spanning-tree portfast bpdufilter default
• If activated on port, applies to that port immediately and causes the port to stop sending and receiving BPDUs unconditionally. A BPDU received on such a port will be silently dropped with no further action. In particular, because the BPDU is dropped, neither BPDUGuard nor PortFast will react on this port even if configured because the BPDU will be dropped before it can be processed by these two features.
• If activated globally, applies only to PortFast ports (regardless how they got into PortFast mode) and causes these port to stop sending BPDUs after approx. 10-11 sent BPDUs. A BPDU received on such a port will cause the BPDUFilter to become operationally disabled on that port (i.e. the port will start sending BPDUs as dictated by usual STP rules) until the port is disconnected or shut down. Notice that because in this case, BPDUFilter was activated on this port in the first place because this port was also a PortFast port, receiving a BPDU will also cause the port to lose its operational PortFast status per the explanation of the PortFast behavior above. If this port was additionally protected by BPDUGuard, it would be err-disabled immediately.

Would this help?

Best regards,

Peter

[jasonsalomons]

Hi Peter,

Thank you for the detailed reply. The information you have provided confirms my understanding of these features which is exactly what I was hoping for (and in time for my upcoming SWITCH exam).I hope others can beneift from this information as well.

I think I have managed to spend the last several hours reading to discount other's misinformation which is very frustrating as you can imagine as there are a few other topics I need to brush up on.

I have just two quick questions - do you personally enable bpduguard globally within your network on a portfast port or are you happy to allow the port to come up into listening/learning mode?

And if portfast is enabled and a BPDU is received which transitions the port to non portfast, does this generate a event in the log?

Regards,

Jason

[Reza Sharifi]

Hi Jason,

do you personally enable bpduguard globally within your network on a portfast port or are you happy to allow the port to come up into listening/learning mode?

As Peter correctly said, you can enable it globally if you know for sure you don't have any access port connecting to other switches, but I like to be specific and enable it where I want it. One of the reasons I like to do it per interface is that if some one connect a switch to the network and configure the port as access, I don't have to worry about loop in the network. If you do it per interface, there is more manual process involved.  Another word, if some one connect a switch to the network, they also have to enable portfast on that port to cause loop, vs with global it is already there.  It all comes down to a matter of preference and your environment.

here is ample port config:

end

*Mar 11 17:54:00.906: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/2, changed state to up

*Mar 11 17:54:01.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/2, changed state to up

interface GigabitEthernet1/0/1
spanning-tree portfast
spanning-tree bpduguard enable
end

if portfast is enabled and a BPDU is received which transitions the port to non portfast, does this generate a event in the log?

I tested this and the only thing I saw in the log is this:

*Mar 11 17:54:00.906: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/2, changed state to up
*Mar 11 17:54:01.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/2, changed state to up

HTH

[Peter Paluch]

Hi Jason,

To add to Reza's answers:

I have just two quick questions - do you personally enable bpduguard  globally within your network on a portfast port or are you happy to  allow the port to come up into listening/learning mode? 

I am not sure if I understand you here, as BPDUGuard does not directly relate with "coming up into listening/learning" states. Perhaps you meant PortFast here?

Anyway, I do tend to use both span portfast default and span portfast bpduguard default as originally noted. And Reza's comment is absolutely correct. In a well maintained network where you know what you're keeping inside, either approach will do - just be sure you know what you are doing.

And if portfast is enabled and a BPDU is received which transitions  the port to non portfast, does this generate a event in the log?

It does not generate any logs to my best knowledge, and I have not come across any configuration command that would cause these events to be logged, sadly. Any Cisco engineer reading this? It would be a good feature enhancement request!

Best regards,

Peter

[jasonsalomons]

Peter Paluch wrote:
Hi Jason,
To add to Reza's answers:
I have just two quick questions - do you personally enable bpduguard  globally within your network on a portfast port or are you happy to  allow the port to come up into listening/learning mode? 
I am not sure if I understand you here, as BPDUGuard does not directly relate with "coming up into listening/learning" states. Perhaps you meant PortFast here?

Sorry Peter, it was my way asking whether in your network you have BPDUGuard enabled? Ie without it configured and portfast enabled only, the portfast port will go back through the stages of LIS/LRN etc when a switch is connected.

I did get a chance to connect a couple of switches to verify BPDUguard this morning and did receive it in my logs (with logging informational) when configured globally or per interface.

00:04:20: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

00:04:22: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet0/1 with BPDU Guard enabled. Disabling port.

00:04:22: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/1, putting Fa0/1 in err-disable state

00:04:24: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down

[Leo Laohoo]

I have just two quick questions - do you personally enable bpduguard globally within your network on a portfast port or are you happy to allow the port to come up into listening/learning mode?

In our network, all access ports have STP PortFast and BPDUGuard enabled.  I also make sure that we do NOT enable "errdisable recovery cause bpduguard".  This command is THE MOST IMPORTANT of them all.  Because if you have this command then you, as a "network engineer" should be thrown off the cliff, into the sea and wearing a pair of concrete "shoes".

[Peter Paluch]

Hi Leo,

You're so adamant about not enabling the errdisable recovery cause bpduguard Have any personal experience, or a good story to tell?

Best regards,

Peter

[Leo Laohoo]

Have any personal experience, or a good story to tell?

Queue the opening tune from the "Godfather".

Yeah.  We had someone configure this and we had "fun" times trying to figure out where the STP loop was coming from.

It took hours crawling through each config and when we found it, we went "Gotcha, you SOB!" so we got rid of the command ... a few hours later another loop.  So we all looked at each other and went, "Please don't tell me the ding-a-ling configured MORE of the same command?".  And, yes, he did.

Like I said, "fun" times.

Since then, I've learned to look for this command and take it out immediately.  All my Zero-Touch templates have the "no errdisable recovery cause bpduguard".  Just to be sure.

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Leo Laohoo wrote:
Queue the opening tune from the "Godfather".

Hmm, let me guess and if you only want to "warn" another network engineer, they might wake up with a severed supervisor card next to them in their bed.  Of course, it's nothing person, just business.

[Leo Laohoo]

they might wake up with a severed supervisor card next to them in their bed.

He sleeps with da fish with his newly mixed Christian Di0r concrete shoes.