河床赢得了7家供应商的WAN优化测试
挑战者iPanema和Exinda得分高标志
- iPanema IP |引擎在顶部出版，具有非常复杂的全球应用程序管理系统。
- 另一方面，思科WAVE引擎没有内置的流量管理功能。尽管如此，思科isr集成优化还是获得了所有IOS流量管理能力。
- 认为流量管理很重要的网络经理们将会关注Exinda x800系列、Ipanema ip|引擎和Riverbed Steelhead作为具有最复杂功能集的产品。
Ipanema IP |引擎提供我们测试的任何产品的最具创新性的交通管理组合。Ipanema的IP |引擎技术在莎莎管理工具中提供全球交通管理。
在一个纯星型网络中，比如分支机构聚集在一个单一的数据中心周围，流量管理很容易，因为网络实际上是一系列点对点的线路，所有这些线路都可以在两端进行控制。2020欧洲杯预赛
但是在拥有多个数据中心、支持中心、基于云的通信和分支到分支流的现代网络中，虚2020欧洲杯预赛拟点对点电路消失了。相反，每个站点可能会与多个其他站点通信，这可能会导致拥塞和用户不满。
在这种环境中的交通管理变得非常困难，没有某种全球交通观点在一瞬间的基础上。
Ipanema的ip|引擎彼此保持着持续的通信，当多个站点(例如，威胁要用有限的带宽压倒单个分支机构)时，可以应用全局流量管理。Ipanema的ip|引擎技术确实有效，但并不完美。
我们看到多个Ipanema ip|引擎设备协调流量，并提供跨不同站点的协调流量管理。然而，我们也看到了一些异常，指出了一些需要解决的错误。例如，我们锁定了一个特定的流媒体应用程序到256kbps，但是看到我们的Ipanema ip|引擎在很长一段时间内允许了50%的流量。我们的Ipanema支持团队最初将此归咎于缺乏全球设备同步，但Ipanema后来告诉我们不需要同步——这让我们对不准确的流量管理行为更加一无所知。
网络管理人员还需要知道，Ipanema ip|引擎只支持非常严格的网络架构和流量管理模型。当定义全球流量时，Salsa管理带宽是基于应用程序，而不是基于每个站点。因此,你可以说“视频会议每个电话512 k的保证”或“Citrix XenDesktop 64 k的保证每个会话”但没有简单的方法来表示有多少视频通话或Citrix XenDesktop会话可以进入或从一个特定的网站或网站的带宽的百分比可以被一个特定的应用程序。
我们认为一些网络管理人员会发现Ipanema的ip|引擎流量管理技术是他们梦想的答案。然而，Ipanema的网络和流量管理模型没有协商的余地——要么您的网络和流量模型符合Ipanema的要求，要么它们将无法解决您的流量管理和应用程序保证问题。
对于其他六种产品，我们在站点的基础上验证了出站和入站流量管理的正确操作（由于没有其他产品包括Ipanema的全球交通观点）。我们基于典型的WAN交通政策的所有测试。我们测试的所有产品通过了这些测试，受到每个产品可以支持的差异的影响。在某些情况下，我们必须稍微改变我们的政策。例如，我们的测试政策要求监督娱乐网使用，但并非每个产品都可以识别BitTorrent等应用程序，并将它们与非娱乐互联网使用区分开来。
河床的Steelhead和Exinda的X800电器显示了复杂的交通管理能力，使我们在ipanema下面排名，但在其余部分之上。
这两款产品突出的一个关键特性是第7层应用程序识别:能够基于所使用的应用程序应用流量管理规则，而不仅仅是IP地址和端口号的简单元组。
Exinda的遗产是作为一个交通管理公司，这使得它在我们测试的这一部分中可以擅长它。例如，EXINDA X800可以应用每个站点和每个主机流量管理规则，使网络管理员提供机会在重大流动使用的网站中提供一些“公平性” - 或者下载1GB IOS7升级的人影响互联网链接上的业务流量。
通过Exinda x800每个主机“动态虚拟电路”，主机(由子网、VLAN或其他限定符指定)可以在其他每个站点、每个子网或每个应用程序的限制之上获得一块带宽，以便公平地共享。我们的测试发现这个功能运行正常，但有一个例外:流量管理和Exinda的互联网网页缓存功能不兼容，Exinda告诉我们，他们会在未来的产品版本中修复这个问题。
Exinda x800和Riverbed Steelhead都具有入站和出站流量管理功能，尽管Steelhead在配置上奇怪地不对称。河床最近为流量管理添加了一个很好的层次模型，但这只扩展到出站流量。Exinda x800在两个方向上都有相同的层次模型。
我们也更喜欢Exinda的x800流量管理功能，这些功能不是Riverbed Steelhead的，但在定义公司网络政策时可能非常有用。例如，Exinda x800具有用于流量管理的时间规则，并且能够以百分比和绝对值表示带宽。
Exinda x800还有一个高等教育网络管理者会欣赏的功能：在一段时间内超过一定流量配额的用户可以被送到一个临时“监狱”，限制他们可以使用的带宽。Riverbed的Steelhead没有这些功能。
虽然蓝色大衣Mach5，Citrix的CloudBridge 2000和Silver Peak的VX系列都有交通管理功能，但它们带来了更少的能力工具。例如，Citrix CloudBridge 2000具有先进的优先级和警察应用程序的精致方式，但不会让您保证特定的带宽切片到任何应用程序。
波不为WAAS
思科值得在这里特别提及。当我们开始测试时，思科只有其独立的Wave设备，具有复杂的WAN重复和压缩功能的设备，但无法执行任何类型的流量管理。
在我们测试的中途，Cisco在其ISR系列中发布了一款新的中型路由器4451-X。这种新的硬件包括IOS-XE和运行内部虚拟机的能力，包括Cisco广域应用服务（WAAS）引擎。与此同时，Cisco在ISR系列中引入了一种新的许可变体，称为“AX”（用于“应用程序体验”），其中包括四个捆绑在一起的选项：WAAS、应用程序可见性和控制、安全性和正常数据许可。此新许可证与4451-X上的一些自动配置向导相结合，大大简化了向4451-X ISR平台添加网络优化功能的过程。
因此，我们决定专注于ios集成的WAAS产品，而不是思科独立的WAVE设备。考虑使用思科进行网络优化的网络管理人员需要小心，不要将思科的独立选项(作为广域网加速产品的旗舰)与新的捆绑ISR设备混淆。独立WAVE在某些环境中仍有一席之地，但大多数网络管理人员应该以ios集成设备为目标，以实现特性和成本效益的部署。
我们在独立的WAVE设备上测试思科的加速性能，这应该和新的集成WAAS系统一样，因为它们运行的是相同的软件。独立的Cisco WAVE设备完全没有流量管理功能，能见度也非常有限。
IOS和IOS-XE都有一套全面的流量管理工具，这使Cisco在我们的测试中与Blue Coat Mach5、Citrix CloudBridge和Silver Peak VX系列大致处于同一排名。但是，Cisco IOS还具有应用程序标识功能（NBAR），可以与流量管理相结合，以超越此基线。
另一方面，在中间使用WAAS引擎使用NBAR来影响流量管理会导致不可维护的配置混乱不堪。虽然CCIEs可能能够处理此类问题，但我们认为IOS或IOS- xe结合WAAS引擎并不是交通管理的长期最佳选择。
能见度：Exinda，Riverbed Excel
在处理数百或数千分支机构时，快速钻取和诊断网络和应用问题的能力是一个主要的竞争优势。除了问题解决 - 能力规划，趋势分析和使用跟踪之外，可见性可以通过良好的可视性提高。
由于网络优化设备在防火墙上获得了WAN流量之前，这是一个很好的地方，可以让分支机构进入企业网络或互联网的流量。
我们的测试集中在评估产品的短期和长期流量分析能力。我们发现Riverbed Steelhead和Exinda x800提供了最强和最广泛的可视性特性集——尽管要充分利用Riverbed Steelhead还需要对Riverbed Cascade分析工具进行预算。
接下来的IPANEMA IP |发动机和银峰值VX系列，带蓝色大衣Mach5，Citrix CloudBridge和Cisco Waas带上后部。
短期分析:Exinda, Ipanema提供了最丰富的背景
我们从问这个问题开始:“现在谁在我的网络上做什么?”我们发现所有的产品都很相似。所有这些都提供了网络性能的概述，包括压缩，并可以查看当前打开的连接。有些甚至会让您进行深入研究——例如，Cisco WAAS会告诉您您想要了解的关于开放连接的一切。这对于调试网络优化工具非常有用。在这个级别上，设备之间最大的区别在于它们能够使用应用识别技术来添加更多的上下文:只有Ipanema ip|引擎和Exinda x800系列提供了这种类型的信息。(Riverbed将从Steelhead操作系统RiOS的下一个版本8.5开始，将其应用程序识别信息添加到流量数据中。)
使用Blue Coat Mach5、Cisco WAAS、Citrix CloudBridge和Ipanema ip|引擎，每个站点的信息基本上都停止了，并且没有关于过去会话的真实信息存储在他们的设备上。
Silver Peak VX系列，河床Steelhead和Exinda X800系列进一步，在设备上提供流量历史数据，让您通过不同视图，例如通过IP地址，应用程序组和应用程序枢转。Exinda X800系列添加了奖励：通过Windows Active Directory域控制器将用户名映射到IP地址，它可以基于用户名和IP地址启用报告和流量管理。当然，有这种方法存在可伸缩性问题，但在一个带有单个Windows域和单个网络优化框的分支机构中，这一切都适当。
我们对箱上交通信息的测试集中在短期流量和交通信息上。对于长期的流量数据，我们寻找其他的解决方案。
长期分析：它是河床，蓝色外套和银峰
我们认为，由于两个原因，不应被要求提供现场电器是长期的信息存储库：对最终设备的性能影响以及从单站缺乏全球视图。处理存储和分析交通的性能要求可能是棘手的，并要求在分支中坐在路上的设备存储超过一个月的数据不是一个好主意。
全球视野也是关注长期报告的一个关键原因。任何一个设备都可以告诉您在该站点上发生了什么，但是当网络或应用程序管理器在更大范围内查找问题，或者在整个网络上查看趋势信息时，更大的视图是很重要的。在数据中心端，问题更加复杂，多个设备可能存在于多个数据中心，需要聚2020欧洲杯预赛合。
从长期来看，导出流、流量和优化数据的明显解决方案是使用NetFlow v9(或IETF替换，IPFIX)等标准。当我们开始测试时，我们假设我们能获得100%的覆盖率，但我们很惊讶:Blue Coat Mach5、Citrix CloudBridge和Ipanema ip|引擎还没有达到这一目标——Blue Coat告诉我们他们正在增加这一功能，而Citrix表示他们将通过与Splunk的合作获得同等的功能。
思科的独立WAVE系统(来自发明NetFlow的公司)也不支持NetFlow，但集成到IOS中的WAAS可以基于IOS的能力输出NetFlow。
Riverbed Steelhead、Exinda x800系列和Silver Peak vx系列均出口NetFlow。但是，网络管理人员在这里必须小心，仅仅因为在NetFlow中发送了优化信息，并不意味着每个NetFlow收集器和分析器都可以使用它做任何事情。在2009年收购妈祖网络公司时，Riverbed就清楚地认识到了这个问题，并重新推出妈祖的分析工具“河床级联”(Riverbed Cascade)，为Riverbed提供了一个具有广泛应用分析功能的顶级分析工具。