cisco fabricpath 功能介绍

网络架构师希望成长中的数据中心运行速度越来越快，让用户越来越满意，管理越来越简单。思科表示其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成功地完成了所有任务。