Portfast port VS Edge port

Ok, I'm watching the STP intruction video for CCIE R&S (video 20) and I can't seem to get the difference between these 2 port roles. 

 

Brian begins to state that they are the same, but work differently. When watching the video further, it does not become clear to me what the difference exactly is between a portfast port in Normal STP and an edge port in Rapid STP. I know that you configure them with them same command, but I'm not getting the difference...

 

- An Portfast port in Normal spanning tree wil always stay in that state and not transition into somehting else when BPDU's are received??

- An Edge port however will change from edgeport and will participate in STP calulation??

 

Did I get that right?

 

«1

Comments

  • I don't know of any different between Edge port and Portfast (other than the different states that 802.1w uses in place of 802.1D).  I guess Edge port disables the proposal feature of 802.1w otherwise there would be a delay in forwarding.

     

    Portfast will also lose the portfast status when BPDUs are received.  

     

    Nick

  • Edge ports are used in RSTP. The way to define an edge port on Cisco devices is to use spanning-tree portfast. They just decided to reuse that command instead of creating a new one called spanning-tree edge or such.

  • Unlike PortFast, an edge port that receives a
    BPDU immediately loses edge port status and becomes a normal spanning tree port. There is no additional key differences between these features.  All ports
    directly connected to end stations cannot create bridging loops in the network.
    Therefore, the edge port directly transitions to the forwarding state, and
    skips the listening and learning stages. Neither edge ports or PortFast enabled
    ports generate topology changes when the link toggles. Once we are able to work with portfast, it can be eaily migrated to RSTP.

    Hope this helps!

  • Portfast is also lost if a BPDU is received.

     

    Nick

  • Hi Martin,

    It doesn't loose its portfast status. You can try this enabling portfast on two switches and connecting each other. You will see the loop if you have connected it redundantly because it skips the important steps of spanning tree i.e. listening & learning.

    So, it can be harmful to configure this feature on trunk interfaces where we have multiple uplinks.

    Good luck!

  • Here Martin

     

    This is from real gear

     

    SW1 connected to SW2 on port f0/15

     

    Both lose portfast:

    interface FastEthernet0/15

     switchport mode access

     switchport nonegotiate

     spanning-tree portfast

    end

     

     

    Rack1SW1#sh span int f0/15 portf

    VLAN0001            disabled

     

    Rack1SW1#sh int f0/15 sw

    Name: Fa0/15

    Switchport: Enabled

    Administrative Mode: static access

    Operational Mode: static access

    Administrative Trunking Encapsulation: negotiate

    Operational Trunking Encapsulation: native

    Negotiation of Trunking: Off

    Access Mode VLAN: 1 (default)

    Trunking Native Mode VLAN: 1 (default)

    ...

     

     

    Rack1SW1#sh cdp ne f0/15  

    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

     

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

    Rack1SW2         Fas 0/15          13           R S I     WS-C3560- Fas 0/15



    Nick
  • Hi Martin,

    An excerpt from Cisco documentation:

    "Because the purpose of Port Fast is to minimize the time ports must wait for spanning-tree to converge, it is effective only when used on ports connected to end stations. If you enable Port Fast on a port connecting to another switch, you risk creating a spanning-tree loop."

    If it looses the portfast status, then how loop occure if you connect this port with the Switch[8-|]

     

  • Hi Nick,

    I think we got the conclusion through Daniel's post.

    Same thing I found in another blog, but not in Cisco documentation;

    Portfast has two modes of operation. One is global, the other one is per-port configuration. Global configuration will causeaccess ports to start forwarding traffic immediately, unless BPDU is received on the port. If BPDU is received, port loses portfast status and reverts to normal operation, i.e. passing through all the states.

    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.

    So, we can conclude that if we enable portfast globally, it looses portfast status in the case it receives BPDU but if we enable portfast specifically in interface, it remains in same state. Am I right?

     

  • Hi Hari

     

    It is also lost if configured on the interface.  From my example above (portfast configured at interface) I made a change and configured BPDUfilter on SW2 so SW1 does not see BPDU.  You can see here SW1 keeps portfast until I disable BPDUfilter on SW2 and then it immediatly loses it.

     

    Rack1SW1#sh span int f0/15 portf

    VLAN0001            enabled

    Rack1SW1#sh span int f0/15 portf

    VLAN0001            enabled

    Rack1SW1#sh span int f0/15 portf

    VLAN0001            enabled

    Rack1SW1#sh span int f0/15 portf

    VLAN0001            disabled


    Nick
  • With a very short list of exceptions, those who can do!

    Again, with a very short list of exceptions, those who can't write books, teach or create documentation.

    Find those on that short list and soak up their knowledge. Also make good use of live equipment to provide clarification when available documentation is either unclear or appears to be incorrect and/or incomplete.

    HTH

    Ernie

  • Sometimes the documentation is wrong. I also believed for a long time that portfast on the interface was unconditional but it's not. At least not with the software that I tried.

    I also did a blog post on silent mode for PAgP which is also uncorrect in the documentation. I have submitted this as a bug in the documentation to Cisco so I hope it gets corrected.

  • Well...that's the problem. People who know tend to differ in opinion. That's why I'm asking.

     

    And seeing that there are people disagreeing in this thread, makes me think that this fact is not clear.

  • Edge port—A port at the “edge” of the network, where only a single host connects. Traditionally, this has been identified by enabling the STP PortFast feature. RSTP keeps the PortFast concept for familiarity. By definition, the port cannot form a loop as it connects to one host, so it can be placed immediately in the Forwarding state. However, if a BPDU ever is received on an edge port, the port immediately loses its edge port status.

    HTH

    Shahid

    On Aug 29, 2013 4:14 PM, "AshwinR" <[email protected]> wrote:

    Ok, I'm watching the STP intruction video for CCIE R&S (video 20) and I can't seem to get the difference between these 2 port roles. 

     

    Brian begins to state that they are the same, but work differently. When watching the video further, it does not become clear to me what the difference exactly is between a portfast port in Normal STP and an edge port in Rapid STP. I know that you configure them with them same command, but I'm not getting the difference...

     

    - An Portfast port in Normal spanning tree wil always stay in that state and not transition into somehting else when BPDU's are received??

    - An Edge port however will change from edgeport and will participate in STP calulation??

     

    Did I get that right?

     





    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • I think my question is not clear.

     

    Basically I'm asking if the behavior of and portfast port, which is called this way in Normal STP, and a Edge port, which is called edge port in Rapis STP, if they are the same?

     

    So the only difference, for now, is the name in the different STP types??? In the video mentioned, Brian says that both ports work differently. That is why I'm asking my question. the problem is that he makes that comment, but I don't get a clear explanantion as to what is different between those ports.

  • Hi Nick/Daniel,

    Thanks for correcting all of us since it has been defined wrongly on the various blogs. One major issue is the lack of proper documentation in Cisco too.  Hope it's clear to all now.[:D]

     

  • I think Brian's can shed some lights on this! because it took very hard time of our experts.

    Brians, will you please give the proper answer?

  • Hi,

        So things are very simple:

    1. Regardless of the STP algorithm you run, a portfast enabled port will always jump directly to forwarding state.

    2.
    Regardless of the STP algorithm you run, and how portfast is enabled
    (global mode, port mode, voice port), a portfast port will always  jump
    out of this state and become a regular STP port (non-portfast) if it
    receives a BPDU inbound.

    3. In 802.1D, a portfast port will not
    generate a TCN BPDU on a port up/down event, while in 802.1W a portfast
    enabled port will not generate a BPDU with TC flag set on a port up/down
    event. (so implementation is different because of the algorithm but end
    result is the same).

    4. In 802.1D if you don't have your host
    ports as portfast enabled your end-to-end time of convergence (for
    example in case of Root Bridge re-election) is not affected. In 802.1W
    if you don't have your host ports as portfast enabled your end-to-end
    time of convergence (for example in case of Root Bridge re-election) is
    affected due to the RSTP Sync process which is active on all non-edge
    (which means non-portfast enabled) ports, and because hosts will not
    reply to the SYNC process RSTP will fallback to 802.1d for these ports
    and transition the ports through listening/learning phases which
    increases your convergence with 30 seconds.

     

    Regards,

  • Hi,

        So things are very simple:

    1. Regardless of the STP algorithm you run, a portfast enabled port will always jump directly to forwarding state.

    2. Regardless of the STP algorithm you run, and how portfast is enabled (global mode, port mode, voice port), a portfast port will always  jump out of this state and become a regular STP port (non-portfast) if it receives a BPDU inbound.

    3. In 802.1D, a portfast port will not generate a TCN BPDU on a port up/down event, while in 802.1W a portfast enabled port will not generate a BPDU with TC flag set on a port up/down event. (so implementation is different because of the algorithm but end result is the same).

    4. In 802.1D if you don't have your host ports as portfast enabled your end-to-end time of convergence (for example in case of Root Bridge re-election) is not affected. In 802.1W if you don't have your host ports as portfast enabled your end-to-end time of convergence (for example in case of Root Bridge re-election) is affected due to the RSTP Sync process which is active on all non-edge (which means non-portfast enabled) ports, and because hosts will not reply to the SYNC process RSTP will fallback to 802.1d for these ports and transition the ports through listening/learning phases which increases your convergence with 30 seconds.

     

    Regards,


    Points 1 and 2 are crystal clear.

    But at point 3 and  it gets a bit muddy. So in both variant of Spanning Tree its'the same but not [:S]

    Point 4 I just don't udernstand what it states, it gets very confusing [:S]

  • >>>

     In 802.1W if you don't have your host ports as portfast enabled your end-to-end time of convergence (for example in case of Root Bridge re-election) is affected due to the RSTP Sync process which is active on all non-edge (which means non-portfast enabled) ports, and because hosts will not reply to the SYNC process RSTP will fallback to 802.1d for these ports and transition the ports through listening/learning phases which increases your convergence with 30 seconds.

    <<<

    This is not 100% correct. 802.1W has bridge detection machine. In this if host connected port is not configured as port fast, then AdminEdge will be False but OperEdge will be True in 3 sec (in case of point-to-point connection to host) and in 20 sec (in case of shared link). Once OperEdge is True, port on switch will go to forwarding immediately. So max time delay will be 20 sec in case of Hub, but in point-to-point link it will be 3 sec. 

    OperEdge becomes True once this port does not receive BPDU in EdgeDelayWhile time which is either 3 or 20 sec.

     

  • @AshwinR,

       So for point 3: when a topology change is detected, in 802.1d the bridge detecting the change needs to tell this to the root bridge, but STP did not allow to send regular BPDU upstream onthe Root Port, thus a special TCN BPDU was created. When a topology change is detected in 802.1w, the bridge detectting the change does not need to announce anyone, it locally converges due to the SYNC process, but for the TC While Timer all BPDUs will have the TC bit set. So 802.1d uses a special BPDU to signal topology change while 802.1w uses a regular BPDU but with a bit (TC) set to true. You may also read the following document, it's good:

    http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

       Does it make sense? What is unclear in step4? :)

     

    Regards,

  • @dineshg,

        Theory is theory and practice is practice, have you tested it? You'll see that when RSTP converges, all non-designated ports where the SYNC process is not sucessful will stay 2*FW_time (2*15 by default) before going to forwarding state (15 sec in BLK and 15 sec in LRN).

    Regards,

  • @dineshg,

        Theory is theory and practice is practice, have you tested it? You'll see that when RSTP converges, all non-designated ports where the SYNC process is not sucessful will stay 2*FW_time (2*15 by default) before going to forwarding state (15 sec in BLK and 15 sec in LRN).

    Regards,



    On Mon, Sep 2, 2013 at 3:46 PM, dineshg <[email protected]> wrote:

    >>>

     In 802.1W if you don't have your host ports as portfast enabled your end-to-end time of convergence (for example in case of Root Bridge re-election) is affected due to the RSTP Sync process which is active on all non-edge (which means non-portfast enabled) ports, and because hosts will not reply to the SYNC process RSTP will fallback to 802.1d for these ports and transition the ports through listening/learning phases which increases your convergence with 30 seconds.

    <<<

    This is not 100% correct. 802.1W has bridge detection machine. In this if host connected port is not configured as port fast, then AdminEdge will be False but OperEdge will be True in 3 sec (in case of point-to-point connection to host) and in 20 sec (in case of shared link). Once OperEdge is True, port on switch will go to forwarding immediately. So max time delay will be 20 sec in case of Hub, but in point-to-point link it will be 3 sec. 

    OperEdge becomes True once this port does not receive BPDU in EdgeDelayWhile time which is either 3 or 20 sec.

     





    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Cristian did some great explaining as always.

     

    Remember that in 802.1w TC does not have to be sent when port goes down because we are only concerned about adding connectivity, not losing it. However if losing a port leads to new/changing root information then we must send out TC for the MAC address table to be updated.

    Also RSTP was incorporated into 802.1D in 2004 so it's actually part of that standard now as well.

     

    If the RSTP sync process fails then there is a timer called FdWhile set to 15s. After this the switch gives up and takes the port through discarding -> learning -> forwarding so in total it should take around 45s. Take a look at a blog post I did for more information about the RSTP sync process:

    http://lostintransit.se/2013/08/08/rstp-synchronization-behind-the-scenes/

  • Correct just that discarding->learning->forwarding takes 30 seconds given the default timers.

    Cristian.

    Sent from my iPhone

    On Sep 2, 2013, at 20:16, daniel.dib <[email protected]> wrote:

    Cristian did some great explaining as always.

     

    Remember that in 802.1w TC does not have to be sent when port goes down because we are only concerned about adding connectivity, not losing it. However if losing a port leads to new/changing root information then we must send out TC for the MAC address table to be updated.

    Also RSTP was incorporated into 802.1D in 2004 so it's actually part of that standard now as well.

     

    If the RSTP sync process fails then there is a timer called FdWhile set to 15s. After this the switch gives up and takes the port through discarding -> learning -> forwarding so in total it should take around 45s. Take a look at a blog post I did for more information about the RSTP sync process:

    http://lostintransit.se/2013/08/08/rstp-synchronization-behind-the-scenes/




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • In my post, I assumed autoEdge is true for host connected port. This variable is false by default. So it takes 30 sec for host connected port to go to Desig/Fwd. If one does "spanning-tree portfast default" autoEdge will be true for access ports and host connected port will to Desig/Fwd immediately.

    Thank you all for clarification. It is clear for me now. 

    It is that if autoEdge is True bridge detection will run. If autoEdge is False bridge detection will not run.

  • peetypeety ✭✭✭

    4. In 802.1D if you don't have your host ports as portfast enabled your end-to-end time of convergence (for example in case of Root Bridge re-election) is not affected. In 802.1W if you don't have your host ports as portfast enabled your end-to-end time of convergence (for example in case of Root Bridge re-election) is affected due to the RSTP Sync process which is active on all non-edge (which means non-portfast enabled) ports, and because hosts will not reply to the SYNC process RSTP will fallback to 802.1d for these ports and transition the ports through listening/learning phases which increases your convergence with 30 seconds.

    Point 4 I just don't udernstand what it states, it gets very confusing Tongue Tied

    For 802.1D, take a L2 network.  Add a switch with portfast on every port but the uplink, and time the convergence on that switch.  Now add a switch without portfast on any port, and time the convergence on that switch.  You'll get identical times.

    For 802.1w, take a L2 network.  Add a switch with portfast on every port but the uplink, and time the convergence on that switch.  Now add a switch without portfast on any port, and time the convergence on that switch.  You'll find that the second switch is slower to converge: the first switch converged near-instantly, because it was able to negotiate proper root placement with the uplink neighbor, and knew that none of the portfasted ports would be root (or if they did, they would transition to root separately and later, in ~45 seconds).  The second switch couldn't converge near-instantly, because it had no idea if a better root sat on the other side of any of the other ports; it has to wait for legacy STP timers to be sure.

  •     So things are very simple:

    1. Regardless of the STP algorithm you run, a portfast enabled port will always jump directly to forwarding state.

    This is clear

    2.
    Regardless of the STP algorithm you run, and how portfast is enabled
    (global mode, port mode, voice port), a portfast port will always  jump
    out of this state and become a regular STP port (non-portfast) if it
    receives a BPDU inbound.

    This is also clear, but you can prevent this behavior for both STP and RST by using BPDU guard right?

    3. In 802.1D, a portfast port will not
    generate a TCN BPDU on a port up/down event, while in 802.1W a portfast
    enabled port will not generate a BPDU with TC flag set on a port up/down
    event. (so implementation is different because of the algorithm but end
    result is the same).

    Ok, what I got so far is that with normal STP when a change happens on 1 of the switches, it send a BPDU to the rootbridge. When a change happens on a switch with RSTP, it sends it (TCN) to all switches?, but using the command basically changes nothing, it works the same as STP?? How is this an improvemtn over STP [8-)] 

    4. In 802.1D if you don't have your host
    ports as portfast enabled your end-to-end time of convergence (for
    example in case of Root Bridge re-election) is not affected. In 802.1W
    if you don't have your host ports as portfast enabled your end-to-end
    time of convergence (for example in case of Root Bridge re-election) is
    affected due to the RSTP Sync process which is active on all non-edge
    (which means non-portfast enabled) ports, and because hosts will not
    reply to the SYNC process RSTP will fallback to 802.1d for these ports
    and transition the ports through listening/learning phases which
    increases your convergence with 30 seconds.

    Can you explain more on the RSTP SYNC process?? Also I read the last part a few times, but just does not click. CAN you explain it differently?

     

     


  • The root and designated ports are put into forwarding state. But they are put into forwarding state only if it is sure that no loop will be formed. (ie spanning tree information is consistent. The states and roles of other ports on neighboring bridges is calculated with latest spanning tree information. This is achieved by spending enough time before putting port into forwarding state [as done in STP.]) 

     

    A Root port can be put immediately to forwarding state if earlier root port is not forwarding at that moment. Example alternate port becoming root port and root port becoming alternate port. As soon as earlier root port becomes alternate and discarding new root port becomes forwarding immediately. 

     

    But for designated port to become forwarding which is connectd to only 1 another bridge, that other bridge's ports should have latest spanning tree information and have done with role-state calculation. This requires message exchange between these two bridges. 

    Typical message exchange is below.

    When RSTP decides port p's role as designated on Bridge B, it does following.

    1. B:p sends proposal flag in RST BPDU to connected port on another bridge (say bridge C port q ie C:q) with its role designated.

    2. At reception of proposal flag, received port (C:q) which can be in root, alternate, backup role, decides to put all non-edge ports on bridge C into discarding state (Exception exists [given in next paragraph]). Once all such ports are discarding, it sets internal variable synced (per port) to true. If all ports other than proposed port (C:q) are synced, the proposed port agrees. The proposed port sends Agreement flag with its role to proposing port (B:p).

    3. Once B:p receives agreement, it knows its designated port can be put into forwarding state immediately and connected port (C:q) agrees to (B:p) going forwarding. This meanes spanning tree information on bridge C is consistent with B:p.

     

    A port is not needed to put into discarding state after some other port on this bridge received proposal in below conditions.

    1. If a port x on bridge C is already discarding, it has synced set to true on C:x. it need not be put into discarding state again.

    2. If a port y is designated port on bridge C and it is in forwarding state (ie after exchange of proposal-agreement flags with its attached bridge D) then is in agree state. Such port need not be put into discarding state. I will have synced set to true.

     

    So sync process can work in parallel on other poin-to-point links.

     

    The sync process works on p2p links only. As proposal-agreement-role flags are defined only in RSTP (which are not defined in STP) only RSTP bridges (by extension MSTP) understant these flags. If STP and RSTP bridges are p2p connected then RSTP detectes STP's presence and sends STP BPDU on that port, which don't contain these spetial flags. So time is required before putting port to fwding state in this case.

  • AshwinR 

    2) right; BPDU guard would put the port in err-disabled state, you could shut/no shut the port to recover it or use errdisable recovery mechanisms to bring the port back up automatically

    3) your understanding is not correct; if you have portfast enabled on a port, the switch does NOT send a TCN up. The end result is the same, it is just the implementation that is different among the two flavors of STP

    4) http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf

Sign In or Register to comment.