思科FabricPath评测

出色的性能

我们测试了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成功地完成了所有任务。

结语

我们希望尽快看到更多的交换机支持FabricPath，毫无疑问，在网络领域，它是一个显著的进步，正如我们的测试显示，FabricPath简化了网络设计，提高了网络可扩展性和弹性，对于那些在意图扩大数据中心的网络架构师而言，现在使用FabricPath是个绝佳的选择。