Re: STP Blocking state on port up time

Hi Joe

Not sure this answers all your questions but here's my notes from portfast caveats:

RSTP IEEE 802.1 w

-by default switch ports facing hosts or servers are automatically placed in the edgePort state because the switch does not see any BPDUs comming on those ports.
-when we globally configure portfast default we ensure that the all the access ports are transitioned to edge port p2p status.
-port states transition from Discarding,Learning,Forwarding (+Alternate & Backup) so we enable the edge ports to go straight to Forwarding
-If a bpdu is received it will lose edge port status and go through the above states to ensure a loop free topology
-If the port flaps with a link-down it will not create a TCN

STP IEEE 802.1 d

-By default all ports go through the STP states Disabled,B locking, Listening, Learning,vForwarding if we configure portfast globally then access ports go straight to Forwarding p2p status
-If a bpdu is received on portfast enabled port it will remain in forwarding (hence the need for guard or filter to prevent loops)
-if the port flaps with a link-down it will create a TCN (sent to the root bridge who will notify the other bridges to flush their cams using the hello_timer)
-as a side note blocking ports rely on the reception of bpdu's if none are received it can cause a loop as it transitions through the STP states again potentially going into forwarding state (use a technique to combat)

This was the behaviour I made notes on when I debugged on the 3560 access switch running 12.2 (44) SE6 like you say it could very well be platform dependant certainly the texts all talk about 802.1d going through Disabled, Blocking, Listening, Learning, Forwarding

--
BR
Tony
Sent from my iPhone on 3
> On 10 Oct 2013, at 17:15, Joe Astorino <joeastorino1982_at_gmail.com> wrote:
> 
> So the topic of discussion is if an interface actually STARTS in blocking
> mode when a port is turned up.  My previous studies led me to believe an
> interface coming up goes DIRECTLY to listening state, followed by learning
> and forwarding, yielding a total convergence time of exactly 30 seconds.
> Some other labbing and documentation seems to contradict this IN CERTAIN
> CASES
> 
> Documentation and some Cisco press books mention an interface always starts
> in blocking. Others, like the old cat 4000 guide indicate it starts in
> listening.
> 
> Lab tests are mixed.
> 
> - If portfast is NOT enabled, "debug spanning-tree events" never mentions
> anything about blocking.  It simply says it transitioned the port to
> listening.  The question becomes what did we transition from ?
> 
> - If portfast IS enabled, we actually see in the debug that it "jumped from
> blocking to listening", although this happens almost immediately
> 
> - The other interesting thing is that on some switches I tested with there
> is a period of up to 5 seconds from the moment you hit enter to the moment
> it transitions to listening state. On other switches it's immediate.  The
> question becomes, is that 5 seconds "blocking" state or something else?  My
> thought there is it could be just port initialization, DTP, auto
> negotiation, etc.
> 
> So definitively, can anybody really say if when a port first initializes it
> does or does not technically pass through the blocking state or if it
> actually starts in listening? Perhaps there is an answer alluding me, or
> perhaps it is truly platform dependent.
> 
> 
> -- 
> Regards,
> 
> Joe Astorino
> CCIE #24347
> http://astorinonetworks.com
> 
> "He not busy being born is busy dying" - Dylan
> 
> 
> Blogs and organic groups at http://www.ccie.net
> 
> _______________________________________________________________________
> Subscription information may be found at: 
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net