【IT168 技术】09年的这个时候我们曾经看到过这样一个故事，一个系统管理员希望他的路由器可以帮助他实现远程监控本地状态的功能，然而一些老的思科和Juniper路由都无法满足其需求，后来他决定采用开源路由来解决这个问题，并获得了不错的效果(详见《开源路由使企业成本锐降 能否撼动思科Juniper?》 http://network.51cto.com/art/200906/129293.htm)。

　　两年过去了，问题在不断出现，技术也在不断变化，每个厂商都在一个或几个框架下提出了各自不同的解决方案和产品。然而，这并不代表每个产品和解决方案都可以完美解决用户的每个问题。正如前面的故事中提到的，单纯依靠成型的产品并不一定能够获得我们想要得到的结果，或者说，单纯依靠一家厂商的力量往往是难以满足用户层出不穷的问题的。

　　以虚拟化为例，用户在构建虚拟化网络的时候，不论过程如何，其最终目标一定是相对明确的，那就是降低运营成本，提高运营效率。至于说是采用Nexus 1000V还是VEPA框架下的产品，往往对于我们来说并不像想象的那么重要。关键在于看哪种方式更适合自己的需求。

　　以Nexus 1000V为例，Nexus 1000V是一个软交换机，可以和硬交换机统一网管起来.但是其也有一个很严重的问题，也是软交换最根本的问题——占用计算资源。在计算资源有限的情况下，用户往往并不希望拿CPU资源来换取交换功能，而是希望直接交由硬件交换机来完成。这个问题还是没有解决，所以它往往需要额外的服务器开销。

　　那么，我们就要寻求更多的解决办法来实现虚拟化这个目的，H3C网络及安全产品部解决方案部部长康亮在接受51CTO记者采访时曾谈到：“业界除了思科以外的其他的厂家，大家都在说需要一个开放的、标准化的接口，所以我们要做的就是面向虚拟化以后新的以太网能做这个事情，那就是VEPA，基于VEPA做的产品我们可以开放互联，而且可以实现网络和服务的解耦合。”当然，支持VEPA不等于千篇一律，各家的产品也在细节方面有着各自的特点和长处，这样一来，留给用户的可选择空间也就更大了。

　　另外，最近关注网络的朋友们一定会发现，OpenFlow的出镜率越来越高，这种被比喻为“C编译器”的技术实际上也为用户的广泛选择出了一份力。有较为尖锐的评论指出：“从产业链看，以思科为首的传统路由交换厂商没有任何理由支持这个技术，因为这个技术本身就是要打破传统路由交换的封闭性，把业务和平台分离，这明显是在挖传统路由交换厂商的墙角。”说法上有些极端，厂商也并不完全认同这样的说法，康亮谈到：“在数据中心通过openflow这样一个技术，用一个集中的控制器实现把所有的东西管起来，是一个很好的想法。但是我认为这项技术还是面临着产品化、商业化等问题，还要考虑到扩展性、时延性这些技术问题，目前OpenFlow技术好像还没有完全解决这些问题。”

　　还有一个比较典型的例子，就是建设数据中心的二层网络，尤其是从小规模二层网络到超大规模二层网络的升级。简单来说，所谓的二层网络可以定义为同一个Vlan在泛数据中心的接入层上出现。当数据中心的规模非常大的时候，比如一万个接口，在所有接入层设备中只架设一个Vlan将给运维造成很大的麻烦(亚马逊就在基于虚拟机做集群，几千个虚拟机做集群做超高性能计算，所以一个集群里的所有虚拟机需要在同一个Vlan上面，未来的数据中心很有可能会经常采用此类模式)。康亮指出：“如果要实现一个Vlan能出现在所有接入层交换机的话就需要部署大量的生成树协议。如果不部署生成树协议，就会出现网络风暴。但是一旦部署了大量的生成树协议就会发现里面有四大问题，带宽利用率下降、收敛时间比较长、管理复杂、网络规模越大越难部署。”

　　目前解决这方面问题的主要技术就是思科的VSS和H3C的IRF2，以及TRILL协议。VSS和IRF2的理念类似，都是把两台或多台交换机通过虚拟化的手段虚拟成为一台交换机，从而实现在低于一万台服务器的网络中不需要部署SPT就实现大的二层Vlan;而TRILL则主要面向超过一万台服务器的网络。在几种技术的对比过程中，思科VSS有一个问题是让大家比较纠结的，那就是VSS并不能支持思科全系列的产品，在思科S65等系列中才能获得很好的效果，并且完全不支持其nexus产品。IRF2在这方面则具有一定的优势，H3C从100G平台的核心交换机到接入层交换机产品(即基于全线交换机产品S12500，S9500E，S7500E，S5800，S5600，S5500，S5120EI，S3600系列)已经全部支持IRF2，这在一定程度上就保证了用户有限的投入可以换来满足其需求的产品。不过，思科VSS在单管理点、IP地址和路由实例等方面仍然具有相当强的优势，在消除传统园区网设计中非对称路由引起的单播泛洪等方面也有较为出色的表现。

　　在各种网络技术的对比过程中我们发现，以万变应不变，以多样化的技术来解决几个甚至是一个问题，这或许才是我们真正需要的技术解决之道，毕竟没有人希望被某一个产品“绑架”，哪怕仅仅是形式上的;从另外一个角度来说，如何利用好公有的技术来为最终用户需求服务，在目前，仍然是厂商们亟需解决的问题——不可能人人都是自己动手利用开源工具来解决问题的技术大牛，如果厂商有更好的解决方案和技术，工程师们为什么会不热衷于“不劳而获”呢?