Show 171 – Cisco FabricPath Deep Dive Part 2

Cisco FabricPath is a TRILL-based layer 2 forwarding technology that can take the place of spanning-tree. Allowing a fully-meshed layer 2 network to forward traffic across all links, FabricPath helps customers to make the most of their expensive 10GbE and 40GbE interconnects. In this show, Jamie Caesar, Colby Glass, and Ed Diaz discuss real-world FabricPath design and deployment with host Ethan Banks. There’s no one from Cisco on this show – just end users sharing their real-life FabricPath experiences.

This is part 2 on FabricPath. You should probably listen to part 1 before listening to part 2. Enjoy!


Show 152 – Nexus Announcements From Cisco Live 2013 With Ron Fuller – Sponsored < Includes a discussion about Nexus Validation Testing, which Ethan mentioned in this show.

This show was sponsored in part by Please give them a visit. Excellent training from some of the very best in the business.


Image from

Ethan Banks
Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
Ethan Banks
Ethan Banks
  • Jens

    Regarding the topic that “all VLANs should be configured in the complete fabricpath domain”. For obvious reasons this is what is stressed by Cisco, too – all guides give clear advise to have VLANs consistent in the complete fabric.

    The Quick Start Guide FabricPath ( for example is very clear on this:

    “FabricPath VLANs must be configured on all switches in the FP domain”

  • jsicuran

    Remember FP is NOT Ethernet. CE transparent bridging learning is not done at all as mentioned. VPC and VPC+ is better on the edges no need for the rigidity as mentioned and no CFS between cores.

  • jsicuran

    TCNs are not allowed to cross FP

    • Colby Glass

      TCNs are propagated across FP if the STP domain is set:

      “If a connected STP domain is multihomed to the FabricPath domain, a TCN must be able to reach to all devices in the STP domain through the FabricPath domain. As a result, the TCN is sent to the FabricPath domain through the IS-IS protocol data unit (PDU) by default.”

      • jsicuran

        Colby what doc are you referencing? I had the following informaiton from a Cisco whitepaper on FP

        8. Cisco FabricPath Interaction with Spanning Tree

        Cisco FabricPath supports not only direct Classic Ethernet host connections but also connection of traditional spanning-tree switches to Cisco FabricPath edge ports. By default, Cisco FabricPath switches transmit and process Spanning Tree Protocol Bridge Protocol Data Units (BPDUs) on Cisco FabricPath edge ports (you can modify this behavior using features such as BPDU guard and BPDU filter), and therefore participate in building the Spanning Tree Protocol forwarding topology in each connected Spanning Tree Protocol domain.
        However, BPDUs, including topology change notifications (TCNs), are not transmitted on Cisco FabricPath core ports, and no BPDUs are forwarded or tunneled through the Cisco FabricPath domain by default (a configuration option to forward TCNs through Cisco FabricPath is discussed in Section 8.1, “Forwarding TCNs”). Therefore, Cisco FabricPath isolates each Spanning Tree Protocol domain, and topology changes in one Spanning Tree Protocol domain are not propagated to other domains connected to the same Cisco FabricPath fabric.
        This isolation is accomplished by having the entire Cisco FabricPath domain appear as a single Spanning Tree Protocol bridge to any connected Spanning Tree Protocol domains, as shown in Figure 30. To appear as one Spanning Tree Protocol bridge, all Cisco FabricPath bridges share a common bridge ID (BID): C84C.75FA.6000. This bridge ID is statically defined and cannot be configured by the user.

        • Colby Glass

          Scroll lower (8.1 Forwarding TCNs) in the doc you pasted that from. It’s all explained there. Here’s a blurb:

          “By default, STP BPDUs are not carried through the FabricPath core, and topology change events are constrained to the individual STP domain in which they occur. **However, a configuration option is available to enable FabricPath edge switches to forward TCNs through the FabricPath cloud in order to support certain topologies.**”

          If you scroll even lower, you’ll see a scenario and this text:

          “Suppose a TCN is generated in STP domain 1. Other FabricPath edge switches connected to the same STP domain should receive the TCN through the FabricPath core in order to flush their MAC tables.”

  • Ron Fuller

    As Jamie mentioned, I had told him that NX-OS on the N5K and N6K could not participate in a FabricPath domain with Anycast on the N7K. This is due to a new TLV we added for Anycast. The good news is that as of NX-OS 6.0(2)N2(1) we added support for the TLV so you can build a FabricPath domain with N7K, N5K and N6K where you leverage Anycast.

  • What Lies Beneath

    On the subject of software testing, I would have thought regression testing (which I believe is fairly standard almost everywhere or at least good practice) would have been the appropriate term and what Cisco did. Obviously not and a classic case of hubris on their part I’d suggest*. Considering the possible impact and the nature of networking, plus the pricing, well, do I need to say more…

    *I smell bridges burning.