STA - TCN & Uplink Fast

In the topology in this link (http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/10575-51b.gif).  Imagine were using pvst (and not rapid-pvst)

 

I have some questions about the way uplink fast actually works with the TCN that gets generated.  

 

Normally, when there is a topology change in the network (port goes into forwarding, or moved from learning or forwarding into blocking mode) a TCN is sent upstream to the root bridge. The root bridge sends a TCN replay with the Ack flag set.  This then tells the other switches to age out their mac tables by setting the cam max_age time to a a period of the forwarding delay (15 secs by default).

Now then, if uplink fast is configured, and say switch A (in the topology I provided in the link at the top of this page) moves port p2 straight into forwarding then sends dummy multicast frames with the source mac's of the entries in it's cam table toward Switch D2. What happens in terms of TCN generation? Switch A should still send a TCN out as a muilticast that eventually hits the root bridge. The root bridge will then send the TCN with an Ack bit set as a reply, which causes all the downstream switches to age out their cam table within 15 secs (default forward delay timer). So that seems to defeat the feature in uplink fast whereby Switch A sends dummy multicast frames so that Switch D2 can update its cam table. The idea behind that feature was to ensure the forwarding path doesn't take 300 seconds to age out (and potentially black hole traffic), which it achieves - i.e. forced Switch D2 to learn the new forwarding port to reach the mac addersses hanging off Switch A.  However, D2 is gonna forget all these entries now within 15 seconds & again have to re-learn them.

 

So ultimately my question is, am I correct in my assumptions whereby TCN really works against uplink fast? or am I missing something here?

Comments

  • Hi,

    I thought the best way to see how things work would be to set up your example as the following :

                              SW1

                          1/0       0/2

                         /              

                       /                  

                    /                       

                 0/0                        0/0

              SW3 0/2 ----------1/0 -SW2

    Ok now, SW1 is the ROOT :

    SW1#sh spann vl 1

    VLAN0001
      Spanning tree enabled protocol ieee
      Root ID    Priority    32769
                 Address     aabb.cc00.6400
                 This bridge is the root
                 Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

      Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
                 Address     aabb.cc00.6400
                 Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
                 Aging Time  15  sec

    Interface           Role Sts Cost      Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Et0/2               Desg FWD 100       128.3    Shr
    Et1/0               Desg LIS 100       128.5    Shr

    On all switches, debug spanning-tree events has been issued and on Sw3 also debug spanning-tree root. 

    Currently no uplink-fast feature has been configured on Sw3 and this is what the port states and roles are :

    SW3#sh spann vl 1 | b Interface
    Interface           Role Sts Cost      Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Et0/0               Root FWD 100       128.1    Shr
    Et0/2               Altn BLK 100       128.3    Shr

    Sw3 :

    SW3(config)#int e 0/0
    SW3(config-if)#shut
    SW3(config-if)#
    *Jun 19 12:16:44.832: STP: VLAN0001 new root port Et0/2, cost 200
    *Jun 19 12:16:44.832: STP: VLAN0001 Et0/2 -> listening

    *Jun 19 12:16:44.832: STP[1]: Generating TC trap for port Ethernet0/0

    *Jun 19 12:16:46.833: STP: VLAN0001 sent Topology Change Notice on Et0/2

    *Jun 19 12:16:59.834: STP: VLAN0001 Et0/2 -> learning

    *Jun 19 12:17:14.838: STP[1]: Generating TC trap for port Ethernet0/2
    *Jun 19 12:17:14.838: STP: VLAN0001 Et0/2 -> forwarding

    Ok, so Sw3 moves 0/2 port to ROOT role and generates TCN toward Sw2, which receives it on port 1/0 and forwards it out port 0/0 to the ROOT :

    SW2#
    *Jun 19 12:16:46.834: STP: VLAN0001 Topology Change rcvd on Et1/0
    *Jun 19 12:16:46.834: STP: VLAN0001 sent Topology Change Notice on Et0/0

    and SW1, the ROOT, receives the TCN :

    *Jun 19 12:16:46.834: STP: VLAN0001 Topology Change rcvd on Et0/2

    When activating uplinkfast feature :

    SW3(config-if)#do sh spann vl 1

    VLAN0001
      Spanning tree enabled protocol ieee
      Root ID    Priority    32769
                 Address     aabb.cc00.6400
                 Cost        3200
                 Port        3 (Ethernet0/2)
                 Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

      Bridge ID  Priority    49153  (priority 49152 sys-id-ext 1)
                 Address     aabb.cc01.2c00
                 Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
                 Aging Time  300 sec
      Uplinkfast enabled

    the blocked port transitions immediately to forwarding :

    SW3(config)#int e 0/0
    SW3(config-if)#shut
    SW3(config-if)#
    *Jun 19 12:24:42.360: STP: VLAN0001 new root port Et0/2, cost 3200
    *Jun 19 12:24:42.360: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 Ethernet0/2 moved to Forwarding (UplinkFast).

    So, the idea is that uplinkfast feature helps on transitioning the network faster, the port being moved to FWD state immediately.

    I don't really understand what you're referring to when mentioning "TCN really works against uplink fast". TCN is the mechanism used by STP to announce changes in the network. Can you elaborate on this a little bit ?

     

     

     

     

  • I think you've missed the point here, you've simply just explained uplinkfast.  My question was regarding how the TCN's work against uplink fast.

  • I used your post here as an inspiration for a blog post:

     

    http://lostintransit.se/2014/06/24/ethernet-stp-topology-change-and-the-behaviour-of-ethernet/

     

    Hopefully you get something out of it.

  • Ah so you basically agree with me ;-) 

  • Are you surprised? :P

    I guess it's challenging to come up with features like Uplinkfast and Backbonefast and still comply with STP standard. Cisco implemented these for PVST+ and then they essentially became part of the RSTP standard.

  • hehe.  Well sometimes I think I understand something then someone tells me it's slightly different, so sometimes I like to have someone smart to verify it.  That's why I like this forum; people tend to really understand a technology way more than an average person & you will generally get a very accurate answer to your problem by the end of your thread!


    :-)

  • Does this mean that the MAC address table of switch D2 will be cleared off twice?

    Once by the multicast frame generated by Switch A. And next time by the Configuration BGPDU with TC bit set generated by D1.

     

    Am I right?

     

  • Krishna, the MAC addresses are going to be cleared twice in this case. Once by the multicast frames sent and then again by the TCN that the Root Bridge will send out. The TCN tells the other switches that they need to flush their CAM tables since there has been a change somewhere in the network.

    Another thing to consider here, what happens when a switch's CAM table is full, or empty in this case? It will flood the frames out all interfaces except the one it received it on. Realistically, the feature is working and does lead to overall better performance on the network.

    Hope this helps,

    Eric

Sign In or Register to comment.