我们如何测试思科的VSS

我们通过三组测试测量轴路带宽和延迟，故障转移时间和网络骨干网的单播/多播性能进行评估为VSS性能。

对于此处描述的所有测试，我们配置了一个10,000行接入控制列表（ACL）覆盖层-3和第4层标准，并发现了ACL中的随机条目如预期所阻止的流量。作为对用户进行未经授权的更改的保障措施，思科工程师还配置了访问和核心交换机，以重新标记每个数据包中的差异代码点（DSCP），并且我们使用Spirent TestCenter流量生成器/分析仪中的计数器进行重新标记。思科还支持所有测试流量的Netflow流量监控。

为了评估织物带宽和延迟，所测试的系统是一对Cisco Catalyst 6509-E交换机。思科工程师在交换机之间设置虚拟交换机链路（VSL），每个都配备八个WS6408 10G以太网线路卡和一个虚拟交换管理主控器720-10G管理/交换机结构卡。总共剩下的130个10G以太网测试端口：每条线路卡上的八个，以及每个管理卡上的一个（我们使用管理卡的其他10g以太网端口设置开关之间的虚拟链接）。

使用Spirent TestCenter流量生成器/分析器，我们在130个10G测试端口上提供64、256和1518字节的IPv4单播帧，以确定吞吐量和延迟。我们测量的延迟为线速率的10%，这与我们在以前的10G以太网交换机测试中的做法一致。Spirent TestCenter分析器在每个端口上模拟了100台独特的主机，总共相当于1.3万台主机。

在故障转移测试中，目标是比较丢失交换机时的VSS恢复时间与使用较旧的冗余机制恢复时间。

该测试涉及三对Catalyst 6509交换机，代表企业网络的核心，分布和访问层。我们用三种配置运行故障转移测试。在第一场景中，我们使用了传统的冗余机制，例如快速生成树和热备路由协议（HSRP）。然后，我们使用VSS运行两个故障转移方案，首先使用分发交换机上的虚拟链接，并再次在分布和核心交换机上再次使用VSS链接。

对于每个测试，我们开始通过为测试床的核心和接入侧面上的16个接口提供流量。我们开始使用基线事件进行故障转移测试以验证是否存在帧损耗。虽然Spirent TestCenter提供了300秒的测试流量，但我们将电源切断到其中一个分配交换机。因为我们以每秒100,000帧帧的速率向每个接口提供流量，所以每个丢弃的帧表示恢复时间的10微秒。因此，例如，如果Spirent TestCenter报告了32,000个丢失的帧，则故障转移时间为320毫秒。

骨干性能测试使用类似于故障转移测试中的VSS配置的设置。在这里，还有三对Catalyst 6509交换机，代表企业网络的核心，分布和访问层。在这里，我们还通过分发交换机上的虚拟链路进行了单独的测试，并再次使用分布和核心交换机上的虚拟链路。

为了表示企业条件，我们在这些测试中设置了大量的路由、主机和流。从核心方面，我们配置了Open Shortest Path First来发布17.6万条独特的路由。在访问端，我们设置了4个虚拟局域网(VLAN)，每个虚拟局域网有250台主机，每个主机有16个端口，总共有16000台主机。在组播流量设置方面，每个接入侧VLAN中的一个主机加入了40个组，每个组有16个发射器;有16个核心端接口。总的来说，这个测试代表了超过10,000条多播路由，以及超过56亿条唯一的单播流。

在骨干测试中，我们使用了部分网格化的流量模式来测量系统吞吐量和延迟。如RFC 2285中所定义，部分网格图案是测试床两侧的端口彼此交流交流，但不属于它们。在这种情况下，这意味着所有访问端口都与所有核心端口交换流量，反之亦然。

我们在核心交换机上测试了所有四种单播、混合组播/单播和虚拟交换的启用和禁用(虚拟交换在分布交换机上总是启用，在接入交换机上总是禁用)。在所有四个主干测试设置中，我们测量了吞吐量和延迟。

我们在思科圣何塞校区的一个工程实验室里进行了这些测试。这偏离了我们在自己的实验室或中立的第三方设施进行测试的正常程序。这一变化是由于逻辑上的必要性:思科的实验室是唯一一个在规定的时间内有足够的10G以太网测试端口和电力来进行这项测试的实验室。网络测试和Spirent工程师进行了所有测试，并验证了交换机和测试仪器的配置，就像我们进行任何测试一样。无论在哪里进行试验，这里给出的结果都是相同的。

---

<返回主考试

了解有关此主题的更多信息