Juniper起诉PaloAlto Networks:都是钱惹的祸
作者 陈怀临 | 2011-12-20 08:07 | 类型 行业动感 | 24条用户评论 »
|
[今天刚知道这个消息。很震惊。。。下面是从网上抄录来的新闻] Juniper美国联邦地方法院提起诉讼称,Palo Alto正在侵犯其下一代防火墙技术的专利权,该技术虽然由Palo Alto创始人发明,但Juniper公司拥有其专利权。 今天,Juniper美国联邦地方法院提起诉讼称,Palo Alto正在侵犯其下一代防火墙技术的专利权,该技术虽然由Palo Alto创始人发明,但Juniper公司拥有其专利权。 Juniper在美国联邦地方法院提起诉讼,并称Palo Alto创始人明知Juniper拥有其技术专利权,却依旧使用其创造竞争性的防火墙。 基于以上原因,Juniper请求法院对Palo Alto的侵权进行三重处罚。这起诉讼表明,处罚应不少于通常的专利使用费。 Palo Alto一个发言人表示公司拒绝对这起诉讼发表评论。 Juniper公司在一份电子邮件声明中说,“Juniper公司专注于为我们的客户提供突破性的创新,作为全球领先的高性能网络公司,我们将采取一切适当措施,捍卫和保护我们的创新。” 该诉讼声称NetScreen前高管NIR Zuk和Yuming Mao亲自抄刀该技术(NetScreen于2004年被Juniper以40亿美元收购)。 投诉称NIR Zuk和Yuming Mao敏锐地意识这六项专利将引起争议,因为他们申报了一个以上的该专利。 根据Gartner公司最近的一份技术报告,Juniper和Palo Alto与Check Point、Cisco、Fortinet公司及McAfee 一起,是在企业网络防火墙方面的两家顶级供应商。其中Palo Alto被列为该市场的领导者,而Juniper是该市场的挑战者。 关于Palo Alto,Gartner表示:“Palo Alto公司的高性能下一代防火墙功能,继续推动竞争对手在防火墙市场进行回应,之所以将之列为领导者主要是因为其下一代防火墙的设计,沿着下一代防火墙 路径的对市场进行重新定向,不断地转变其领导者和挑战者的位置,市场混乱致使领导者进行回应。通过一个统一的单通道检测引擎,而非对传输流量的检 测,Palo Alto一直凭借相对较少的模型保持其性能。 对于Juniper,Gartner报告显示,“Juniper被评估为企业的挑战者,因为我们看到Juniper选择使其所有的产品相互呼应,而非通过其视觉或功能来取代其竞争对手的产品。在评估期间,Juniper似乎更专注于其他产品,并没有在防火墙产品上进行显著的改进,然而,Juniper经常入围并被运营商、服务提供商和数据中心部署选为供应商,这很有可能是因为价格及其最大设备的高吞吐量。” Infonetics将Juniper列为在网络安全收入中仅次于思科的第二大网络安全厂商,但其投资组合已经远远超过下一代防火墙这一个产品。 | |
没有圣诞攻势的美股市场
作者 ibluesea | 2011-12-18 18:49 | 类型 弯曲财经, 行业动感 | 1条用户评论 »
|
这是一个没有圣诞狂欢的股票市场。美股市场被欧债危机和美国的国内政治斗争所左右了。奥巴马满怀的理想在现实面前也不得不屈服了。共和党几乎达到凡是民主党提出的都反对,凡是对奥巴马有利的都不支持的境地。巨额财政赤字削减计划没有完成,税务裁减也只能延期2个月。这个表面斗争的背后是来自金融财团的大力支持。民主党激进地推出了富人加税,加强银行监管,减少了银行业的利润。金融集团对此非常不满,转而大力支持共和党。共和党积极出面,打击奥巴马的主张,削减他可以动用的资金,使得经济迟迟不能逆转,民众对于民主党政府也越来越不满意。面临2012年的总统大选,他不得不从激进的立场上往后退,回到比较中立温和的立场。为了刺激经济,他只能转向实力雄厚的银行财团,寻求他们的帮助,只有这样,才有机会赢得再次当选。当然,银行财团也会提出他们的要求,诸如取消过于严格的监管措施,就房贷问题和各大银行达成妥协,等等。目前这个斗争在短期内大概还不会结束。 | |
WeConnect PhotoBox --Connect your friends via Photos!
作者 陈怀临 | 2011-12-18 10:28 | 类型 行业动感 | 42条用户评论 »
|
这年头啥是平台?已经是平台的才是和就是平台[有点哲理,大家不要被忽悠了]。 Facebook就是平台。是平台的才是平台。否则是意淫。。。 如何把Killer应用和事实上的平台结合在一起???? WeaverMobile隆重推出: WeConnect PhotoBox!!!!! “Connect Friends via Photos” 几个亮点如下: 1。 方便的,完整的看自己和所有朋友在Facebook上的照片集 2。 可以批量上载你在旅游,[各种]派对,家庭聚会,同学聚会的照片。速度惊人 3。 可以批量下载存档自己和朋友在Facebook上的照片 4。 可以非常方便的repost照片,like it和各种操作! 5。 性能全面超过Facebook app和其他相关app!特别是批量photo的操作! 下载地址: App Store: http://itunes.apple.com/us/app/weconnect-photobox/id487803225?mt=8 Or Search “WeConnect PhotoBox” from App Store in your iPhone/iPad | |
山石网科 。苏州 。研发基地
作者 陈怀临 | 2011-12-14 18:58 | 类型 行业动感 | 16条用户评论 »
清华创业集中营 。北极光 。邓锋 。谈创业
作者 陈怀临 | 2011-12-14 16:51 | 类型 行业动感 | 2条用户评论 »
《给力吧,x86》专题连载九:英特尔Sandy Bridge平台网络通信性能测试分析
作者 老韩 | 2011-12-14 11:07 | 类型 研发动态, 科技普及, 网络安全, 行业动感, 通讯产品 | 56条用户评论 »
《给力吧,x86》专题连载八:英特尔5520平台网络通信性能测试分析(下)
作者 老韩 | 2011-12-12 17:16 | 类型 研发动态, 科技普及, 网络安全, 行业动感, 通讯产品 | 26条用户评论 »
|
上一期连载内容中(见本报今年34期第28、29版),我们介绍了上海交通大学网络信息中心的老师们在流量分析与优化系统选型中面临的问题。那么,x86平台在万兆环境下能否稳定工作?现有平台的性能是否又能满足需求?针对种种疑虑,老师们对送测产品进行了长期、细致的测试验证工作。
性能初测通过 在吞吐量测试中,老师们只选择了64Byte和512Byte两种比较具有代表性的帧长。前者是对设备极限性能的考验,现网中绝少出现(个别DDoS攻击会在短时间内产生大量小包,对工作在4层以上的设备造成很大压力);后者则比较接近现网中的平均包长(600-700Byte),测试结果具有比较强的参考价值。考虑到个别设备会在超过极限处理能力后性能大幅下降,丢包率远远超过理论值(通常丢包数量应等于测试流量减去极限处理能力),有着资深运维经验的老师们还特别考察了Panabit在过载时的性能表现。
表注:吞吐量、丢包率测试结果(4层,数据包有IP头/协议类型UDP) 从结果中可以看出,面对一系列苛刻的测试条件,由顶级英特尔5520平台所承载的Panabit应用层流量分析与优化系统还是表现出了不错的性能。在使用64Byte帧进行测试时,系统整体吞吐量达到20%,整体包转发速率为5.96Mpps;当使用512Byte帧时,系统整体吞吐量达到64%,整体包转发速率为3Mpps。测试结束后在Panabit提供的统计信息中可以看到,所有流量也被顺利识别为未知协议。而在使用略高于两个极限值的测试流量进行过载测试时,测试仪统计得到的丢包率也在预定范围内,系统整体运行稳定。
表注:吞吐量、丢包率测试结果(3层,数据包有IP头/协议类型None) 瓶颈究竟出现在哪个环节?是转发层面还是业务层面?老师们利用之前的环境,使用另一组测试用例进行了验证。这次测试仪发出的流量将不包含UDP头部,仅为带有IP头的3层报文。根据Panabit应用层流量分析与优化系统公布的运行逻辑,这样的流量从负责数据转发(I/O)的内核提交到做状态检测与应用协议识别控制的内核后,将只进行连接层面的处理,业务逻辑基本等同于工作在桥模式下的状态检测防火墙。在抛开繁重的应用协议识别的包袱后,系统的整体处理能力是否会有一个飞跃呢?测试得到的结果令人感到意外,当使用64Byte帧进行测试时,整机吞吐量仅比之前高出4个百分点;而当使用512Byte帧测试时,吞吐量没有发生任何变化。虽然目前无法判断状态检测引擎是不是瓶颈所在,但基本可以判定应用协议的识别控制并不是系统整体的瓶颈,x86处理器在计算能力方面的优势还是值得肯定的。而这一阶段的测试数据也让老师们相信,Panabit应用层流量分析与优化系统对于上海交通大学校园网目前的运行情况来说,也是能堪大任的。 5520平台深度分析 在征得老师们的许可后,我们在同样环境下使用久经考验的评估利器NCPBench 0.8进行了测试,得到了可以用做纵向对比的数据。在这个环节中,服务器上的两个万兆接口和每两个相邻的千兆接口被配置为网桥,在纯转发与简单业务两种模式下使用64Byte帧进行测试(NCPBench的功能介绍和使用方法见本报今年第16/17期51版)。
表注:NCPBench吞吐量测试结果 我们又得到了两组几乎一致的数据,无论是纯转发模式还是简单业务模式下,被测平台的吞吐量均为39.163%,包转发速率则接近14Mpps。还有一处值得注意:两种模式下,4个千兆接口间均能达到线速转发,两个万兆接口间则只能达到单向4Mpps、双向共8Mpps的转发速率。我们非常关注前者会对后者造成多大的影响,所以在最后单独对两个万兆接口进行了纯转发测试。此次得到的数据是单向5.12Mpps、双向共10.24Mpps,较之前有所上升,但与整机处理能力仍有不小的差距。需要说明的是,NCPBench允许测试者自行设定要使用处理器内核的数量,上述数据是在使用两个核情况下的测试结果。我们也尝试使用更多的内核数进行了测试,得到的数据基本相同,个别情况下还会略低。 这是个很有意思的现象,对瓶颈定位有着很大帮助。与Panabit“特定内核处理特定业务”的逻辑不同,NCPBench的业务模型采用SMP模式构建,每个内核都进行数据包转发与业务处理操作。理论上如果每个核都达到满负荷工作状态,纯转发模式时的性能会高于简单业务模式。所以我们从测试结果中只能得到这样的结论,即无论在哪种工作模式下,处理器内核的利用率都没有达到极限,即便只使用两个内核时也是如此。 在长期的测试工作中,处理器资源耗尽通常是系统整体瓶颈的惟一原因,而这种“喂不饱”处理器的情况,还是第一次出现。我们也曾怀疑性能瓶颈可能来自于NCPBench自带的网卡驱动,但在稍后进行的对英特尔Sandy Bridge平台的测试中,同样的驱动在一块同样基于英特尔82599EB网络控制器的网卡上带来了28Mpps的纯转发能力。所以,我们只能做出最遗憾的推测,即戴尔PowerEdge R710服务器的某个部分也许存在I/O方面的设计瓶颈。之所以不怀疑5520平台,是因为我们在另一个测试中,在一台采用E5550/4GB/82599EB配置的网络通信硬件平台上得到了两口间16Mpps、4口间超过22Mpps的测试数据。这也与我们经验中侧重于计算的服务器平台,在I/O方面逊于专注于通信业务的网络通信硬件平台的认识相吻合。 其实,即便是同样类型、同样配置的设备,在承载网络通信、安全这种时延敏感型业务时的表现也可能存在很大差异。在之前我们进行的基于Atom D525平台的评测过程中,就出现过来自不同厂商的配置完全一样的产品性能差异达40%的情况。我们无法对此做出更准确的解释,只能提醒广大用户和各厂商负责供应链的人员,在选型时一定要做更加细致的测试工作。 识别准确 稳定可靠 经过一系列测试,由英特尔5520平台承载的Panabit应用层流量分析与优化系统表现出了不错的性能水准,受到上海交通大学网络信息中心老师们的普遍认可。实际上,老师们对该系统在应用协议识别率及稳定性方面的测试早在去年底就已开始,他们使用另一台基于英特尔至强E5620处理器的服务器搭载Panabit,以旁路模式对两个万兆接口镜像而来的所有IPv4出口链路的上、下行流量进行了长期的监控分析。从老师们提供的统计资料中可以看出,未知协议所占流量在累计数据中所占的比重为2.8%,在10分钟统计数据中的所占比例也仅为3%,识别率堪称优秀。而在稳定性方面,资料显示该系统已连续运行超过168天,老师们也坦言没有出现过任何异常,只是在系统更新等人为操作时才会重启。 出于更加稳妥的考虑,老师们还是决定进行更长时间的旁路测试后,再讨论将其部署到网络边界。不过我们认为,在如此复杂的应用场景下长期稳定运行的事实,至少可以适当修正那些“x86架构产品稳定性不如专用系统”的论调。如果决定接入,硬件设备还要在可靠性方面满足更多的要求。例如现在工作在旁路模式下,可以不考虑接口的硬件Bypass,但当接入现网环境时,硬件Bypass特性就成为一条底线。服务器搭配多网卡的方式显然不能满足这一需求,我们建议老师们辅以专用的硬件Bypass设备,或直接选购支持该特性的x86网络通信硬件平台。 站在科研的角度,网络信息中心的老师们还提出了一些颇具价值的建议。例如针对前景被广为看好的OpenFlow,老师们建议Panabit增加在协议识别后输出Syslog信息的能力。这样一来,该系统就可以直接部署在一些基于OpenFlow搭建的网络环境中,为控制器提供基于应用层协议的策略配置能力。网络设备在并发连接方面的限制如今也需要突破,像本次测试版本中限定的600万并发连接数,仅用两台高性能服务器做端口扫描(模拟DDoS攻击)就可以打满,此时协议的正常识别就会受到影响。毫无疑问,这些来自科研领域兼一线用户的真知灼见,对产品的完善提高有着宝贵的指导意义。 测试后记 本次测试时间久、项目多,我们认为其中最有价值的内容当属老师们使用的测试方法。被测设备两端模拟大量MAC及IP地址后随机发送流量,可以快速制造出大量的新建连接和并发连接,对一切基于状态检测机制的设备造成较大的压力。即便是传统防火墙,也可能在连接的建立和拆除过程中遭遇性能瓶颈,其直接表现就是系统假死机(CPU占用率100%导致失去响应)或真死机/重启(如果系统架构有缺陷的话)。当连接信息足够多时,CPU在处理中也不得不频繁更新Cache中的数据,会对性能造成非常大的影响,许多高端x86架构产品选择Cache较大的至强处理器就是为了规避这一瓶颈。此外,如果使用比较少的流进行测试,业务处理时通常会走快速路径,而随机多流测试可以更好地模拟现网模型,充分评估设备处理慢速路径时的性能。根据我们以往的测试经验,不少安全设备在这种测试环境下性能会有数量级上的下降。 另一方面,我们在之前的下一代防火墙专题中曾经讨论过,使用UDP数据包进行吞吐量测试,不太适合于IPS、WAF等设备的评估,却很容易对流控、上网行为管理等一切基于应用层协议识别技术的设备造成极大的压力。因为目前来看,对UDP包的检测通常是应用协议识别引擎中的最长路径,而测试时构造出的UDP包又必然会被判断为未知协议类型,后继流量没有快速路径可走,设备应对其进行逐包分析。这一环节对硬件处理能力的需求,理论上远远超过状态检测,所以用户即便没有很强悍的测试仪表,也可以通过高性能PC/服务器加发包软件的方式自行测试。惟一需要注意的,是一定要在测试前验证协议识别的效果,保证协议识别引擎处于正常工作的状态。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
《给力吧,x86》专题连载七:英特尔5520平台网络通信性能测试分析(上)
作者 老韩 | 2011-12-12 17:16 | 类型 研发动态, 科技普及, 网络安全, 行业动感, 通讯产品 | 1条用户评论 »
|
在之前两期连载内容中(见本报今年第21期、29期),我们分别测试分析了目前英特尔面向中低端网络通信市场推出的G41、D525嵌入式解决方案。它们已经被证明在目标市场中有很强的竞争力,被不少通信、安全厂商所使用。但在数据中心、骨干网等万兆网络环境中,x86平台的效能与稳定性仍然有待验证。本期我们就与上海交通大学的老师们一起,对英特尔5520平台在万兆环境下的应用效果进行一次测试分析。
做为中国教育和科研计算机网络(Cernet)华东南地区网、上海教育与科研计算机网(Shernet)和校园网(SJTUnet)的建设、管理单位,上海交通大学网络中心拥有很强的科研实力,长期担负着三大网络运营维护的艰巨任务。在此过程中,该中心充分发挥科研能力上的优势,独立自主地解决了许多难度较大的运维问题。我们在连载中就曾经提到,该校两年前在对校园网出口入侵检测系统的选型中,遇到了市售产品难以满足需求的窘况。在充分分析了业务需求的前提下,网络中心的老师选择了带领团队自行研发的方式,以多组x86服务器分布式处理的方式实现了对万兆链路的实时监测。这样的方式,不仅构建了一个开放的、可以承载多业务的科研平台,更将科研成果转化为实际的安全服务,为校园网的稳定运行提供了保障。 虽然上海交通大学校园网目前拥有多条出口链路、总计超过10Gbps的带宽,但在愈发丰富、模式愈发复杂的网络应用面前,也不是永不拥塞的高速路。目前,流量的可视化与可控性已成为网络中心老师们重点关注的问题,他们需要一个强大的应用流量分析管理系统,为运营维护乃至下一步网络建设规划提供准确的参考依据。经过细致地评估,老师们初步选定了连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统。不过,与大多数同级别通信、安全产品不同,该系统运行在x86而非MultiCore-MIPS或NP平台上,而老师们(或者说是大多数人)对于x86平台在万兆环境中稳定工作都没有太多信心。 来吧,就让测试去证明一切。 规格全面提升的5520平台 上海交通大学网络中心的老师们为这次测试准备了一台戴尔PowerEdge R710服务器,它是戴尔为第一代Nehalem-EP处理器平台及其后续Westmere-EP处理器平台设计的2U机架式产品。PowerEdge R710基于英特尔5520 IOH芯片(代号Tylersburg-36D)设计,提供了36个PCIe 2.0信道,最多支持两颗英特尔Xeon 5500/5600系列处理器,可以搭配英特尔ICH9或者ICH10使用。在英特尔尚未明确推出Sandy Bridge嵌入式解决方案的今天,基于5520芯片组的产品仍然是目前设备制造商与用户能够获取到的最高端x86平台。 得益于戴尔灵活的定制化销售模式,测试使用的这台PowerEdge R710配置了一颗英特尔Xeon X5690处理器。它支持SMT超线程技术(测试中关闭),具有6个核心、12个硬件线程,主频达到3.46GHz,最大的Turbo Boost频率高达3.73GHz,属于英特尔32nm Westmere-EP处理器家族中的最高端产品。这颗处理器中的每个核心都具有32KB的L1指令缓存和L1数据缓存及256KB的L2缓存,所有核心共享12MB的L3缓存。此外,Xeon X5690还通过两个6.4GT/s的QPI总线和另一颗处理器以5520/5500 IOH芯片通信,QPI总线为一个双向的并行总线,在X5690上,单向带宽为12.8GB/s。 由于集成了较高规格的内存控制器,单颗Xeon X5690可以支持3通道R-ECC DDR3内存,每通道又支持最多3个R-ECC DIMM。在使用能够支持的最高规格的16GB内存条的时候,每颗处理器可拥有144GB的总内存容量,整个系统(双路配置)则可达到288GB的最大容量。X5690支持的最大内存频率规格为DDR3-1333,不过当所有DIMM插槽都插满内存的时候,运行频率将会降低至1066。而本次测试使用的这台PowerEdge R710服务器配置了3条4GB容量的内存,运行在3通道模式。
与时俱进的网络子系统 和桌面级与嵌入式产品不同,在服务器上,所有的高速设备都直接连接到IOH芯片上,而不是相对低速的ICH芯片,理论上减少了性能瓶颈。测试使用的PowerEdge R710服务器上提供了1条PCIe v2.0 x16插槽和两条PCIe v2.0 x4插槽,分别连接到3组顶级网络控制器。其中一组是一块基于英特尔82599EB芯片的英特尔X520双口万兆网卡,另两组是基于英特尔82576EB芯片的双口千兆网卡,一共提供了两个万兆接口和4个千兆接口。实际上,戴尔PowerEdge R710还板载了4个基于Broadcom网络控制器的千兆接口,但在测试中并未用做业务处理。 英特尔X520双口万兆网卡使用的82599EB是一个强大的网络控制器,是目前英特尔在万兆级产品中最顶级的型号。该芯片原生两个万兆接口,每个接口都可以支持128个TX/RX队列,并可以根据情况最多划分为64个RSS(Receive Side Scaling,接收方扩展)队列。此外,82599EB还支持MSI和MSI-X(Extended Message Signaled Interrupt,扩展消息告知中断)特性和一些与数据中心应用密切相关的高级功能。由于万兆环境下的数据传输需要巨大的带宽,82599EB推荐使用PCIe v2.0 x8或以上规格接口进行连接,否则可能会出现瓶颈。 英特尔82576EB也是比较强大的网络控制器,使用PCIe v2.0 x4接口进行连接,是82580出现前千兆级产品中的顶级型号。该芯片原生两个千兆接口,每个接口支持16个TX/RX队列,最多可划分16个RSS队列。和82599EB一样,82576EB也支持MSI和MSI-X,并支持VMDq、VMDc等虚拟化功能。在与英特尔服务器级Tylersburg IOH芯片搭配时,82576EB和82599EB可以通过I/O AT技术加速其DMA的传输性能。 | |




(2个打分, 平均:3.50 / 5)








