TRILL/Fabric Path – STP integration

Every Data Center fabric technology has to integrate seamlessly with legacy equipment running the venerable Spanning Tree Protocol (STP) or one of its facelifted incarnations (for example, RSTP or MST). The alternative, called rip-and-replace when talking about other vendors’ boxes or synchronized upgrade when promoting your wares (no, I haven’t heard it yet, but I’m sure it’s coming), is simply indigestible to most data center architects.

TRILL and Cisco’s proprietary Fabric Path take a very definitive stance: the new fabric is the backbone of the network routing TRILL-encapsulated layer-2 frames across bridged segments (TRILL) or contiguous backbone (Fabric Path). Both architectures segment the original STP domain into small chunks at the edges of the network as shown in the following figure:

Did you notice I used the routing at layer-2 oxymoron? Packet forwarding within the TRILL backbone is true routing; unfortunately TRILL also retains all the drawbacks of bridging.

The devices running TRILL could participate in the small STP domains, but that participation has nothing to do with TRILL (the TRILL draft is adamant: RBridges do not use spanning tree). In that case, some edge ports might become blocked by STP (the left-hand case in the figure).

Whether they run STP or not, the RBridges have to ensure there’s a single point of contact between a VLAN in the STP domain and the backbone, otherwise all the flooded packets would enter the backbone through multiple entry points, resulting in duplicate packets received by the remote hosts (which might break some odd fainthearted protocols running directly on top of L2). One of the RBridges therefore becomes an appointed forwarder for an edge VLAN.

The right-hand part of the figure illustrates the appointed forwarder concept: the RBridges don’t participate in the STP, none of their edge ports are blocked, but only one of the RBridges acts as a forwarder between the edge STP domain and the TRILL backbone (marked with A), all other RBridges ignore packets received through that VLAN (marked with B).

Assuming the RBridges perform TRILL-based bridging between its edge ports, each access switch on the right-hand side belongs to an independent STP domain and becomes the root of a very small spanning tree.

As the forwarders are appointed on per-VLAN basis (if you want to know the details, the allocation is done by the Designated RBridge – DRB), it’s quite easy to achieve per-VLAN load balancing by adjusting the allocation algorithm used by the DRB.

A pair of Nexus 7000 switches connected with a VPC+ link can perform active-active forwarding into the Fabric Path backbone. More about that in a future post.

More information

Numerous alternatives to STP, including TRILL, Fabric Path and 802.1aq are described in my Data Center 3.0 for Networking Engineers webinar (buy a recording).

The Data Center Interconnect webinar (register here) describes the benefits of TRILL in layer-2 DCI designs using VPLS services.

Both webinars are also available as part of the yearly subscription package.

2 comments:

  1. "Assuming the RBridges perform TRILL-based bridging between its edge ports, each access switch on the right-hand side belongs to an independent STP domain and becomes the root of a very small spanning tree."

    I think this depends... If the Rbridge forwards BPDUs between the ports where the CE switches are connected (both are connected to switch A) then one of the CE switches will become the root bridge because they see each others BPDUs. I understand B blocks, but the CE switches will still form a STP domain via the path over A.

    ReplyDelete
    Replies
    1. If RBridge works on edge physical interfaces, then the BPDUs should not be propagated between ports. If it works on VLAN interfaces, then BPDUs might get propagated.

      In any case, there might be corner cases where BPDUs are propagated between edge ports of the same RBridge. They should never be propagated across TRILL core.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.