A problem has surfaced in recent years when bandwidth needed to be shifted from WAN to LAN and data centers wanted to switch frames as quickly as possible. Network administrators were faced with two options: Either leave the network running Spanning-Tree with one out of two uplinks working or use Portchannels between switches to augment the bandwidth by getting spanning-tree to treat those links as one logical link. When redundancy designers looked at it, they realized that while PortChannels are great, they are typically bound to another single switch, and an alternate path to the destination would be blocked following the spanning-tree rules. So Virtual Port Channel (VPC) came along to alleviate those challenges.
From a bigger picture point of view, time finally came to give intelligence to those L2 frames. What about routing frames like a Layer 3 protocol would do? Some simplistic engineers would say: “Just make your network a Layer 3 network then!” and problem solved. However, technologies such as VMware’s Vmotion want you to move hosts from one side of the network to another, making your network LFNs (long fat networks).
Enter FabricPath. Cisco developed FabricPath and implemented it ahead of schedule on select hardware such as Nexus 7000 F modules and soon to be on Nexus 5000. We mentioned Dr. Radia Perlman earlier, who is also working on TRILL, which is going to be an open-vendor protocol aimed at resolving the same challenges. According to Cisco, FabricPath is more feature-rich than TRILL, and all the Cisco devices that support FabricPath will be able to support TRILL. But, TRILL is not out yet so it is difficult to really see what happens when the rubber meets the road there. FabricPath is already out and working, and the configuration is quite simple.
What both protocols aim to do is to give a switch the ability to see what the destination MAC address of your frame is going to be, then route it (note that I said route) via the optimal path to its destination. In regular switching networks, the switches usually learn each other’s MAC address table during regular transmissions and build their tables accordingly. For example, switch A would learn that a host connected to switch C needs to talk to switch B, almost as a hop-to-hop basis, which is what TRILL is based on, according to what I have seen. FabricPath is different in the way this works: switch A would learn that switch C has the destination MAC address via a discovery or via “conversational process.” The switches would exchange this information on an IS-IS backbone that is established between them. The IS-IS process (hidden from the network admin) would be in charge of determining which path is the optimal path to switch C using the IS-IS algorithms, regardless of the topology changes on the network, effectively getting rid of spanning-tree recalculations on the network.
