October 25, 2010, 12:08 PM — Cisco has three words for network architects looking to grow their data centers: Faster. Flatter. Simpler.
The vendor says its FabricPath technology embodies all three qualities by making far better use of connections between data-center switches than the venerable spanning tree protocol (STP).
In this exclusive test, we assessed FabricPath in terms of its ability to boost bandwidth, reroute around trouble, and simplify network management. In all three areas, FabricPath delivered: Cisco's pre-standard take on the IETF's forthcoming TRILL specification showed real improvement over STP-based designs.
There is a catch: The latest 1/10-gigabit Ethernet line cards for the Cisco Nexus 7000 are the first, and so far only, products to enable FabricPath. That's likely to change as Cisco expands FabricPath support (it's supported in the recently announced Nexus 5500) and more vendors release TRILL implementations.
The test results, combined with the likely appearance of more TRILL solutions in the next few months, suggest a flat future for data center network design. (See an ultimate guide to flat data center networks.)
A view to a TRILL
Growing the data center means meeting at least three networking challenges: More bandwidth, more flexibility, and simpler management. Cisco claims FabricPath, its version of the Transparent Interconnection of Lots of Links (TRILL) protocol, addresses all three requirements. (Parts of TRILL remain in draft status within the IETF, so any implementation today is by definition pre-standard.)
In essence, FabricPath is a form of link-layer routing. FabricPath-enabled switches differ from their conventional Ethernet counterparts in two ways: They compute layer-2 paths using control messages carried over IS-IS, the routing protocol, and they encapsulate incoming Ethernet frames with a FabricPath header. This header contains routable source and destination switch addresses and a time-to-live field for loop prevention.
FabricPath involves minimal additional configuration, and doesn't require knowledge of IS-IS. It takes two lines to enable FabricPath in the switch configuration; the only other mandatory requirement is to distinguish fabric ports from edge ports (a single command on each fabric-facing interface). In testing we also used optional commands for assigning switch IDs and setting the hashing algorithm used by traffic flows; these required one line apiece.