01-19-2006 12:47 AM - edited 03-03-2019 01:29 AM
Hi all
I am going thru some configuration of switches in a ring topology. Running MSTP and RSTP.
I was surprised to see that thE uplinks to adjacent switches are configured with "spanning-tree portfast trunk". Cisco guidelines are pretty clear on the use of this command.
What I cannot figure out is how and why are these ports forwarding.
"sh spanning-tree interface gigabitEthernet 1/0 portfast" shows portfast is disabled for all MST's.
Does this reduce RSTP convergence when it has to recalculate ?
TIA
sAM
Solved! Go to Solution.
01-19-2006 05:39 AM
It is quite clear what cisco says is to be done, I'm guessing there's probably a reason why they do not encourage us to use portfast on interswitch comm.
01-19-2006 02:57 AM
As far as I am aware, uplinkfast is to be used for switches, and portfast ONLY for access drops. Can you detail a little more what you are seeing?
01-19-2006 04:02 AM
Hi William
I agree !
What I am seeing as I described. An uplink configured with porfast trunk. I would have expected teh interface to be disabled as a result since it would be reciving BPDUs and it is not meant to. However.
My other concern is if I am wasting more time than necessary if RSTP needs to converge.
TIA
Sam
01-19-2006 05:39 AM
It is quite clear what cisco says is to be done, I'm guessing there's probably a reason why they do not encourage us to use portfast on interswitch comm.
01-19-2006 09:47 AM
Portfast trunk, as its name implies, enable portfast on trunks. We had to introduce the "trunk" keyword because portfast would only be effective on access ports (i.e. non-trunks) and there are some cases where you want portfast on trunks (on a trunk that connects to a router for instance).
Portfast is to be configured on edge ports (that's the IEEE terminology btw). An edge port basically leads to hosts that operate above layer 2 (routers, servers, etc...). Because an edge port cannot introduce a bridging loop in the network, there is no need to wait before putting the port to forwarding. Configuring portfast on your trunk will just simply put it to designated forwarding as soon as it comes up. The feature in fact only has an effect at link up. Well, there is a secondary side effect of portfast: a portfast port does not generates TC.
Since MST and RSTP, portfast has now an operational and a configured value. Basically, as soon as a port receives a BPDU, it loses its portfast status because it is obvioulsy connected to a bridge. That's probably why you are saying that the show commands display portfast as disabled: it is configured, but operationally disabled.
This will not prevent the port from going to forwarding. Portfast does not disable STP, it's just again modifying the behavior at link up.
In theory, if there is no redundancy in the network (ie no physical loop), you could enable portfast everywhere. Actually, you could completely disable STP;-)
However, in your lord of the ring scenario, it is not appropriate and you could end up with transient bridging loops. I guess that the engineer who configured this on the trunk was desperately trying to speed up the convergence of the ring.
Regards,
Francois
01-19-2006 12:12 PM
I totally agree !
This confirms my understandig of the command guidelines...next challenge convince the Engineer to remove it :-)
Many thanks
Sam
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide