福建星网锐捷网络有限公司评论(怎么样)

呵呵,lz很多被成研开除的人,我来锐捷一年对,感觉很不错,没有上面所说的那样.见仁见智.

下面是2007年底锐捷设备在中山大学出现全网严重故障后，市场支持撰写的总结，从中可以看出来，锐捷设备质量很差，也可以看出来，锐捷的设备基本上是作坊式研发和生产，

锐捷网络中山大学故障支持总结
这次中山大学的支持，前后有将近一个月的时间，看到了中大的网络从不稳定到逐步稳定的过程，对我们产品在外面的应用和我们产品的质量也有了一定的了解，也感觉到实际应用环境中对产品质量的苛刻要求。
中大网络各种问题的爆发有各方面的原因，除了我们产品软件本身的问题，还和学校的网络规划，我们的前期方案，客支的后期部署都有关系。
首先，学校的拓扑是86底下直接接二层设备，网关大部分在86上，86做为一个大汇聚使用，底下接几千(5K以上)用户，在这样的拓扑环境下，86很容易受到攻击，而且只要有一个网段有攻击导致86的cpu高，86底下的所有用户都会受到影响，这也是前期arp攻击的情况下，到处都有用户报断网，这头解决了，那边又冒问题，导致处理时很被动，同时效率很低的原因；如果前期方案能将三层下放，把86解放出来，86稳定的话，出问题的只是一两栋楼，定位和解决都会容易的多。更重要的是，前期方案确定后，拓扑基本上就确定了，后面出问题要调整拓扑是比较难的，而通过调整配置大多数情况下只能规避问题，而很难从根本上解决问题，只是治标不能治本，为后面留下隐患；现在中大的网络虽然基本稳定，但是如果有arp攻击的话，cpu还是会到70%左右，虽然不影响单播的转发，但是总给人不放心的感觉，后面上其他功能时，比如组播，会有很大的隐患。因此，我们的前期方案应该有更严格的审核，避免后期出问题时很被动。
客支在部署时的一些不当的地方，也是原因之一。比如版本的升级有遗漏，某些配置不当导致s21受攻击。特别是vlan的配置没有进行裁剪，所有设备上连口都是trunk口，包含所有vlan，导致arp攻击时，攻击报文泛滥到所有设备，只要有一两个攻击用户，所有设备的cpu都被砸高，整个网络不稳定。由于客支的工作比较杂，负责的产品很多，要求对所有产品，特别是新产品的特性都很熟悉不现实，而且我们的配置指南写的比较差，对新产品，最好先设计几套推荐的方案，有一些指导性的配置，经过测试组测试基本没太大问题，再推出去，会减少很多问题。

再有就是也是最重要的，是我们的产品质量有很大的问题。中大这次出了很多问题：
 86，37的软件转发
 86的ip地址冲突导致用户无法上网
 86的短帧计数不正确
 57认证死循环，用配置规避无效
 37软件快转，升级时千兆口无法up
 s21 arp check没有打开，cpu高
 s21 reload不成功
 s21认证用户超过容量时，ffp表项乱了
 s21的ip授权打开时，acl无法使用
 s86, s57,s37 arp unresolve显示
 多播断流，多播造成ospf邻居down
 ...
86， 57，37，21全线产品都有问题，而且很多产品不只一个问题，不断的问题不仅使老师对我们产品印象很差，到后期，只要网络有问题，不管是否我们产品的问题，老师都是先怀疑我们，虽然后面查出来很多都不是我们的问题，有很多原来可以解释的问题，老师也不相信，工作上很被动；再有就是我们自己对产品的信心也受到打击。总之，问题多多，产品质量还有很高的提升空间。在外面体会了一下市场的应用，对比一下自己以前的想法，发现有很大的反差，也感觉到了我们开发中的一些问题，个人看法，总结如下：
 开发时间比较紧，测试不够充分或者不够全面：比如上面86软件转发这么严重的问题不应该漏过去的
 开发时程序健壮性，性能要求和安全性考虑不够：
对实际环境的各种“异常”情况考虑不足，对各种攻击没有相应的处理机制。比如57认证死循环的bug，没有考虑非ruijie认证客户端的情况；又比如对 arp报文的处理，所有arp报文送cpu且转发，acl也deny不掉，arp攻击时，没有防范的机制，只能看着，基本上没有什么好的办法。
这次出去有一点比较大的感触就是，原来认为一些细节的东西无所谓，cpu高一点无所谓，实际上对交换机特别是86这种核心交换机来说，不管什么样的问题，只要有可能造成网络中断，不管是那个模块，哪一行代码，效果都是一样的，这和经常提到的最短板的理论一样，只要存在哪怕一小点漏洞，在实际复杂的应用环境中，基本上是在劫难逃。
开发时程序健壮性和安全性考虑不够的原因一个是开发人员的水平和经验不够，缺乏网络实际应用的经验，有很多问题考虑不到，这个只能靠积累；还有就是主观上质量意识不够强，认为有的细节处理太繁琐，就忽略过去，而很多时候恰恰是这些细节导致的问题，这个方面是我们可以去加强和改进的地方。
 开发时对性能要求考虑不够：原来系统测试中有很多的性能bug，比如cpu高导致的vrrp振荡，ospf邻居down掉，线卡cpu被报文砸傻导致控制台挂起等，这些bug原来的处理一般都是delay，或者把网线拔掉能恢复就可以。但是在实际的应用环境中这些基本上意味着断网，这个效果和死机差别不大，而且这些问题有些在受攻击的情况下还是比较容易出现的，如果不解决的话，存在很大的隐患。比如这次的多播造成ospf邻居down掉。
 开发时对细节不够重视：比如arp unresolve显示不正确，86的短帧计数不正确，show int 中Storm control写成Strom control，这些问题虽然看起来问题很小，不会对使用造成影响，但会使客户产生不好的印象，对我们的专业水准产生怀疑。
 开发时一些功能模块的开发缺少规划：通常很多新功能都是产品线临时提需求，研发出临时版本，在比较短的时间内开发，然后在下一个正式版本中根据临时版本的做法加入新功能。这种开发方法虽然能很快的满足市场的需求，但是由于临时版本时间上很紧，有很多考虑不周全的做法，而且只适用于特定的场合，造成小功能很多，而且功能模块间关系比较复杂，通用性不强。比如我们限制的安全功能做了很多：acl，ip+mac绑定，端口安全，dot1x，安全通道，gsn， dhcp的绑定，dhcp的全局策略等等；这些功能很多功能类似，相互间优先级比较混乱，同时应用时可能会存在各种问题，比如很多应用都有deny功能，会影响到其他模块。而我们现在的开发中跨模块的协调很难，缺少统一的规划，很容易新模块的引入引起很多新的问题。比如上面s21的ip授权打开时，acl 无法使用的问题。
 开发人员的水平问题：开发人员很多都是3年以下的员工，水平和经验有限，个人觉得有几个比较欠缺的方面（1）大多维护一小部分模块，对涉及到其他模块的问题比较模糊（2）对实际应用缺乏了解，和外面交流很少，对其他厂商的了解也很少，很多情况下都处于闭门造车的状态（3）大部分时间在做项目，积累比较少。实际结果是我们可能对芯片交换机比较了解，但是却不懂网络；可能会查bug，对网络本身的建构和优化所知甚少。这样的情况下，要开发出高质量的产品难度不小。

为成研院朋友的安危担心。有人知道成研院现在震区的安全情况么？

打倒銳捷！！！

楼上的，
这个已经不是什么人品问题了，
这个是人性尚存的问题。

人品有问题，前提是这个人做事还像是人做的事情。

而现在看来，为了所谓的公司文化（加班）；为了满足自己的兽欲（不管怎么，上班/加班时间只能多，不能少）；为了在上头那里挣一些可怜的表现，他们抛弃了仅存的那一点人性，逆着历史的水流，向兽性迈出了一步又一步。

廖永、小波，他们俩真的非常的不幸，遭遇了飞来横祸。然而，这不是最不幸的，这两位兄弟遭天灾后，在被那些人口中的，所谓的员工快乐生活的家园的公司里，没有得到关怀，没有得到帮助，甚至没有得到慰问。他们得到的只是抛弃，和更凶残的压榨，……。

用鲁迅先生的话来形容就是，我觉得我所处的是非人类的世界。


锐捷，你叫我们拿什么来爱你？