網絡架構師希望成長中的數據中心運行速度越來越快，讓用戶越來越滿意，管理越來越簡單。思科表示其FabricPath技術可以滿足這三大願望，它使數據中心交換機之間的連接比傳統的生成樹協議（STP）更好，在這個獨家測試中，我們評估了FabricPath在提高帶寬，重整問題路由和簡化網絡管理方面的能力，在這三個方面，FabricPath最終提交了滿意的答卷，思科採用了IETF即將發佈的TRILL預標準規範，它比基於STP的設計表現確實要好得多。
但有一個問題：目前只有思科Nexus 7000裝備F1 1/10GB以太網線卡纔可以支持FabricPath，隨着思科對FabricPath支持的擴大，這種情況肯定會得到改善，思科最近宣佈Nexus 5500也會支持FabricPath，相信會有越來越多的新產品會兼容TRILL規範。
初識TRILL
成長中的數據中心至少要面臨三個網絡方面的挑戰：更多的帶寬，更靈活和更簡單的管理，思科聲稱FabricPath是多鏈接透明互聯（Transparent Interconnection of Lots of Links，TRILL）協議的一種實現，一舉解決了這三個挑戰，TRILL規範在IETF內部仍然處於草案狀態，因此今天的任何實現都是基於預定義標準的。
從本質上講，FabricPath是一種鏈路層路由協議，開啓FabricPath的交換機和傳統的以太網交換機有兩個地方不一樣：它們使用IS-IS上傳輸的控制消息計算出二層路徑，使用FabricPath頭封裝入站以太網幀，消息頭包含路由的源和目標交換機地址，以及阻止循環的TTL值。
FabricPath減小了配置難度，不需要掌握IS-IS知識，只需要兩行交換機配置命令就可以開啓FabricPath，唯一強制性要求是要區別邊緣端口和Fabric端口，在測試中，我們分配了交換機ID，並設置了通信流使用的哈希算法，每個都只需要一行命令就能搞定。
FabricPath相對STP最大的優勢是帶寬和多用途，STP提供冗餘和阻止循環，但它使用的是主/備用模式，因此，STP網絡爲任何流量提供了兩個可能的路徑，但只有其中一個可以轉發流量，生成樹設計要求路由器在廣播域之間傳輸信息，進一步限制了可用帶寬，並增加了複雜度。反過來，路由器增加了延遲，並需爲冗餘準備額外的鏈路。
與此相反，FabricPath跨所有參與的交換機創建一個簡單的交換機網絡，增加了二層域內的可用帶寬，FabricPath使用等成本多路徑（ECMP）路由跨所有可用鏈路轉發流量，因此它是一個主動/主動模式的技術。
擴大的二層域也需要少量的三層路由跳數，減少延遲，它讓VMware的VMotion這樣的遷移服務變得更簡單，更大的二層域簡化了變更管理，因爲移動連接的主機不再需要IP地址和/或修改VLAN配置。
FabricPath也減少了洪水廣播和MAC地址表大小，這兩個在大型二層網絡中是衆所周知的問題，FabricPath交換機發送到未知的目的地時使用多播而不是洪水式轉發，它使用從Fabric學到的信息和邊緣交換機上的源MAC地址計算出路由表。
此外，它使用一個叫做“會話學習”的技術，交換機只使用會話真正使用到的端口填充MAC地址表，這和傳統的交換機不一樣，傳統交換機會看到廣播域內的所有洪水流量，並把每個地址都放入MAC表，與此相反，FabricPath交換機不需要龐大的MAC地址表，即使二層域覆蓋了數以萬計的主機。
思科聲稱FabricPath可以縱向擴展到256條活躍路徑，每條路徑包括多達16個使用鏈路聚合的鏈路（按思科的叫法即EtherChannel），我們沒有核實這是否屬實，因爲要驗證的話需要將近1萬個測試端口，我們只能按比例縮小規模進行測試，每個交換機設置16條活動路徑，每條路徑最大可以支持16個鏈路。
FabricPath的最大缺陷是支持它的產品數量有限，在9月份的測試中，只有思科Nexus 7000交換機支持，並且需要裝備F1 32口 1/10GB以太網線卡。思科最近宣佈Nexus 5500也將支持FabricPath，但要等到2011年發佈新的軟件版本。除此之外，目前尚不能將FabricPath延伸到其它思科交換機上，更不用說其它廠家的產品了。
雖然FabricPath一開始就被大家看好，但在評估數據中心交換機時，它不會成爲唯一的評判標準。因爲我們的測試主要關注的是FabricPath的功能，其它問題我們暫時不談，如可擴展性和延遲。
另一個問題是價格，150萬美元的價格不得不叫人吃驚，但它包含6個Nexus 7000和384個10G以太網和光纖端口，現有Nexus 7000用戶可以添加F1 FabricPath線卡，每個大約3.5萬美元。
出色的性能
我們測試了FabricPath五個方面的功能，所有這些都是在由6個Nexus 7000連接而成的一個FabricPath網絡中完成的，總共連接了128000個模擬主機，Spirent TestCenter流量產生器/分析器模擬每端口100個主機，爲6個交換機上128個10G以太網端口提供流量。
在第一次測試中，我們試圖驗證FabricPath是否可以支持交換機之間的16條冗餘路徑，在配置好兩個邊緣交換機上的16個EtherChannel端口後（每個端口4條鏈路），我們使用Spirent TestCenter在所有模擬主機之間連續發送5分鐘的流量。
在這個測試中，交換機轉發了所有通信，沒有出現幀丟失的情況，驗證了FabricPath跨16個冗餘連接負載共享的能力。
雖然EtherChannel組的數量很重要，也就是每個組中的鏈路數量，主機之間包含大規模應用程序數據傳輸，因此這裏是重點，我們使用和第一次測試相同的物理拓撲結構，但這次每個邊緣交換機配置了四個EtherChannels，每個EtherChannels包含16個10G以太網鏈路，系統再次圓滿完成了任務，沒有幀丟失。
我們也分析了FabricPath如何處理主機MAC地址，在前面的測試中我們已經看到了問題，交換機的哈希算法導致跨多個鏈路的測試流量分佈非常不平衡。然後我們使用完全不同的僞隨機MAC地址進行重複測試，獲得了幾乎完全相同的結果，因此交換機可以跨所有核心鏈路統一分配它們。
不會出現組播性能損失
思科也聲稱FabricPath可以跨多個交換機管道負載共享組播源接收器樹，而STP網絡只有單個樹，我們在一個非常大的組播設置中對此進行了測試，Spirent TestCenter在兩個邊緣交換機的每個端口上模擬100個組播源（總共128個端口），每個交換機的每個端口也加入了源自其它邊緣交換機上所有端口的50個組，相當於二層設備有64萬條組播路由（128個邊緣交換機端口*50個組*每個組100源）。
爲了確定FabricPath是否能夠負載共享組播流量，每次測試完畢後，我們都檢查了各個EtherChannel接口的數據包計數，結果顯示組播比單播流量的變化要大，但也不是很明顯，最多的時候，跨多個EtherChannels的數據包計數約相差2.5%.
隨後，我們混合單播和組播流量重複了相同的測試，FabricPath再次成功將所有幀傳輸出去，但單播和組播數據包計數的差異和單獨測試單播或組播時的情況一致，這表明向傳輸單播流量的FabricPath爲了加入組播流量不會對負載共享帶來負面影響，反之亦然。
FabricPath故障轉移
對於數據中心網絡而言，彈性比高性能更重要，不管是FabricPath還是STP，最關鍵的問題是儘快重新路由故障鏈路或交換機上的通信流量，使用快速生成樹時進行故障轉移需要1-3秒，如果是標準的生成樹則需要45-60秒，你可能想問，既然FabricPath那麼優秀，那麼它在發生故障後需要多長的時間轉移呢？
爲了找到答案，我們在四條路徑，16個鏈路上做了相同流量的測試，通過關閉骨幹交換機來模擬故障轉移，我們重複測試了四次，測試結果表明FabricPath比生成樹確實要快，就平均值而言，系統重新路由發送到故障骨幹交換機的通信流量的時間只有162毫秒，較快速生成樹的1-3秒有一定的改善。
我們也測試了向FabricPath網絡增加交換機後的匯聚時間，即將先前關閉的骨幹交換機加電啓動，在這個測試中，我們發現匯聚時間爲0，IS-IS協議識別新的路徑，然後開始在它上面路由通信流量，在重新計算路由期間沒有幀丟失。
數據中心網絡管理器（DCNM）
在最後的測試中，我們檢查了思科的數據中心網絡管理器（Data Center Network Manager，DCNM）軟件，它用於配置和監控FabricPath網絡，DCNM使用簡單對象訪問協議（Simple Object Access Protocol，SOAP） - 一個基於XML的數據表示方法，它允許第三方Web服務調用它。
在我們的測試中，我們的重點放在DCNM執行常見的FabricPath管理任務上，所有測試的任務都包含在DCNM的基礎版本中，免費提供給管理Nexus交換機，一些額外的功能，如配置歷史管理是需要額外付費購買的，因此我們沒有測試它們。此外，DCNM主要負責Nexus交換機管理，雖然它可以使用思科發現協議（Cisco Discovery Protocol，CDP）發現非Nexus交換機，但它管理的信息僅限於CDP發現的，使用Nexus設備時，管理工具包更能發揮作用。
在我們的第一次測試中，我們配置的DCNM發現了6臺Nexus交換機，第二次測試時，我們配置DCNM當FabricPath鏈路上的流量超過80%的利用率時發送文本和電子郵件，第三次測試時，我們配置DCNM在鏈路失效時自動報警（我們是通過拔掉邊緣交換機和骨幹交換機之間的線纜觸發的），最後，我們配置DCNM應用早前檢測到的加權隨機數給所有交換機配置排隊，然後移除所有交換機配置的WRED部分，DCNM成功地完成了所有任務。