FabricPath MD Tree Path "Blocking" Selection

KishSquaredKishSquared
in CCIE Data Center Technical

I understand how to manipulate the FP root and secondary-root for the two MD trees, but how are the 'blocked' links selected? And how can I manipulate them? :)

I tried doing this with metric tuning, but it didn't appear to work - my switch prefers the higher-cost path to the root.  I wondered if it chose the highest system-id or switch-id, along the lines of root selection, but my tree in-lab is favoring a switch with lower IDs for each.  I even wondered if it couldn't be manipulated live, but a shut/no-shut didn't help.

Or maybe I'm just wrong about my root-selection.  Is there a command to verify root status?

· Share on FacebookShare on Twitter

Comments

  • KishSquaredKishSquared

    Quick update on the end question - 'show fabricpath ftag' shows the primary root, since the root determines ftag values.  Not sure how to verify secondary root yet.

     

    N7K-AGG_B# sh fabricpath ftag
                            FABRICPATH FTAG TABLE
    ========================================================================
             ALLOCATING
    FTAG      SYSTEM-ID     TREE-ID     TOPOLOGY-ID    FLAGS     STATE
    ------+---------------+----------+--------------+----------+------------
    1       547f.eef9.22c1      1          0           Primary    Confirmed
    2       547f.eef9.22c1      2          0           Primary    Confirmed

    · Share on FacebookShare on Twitter
  • KishSquaredKishSquared

    One more find - it seems the root is always listed as 'metric 0' under 'show fabricpath isis trees'.  In my case, 5 for Tree1 and 13 for Tree2:

    N7K-CORE_A# sh fabricpath isis trees
    Fabricpath IS-IS domain: default
    Note: The metric mentioned for multidestination tree is from the root of that tr
    ee to that switch-id
    *:directly connected neighbor or link
    P:Physical switch-id, E:Emulated, A:Anycast

    MT-0
    Topology 0, Tree 1, Swid routing table
    5, L1
     via Ethernet4/5, metric 0
    12, L1
     via Ethernet4/5, metric 80
    13, L1
     via Ethernet4/5, metric 40
    14, L1
     via Ethernet4/5, metric 40

    Topology 0, Tree 2, Swid routing table
    5, L1
     via Ethernet4/5, metric 80
    12, L1
     via Ethernet4/5, metric 40
    13, L1
     via Ethernet4/5, metric 0
    14, L1
     via Ethernet4/5, metric 40

     

    Now if I can just figure out how to manipulate the trees, assuming Cisco has provided us with the knobs to do so.  It seems like metric tuning should work but so far I've been unable find success.

    · Share on FacebookShare on Twitter
  • fragilemohifragilemohi

    why don't you try this below command and gives you preceisely who is Primary and seconday Root!!

     

    show fabricpath  isis topology summary

    · Share on FacebookShare on Twitter
  • KishSquaredKishSquared

    Whoa, thanks Fragile!  That's even better :)

    I suppose that distraction has been resolved.  Now does anyone have any thoughts about the primary topic of blocked path selection?

    · Share on FacebookShare on Twitter
  • KishSquaredKishSquared

    I'm going to raise this dead topic to life and see if anyone else has any cool thoughts about this. Is there a way to manipulate the path selection for the fabricpath multidestination trees?

    · Share on FacebookShare on Twitter
  • prasad.kulangaraprasad.kulangara

    I am also feeling the same, after reading the below link. The metric manipulation is the option available for a non root fabricpath node to alter the MDT root port....

    the root switch-id recursive lookup is performed, so the modification of metric should do the job. But i dont think that it will just affect the MDT. I will increase the cost of the path blindly thus affecting all routes.

     

    http://www.cisco.com/c/en/us/support/docs/switches/nexus-5000-series-switches/116303-technote-nexus-00.html

    · Share on FacebookShare on Twitter
  • Dominic_FoleyDominic_Foley

    Priority is for root of MD trees, and from the MD trees, an SP tree is built.  The metrics are simply about routing ISIS (which will also by its very nature take into account manipulation of the root port). 

    I wouldn't say that 'blocking' is part of fabricpath.  It is a routing protocol essentially and builds a SPT, so based on metrics, best path selection is done, no ports actualy get blocked, just unused depending on your routing and tweaking of the metrics.

    Let's take a very simple example - 2 FP switches connected together.  Now one will be the root for MD tree1 and the other for MD tree2.  Now, let's also say the links between the two switches are connected as follows:

    1) A single 10Gig port and

    2) A 20Gig port-channel

    So, what will the ISIS routing look like?  well clearly the 20G port-channel will have a lower metric, so that will be chosen as the best link.  However, if you wish for both links to be utilised, you can then tune your metrics to be the same (i.e. fool the switch) on both links (the single and the port-channel).

    HTH

    Now try configuring different FP topologies for different vlans, such that you have 2x MD trees for each topology with the associated vlans mapped....

    · Share on FacebookShare on Twitter
  • KishSquaredKishSquared

    Thanks guys - that makes sense if it's limited to metric manipulation, but as Prasad said, it takes careful calculations to change the MD tree without drastically altering the FP routing. I could see Cisco asking for this kind of consideration on the lab.

    I've studied multiple topologies, but I don't think they'll be on the lab since they're a 6.2 innovation. I know the lab is listed as 6.x, so it's a possibility, but I'd expect them to announce the expansion of features. There are a lot of FP and OTV add-ons in 6.2.

    · Share on FacebookShare on Twitter
Sign In or Register to comment.