portfast to non managable switch

[vipinrajrc]

Hi Experts,

Recently i have found that in one of the switches in our environment, portfast enabled to a interface whichis connected to a non-managable switch.

But 3 servers are conencted to that non-managable switch.

Since this switch is connected to only servers, there wont be any problem, right??

Thanks

Vipin

[Jon Marshall]

Vipin

You should not enable portfast on any link between switches. Even if there is only one link at the moment if someone connected another link between the 2 switches there could well be an STP loop formed.

You should remove portfast from that config.

Jon

[vipinrajrc]

Hi,

But the second switch is non-managable switch. So do i need to remove portfast. also some servers are connected to this non managable switch

Thanks

Vipin

[Jon Marshall]

Vipin

Just to add to Peter's post. Just because it is unmanaged does not mean can enable portfast. A switch is still a switch whether it is managed or unmanaged.

Jon

[Peter Paluch · Accepted solution]

Jon, Vipin,

Jon is of course correct about the fact that the PortFast towards another switch should not be enabled.

I see two aspects to this issue: first, whether it will work correctly in your network exactly as-is, and second, how will it react to several what-if scenarios.

In your current network in the precise state it is now, with that unmanaged switch having a single uplink to the managed upstream switch, and having a number of non-looped links to devices that do not perform Layer2 switching/bridging among themselves, using the PortFast does not create any issues.

If we start thinking about what-if scenarios (what if another uplink is connected to the upstream switch, what if somebody connects a cable and inadvertently or deliberately creates a physical loop, what if the servers are interconnected and configured with some sort of bridging), certainly, the PortFast is absolutely inappropriate as it will allow at least transient switching loops to occur, and it is not clear if the managed switches will have enough CPU power to recover from the loop after it starts flooding frames all over the network.

So I would personally put it this way: It is not a recommended scenario, and it is not a best practice approach. Then again, in a tightly controlled environment, it is just like any other powerful tool that either helps you make things work better, or will come back haunting you if used improperly. It is up to you to decide if the benefits outweigh the risks involved. In any case, having an unmanaged switch alone is a risk enough.

This reminds me strongly of how we were told strongly on my classes of programming not to use the GOTO command. Sure, it allows all kinds of bad things to do. However, there are certain situations where a judicious usage of GOTO command simplifies the resulting code complexity and memory footprint significantly. You could find the GOTO statement used quite often in Linux kernel code, for example - and surely, Linux kernel coders are by no means lamers in C programming. It is simply about knowing exactly what advantages, disadvantages and risks does it involve to use such powerful mechanism. The PortFast towards a single unmanaged switch is, in my opinion, quite a similar story.

Best regards,

Peter

[Jon Marshall]

Peter

Interesting points but i would argue the case slightly differently. Why would you not disable portfast on that link ie. what do you gain from having it there especially considering there are servers attached to the switch ?

The obvious answer is you gain immediate forwarding as opposed to having to wait for 45 seconds with traditional STP. But i'm not sure how this is an advantage in Vipin's scenario. Even if it was an advantage it would in my opinion be vastly outweighed by the potential disadvantage of creating an STP loop. I have seen an STP loop take down a whole DC simply because of a misconnected cable. The DC was under tight control but unfortunately it was a server guy who ended up creating the problem. You can imagine we tightened them up even more after that

As you know from my posts i very very rarely state that there is anything you must do in a network but i do feel in this case that enabling portfast on a switch interconnect link just doesn't make sense.

Jon

[Peter Paluch]

Jon,

I absolutely agree with everything you have said. I think that we have come to a point here where we both understand the arguments of each other and we know that it works this or the other way around. It is probably just our inner preferences and attitudes to best practices and make-it-safe approach. It probably follows from my inexperience in real life, as I've complained a few times already.

There is however one thing to consider: even without PortFast, if somebody creates a physical loop on the unmanaged switch, the ensuing broadcast/multicast/unknown unicast storm can be perfectly propagated through the normal STP port on the managed switch to the remainder of the network. It will not loop in the STP-protected part but will still be delivered there. Considering this, having the PortFast enabled or disabled does not seem to make much of a difference here.

My concluding remark to all of this... Jon's approach is perfectly safe, and when following it, nothing can get seriously wrong. It is a best practice and how things should be done. What I have suggested is an inherently unstable configuration that provides one single benefit - a quick transition of the link between the managed/unmanaged switch to the forwarding state, and apart from that, it has lots of possible issues. Generally, what I have suggested can not be recommended.

Sorry to initially confuse you, Vipin. I suggest you follow Jon's recommendation and deactivate the PortFast towards your unmanaged switch. Jon, thank you for being so clear about your thoughts!

Best regards,

Peter

[Jon Marshall]

Peter

Apolgies, perhaps i did come across a bit strongly, it's just that of all my network experience, an STP loop is probably the one that gives me most nightmares

One thing i am not understanding though, and perhaps this means i didn't follow your argument correctly is your statement -

There is however one thing to consider: even without PortFast, if somebody creates a physical loop on the unmanaged switch, the ensuing broadcast/multicast/unknown unicast storm can be perfectly propagated through the normal STP port on the managed switch to the remainder of the network.

are you assuming that on an unmanged switch STP would not be running ?  If not then perhaps my knowledge is lacking as you have a very good understanding of STP but i thought STP was enabled by default so as soon as you made the second connection STP would have to recalculate and place one of them in blocking.

Am i misunderstanding (very likely )

Jon

[Peter Paluch]

Jon,

No apologies necessary at all! You were perfectly okay and you have stated your point always in a most polite manner.

are you assuming that on an unmanged switch STP would not be running ?

Yes, that is my assumption. An unmanaged switch does not run STP, although it is transparent to STP BPDUs. I have not seen an unmanaged switch run STP.

The scenario I was talking about is having a single uplink from the unmanaged switch to the managed switch, and creating another physical loop that starts and ends solely on the unmanaged switch. Obviously, this loop would not be blocked on the unmanaged switch because it does not know how to do it. Now imagine one of the servers sent a broadcast. This broadcast would be received by the unmanaged switch, and because of the loop, it would be endlessly propagated through all other ports, including the uplink up to the managed switch and further into the network.

This propagation would obviously be cut off after up to 2 seconds - as the managed switch sends its BPDUs, they would also be caught in a loop and get received by the same port on the managed switch that sourced them. STP would then place the port in a "broken" (self-looped) discarding state. Eventually, the port could even be placed into err-disabled state if also the LOOP frames would be looped back. During those 2 seconds, however, the network is unprotected - and if there were enough broadcasts to kill off the CPU on the managed switches, it is then probable that it would not be able to even process the BPDUs that got looped, and block the port.

Best regards,

Peter

[Jon Marshall]

Peter

Yes, that is my assumption. An unmanaged switch does not run STP, although it is transparent to STP BPDUs. I have not seen an unmanaged switch run STP.

Ahh, that is where we were coming at it from a different perspective i think. I was assuming unmanaged simply to be a switch that was not configured with an IP address etc. but i still assumed it was running STP, hence my argument.

Yes, if the switch is not running STP then as you say the portfast issue is not particularly that relevant.

Jon

[Peter Paluch]

Jon,

Yes, if the switch is not running STP then as you say the portfast issue is not particularly that relevant.

Exactly, that was my point. If I knew the "unmanaged" switch was able to run RSTP then I would absolutely mandate running it and removing the PortFast, because the Proposal/Agreement would provide the fast convergence.

But after all this, I really think that you have made a better point with not configuring PortFast towards other switches. It is simply a safe-bet. Thanks for that!

Best regards,

Peter

[Peter Paluch]

Hello Vipin,

In your current setup, there is no physical loop and hence there should be no issues - and in fact, it is the only way for a fast convergence between your manageable switch and the other unmanaged switch. Just make sure that entire physical setup is tightly controlled and that all modifications to the physical topology are thoroughly inspected so that they do not create a physical loop.

In future, it would be best to plan to replace the unmanaged switch with a managed switch supporting RSTP and MSTP. This will prevent you against loops and at the same time provide fast convergence.

Best regards,

Peter